開發時面對 GTK+ 臭蟲的一點小技巧

GTK+』是個易學的 Toolkit,用它來寫 Linux/BSD 上的圖形化界面,非常的簡單。用其開發出來的程式,除了可以在 X11 上運作,甚至是可以使用 DirectFB 直接將 GTK+ 程式畫在 FrameBuffer 上,所以 GTK+ 也常見於 Embedded System。

在 GTK+ 1.x 時代發展到最後,效能、輕量程度和穩定度都很好,目前仍然被許多 Embedded Device 所採用。但 gtk+ 2.x 之後的變革極大,每個版本都有大量的新東西,導致有些版本異常肥大,或有些版本異常 Buggy 都不足為奇。曾經也撰文寫過說,在開發 GTK+ 程式時,常碰到非常奇怪的問題,而除錯所花的時間少可以很少,多可能一兩天都不見得能找出問題。

這邊有些除錯的方法,可以幫助 GTK+ 開發者能找出程式上的臭蟲:

在執行欲 Debug 的程式前,先設好 G_DEBUG 環境變數:
G_DEBUG="fatal-criticals"
在產生 Makefiles 時,可下參數開啟 cast-checks 以得到更多的 debug information:
./configure --enable-cast-checks
用這幾個小技巧,就能比較容易發現 GTK+ 程式的錯誤。

不過如 PCMAN 所說,開發 GTK+ 程式時,放一套 GTK+ Source Code 在旁邊供著,還是比較有保障的〔笑〕。許多奇怪問題,還得靠 GTK+ Source Code 來釐清真相,速度可能比 Google 還來得快。

別以為『 GTK+ 哪這麼多問題?』,從很多 GNOME 和其他程式的 Code 就可以發現,為了解決 GTK+ 問題,有數不清的 Dirty Hack 和重寫。所以,和世界各地的 GTK+ Program 開發者聊到『GTK+ Sucks』時,總是能會心一笑和產生共鳴,不是沒有道理的。 :-)

後記
Open Source 最大的好處是讓開發者可以到處看 Code ,這意味著一切技術都是透明的,對於提升開發者自身能力上是很棒的。而對使用很多不同 Libraries 的 Project 來說,如果在有許多樣本的情況下,其開發者看 Code 的數量,其實就是程式碼品質的關鍵。所以,GTK+ 的 Source Code 當然也要看一下才是。 :D

留言

這個網誌中的熱門文章

有趣的邏輯問題:是誰在說謊

Web 技術中的 Session 是什麼?

淺談 USB 通訊架構之定義(二)

淺談 USB 通訊架構之定義(一)

Reverse SSH Tunnel 反向打洞實錄