http://devbean.blog.51cto.com/448512/175190/
wxWidgets与其他工具库的比较(上)
2009-07-08 11:16:30
标签：MFC Qt 休闲 wxWidgets gtk+
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://devbean.blog.51cto.com/448512/175190
本文是在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的主要要求，但并不是很大的工作量。
GTK+
● GTK+的网站：www.gtk.org；
● GTK+原本是Gimp的一个工具库，是在LGPL协议下发布的Unix系统GUI库；
● GTK+已经被移植到Windows，VMS以及其他的系统上面(在MacOS X上面现在可以通过苹果的X11应用程序实现，其本地版本正在开发之中)，使用相同的API。但是，GTK+的设计初衷是Unix，多平台的开发是后来才加入的；
● GTK+是GNOME用户界面的原始构建库；
● 不同于wxWidgets，GTK+支持C语言(同样，GTK+也有一个C++的封装版本GTKMM，http://www.gtkmm.org)；
● GTK+的API被很好的设计过，包含了安全类型转换和其他的一些机制，但是C++语言已经内建了这些；
● GTK+构建在glib库之上，这是一个通用库(在某些方面类似于C++的STL，它提供了一些数据结构，以及一些帮助内存管理的函数等)；
● 在不同平台具有相对一致的界面，除了Windows XP，在XP系统中，GTK+尝试使用Wimp外观(基于UxTheme)来模拟Windows本地界面，获得了一定的成功。但是，它依然是一个Unix库；
● 既然wxWidgets在Unix上使用GTK(或是GTK2)，也就没有什么理由在wxWidgets之上构建跨平台的C++程序了。
Kylix
● Kylix是Borland/Inprise的一个不成功的产品，所以很难说它还会继续被支持多久；
● Kylix基于Qt构建；
● Kylix仅支持为数不多的平台；
● Kylix的IDE使用了不少于三个库，并且很不专业。
Lazarus
● Lazarus是一个跨平台的开源RAD IDE，也是一个编写GUI程序的库；
● Lazarus很多地方与Borland Delphi兼容，相同的代码可以被这两个编译器编译；
● Lazarus有为本地使用或者客户端/服务器的数据库应用的数据展示组件；
● Lazarus仅支持Object Pascal；
● 工作方式类似于wxWidgets，支持很多底层的工具集：gtk1，gtk2，win32api，qt，carbon和winCEapi；
● 底层的免费Pascal编译器支持很多现在仍在使用的操作系统和架构；
● 现在它支持的平台比wxWidgets少。
Ultimate++
● Ultimate++仅支持Windows和Linux，不支持MaxOS；
● 在http://upp.sourceforge.net/www$uppweb$vswx$en-us.html的对比展示了一个简单的例子，但是这并不能说明这个库如何很好的开发更大的应用程序。
Notus
● Notus网站：http://sourceforge.net/projects/notus；
● 实际上存在wxWidgets ;) (豆子：原文是wxWidgets actually exists，这可能是说还有更好的wxWidgets)；
● Notus似乎是要更多地使用标准库和现代C++概念，例如遍历器、模板、命名空间等等(相比之下，wxWidgets更多的是使用了非标准的方式)；并且它更多地是借鉴了Boost的设计理念(你可以把它认为是一个好的或者不好的事情)，它和Boost的其他的库在一起工作得很好。当然，既然它并不存在，这是不是真的还得要时间的检验。(豆子：看看Notus的站点，好像这是库是把泛型的概念带入到GUI编程里面)
MFC
● MFC仅仅能够在Windows上免费使用：
○ Visaul C++跨平台版本有一个maxintosh版(至少要800美元)，但是自从4.1版本的编译器就不支持了；
○ 也有一些Unix的模仿，如MainWin，相当的昂贵，需要运行时协议，并且据说有一些有问题的支持；
● 如果一个程序使用wxWidgets或者MFC构建，并且源代码是开放的，那么EULA(豆子：最终用户许可协议)是不能约束wxWidgets的；
● MFC的执行程序比wxWidgets小(基本上是靠编译器实现体积缩小的)；
● MFC拥有很多优秀的商业组件；
● 有人说，wxWidgets的事件表(event tables)要比MFC的消息映射(message map)好；
● wxWidgets的类层次结构更多合理，而MFC在顶层类名显得不那么一致性；
● wxWidgets提供了大量的相关的方便的工具类，而MFC提供了更多的窗口相关的类；
● 同.NET不同，MFC不会迁移到.NET平台；另一方面，wxWidgets已经有了初步的.NET版本；
● MFC提供了更多的组件，尤其是有关数据的控件；
● 有些地方使用wxWidgets更加简单一些，例如特定类型的窗口(如总是在最上方的窗口等)，另一些地方使用MFC会更方便，日期选择工具条；
● 或许使用MFC最重要的一点是MSVC，这个IDE本身；
● 参见WxWidgets For MFC Programmers了解更多区别。
Mozilla Framework
● 参见http://www.mozilla.org/why/framework.html；
● 在Mozilla程序中需要使用JavaScript、XUL和C++；而wxWidgets只使用C++；
● 在Mozilla中使用C++(XPCOM)相当困难；在wxWidgets中使用C++就简单得多。
Tk
● Tk又称为：Tcl/Tk，Perl/Tk；Python/Tkinter；
● 参见：http://wiki.tcl.tk/tk；http://wiki.python.org/moin/TkInter；
● 古老的API，但是实现了基础的功能。很多扩展提供了新的组件：著名的BWidgets Tcl/Tk扩展提供了纯Tcl编写的megawwidgets；
● 没有GridView~ListView，但是有一个简单的list；
● ComboBox是一种按钮；
● 默认命令是双击，但如果你希望“单击”或其他事件，那也是支持的，不过你会很难发现它们；
● Python将这个库选为默认的，但是一些发行版(如Pardus)并没有默认包含；
● 从一个组件获得返回值是通过StringVar、IntegrVar和DoubleVar类，这很令人困惑；
● 提供MaxOS X上面的本地外观(很久以来就是如此)，使用Tile扩展实现Windows XP的本地风格，其他情况下是Win9x的风格；
● 在X11下并不能工作得很好。事实上，它看起来有点像Motif :-( ，看一下Tile扩展，它的目标是让Tk在X11下获得新生；
● Tk是工具命令行语言(豆子：原文是Tool Command Language)的一个扩展。这种语言是一个强大的跨平台脚本语言。但是不得不承认，Tcl的学习曲线很高，它是一种和C/C++完全不同的语言；
● 你可以把完整的Tcl/Tk应用程序包装成一个二进制文件，一个独立的Starpack，或者说是一个使用一种小巧的脚本解释器Tclkit运行的Starkit。发布就是这么简单。
VCF
● VCF网站：http://vcf-online.org；
● 清晰的OO设计；
● 在Windows是成熟的，部分支持MaxOS X和Linux；
● BSD协议。
WideStudio
● WideStudio网站：http://www.widestudio.org；
● WideStudio使用它自己的组件；
● WideStudio的安装包含在MinGW和gcc之中(不是可选的)；
● WideStudio有一个IDE/设计器；
● 它的IDE/设计器有Eclipse插件版本(参见http://www.eclipse.org/dsdp/nab/)；
● WideStudio没有控件交互的键盘导航；
● WideStudio的容器类不允许使用名字引用(如myWindow("labelCaption")->Test)；
● WideStudio的库的总大小小于10M(2008-01-25)，小型的应用程序的发行版小于4M。
什么情况下不应该使用wxWidgets？
● wxWidgets缺少创建漂亮的表格、图表的商业GUI组件。参见wxCode；
● 不支持主题(区别于在底层使用主题的工具库)，除非你使用wxUniversal或者wxSkin；
● wxX11相比于其他的工具库只是一个子集，并且不稳定。你应当使用wxGTK，这个实现基于GTK构建，而不是直接在X11上面。wxX11更适合于没有GTK的嵌入式设备；
● wxWidgets试图支持大量的特性，因此，有些很少用到的组件不如经常使用的组件稳定。就像使用任何开源库一样，大量的测试是最佳的解决方案；
● wxWidgets没有提供任何平台的二进制发布。你不得不自己编译wxWidgets。wxpack提供了Windows平台上的wxWidgets的二进制版本，但是你需要下面几百兆的开发包；
● 使用本地组件使得相同的代码在不同平台表现有所不同，并且可能有一些平台相关的bugs。
现在终于将这篇文章翻译完了。很多翻译不当的敬请谅解！虽然这是篇发布在wxWidgets上面的Wiki，但是我觉得写得还算中肯，因此是有一定的借鉴意义的。
这里列出了很多库，或许一些现在已经停止开发了，至少也算是见证一下C++ GUI库曾经的百家争吗、百花齐放的场面吧！呵呵…