wxWidgets与其他工具库的比较

原文：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。

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年的，已经不足为信了，不过，豆子也没有去找更新的资料）。