2010年7月25日 星期日

知名 GUI lib 簡評 (GTK+, Qt, wxWidgets)

http://blog.udn.com/keithmin/679610
(按:原文有些地方句讀錯誤,或語義欠詳,我有補綴一些字)

GTK+

     GTK+ 主要用在 X Window 上,入門門檻較高。特色是,他用不具有物件功能的純"C" 語言,模擬物件導向。 所以寫起來比較複雜艱澀,而且充滿大量巨集,使用和除錯都不是很容易,但優點則是可以用 C,不需 C++,如果和 Win32 SDK 比較,不會難學多少,缺點是不易上手使用,而且文件比較缺,架構又非常複雜,且提供的東西比起其他無所不包的 library,是簡陋了一點,函數命名又臭又長。


    對於簡單的程式,GTK+ 會顯得太複雜,但是當你開始想擴充其他 library 也都沒提供的進階功能,就會開始讚嘆GTK+ 的架構嚴謹,還有超乎想像的高度彈性。 同樣的東西要用 MFC 來做反而會要人命並且多國語言的支援良好,內部也全面使用 UTF-8,相容性好,又是 unicode能夠習慣的話,GTK+ 值得推薦,但沒有很建議學,畢竟不好學,要用到熟會需要比較久,而且那樣很多 C++ 的功能會用不到。 GTK+ 有 C++ 版本叫做 GTK--,沒用過但看文件覺得,並沒有比 gtk+ 簡單到哪裡去。 因為 gtk+ 本來就是物件導向,所以即使換了 c++ 語言,寫起來架構還是差不多的。


    另外,gtk+ 有 Windows 版本,但缺點是,執行緩慢,不穩定,而且介面是使用 gtk+ 自己的,不是使用 Windows 內建的"Native" 原生圖形介面
,看起來會不太習慣。 Mac OS X 下可用 X11 來執行 gtk+但那樣出來的程式是長得像 UNIX 程式,而不是美美的 OS X Aqua 外觀。


wxWidgets

    wxWidgets 和 MFC 最接近, 命名習慣或架構都高度相似,會 MFC 幾乎不用重新學習有十餘年歷史,此外,他的物件封裝比 MFC 要好,提供的功能也多上太多,又跨平台一般知名的 MFC 程式都會選擇用 wxWidgets 改寫,來快速移植原程式到其他平台例如 eMule 用 wxWidgets 移植出 aMule, xMule, 還在開發中的 Filezilla 3...等


    而它最主要的特色是,他是"跨平台"的 "Native" GUI toolkit在各種平台上都可寫出使用該平台內建 Native 原生圖形介面的程式。 在 Windows 上就長得跟其他 Windows程式一樣,在 Linux 下就使用 gtk+ 的圖形介面,在 Mac OS X 下就可以使用華麗的Aqua 外觀風格,這點是非常強悍。 不像 gtk+ 到其他系統都還是只能用 gtk+ 自己的。(它的)缺點是,中文支援在有些地方會出問題,例如剪貼簿的操作。 得自己 patch但仍然相當推薦,即使是個龐大的 library,效能依舊不會太差,尤其在Windows 上執行速度並不輸 MFC,與其學 MFC,不如學 wxWidgets。


Qt

     Qt 的功能,應該是這三者加上 MFC 之中最強大的,文件也很完整,又有 RAD 工具可以輔助開發,並且有商業公司做強力後盾。不但有 Windows/X Window/Mac 版本,甚至還有嵌入式系統可用的版本,穩定性還不錯,物件封裝也算良好,資源比 GTK+ 或wxWidgets 多得非常多,而且發行公司提供了相當多範例,算是一家以開放原始碼成功營利的模範公司。 知名的 KDE 整個是用他開發,證明了他的穩定性和強大功能。


    缺點是如果你用他開發非 GPL 開放程式碼的軟體,必須以極昂貴的金額,購買商業版本。 而他的圖形介面並不完全是 "Native GUI",只是透過 theme 去模擬系統上的標準 GUI,所以看起來很像,卻會有些地方可以明顯看出破綻。 執行速度緩慢還有過於龐大則是另一個問題。 雖然封裝得很良好文件也齊全,並不代表他就很容易學還有一個嚴重問題是,他寫的不是標準 C++,他使用的 signal/slot 機制必須透過 Qt提供的 preprocessor 處理過才可以轉送給編譯器,這部份可能被限定用 qmake,算是一個可惜的地方,不過瑕不掩瑜,還是很推薦。忘了說,他內部也是 unicode,多國語言沒問題。