各种界面开发工具 MFC,WTL,QT，wxWidget,GTK+

界面库名称

接口设计

界面编辑器

高级布局功能

平面绘制

平台兼容性

语言支持

IDE兼容性

视图-模型分离机制

运行时

其它

Windows Forms

接口优秀。C++下使用CLI扩展，其它语言为原生支持。

界面编辑器完整，包括布局、属性、消息关联的完整设置。不可预览。

Table Layout，Splitter Layout，Flow Layout等，Anchor和Dock机制。多分辨率界面下表现良好。

GDI+，面向对象的2D绘制接口，使用简便。

需要.Net平台支持。WIndows或Linux（Mono，非官方支持），支持Windows CE

C++/CLI, 支持.net的语言。

仅VS。

布局和视图方案建立在代码中。部分组件支持Model-View架构。

需要部署对应的.net

商业协议

MFC

基于宏和虚函数，使用特殊格式注释，使用自定义的RTTI系统。类接口设计优良。通过回调函数和虚继承重载调用客户代码。

基于资源编辑器，仅能对空间基本布局和少量属性进行调整。不可预览。

缺乏高级布局功能，多分辨率需要是手工或程序中调整。

GDI及GDI封装，可选GDI+

Windows，Windows CE

C++ Only，
支持COM时可以实现Binary级别复用。

仅Visual Studio

使用资源保存控件的基本控件布局，提供Doc-View机制和控件数据交换支持视图分离。

需要部署MFC运行时库。

商业协议

WTL

基于模板和虚函数。类接口类似于MFC。需要使用多重继承。通过模板特化和回调函数与客户代码交互。

同MFC

同MFC

同MFC

同MFC

同MFC，对COM的支持比MFC完善很多。

Visual Studio，Windows下支持标准的C++编译器。

使用资源文件保存空间布局。

无

自由协议

wxWidget

宏，自定义RTTI。使用回调函数与用户代码交互。

无官方界面编辑器。可使用第三方界面编辑器。部分编辑器具有完整的所见即所得功能，且具有预览能力。

使用Sizer实现多分辨率的布局。功能偏弱。

wxDC等。

Windows，Linux，Unix，MacOS等

C++, .NET, Python,
Lua,
Ruby等

良好的编译器兼容性，缺乏IDE继承。

可以将界面属性生成到代码中，也可以使用XML格式保存。

wx的动态链接库或静态链接。

自由协议

Qt

使用宏和自定义的RTTI。使用Singal-Slot机制实现用户代码交互。可通过继承实现扩展。

Qt Designer，具备完整的所见即所得编辑功能。可预览界面。

具备完整的布局功能。多分辨率/多平台下表现良好。

QCanvas等。

Windows，Linux，Unix，MacOS等。

C++，Python等

可集成到Eclipse和VS

使用资源文件保存界面信息。部分组件具备Model-View-Delegate架构

qt的动态链接库。

开源协议+商业协议

GTK+

使用signal-slot机制完成用户代码交互。

GLADE，具备所见即所得的界面编辑功能

Layout Containers，具备较完整的布局能力。

GTK Graphics Context

Windows，Linux，Unix，MacOS等。

C，C++，Python，.NET等。

（暂时未知）

使用代码完成界面设置。部分组件具备Model-View架构。

GTK Runtime

开源协议

此外，除了WTL外，其余各界面库均有完整及时的文档和手册，因此比较项中不再指明。

回帖中有人指出国际化问题的比较，事实上MS的产品和开源对于国际化的解决方法是不同的。但是都可以比较方便的解决国际化问题。

 

Nokia 最近推了 Qt Creator，是较好的IDE环境 

wxwidget做简单的还可以, 做复杂的界面,嘿嘿,那就麻烦了. win下还是MFC最爽

wxWidgets的代码质量不是很高，有一些比较初级的bug。我用过一段时间的wxWidgets，自己测试没问题，但是用户总会发回一些crash report。
另外，wxWidgets和Qt除了对于一些常见应用，比如窗口、DC的封装之外，还提供了很多系统接口的封装，比如clipboard, thread, socket等。
Qt有Qt Creator作为IDE，工程项目文件可以跨平台，另外，工程文件也可以用qmake转成平台无关的makefile。

 

GTK+, Qt, wxWidgets 比较简评

//这位台湾的高手把GTK+, Qt, wxWidgets比较分析得相当到位。明显，MFC注定将淡出江湖了。

[心得] 知名 GUI lib 简评 (GTK+, Qt, wxWidgets)
之前因为把 MFC 痛骂了一顿，有网友在询问其他 GUI toolkit, 所以小弟分享一下个人对三大知名图形介面 library 的简短评论纯属个人主观意见，不是业界人士，所知有限，望先进前辈不吝指正或补充

先讲 GTK+

GTK+ 主要用在 X Window 上，整个设计的架构和许多概念和 MFC 以及一般 Windows 上的程式开发大异其趣，入门门槛较高，而且最主要的特色是，他用不具有物件功能的纯”C” 语言，模拟物件导向。 所以写起来比较复杂艰涩，而且充满大量巨集，使用和除错都不是很容易，但优点则是可以用 C，不需 C++，如果和 Win32 SDK 比较，不会难学多少，缺点是不易上手使用，而且文件比较缺，架构又非常复杂，且提供的东西比起其他无所不包的 library，是简陋了一点，函数命名又臭又长。 对於简单的程式，GTK+ 会显得太复杂，但是当你开始想扩充其他 library 也都没提供的进阶功能，就会开始赞叹GTK+ 的架构严谨，还有超乎想像的高度弹性。 同样的东西要用 MFC 来做反而会要人命, 并且多国语言的支援良好，内部也全面使用 UTF-8，相容性好，又是 unicode能够习惯的话，GTK+ 值得推荐，但没有很建议学，毕竟不好学，要用到熟会需要比较久，而且那样很多 C++ 的功能会用不到。 GTK+ 有 C++ 版本叫做 GTK–，没用过. 但看文件觉得，并没有比 gtk+ 简单到哪里去。 因为 gtk+ 本来就是物件导向，所以即使换了 c++ 语言，写起来架构还是差不多的。 另外，gtk+ 有 Windows 版本，但缺点是，执行缓慢，不稳定，而且介面是使用 gtk+ 自己的，不是使用 Windows 内建的”Native” 原生图形介面，看起来会不太习惯。 Mac OS X 下可用 X11 来执行 gtk+但那样出来的程式是长得像 UNIX 程式，而不是美美的 OS X Aqua 外观.

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。

Qt 的功能，应该是这三者加上 MFC 之中最强大的，文件也很完整，又有 RAD 工具
可以辅助开发，并且有商业公司做强力后盾。不但有 Windows/X Window/Mac 版本，甚至还有嵌入式系统可用的版本，稳定性还不错，物件封装也算良好，资源比 GTK+ 或wxWidgets 多得非常多，而且发行公司提供了相当多范例，算是一家以开放原始码成功营利的模范公司。 知名的 KDE 整个是用他开发，证明了他的稳定性和强大功能。缺点是如果你用他开发非 GPL 开放程式码的软体，必须以极昂贵的金额，购买商业版本。 而他的图形介面并不完全是 “Native GUI”，只是透过 theme 去模拟系统上的标准 GUI，所以看起来很像，却会有些地方可以明显看出破绽。 执行速度缓慢还有过於庞大则是另一个问题。 虽然封装得很良好文件也齐全，并不代表他就很容易学还有一个严重问题是，他写的不是标准 C++，他使用的 signal/slot 机制必须透过 Qt提供的 preprocessor 处理过才可以转送给编译器，这部份可能被限定用 qmake，算是一个可惜的地方，不过瑕不掩瑜，还是很推荐。忘了说，他内部也是 unicode，多国语言没问题。

以上三套只是简单介绍，其中 Qt 的程式我没有实际完整开发过，但明显的三套都远远比只能在 Windows 上用，功能少 Bug 多难学难用几乎无多国语言支援的 MFC 要强。
三套可跨平台的 library 大家可自行选择，只能用在 Windows 的 MFC 就不用考虑了