KDE項目小組最近推出了最新的開發人員FAQ，由KDE項目開發人員David Faure編寫，包含了KDE開發的方方面面，內容十分詳盡。相信您看過這個FAQ后，將對KDE的開發過程有一個非常清晰地認識，沒準以後就成為了一個KDE開發高手了呢。本FAQ分為基本問題、技術問題和調試問題三部分。
原文：http://developer.kde.org/documentation/other/developer-faq.html。
原問題由Philippe Fremy列出，David Faure回答。請把其他問題、回應或者評論發送給pfremy@chez.com。
KDE項目開發人員基本問題解答
Q：我想開發新的應用程序，你對此有什麼建議？
大家都知道，我們還需要編寫更多的KDE應用程序，不過，已有的kde應用程序更需要得到你的幫助。如果你想了解一下目前需要大家幫忙的地方，請不妨看看本頁面上的相關內容。
在開發新的應用程序之前，請最好先查看一下apps.kde.com站點的內容，從中了解現有應用程序的開發情況。你還可以查詢kde-devel@kde.org郵件列表，了解一下是不是已經有人在著手開發你正計劃的同一項目了。
Q：我是一名程序開發人員，我能為KDE做點什麼？
請從工作列表中查看一下目前的開發任務－其中必有一項屬於你。當前，KOffice和KDevelop軟體儘管受到很多讚譽，但是相關的開發人員太少了，你可以不妨瞧瞧這兩個項目。其實，並不是說一定要成為KDE核心開發人員才能對KDE有所貢獻。KDE是高度模塊化的程序項目，在不必了解整個系統的情況下，你可以通過自己的工作來改進項目中的某一部分。
你還可以查詢kde-devel，看看誰需要你的幫助。
你還可以通過使用最新版本的KDE從中發現自己可以援手的地方。比如，主題生成器（theme generator）、konsole計劃編輯器、遊戲的改進等等。這麼大的項目，裡面肯定有遺漏什麼特性的地方，就等你大顯身手了！
你對某個特定領域很熟悉嗎？你對它很感興趣嗎？瞧瞧其中有沒有你能上手的應用程序，要不你乾脆自己寫一個。KDE特別需要更多的、面向非專業人士的應用程序。
Q：我不是開發人員，我又能做點什麼呢？
好多任務並不需要任何開發技能。比如，編寫程序評估報告（參見kde-promo郵件列表）、幫助編寫文檔（參見i18n.kde.org/doc）、搞翻譯（參見i18n.kde.org）、找bug（參見bugs.kde.org）等等。
Q：要參與KDE的開發需要達到怎樣的開發水準？我應該學習什麼？閱讀什麼？
你應該熟悉C++。還應該讀過Qt指南，瀏覽過Qt的文檔，對Qt比較熟悉。你還應該閱讀一下KDE指南，了解該軟體的結構和文檔 。你還可以閱讀KDE方面的書籍，反正沒什麼壞處。當然，要成為kde開發人員也不必非要熟悉KDE的整體結構。kde技術用起來很簡單，所以，你還是把注意力放到自己真要做的工作上為好，以後再了解一點其他方面的情況就可以了。
developer.kde.org和doc.trolltech.co（還有$QTDIR/doc/html）包括了大量相關材料，應該充分利用這些材料。
你可以通過閱讀這些學習材料，查找示例目錄，看看其他人編寫的程序代碼。閱讀和編寫程序代碼是學習編程的最佳方式。
Q：什麼是cvs？我怎麼從cvs得到kde？
參見匿名cvs頁面。
Q：我能把自己編寫的應用程序加到KDE里嗎？
有三個要求：1.你的應用程序必須在最新版本KDE下編譯（CVS）。2.你的應用程序必須穩定。3.你的應用程序必須可維護。你的程序也許沒有太多的bug，受到的讚許也很多，但人們希望你能修補自己的程序bug，實現合理的程序要求。還可以參見下一個問題。
Q：在KDE內部或者外部開發，哪種情況更好一些？
核心開發人員Waldo Bastian在一封有版權的郵件中是這樣解釋的：
作為KDE開發人員的一分子就意味著你必須同其他人合作。這種合作可以為開發人員帶來很多權利，同時也賦予了開發人員更多的責任。
這些權利有：你的代碼將出現在所有發布版上，人們可以修補代碼中的bug，你可以獲得免費的譯文和文檔，大量的程序漏洞報告等等。
另一方面就是其責任了：你必須和項目中的其他開發人員保持聯繫，其他人可能修改你的代碼，你必須尊重發布凍結（release freezes），你可以獲得很多bug報告，人們希望你修補這些bug來維護自己的代碼。
你不能只選擇權利而忽略你的責任，權利和責任是相互依存的。
總而言之，軟體的作者應該把自己的應用程序放到CVS裡面去。我們通常不把軟體放到KDE CVS里，除非作者希望這麼做。反過來，如果作者樂於在CVS以外開發自己的程序那也是他作為作者的權利。除非某個應用程序的實際開發團隊出現了分裂，否則非要把項目開發分開來做是毫無道理的。
但是……，如果把你的代碼置於開放源代碼許可協議管轄之下並將其放在了KDE CVS之內，那麼你就給世界以（正如KDE所為）不可取消的權利來使用你的代碼。KDE會使用這一權利來保護KDE的利益，即便違背了作者自己的願望也是如此。
Q：我如何獲得使用cvs的權利？
請詢問Stephan Kulow（coolo@kde.org）或者David Faure（faure@kde.org），解釋一下你為什麼需要使用cvs。如果你對某個不屬於你的應用程序做出了貢獻，那麼你最好首先把你的代碼作為程序補丁提交給作者，讓作者使用這些代碼。如果作者並不負責維護自己的應用程序，你就可能成為新的維護人員……。儘管cvs許可權並無限制，我們還是希望你不要在其他開發人員同意的情況下就弄亂人家的代碼。
你還必須尊重軟體發布版本規劃的特性凍結（feature freeze，在developer.kde.org上發布）。
Q：我的應用程序不穩定，但是我想它加入KDE。
我們一般首先把這些程序放在kdenonbeta裡面（== kde-alpha）。請在該軟體版本中開發，到準備好以後，再把你的程序放到適當的kde軟體包里。
Q：我不想失去自己的cvs歷史記錄。
當把你的應用程序放到kde之內的時候請提供你的cvs知識庫的tgz包。
Q：特性凍結（feature freeze）適用於kdenonbeta嗎？
不，kdenonbeta不是發布的軟體包。但是，如果你希望自己的應用程序加入軟體包，那麼請在發布測試版之前提出申請。
Q：我可以在同一台計算機上同時安裝穩定的和不穩定的兩套KDE嗎？
可以，請查看kde1和kde2頁面。這種情況同樣適用於kde 2的兩個不同版本。
Q：我如何通過CVS模塊檢查目錄？
檢查頂級目錄用'cvs co -l modulename'命令，用'cvs co modulename/admin'命令則檢查模塊中的admin/dir目錄，然後可以用'cvs co modulename/subdir'命令檢查你希望檢查的目錄。比方說，為了從kdenonbeta中找到唯一的reaktivate目錄，你可以採用以下命令：cvs co -l kdenonbeta cvs co kdenonbeta/admin cvs co kdenonbeta/reaktivate。
然後照一般編譯方式進行編譯即可。以上的回答也適用於以下問題：「我怎麼能得到單一語言的kde-i18n？」。
Q：我怎麼能得到象tarballan程序那樣的單一kde程序？
kdesdk/scripts/cvs2pack可以從kde源代碼樹和軟體包中抽取出特定的應用程序。
KDE項目開發人員技術問題解答
Q：我該如何著手編寫一個新的應用程序？
最簡單的辦法是使用kdesdk/kapptemplate或者kdevelop產生Makefile.am文件。或者，你可以從其他應用程序那裡拷貝一份Makefile.am並把它安裝在已有KDE源代碼的新頂級目錄下。第三，你還可以用以前開發軟體的老辦法，但你這樣一來就沒有用到autoconf/automake框架的強大開發功能了。
Q：什麼是dcop、kpart、kio、kdesktop、kdeinit……
請查看developer.kde.org，特別是結構文擋。另外還可以查看kde書籍。
Q：我真的需要使用dcop和kpart嗎？
當然，你不必一定要使用它們，不過用了會好得多。KPart可以實現強大的代碼重用。Dcop具有腳本能力，功能強大。這些技術用起來既簡單，部署的範圍又廣，如果你會用卻不使用那可真丟人的。
Q：Makefile是如何產生的？
請參看autoconf和automake手冊了解其內容。KDE軟體構建系統（build system）通過一種名叫am_edit（你可以在admin目錄下找到）的程序對此進行了改進和提升。基本上，automake把Makefile.am轉變為Makefile.in文件，然後am_edit運行並用KDE特有標籤的真實含義取代Makefile.in文件中所有的KDE特有標籤，configure會根據Makefile.in文件創建一個Makefile文件。
am_edit所處理的KDE特有標籤的說明：
Moc文件
如果你所有的.cpp/.cc文件中都包括其.moc文件（這是快速編譯下的建議方式），或者，如果你正在編譯單一的二進位文件/庫，那麼只要使用METASOURCES=AUTO即可。萬一在同一目錄下有多個二進位文件/庫，那麼你可能需要如下所示來使用該命令：
libsomething_la_METASOURCES = myfile.moc myotherfile.moc mybinary_METASOURCES = someotherfile.moc
QT Designer文件
myprogram_SOURCES 後面增加.ui文件即可
QT Designer文件
myprogram_SOURCES 後面增加.ui文件即可
DCOP stub和skel
myprogram_SOURCES里增加將生成的.skel和.stub文件即可
圖標
KDE_ICON = AUTO 把圖標安裝到全局KDE目錄，而appicondir = $(kde_datadir)/myapp/icons appicon_ICON = AUTO 則把圖標安裝到「myapp」指定目錄（建議在只有某一個程序需要該圖標的情況下這麼作，這樣可以避免弄亂全局目錄，同時還避免了發生和代碼名稱的衝突）。
為了運行 AUTO （以及為了讓圖標正常裝載），你需要採用以下的命名規範：<depth><size>-<type>-<name>.png。
其中：depth取值hi或者lo，也就是指hicolor或者locolor（實際圖標風格的名稱），size是16、22或者32。type的取值是，應用程序圖標是'app'、mimetype圖標是'mime'、菜單、工具條按鈕是 'action'、某些文件系統（目錄等）圖標是 'filesys'、光碟機/軟碟機/硬碟等圖標是'device'。
你可以在圖標選擇對話框內找到同樣的圖標類型。
注意這一規範只對源代碼有效。安裝的時候，圖標會被拷貝到正確的目錄，並被簡單命名為<name>.png。
文檔
KDE_LANG = en （文檔採用的語言）
KDE_DOCS = AUTO （如果目錄就是應用程序的名字）
KDE_DOCS = myapp 使用特定的應用程序名稱
翻譯
為了讓你的應用程序可譯，你必須用i18n()把代碼中出現在用戶面前的英語字元串擴起來 。你還要在你的頂級Makefile.am中定義一個消息目標。腳本會調用所有的消息目標來創建kde-i18n模塊中的pot文件。然後，翻譯器就可以創建包含這些翻譯消息的.po文件。
現在讓我們回到消息目標（messages target）。它應當對包含i18n的源代碼調用XGETTEXT——這不等於_SOURCES參數下的調用，因為_SOURCES包含了.ui和.skel文件，這兩種文件不能同xgettext一起工作。這就是為什麼你通常使用*.cpp、*.h，而不是以上文件的原因（如果可能，請保證包含了子目錄）。所以，簡單情況下，消息目標看起來如下所示：
messages:
$(XGETTEXT) *.cpp *.h -o $(podir)/mypotfile.pot
mypotfile是你的主KInstance的名字（對應用程序來說，這就是傳遞給KAboutData的第一個參數，對組件來說，比如part和插件，這就是你創建的KInstance的名字）。
如果你有.ui（Qt designer）或者.rc（XML-UI）文件，使用 messages: rc.cpp腳本即會用當前目錄內的ui和rc文件創建rc.cpp。如果你在子目錄下有.ui或者.rc文件，那麼，在XGETTEXT調用之前，你需要向消息目標中增加$(EXTRACTRC) */*.rc >> rc.cpp這一指令。
還有一個特殊情況是「tip」文件，這是一種XML文件，其中包含了顯示給用戶的提示。在這種情況下應該使用以下命令：
messages:
perl ./preparetips > tips.cc
$(XGETTEXT) *.cpp *.h tips.cc -o $(podir)/mypotfile.pot
rm -f tips.cc
比如，你可以在kdebase/ktip下找到以上這種腳本（顯然，臨時tips.cc文件到底用什麼名字並不重要）。
最後的問題是編譯和安裝.po文件。在kde-i18n以內，Makefile.ams文件包含了KDE_LANG=language 和POFILES=AUTO兩個指令，意思是目錄下所有的.po文件都安裝了該語言。
如果你提交了獨立的應用程序，而且你想讓該程序安裝自己的po文件，那麼你通常會有一個po/子目錄，該目錄內的Makefile.am的文件會認定 POFILES=AUTO。在這種情況下，.po文件在拷貝的時候會根據自己的名字，比如$(PACKAGE).mo而得以建立（比如，de.po安裝到de/LC_MESSAGES/$(PACKAGE).mo下面，而fr.po 則安裝到fr/LC_MESSAGES/$(PACKAGE).mo下面）。
Qt-only程序
默認情況下，am_edit需要kdecore產生「meta-unload」中間文件。為了在建立Qt-only程序時禁用它，請使用KDE_OPTIONS = qtonly。
Q：make參數有哪些？
all：默認參數（當鍵入「make」時）。
clean：刪除所有生成的文件。
distclean：還刪除Makefile.cvs產生的文件，在KDE內不太有用（參看「dist」概念下的dist和cvs-clean以了解更好的清除文件方式）。
dist：通常用CVS源代碼生成tarball，但在KDE內沒有受到良好的支持。最好使用kdesdk/scripts/cvs2pack完成同樣的功能。
cvs-clean：（只用於CVS用戶）刪除不在CVS中的任何文件（警告，如果你還沒有提交變更就不要使用它！）。
force-reedit：重新運行Makefile.am中的automake和am_edit。
install：很好，安裝所有的東西。
install-exec：只安裝二進位文件和庫。
install-data：只安裝數據文件。
check：編譯測試程序（比如，由check_PROGRAMS定義的文件）。在「make check」期間實際運行某些測試是正確而且有益的，請參看kdelibs/arts/tests/Makefile.am。
Q：我檢查了cvs，沒有configure和Makefile？
使用make -f Makefile.cvs，該命令會運行所有產生Makefile的步驟。
Q：不同的編譯選項有哪些？
--enable-debug：增加調試符號，禁用程序優化、打開kdDebug()記錄（log）。
--disable-debug：上一參數的反面：啟用程序優化並關閉kdDebug()記錄。
--enable-final：把所有的.cpp文件連接為一個大型的.all_cpp.cpp文件，然後編譯該文件（而不是編譯其中的各個.cpp文件）。這會讓整個編譯過程變得更快，通常會產生更好的優化代碼，但也需要更多的內存。不過，當不同源代碼文件所包含的.h文件相互衝突時經常會出現編譯錯誤，或者，當使用的不同源文件內具有同一名字的靜態函數時也會出現編譯錯誤。這樣做在節省軟體打包時間上佔了便宜，但是對開發者而言並不是這樣，因為某個文件中的一個改動就意味著編譯全部軟體包。
--disable-fast-perl：默認情況下，KDE使用perl而不是sh和sed把Makefile.in轉變為Makefile。這是Michael Matz對autoconf的補充。你可以使用該選項禁用它，但編譯速度就變慢了。
Q：你建議我應該採用什麼編譯選項？
如果你是一名開發人員，你應該明確地在--enable-debug參數下編譯Qt和KDE。這樣，你以後甚至可以在Qt和KDE函數內部調試自己的程序。<br>如果你僅僅是個用戶，你也可以使用 --enable-debug。不過，KDE在你的硬碟上會佔據更大的空間但不會減慢桌面電腦的運行速度。優點是：當應用程序崩潰的時候你可以得到堆棧的運行記錄。如果你執行程序總是崩潰，那麼你不妨去bugs.kde.org站點查看你的bug是否已經存在，否則你就可以提交這一個bug，這樣對改進kde大有裨益。
對Qt來說，該編譯選項在qt-copy/README.qt-copy中解釋。
Q：增加編譯速度的竅門何在？
請參看以上的 --enable-final 參數。「make final」把當前目錄下的文件當作一個文件來用，即便沒有採用 --enable-final也是這樣。「make no-final」則執行當前目錄下的正常編譯（即便採用了--enable-final）。 請包含你的moc文件！順便提一句：kdesdk/scripts/includemocs會自動地完成該功能。請購買更多的內存，更快的計算機和另一個處理器。在一部裝備兩個PIII 866 MHzCPU、帶1G內存的計算機上，編譯kde的速度飛快！還有，就是不要使用gcc-2.96。:)
Q：我應該採用什麼縮排格式？
如果你在編寫已有的應用程序，請尊重作者的縮排格式。否則，你想怎麼用就怎麼用。
Q：QSpinNumber的bug是怎麼回事？
QSpinNumber中有個bug，這個bug還沒有的得到糾正。你可以採用KSpinNumber，它幾乎具有和QSpinNumber同樣的特性。
Q：我編譯的時候系統顯示「virtual tables error」？
這通常是因為moc文件沒有和源文件同步，或者完全沒有鏈接。請檢查你是否在運行正確的moc。「which moc」命令可以找出結果。請重新生成你的moc文件（make force-reedit；make clean；make）。
Q:使用dcop的時候，我在myClassHeader.h 文件中增加了k_dcop，但看起來好象什麼特別的事情也沒有發生？
把myClassHeader.kidl加到Makefile.am中，然後再次運行make。
Q：某些Makefile.am中有一個.stub文件，這是幹嘛使的？
Stub沒有很好的文檔化。stub可以讓你把dcop註冊應用程序當作其方法就是自己dcop slot的對象。通常，應用程序都有一個appnameIface.h文件，其中包含了所有的dcop slot。你可以在Makefile.am中增加一個appnameIface.stub並使用目標appnameIface。請參看使用konqueror stub的kdebase/khelpcenter示例。
Q：我在myClassHeader.h文件中增加了Q_OBJECT，但是沒有產生moc文件？
你需要am_edit重新解析你的Makefile.am來產生正確的Makefile。如果它是你在該目錄下所使用的第一個Q_OBJECT，那麼你需要在kdesdk/scripts下重新運行Makefile.cvs 或者create_makefile。否則你只要運行「make force-reedit」即可。
Q：為了讓程序跑的更快點，我把自己全部類都放到了一個cpp文件里，我該如何得到生成的moc和kidl文件呢？
如果某些類使用了Q_OBJECT宏，那你最好別那樣作。KDE框架（am_edit）對這種做法的支持不是很好。METASOURCES=file.cpp可能還更有用些。
Q：我開發了一個kpart（或者插件）。但我不沒有root許可權，所以我不能安裝它。我該如何讓kde知道它呢？
使用其它前綴（比如$HOME/kdeprefix）配置和安裝你的應用程序並且讓KDE知道這一前綴： 或者，你可以設置KDEDIRS為$HOME/kdeprefix:$KDEDIR達到以上目的。為了讓KDE知道新的前綴，你還可以編輯/etc/kderc並增加：
[Directories]
prefixes=/the/new/prefix
但這樣做還不能解決該問題，你還要在設置了新的KDEDIRS之後運行「kbuildsycoca」。
Q：當我向KTradher請求我的kpart庫的時候，它沒有被列出來。
當你安裝新的服務（比如應用程序或者part）的時候必須重新建立mimetype資料庫。理論上說，這個過程應該是自發的（kded會察看這些目錄），如果要自己動手，請運行「kbuildsycoca」。
Q：啟動另一程序的最佳方式是什麼？
kde2遷移指南中有個好法子。請察看kdelibs/KDE2PORTING.html。
KDE項目開發人員調試問題解答
Q：我怎麼才能避免Dr Konqi？
你必須設置環境變數KDE_DEBUG（設置為1或者你實際喜歡的任何東西）。
Q：什麼是核心文件？我怎麼才能得到核心文件？
所為核心文件就是應用程序崩潰的時候的內存影像。使用核心文件，你現在就可以知道設置了哪個變數，應用程序是在哪個地方崩潰的。某些發布版程序禁止生成核心文件。為了重新啟用這一功能，請使用「ulimit -c unlimited」命令。
只要你在程序崩潰后獲得核心文件，你就可以用gdb appname core命令察看核心文件的內容。這樣就會對給定應用程序核心文件打開gdb，一旦gdb提示符出現，最有用的命令就是「bt」，該命令產生崩潰信息的記錄（backtrace）。
要了解如何使用gdb的更多信息請參看該頁。
Q：列印stederr上的debug輸出有更好的方法嗎？
有的，你可以用kdDebug():kdDebug() << "KMyApp just started" <<endl;
該命令語法很像cout，「<<」之間可以使用多種內部類型。這樣就會列印出調試信息，這些調試信息在程序發布的時候會自動關閉（通過--disable-debug）。如果你希望程序發布期間還要獲得這些消息，那麼，因為這些消息都是警告或者錯誤，你不妨使用kdWarning()或者kdError()達到這一目的。
組件和庫最好使用調試區域代碼，比如kdDebug(1234)。使用「kdebugdialog」程序（它是kdebase的一部分）可以關閉或者打開該區域號碼的調試輸出信息，「kdebugdialog --fullmode」還允許控制記錄輸出的位置。
說白了：不要使用qDebug()，該函數在程序發布的時候不會被禁用。還要避免使用assert()或者kdFatal()，他們會在出現問題的時候導致程序崩潰，對用戶沒有半點好處。最好在程序中檢測錯誤，如果可能的話，輸出kdWarning或者kdError再行恢復。
Q：調試我的應用程序可以使用什麼工具？
kdDebug()函數是一種簡單、高效的應用程序調試方式。
gdb，GNU調試器是逐步執行和檢查變數的最快方法（最好用5.0版本，該版本比4.1.x好多了）。
kdbg是採用KDE GUI的gdb前端。它支持多種Qt類型（包括QString）。
Memory leak tracer ：參看kdesdk/kmtrace。README解釋得很全。
kdcop和dcop可以讓用戶瀏覽dcop介面、方便地執行dcop調用。
請查看該頁面和kdesdk，那裡有用的腳本很多。
Q：我在gdb下如何列印qstring？
請查看kdesdk，在你的~/.gdbinit中加入以下命令：
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
然後就可以在gdb中列印qstring myqstring察看其內容。
比如，QString myqstring = QString::fromLatin1("contents"); 可以使用以下的命令來檢查：
(gdb) printqstring myqstring
$1 = 99 'c'
$2 = 111 'o'
$3 = 110 'n'
$4 = 116 't'
$5 = 101 'e'
$6 = 110 'n'
$7 = 116 't'
$8 = 115 's'
請參看kde-devel-gdb文件了解其它定義宏。
Q：當我調試kpart應用程序的時候我沒有符號（symbol），我該怎麼辦？
你必須在主程序之後停止下來裝載共享庫的調試符號。之後，你就可以正常調試了。你甚至可以創建gdb宏以便停在被裝載的part後面。以kword為例，我編寫的代碼如下所示：
define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *,
char const *, bool)'
cont
Q：我怎麼調試ioslave？
請參看kdebase/kioslave/DEBUG.howto。
