如何以個人力量幫助KDE

KDE 是一個強大的圖形桌面環境,各項關於 KDE 使用上的問題或討論歡迎在此提出。

版主: AceLan, Franklin

如何以個人力量幫助KDE

文章訪客 » 週六 4月 16, 2011 11:46 pm

本文內容適用於任意的開源項目。

對於用戶來說,沒有程式設計技能什麼的都是很正常的事情,但是除此之外還是有很多事情可以做。

1、彙報bug

這 是我個人最看重的一點,因為相對而言這個佔用時間最少,但是非常重要。有時候經常見到講這裡是廢品,那裡是廢品的問題。但不知道大家都有沒有去實際彙報 bug。有時候你的情況可能是少數情況,但不代表它不重要。開發人員能覆蓋用例是有限的。bugs.kde.org也不完全是彙報bug的地方,同時也有 一個選項是wishlist,如何區分bug和wishlist最簡單的方法就是某個功能是否應該這麼做還是你想要讓它這麼做。

KDE的網站為:bugs.kde.org

在彙報bug時的幾個注意事項:

在彙報之前先進行搜索,當然由於具體文字使用問題,很可能找不到duplicate的bug,意思是這個bug已經有人彙報過了(我其實彙報過不少最後成為dup的…),即使成為了dup也沒關係。

儘量詳細的描述bug,主要體現在幾點上:

1)你的環境,包括版本,cpu架構,發行版本,你認為相關的套裝軟體版本。
2)可以重現這個bug的步驟。

開發者debug是很困難的,尤其是遇見一個他不能重現的bug的時候,這種情況就只能靠猜了。所以一個可以重現的步驟和環境異常重要,第一條也是保證開發者可以有一個確定的環境可以重現這個bug。

KDE還提供了一個工具可以幫助你,就是Dr. Konqi,在發生崩潰類的bug時,一般它就會跳出來,顯示進程的調用堆疊。已經提供一個嚮導説明你提交bug(如果堆疊不達到3星是不能使用這個嚮導最終提交的,請注意)。

調用棧會有一個評分,這牽涉到它包含了多少資訊。並非1星的就是沒用的,一般我的判斷標準就是有沒有相關的函數名和庫名。這可能需要一些知識。無法判斷的時候其實也可以交給開發人員判斷。

另 外一個問題就是如何提高這個評分。這牽涉到編譯器的優化,一般來說,發行版本在編譯這些套裝軟體的時候會將這這些説明debug的資訊都drop掉,減少包的 大小,因此有些發行版本也提供了包含有debug資訊的套裝軟體,我所知道的有fedora(其他我是真不瞭解,沒有提到不代表偏見),一般包的命名就是原包 名-debug或者-dbg,可能在不同的發行版本中保存於特別的軟體倉庫中需要手動開啟。

如果有條件的話,當然是自己編譯一下也ok。由於Archlinux的打包檔異常簡單,因此我以Archlinux為例。首先最好去找發行版本的打包檔,減少configure的量,以及保證編譯選項一致,以及卸載時方便。

對於Arch來說首先需要在PKGBUILD的options裡面加入!strip,strip的功能是將檔中的符號去掉,所以需要添加。其次就是設置CFLAGS,CXXFLAGS,在build函數的開頭開始寫入:

代碼: 選擇全部
export CFLAGS="-g -O0"
export CXXFLAGS="-g -O0"


-g的含義是保留符號,-O0的含義是編譯優化等級為0。這都能在顯示調用棧的時候顯示出具體代碼的行數,以及中間被優化掉的函式呼叫名稱。CFLAGS對應C語言,CXXFLAGS對應C++語言,對於KDE來說,大部分程式都是C++開發的。

然後你可能需要在配置時修改一些參數。對傳統./configure , make , make install的方式來說,可以先手動./configure –help看看有沒有和debug相關的選項。

對於cmake來說(也就是大部分KDE程式),會有這樣一個參數-DCMAKE_BUILD_TYPE=Release,這裡可以修改為-DCMAKE_BUILD_TYPE=Debug。

以上提升調用棧品質最直接的辦法。如果有時間或者空閒自己編譯下當然好,沒有的話做到前面所說的也沒有問題。

2、身體力行幫助宣傳

當然不需要像傳教士一般,我覺得做到這個程度就ok了:例如在別人詢問推薦的時候,回個帖推薦自己喜歡的程式,如果幫到了別人不也是一件很開心的事情嗎?

3、參與一些非代碼類工作

比如當地語系化翻譯。對於小專案來說,可能就是和開發者直接聯繫,對於KDE這種,一般都會有一個本地的郵寄清單/組織可以聯繫,比如簡體中文就是kde-china at kde.org。(正體中文可至KDE@Taiwan ─ KDE 正體中文資源網)

可以幫助編輯的工具有以下幾個,poedit(GNU提供,gtk),gtranslator(GNOME),lokalize(KDE)。功能大同小異,選擇自己喜歡的就好。

4、提供自己的建議

前面所說的wishlist可能不足以描述複雜的例子,這裡有個更合適的地方:KDE Brainstorm

這可能需要你做一些關於介面的mockup來説明表達你自己的建議,也更加適合討論。

5、donate

細節咱就不說了,別找錯位置和帳號打錯款,Paypal幹這事很容易的。

http://www.ikde.org/discuss/help-kde-yourself/
訪客
 

回到 KDE 一般討論

誰在線上

正在瀏覽這個版面的使用者:Google [Bot] 和 1 位訪客