自由軟體熱血開發者 PCMan 專訪（中）

編按：本文作者 jserv 為若干自由軟體專案的開發者與維護者，希望透過一系列人物專訪，讓更多讀者對台灣的自由軟體社群發展有所認識，進一步肯定台灣自由軟體社群開發者的貢獻。全文分三期刊登。

jserv：談談你最近在 Linux 上的計畫，像是 PCManX、PCManFM，或是 DFB (Debian For Beginners)[15] 等等，以及請分享你在開發的過程中，遇到哪些挫折，還有這段歷程中，你得到哪些意外的收穫？

PCMan：故事講起來真長，延續上個議題，會真的玩起 Linux 來，跟社群的朋友有非常大的關係，要感謝的人列成名單的話寫不完了…。

jserv：嗯，那談談這過程所面臨的挫折好了。

PCMan： 從 PCManX 早期的開發來說，發現 wxWindows 中文支援度不佳，雖然自己 patch 後可解決部份問題，卻不熟悉 GTK+ Programming，GTK+ 文件又少，而且也不熟悉 Linux 上軟體的建構方式，過去在 Windows 上的經驗都用不上，可說是全部從零開始，對所有工具都很陌生。一開始也找不到 co-developer（一開始），幸好很多東西摸久了慢慢就比較有概念。後來改用 GTK+ 2.x 開發，最大的挫折應該就是我不會用 GTK+。不得不重申，GTK+ 的文件真的很少，特別是關鍵性的，而原本 GTK+ 用以處理多國語文顯示、排版的 Pango[16]，對於中文輸出的效能很差，問題是 BBS 連線程式相當注重這方面的效能，幸好在 jserv 的指導下使用了 Xft[17] 解決問題，開發期間多認識了不少朋友，以及學會了一些東西的正確作法。

而最近發展的 PCManFM 來說，最大的挫折是……"GTK+ sucks!"，很多細節弄投入相當大的心力後，往往發現是 GTK+ 的問題，說到這，在PCMan X 開發期間意外發現 GTK+ 底層用以處理資料結構與基本功能的 glib，存在 multi-threaded的 bug，經回報給官方後，已在 GLib 2.8 版修正。繼續 PCManFM 的地方，那些細節不少肇因於 GTK+ 本身設計不良，在閱讀很多其他人的程式碼之後，發現了許多 workaround（註：透過特別的程式設計技巧，避開原本軟體框架的問題，本身並非常規性的解決方案），另一個困難同樣是找不到 co-developer，但陸續收到來自外國朋友寄來的 locale data（區域性的語文翻譯）。

因為 GTK+ 文件簡陋，許多狀況又難以查明原因，只好回過來追蹤一些 GTK+ 本身的程式碼，只為了釐清文件寫不清楚又沒範例之處，實在只能靠 source code 和各種測試，儘管苦不堪言，但這是讓我最不想回 Microsoft Windows 的原因，因為所有東西都有 source code：發現問題後，可手動修正，做 patch；不會寫，可以參考 source code；文件沒有，可以 hack（當然，這邊的 "hack" 是 hacker 用語，意思就是說動手去修改以達到預期的效果）。換言之，工具有很多選擇，資源之豐富，簡直是 programmer 的天堂。自己不會做的還可以取用別人的成果，而且自己的成果也可以輕易被別人取用，大家共同合作，互助共享，我非常嚮往這樣的精神。不用想辦法盜版軟體， 因為所有的東西都是歡迎拷貝、歡迎利用，不喜歡的話就歡迎改造，這種自由和樂趣，應該任何喜歡這個領域的朋友都很難抵抗。想法可以有機會實現，並且有機會 參與軟體的發展，而不是被動的使用者。

對了，回到之前提到的開發挫折經驗。撰寫 PCManFM 這個 file manager，乍看下，file manager 似乎只是個簡單的應用程式，在實地動手開發後，才發現是不小的挑戰。在這個「小程式」中（程式碼的規模已經上萬行了），為了透過 GTK+ 作有效率地顯示檔案系統的階層性，幾乎把過去不熟的 GtkTreeView 系列 [18] 都用上，但是閱讀 GTK+ 官方網站的整份 Tutorial 後，發現還不足以撰寫一個檔案管理程式所需。後來又因為要處理 MIME Type 一類的議題，開始參考由 KDE 與 GNOME 開發者為了桌面系統標準共同發起的 FreeDesktop.org 計畫，一邊涉獵 FreeDesktop.org 的文件，一邊應用到 PCManFM 開發的同時，深深感覺到 Linux Desktop 規格的混亂，而為了處理一些問題，甚至必須去 hack GTK+ source code，這下才又更深入知曉該問題的嚴重性。在這一年多的 Linux 開發經驗來說，程式當中總是必須做一大堆沒有意義的處理，浪費這麼多資源，只是為了處理一些小小的不相容，是必須大力改進的，這也是我說 "GTK+ sucks" 的緣故。而某些 "GTK+ sucks!" 的地方，就要看開發者何時能夠處理、何時有辦法提出解決方案，因為我還沒有修好完全克服這些問題的能力，不僅我在開發 PCManFM 有這個困擾，知名的 XFCE[19] 開發中的 file manager － Thunar[20]，也同樣針對 GTK+ 種種問題，做了修改與補強。

jserv：喔？就你的經驗來說，Thunar 到底做了哪些修改？而這給予 PCManFM 發展過程有什麼幫助或啟發呢？

PCMan：Thunar 自己實做了許多新的 classes，包括放棄使用給 PCManFM 造成很大困擾的 GtkTreeModelFilter[21]、GtkTreeModelSort[22]…等具有很多 bugs 的 GTK+ classes，這些原本是相當有用而且高度彈性的設計，可以協助開發者過濾處理特定欄位的資料內容、 控制資料輸出、以及自訂資料模型的型態[23]， 不過就如剛才說的，一直到了 GTK+ 2.8.x，還是有相當多問題，所以 Thunar 與 PCManFM 都改用自行撰寫 custom model 來儲存資料的方式，同時提昇了效率，又避開了 GTK+ 的 bugs（這部份的 bugs 根據 GTK+ 開發者的說法，在 GTK+ 2.10 會改善很多）。

另外因為用以在 GTK+ 中產生檔案管理畫面，個別檔案圖示的 GtkIconView[24] 效率低落，又為了相容 GTK+ 2.6，Thunar 以 GtkIconView 作基礎，自行改寫出 ExoIconView[25]，提昇效率並修正一些問題，而 ExoIconView 隨後被我又做了些修，而改變成 PtkIconView，加入到我的專案中。

也為了做比較漂亮的 icon view，Thunar 放棄使用 GTK+ 內建可用以描繪 GDK（GTK+ 處理低階繪圖的部份）GdkDrawable（螢幕可視區域）單元物件的各種 GtkCellRenderer[26] 衍生的 classes，而 XFCE / Thunar 開發者在 libexo 當中實做專屬的 Cell renderers。最近 Thunar 的開發者，又在針對 GTK+ 的效能不彰，研究各種改善 GTK+ 的途徑，試圖提昇它的執行效率和啟動速度。改善 Thunar 本身很難有太大的幫助，因為問題主要出在 GTK+ 上（我對於自己開發的程式所做的 profiling [效能評比分析] 結果，也顯示很多的瓶頸，的確在 GTK+ 本身），所以 Thunar 的開發者到後來被迫開始投入大量心力以改善 GTK+ 內部實做。

不只 Thunar，整個 XFCE 桌面環境，都是依賴 XFCE 團隊開發出的 Exo library，而此 library 的目的就是補強 GTK+ 沒有提供，但是他們會需要用到的東西。此外，有些 GTK+ 2.8 有提供，但 2.6 沒有的，他們也自己在 Exo library 寫出相仿的功能，以在 GTK+ 2.6 上運作。

大家一定覺得奇怪，為何 GTK+ 2.8 已經提供了，他們還是堅持要做相容 GTK+ 2.6？ 確切的理由我不清楚，但是就個人的經驗分析，部份是因為很多平台上沒有 GTK+ 2.8。許多應用環境不採用 GTK+ 2.8 的主要原因有以下兩項：

(1) GTK+ 2.8 的問題非常多，有些還相當嚴重，目前正在快速發展的期間，還沒有穩定到可以大量使用，重視穩定性的系統絕對不能貿然升級。 (2) GTK+ 2.8 後引入了 Cairo[27] 的使用，更加打擊了原本就不理想的執行效率，又增加了更多的記憶體用量，這樣的發展，已經讓 GTK+ 在嵌入式系統的應用，越來越困難，可以說現今的 GTK+ 已經不再適用於硬體環境嚴苛的系統了。

有國內做嵌入式系統的朋友表示，他們公司仍在用 GTK+ 2.4，而有外國朋友來信，希望我能支援 GTK+ 2.6，因為在他的 PDA 上，沒辦法負荷 GTK+ 2.8 的使用。

GTK+ 2 的功能在快速增加這是好事，但對於已經很難改進的效能問題，無疑是最致命的重擊，再加上 GTK+ 2.8 穩定性欠佳，我想這些都是造成很多軟體開發人員在 GTK+ 2.10 即將要推出時，仍然必須要死守 GTK+ 2.4 / 2.6 的重要理由。

相關網址：
[15] DFB - Debian for Beginners 打造夢幻的中文桌面環境
[16] Pango
[17] Xft 為 X Window System 中嶄新的 Extension，可用以有效率地繪製平滑、反鋸齒、向量字型，相關的原理可參考 "A New Rendering System For X"
[18] GtkTreeView 與 Gtk+ Tree Model 是在 Gtk+ 中提供程式設計者以 Model-View-Controller 模式，將資料來源與程式邏輯透過一定的安排建立關聯性操作，API 說明可參考 GTK+ 官方文件
[19] XFCE 桌面環境
[20] Thunar 是未來 XFCE 4.4 中用以取代既有的 Xffm 檔案管理整合性應用程式，目標是更快速且方便的操作檔案系統，發展網頁可參考這裡
[21] GtkTreeModelFilter
[22] GtkTreeModelSort
[23] 這系列的 GTK+ classes 由 Kristian Rietveld 所維護，最早的介紹性文件出現於 GTK+ Development mailing-list
[24] GtkIconView
[25] ExoIconView
[26] GtkCellRenderer
[27] Cairo Graphics，新興的向量繪圖開發函式庫，有多種平台的移植，可提供高品質的繪圖處理，自 GTK 2.8 開始，底層的 GDK 與低階繪圖程序就預設以 Cairo 來提供高品質的基本繪圖功能、字型描繪、色彩處理與相關的程序。詳情可參考官方網頁

您也許有興趣閱讀以下文章:

• 自由軟體熱血開發者 PCMan 專訪（下） - 2006-03-23
• 自由軟體熱血開發者 PCMan 專訪（上） - 2006-03-23