本文是在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
● 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
● 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的主要要求，但並不是很大的工作量。
==================================================
待續……