Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 本網站預計持續維運至 2021年底,網站內容基本上不會再更動。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
News

自由軟體熱血開發者 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 來提供高品質的基本繪圖功能、字型描繪、色彩處理與相關的程序。詳情可參考官方網頁



You may be interested in the following articles:




OSSF Newsletter : 第 55 期 JBoss 新產品發佈

Category: FOSS News