wxWidgets与其他工具库的比较(上)

本文是在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的主要要求,但并不是很大的工作量。
 
==================================================
 
待续……

你可能感兴趣的:(mfc,qt,wxwidgets,休闲,gtk+)