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，多國語言沒問題。
