原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章 原始出處 、作者信息和本聲明。否則將追究法律責任。http://devbean.blog.51cto.com/448512/175190
本文是在wxWidgets Wiki上面找到的一篇，對比了wxWidgets和其他一些界面工具的特點。看到很多朋友在網上詢問這些庫各自的特點，我想先把這篇文章翻譯出來——畢竟這也算是一篇官方的文章，應該比較有說服力吧！這篇文章寫於2004年左右，但是很明顯某些地方已經更新了，因爲Qt 4.5是2009年才發佈的！
這是我第一篇翻譯，哪裏翻譯不好敬請諒解！
==================================================
首先是關於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站點：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程序在運行時編譯成字節碼，這意味着當用戶第一次啓動程序時，將耗費更長的時間，而程序相應也會比較遲鈍（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網站：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的主要要求，但並不是很大的工作量。