图形界面库Windows Forms、 MFC、WTL等综合比较
图形界面库Windows Forms、 MFC、WTL、 WxWidgets、Qt、GTK 综合比较见
操作方法
- 01
图形界面库Windows Forms、 MFC、WTL、 WxWidgets、Qt、GTK 综合比较见下表：
- 02
GTK+主要用在X Window上，整个设计的架构和许多概念和MFC以及一般 Windows 上的程序开发大异其趣，入门门槛较高，而且最主要的特色是，它用不具有物件功能的纯C 语言，模拟物件导向。所以写起来比较复杂艰涩，而且充满大量巨集，使用和除错都不是很容易，但优点则是可以用C，不需C++，如果和Win32 SDK比较，不会难学多少，缺点是不易上手使用，而且文件比较缺，架构又非常复杂，且提供的东西比起其它无所不包的 library，是简陋了一点，函数命名又臭又长。
- 03
对于简单的程序，GTK+会显得太复杂，但是当你开始想扩充其它library也都没提供的进阶功能，就会开始赞叹GTK+ 的架构严谨，还有超乎想像的高度弹性。同样的东西要用 MFC来做反而会要人命，并且多国语言的支持良好，内部也全面使用UTF-8，相容性好，要是unicode能够习惯的话，GTK+值得推荐，但不建议 学，毕竟不好学，要用到熟会需要比较久，而且那样很多C++的功能会用不到。GTK+有C++版本叫做GTK–，没用过但看文件觉得，并没有比gtk+简 单到哪里去。 因为 gtk+本来就是物件导向，所以即使换了c++ 语言，写起来架构还是差不多的。
- 04
另外，gtk+有Windows 版本，但缺点是，执行缓慢，不稳定，而且介面是使用gtk+自己的，不是使用 Windows 内建的Native原生图形介面，看起来会不太习惯。 Mac OS X 下可用 X11 来执行gtk+，但那样出来的程式是长得像 UNIX 程序，而不是美美的OS X Aqua外观。
- 05
wxWidgets和MFC最接近，已有十余年历史，命名习惯或架构都高度相似，会MFC几乎不用重新学习。此外，它的物件封装比MFC要好，提供 的功能也多上太多，又跨平台。一般知名的MFC程式都会选择用wxWidgets改写，来快速移植原程式到其它平台，例如 eMule用wxWidgets移植出aMule，xMule， 还有在开发中的Filezilla 3…等。而它最主要的特色是，它是跨平台的Native GUI toolkit，在各种平台上都可写出使用该平台内建Native原生图形介面的程式。在Windows 上就长得跟其它Windows程式一样，在 Linux 下就使用 gtk+的图形介面，在 Mac OS X 下就可以使用华丽的Aqua 外观风格，这点是非常强悍。 不像gtk+到其它系统都还是只能用gtk+自己，缺点是，中文支持在有些地方会出问题，例如剪贴簿的操作，得自己patch，但仍然相当推荐，即使是个 庞大的library，效能依旧不会太差，尤其在 Windows 上执行速度并不输 MFC，与其学MFC，不如学wxWidgets。
- 06
Qt的功能，应该是这三者加上MFC之中最强大的，文件也很完整，又有 RAD 工具可以辅助开发，并且有商业公司做强力后盾。不但有Windows/X Window/Mac版本，甚至还有嵌入式系统可用的版本，稳定性还不错，物件封装也算良好，资源比 GTK+ 或wxWidgets多得非常多，而且发行公司提供了相当多范例，算是一家以开放原始码成功营利的模范公司。 知名的KDE整个是用它开发，证明了它的稳定性和强大功能。缺点是如果你用它开发非 GPL 开放程序码的软件，必须以极昂贵的金额购买商业版本。而它的图形介面并不完全是 Native GUI，只是透过theme 去模拟系统上的标准 GUI，所以看起来很像，却会有些地方可以明显看出破绽。执行速度缓慢还有过于庞大则是另一个问题。 虽然封装得很好文件也齐全，并不代表它就很容易学。还有一个严重问题是，它写的不是标准C++，它使用的signal/slot机制必须透过Qt提 供的preprocessor，处理过才可以转送给编译器，这部份可能被限定用qmake，算是一个可惜的地方，不过瑕不掩瑜，还是很推荐。忘了说，它内 部也是unicode，多国语言没问题。