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