wxWidgets、Qt等界面工具比较

本文是在wxWidgets Wiki上面找到的一篇，对比了wxWidgets和其他一些界面工具的特点。看到很多朋友在网上询问这些库各自的特点，我想先把这篇文章翻译出来——毕竟这也算是一篇官方的文章，应该比较有说服力吧！这篇文章写于2004年左右，但是很明显某些地方已经更新了，因为Qt 4.5是2009年才发布的！

这是我第一篇翻译，哪里翻译不好敬请谅解！

原文：http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits

==================================================

首先是关于wxWidgets的一些基础知识：

● wxWidgets不仅仅使用C++，而且能够使用python、perl、java、lua、eiffel、C#(.NET)、basic、ruby，甚至是javascript(见General
Information)（豆子：有些语言连听都没听说过，呵呵）；

● wxWidgets是一个完整的GUI工具库，提供了很多工具类；

● 有很多文档（虽然一些只是文档片段）；

● 免费供个人使用或者商业使用；

● 只要可能，wxWidgets就会使用本地平台的SDK。也就是说，同一段代码，在Windows下编译将具有Windows程序的外观，在Linux下编译将具有Linux程序的外观；

○ 这样做的优点是，wxWidgets程序看上去和本地程序差不多，有时也会有一些本地组件的行为——例如在OS X上所有的文本域(text area)都将获得内建的拼写检查的能力；

○ 这样做的缺点是，wxWidgets程序在不同平台的行为可能会不一致；那些使用轻量级组件的GUI库或许会丢失一些特定平台的特性，但会将平台相关的代码减到最少（因此，这样做也能够将不同平台组件的行为差异降到最小，并且减少了特定平台的bugs）。另外，由于使用本地感官风格，使得wxWidgets不适合于那些希望具有不同于系统界面风格的程序的开发。

下面是wxWidgets与不同的GUI库之间的对比。

Qt

● Qt(http://www.qtsoftware.com/)和wxWidgets一样，也具有很多和GUI构建无关的类，比如日期/时间，容器，网络，OpenGL功能等；

● Qt 4.5 在Windows、Mac和GNU/Linux下具有两个协议：一个是对开源和商业软件的LGPL协议，以及为那些认为从法律角度来说认为LGPL不安全的人们使用的商业协议。而所有的wxWidgets版本则是在经过修改的LGPL协议（这个协议已经通过了OSI的认可）下发布的，允许免费开发和发布所有的应用程序（豆子：所以Qt那个曾经令人颇有微词的许可问题已经不复存在）；

● Qt没有wxWidgets所拥有的真正的本地化界面。我们的意思是，Qt在各个平台上自己绘制组件，使用自己的绘制技术将其模拟得很逼真。虽然Qt在Mac OS X，Windows XP 和 Vista上使用本地API实现组件的界面风格，但是事件处理、结果回调以及组件布局都是由Qt本身实现的；

● wxUniversal的实现同Qt类似；

● 需要注意的是，在KDE和嵌入式Linux平台上，Qt就是本地GUI库；

● Qt被很多大型项目使用，如KDE和Opera浏览器（另一方面，wxWidgets也被用于AOL Communicator之类的项目）；

● Qt极大限度地使用了虚函数（Qt所有组件的基类QWidget包含至少51个虚函数），这比wxWidgets更加面向对象（相比而言，wxWidgets更多的使用了类似于MFC的宏）。这意味着，使用Qt你的代码行数将少一些，但是wxWidgets的执行速度将快一些（这取决于你向谁去问这个问题）；

● Qt被IBM和Borland Kylix（已经停止更新）使用，这意味着更加可靠。但是，有传言说wxWidgets将被应用于下一版本的C++BuilderX；

● Qt在GNU/Linux上一套完整的包含帧缓冲(framebuffer)嵌入式GUI（Qt for Embedded Linux），使得你能够非常容易的使用。这意味着一旦你有了带有/dev/fb的Linux，你就可以在几分钟内准备好。Qt for Embedded Linux 同X11相比只有很小的差别；

● Qt的IDE很多，QtDesigner、QtCreator、QDevelop、Edyuk等，也能够同流行的IDE，如Visual Studio、Eclipse或者XCode，进行整合（wxWidgets也有很多IDE）；

● Qt提供全面的商业支持（其实wxWidget也有提供，见http://www.wxwidgets.org/support/support.htm）；

● 你可以使用基于Qt实现一个wxWidgets，同样，wxWidgets通过使用wxGTK和GTK-Qt也能模拟Qt。

FLTK

● FLTK的网站：http://www.fltk.org/；

● wxWidgets更加面向对象；

● FLTK更加轻量级，而wxWidgets更加全面（wxWidgets支持网络、打印等，而FLTK仅支持少量或不支持这些特性）。参见wxWidgets功能列表(http://www.wxwidgets.org/about/feature2.htm)，FLTK功能列表(http://www.fltk.org/documentation.php/doc-1.1/intro.html#2_2)；

● FLTK实际上有更多细致不同的组件类型，只要比较一下在FLUID和wxDesigner或者DialogEdit中你所能做的就知道了。我曾经尝试将一个FLTK应用程序一直到wxWidgets上，仅模拟那些按钮就花费了相当多的时间；

● FLTK使用的修改后的LGPL协议比wxWidgets的协议更加严格，虽然它也提供了静态链接的不同情况；

● FLTK有一个能够进行GUI设计的IDEFLUID(http://www.fltk.org/documentation.php/doc-1.1/fluid.html)。

FOX

● FOX站点：http://www.fox-toolkit.org/；

● FOX更加轻量级，而wxWidgets则是全功能的；

● wxWidgets有一个完整的API，而FOX仅仅关注于GUI特性；

● 类似于Qt，FOX在每个平台绘制出其组件，而不是使用本地组件；相比之下，wxWidgets使用的是本地API。因此，FOX可能更快一些，但是它提供的界面可能不能很好的融入目标平台（例如，不能应用Windows XP的主题风格）；

● FOX缺少打印支持，但是支持亚洲文字的I18N（它内部使用UTF-8编码）（豆子：这段原句是FOX lacks printing and I18N support for asian language (it's using UTF-8 internally). ，但原文的意思是缺乏I18N的，可后面又说使用UTF-8编码，因此估计是语误。于是到网上查了一下，FOX 1.6版之前是没有I18N的，1.6版才使用UTF-8编码）；

● FOX不支持Windows标准对话框，但有一个替代方案。

Java

● Java是一个能够使用不同GUI库（Swing，AWT，SWT，Qt Jambi，甚至wxWidgets）的编程语言。wxWidget是一个GUI
API，因此二者能够很好的结合；

● Java程序在运行时编译成字节码，这意味着当用户第一次启动程序时，将耗费更长的时间，而程序相应也会比较迟钝（Java的本地编译器GCJ已经可用，但是并不支持Java所有的特性）；

● 另一方面，wxWidgets直接编译成机器码，因此运行很快；

● 没有混淆的Java字节码很容易反编译出来。如果你的应用程序是开源的，这无所谓，但是如果能够查看源代码成为一个问题，那你就得想想办法了（编译成本地代码的wxWidgets程序也能够被反编译，但是这个过程要比反编译Java字节码困难得多）；

● 使用基于Java的应用程序必须安装JVM。近年来，随着JVM的普及，这已经不是大问题，但是，如果用户使用的是旧版本的JVM，则可能会有性能或者安全的问题；

● 鉴于Java库运行较慢，一些Java库是使用的wxWidgets和C++编写的！

● 上述问题的一个例子是wx4j，一个Java的wxWidgets实现。wx4j用wxWidgets绑定Java，可以让Java程序员使用Java语言，但是拥有C++程序的速度；

● 为了实现跨平台，Java组件仅提供了各个平台公共的特性，一些平台相关的特性从Java API中去除了，这些包括Windows的任务栏，Mac OS的菜单栏和Unix的文件属性等；

● 相比而言，如果你仅在一个平台上进行编译，wxWidgets允许你直接使用平台相关的代码代替 ifdef 预编译，并且wxWidgets也有在不同平台模拟的组件，如MDI和树控件；

● Java程序比C++程序占用更多的内存；

● “一次编写，到处运行”依然是一个神话。所有的JVM都含有bugs，并且在一个平台上编写一个“大”的Java程序，让它在另外的平台也能运行，简直是痴心妄想。并不是说这些问题wxWidgets都解决了，只是它的情形并不会更糟；

● wxWidgets在某些方面更完整更直观。对比一下wxString和java.lang.String，留意一下它们的特性和文档质量；

● 一些Java拥护者说下一版本的JVM将会解决很多速度的问题，但是benchmark
tests do not reflect this（豆子：这个对比是2004年的，已经不足为信了，不过，豆子也没有去找更新的资料）。

SDL

● SDL网站：http://www.libsdl.org；

● SDL（Simple DirectMedia Layer）是一个多媒体的C库，适合于游戏以及自定义组件，对于通用GUI组件并不很方便。它由很多SDL_开头的C结构组成；

● 对比一下wxWidgets和SDL：http://code.technoplaza.net/wx-sdl/；

● SDL在LGPL version 2下发行；

● SDL仅允许单窗口运行；

● 极好的OpenGL集成（或者是构建在OpenGL之上的类库，如OpenSceneGraph，CEGUI）。

SFML

● SFML网站：http://sfml.sourceforge.net/index.php；

● SFML（Simple and Fast Multimedia Library）是一个多媒体的C++库，适合于游戏开发以及自定义组件，对于通用GUI元素并不方便；

● SFML包含很多功能：音频、网络、线程等；

● SFML可以结合wxWidgets、Qt或者X11等使用。

Allegro

● Allegro网站：http://alleg.sourceforge.net；

● 类似于SDL，Allegro是一个适用于游戏开发跨平台C库（包含很多后台使用的组件）；

● 几乎和wxWidgets一样古老（大约1993年）；

● Giftware协议（实质上是public domain）；

● 需要使用gcc和一个汇编器构建；

● 在同一版本已经停止开发多年了，缺乏核心开发成员（原来的开发者已经不在开发团队了），存在一些内部的争论者；

● 非常基础的GUI功能，仅仅支持一个仅有边框的窗口——你甚至不能移动这个窗口！

● “控件”仅仅是通过变长参数列表的函数进行支持，像Qt一样自行绘制（默认的并不好看）。可以使用很简单的API进行自定义（有一些子库提供了比较好看的版本的控件）；

● 绘图当然要比wxWidgets快得多，有一个OpenGL层（http://allegrogl.sourceforge.net/）使使用OpenGL进行绘制要比原来容易很多；

● 非GUI部分（输入等）是底层的，通常比wxWidgets的本地实现快一些；

● 能够同wxWidgets共同使用，虽然Allegro有一些平台相关的函数去获取窗口句柄，但你也可以通过这个窗口句柄创建一个wxWidgets窗口，并且用它指向的那个窗口做任何事情。而wxWidgets使用wxApp指向平台相关的main/WinMain stuff。Allegro要求你在main函数之后添加END_OF_MAIN()。这是整合wxWidgets和Allegro的主要要求，但并不是很大的工作量。

==================================================

wxWidgets和QT之间的选择

跨平台的C++ GUI工具库很多，可是应用广泛的也就那么几个，Qt、wxWidgets便是其中的翘楚。

这里把GTK+排除在外，以C实现面向对象，上手相当困难，而且Windows平台下执行相当慢且不稳定。

Qt和wxWidgets各有各的优点，也各有各的缺点，各有各的适合应用点。

工作环境和爱好限制，个人曾经分别使用过Qt和wxWidgets，

到现在，就个人而言，选择在一般程序方向采用wxWidgets，在手机应用程序方向采用Qt。

先说版权：

Qt，是芬兰的TrollTech公司研发的，现在属于Nokia，一直奉行的是双LICENSE策略，一个是商业版，一个是免费版：

商业版的LICENSE就不说了，免费版的LICENSE，4.5版本之前一直采用GPL，意味着采用Qt的程序要么是商业软件，要么就是GPL软件，

这就造成了虽然出了个著名的KDE，可惜应用范围还是受限，否则的话，应用应该更广阔点；

不过还好，Nokia收购了之后意识到这个问题，4.5版本之后采用了LGPL，其他开发人员可以发布基于免费Qt库连接的商业软件了。

wxWidgets，一直奉行的是LGPL LICENSE。

再评评各自的优缺点：

Qt，一直以来开发公司作为商业公司进行运作，以客户需求为目标，提供了一系列完整的文档和RAD工具，并提供最为完整的平台支持；

对开发人员而言，Qt库本身，也是所有的GUI工具库中最为面向对象化的，同时也是最为稳定的。

罗列一下：

Qt的优点：

1. 支持的平台最多

2. 商业化支持

3. 完整的文档和RAD工具

4. 最为面向对象

5. 世界上最为成功的手机厂商支撑，对于移动终端的支持最为完善

Qt的缺点：

1. 使用的是非标准C++

2. 每个平台不是"Native GUI"

3. 过于庞大且运行缓慢

4. 与其它库不是很兼容（主要是STL之类的兼容问题）

5. 基本只能使用特定的qmake工具（其它工具经过良好的修改也可以，不过相当于重新编写一个qmake，是否值得）

wxWidgets，一直以来的LGPL发布，相当开放，积累了相当一部分研究用户，与现有各类工具库无缝连接地非常好；

同时可惜的是没有非常强大的正规商业化运作，可靠性、资源丰富性远比不上Qt。

还是罗列一下：

wxWidgets的优点：

1. 开放，对于各类第三方库的良好兼容（TAO工具中的Naming_Service Viewer就是采用wxWidgets的）

2. 支持各平台的"Native GUI"

3. 虽然有庞大的库，运行效果极为显著

4. 对各类现有工具的支持（笔者就采用MPC一站式产生所有项目的编译工程）

5. 偏MFC，对于Windows平台MFC程序的跨平台迁移，具有天然的优势

6. XRC，则提供了代码和设计分离的便利，程序员专注整体开发，UI设计群体则提供运行期界面、多语言版本支持功能等

wxWidgets的缺点：

1. 由于是偏MFC，则面向对象封装做得不是非常好

2. 相对缺乏的文档、资源

3. 缺乏很好的商业化支持，如果商业软件出问题需要支持，稍微麻烦点

总之：

在采用第三方工具库的复杂PC应用环境，有一定的底子，wxWidgets是不二的选择

在只需采用Qt单一工具库的应用环境，Qt是个不错的选择；特别是类似于手机这种嵌入式设备环境，由于Nokia的加入，Qt更值得一用。