Archive:Development/FAQs/General FAQ (zh TW)

Development/FAQs/General FAQ

Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文

我想要開發新的應用程式。請問你的建議？

我們都同意，需要大量的 KDE 應用程式加入。但也有很多現有的 KDE 應用程式需要你的幫助。

在開始新的應用程式前，檢查 KDE-Apps.org 上現有的應用程式，並詢問 [email protected] 郵件列表是否有人已經制訂類似的專案是一個好主意。

我是開發人員，我要如何幫助 KDE 呢？

從工作列表檢查開放的工作，其中包含你可以加入的。KOffice 和 KDevelop，儘管受到高度讚賞，但只有極少數開發者，所以你可以從這裡開始。不需要成為 KDE 核心開發人員才能提供協助。KDE 是高度模塊化的，所以你可以完美地改善一個地方，而不了解整個系統如何運作。

如果有需要協助的應用程式，您也可以在 kde-devel 詢問。使用KDE最新版和需要立即的東西。主題生成器？konsole schema 編輯器？改善遊戲？總是有小功能缺失。去實現它吧！

你是熟悉或關注於特定領域嗎？查看是否有相關的應用程式，可以獲得您的幫助。或者自己寫一個。KDE 需要更多非 geek 導向的應用程式。

我不是開發者，我要怎樣幫忙？

有大量不需要開發技術的任務。撰寫應用程式評論幫助 KDE 推廣（請見 kde-promo 郵件列表），幫助文件團隊（請見 i18n.kde.org/doc），協助翻譯（請見 i18n.kde.org），幫助過濾加入的bug（請見bugs.kde.org）。

在哪裡可以找到 Konqi 龍的圖像？

The Konqi for some people SDK is at ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
It was posted to artist.kde.org before that site ceased to be updated.

Further images are on KDE merchandise.

貢獻 KDE 需要什麼樣的水準？我應該學習什麼？我應該閱讀什麼？

您需要了解 C++。閱讀 Qt 的教學和瀏覽 Qt 的文件來熟悉 Qt。然後閱讀KDE的教學和瀏覽架構和文件。您還可以閱讀KDE的書籍。但你不用熟悉整個 KDE 的架構成為 KDE 開發者。使用 KDE 的技術是很容易的，所以集中在你真正需要的，你可以以後再學習其他部分。KDE TechBase 和 doc.qt.nokia.com (或者在您的 $QTDIR/doc/html) 是寶貴的資源，要善用它們。然後瀏覽原始碼，尋找範例目錄，看看其他應用程式的寫法。讀寫程式碼是最好的學習方法。

什麼是 SVN？我如何從 SVN 得到 KDE？

請見匿名 SVN 頁面。

可以存取線上的 KDE 原始碼嗎？

可以

• 瀏覽 http://websvn.kde.org/
• 搜尋原始碼在 http://lxr.kde.org/search
• 瀏覽原始碼生成的 API 文件在 http://www.englishbreakfastnetwork.org/

我應該加入什麼在我的 .subversion/config?

[miscellany] global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \ config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \

• _la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
• .all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
• _meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \

Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \

• .o *.lo *.la #*# .*.rej *.rej *.pyc

And to make svn diff ignore whitespace, and print function names: [helpers] diff-cmd = /usr/local/bin/_svndiff

with the following in /usr/local/bin/_svndiff: #!/bin/sh exec /usr/bin/diff -b -u -p "$@"

Don't forget to make /usr/local/bin/_svndiff executable.

我想加入我的應用程式到 KDE

有三個要求：

• 您的應用程式必須使用最新版本的 KDE 編譯（SVN trunk）。
• 您的應用程式必須是穩定的。
• 您的應用程序必須得到維護。你可能會得到大量的 bug 報告和願望。人們期待你修復 bug 和實現有意義的願望。

可以參見下一個問題。

Is it better to develop inside or outside KDE?

As core developer Waldo Bastian explains in a copyrighted mail:

---

Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.

Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.

On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.

You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.

In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.

BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.

---

It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

如何讓 SVN 訪問 KDE？

See full article at Contribute > Get a SVN Account.

Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.

Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.

You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub)

See also #How do I create a SSH key?

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...

Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on developer.kde.org)

A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.

我的應用程式還不穩定，但我想讓它加入 KDE

第一步，我們可以把它放在 playground（=kde-alpha）。當準備就緒時，請您的應用程式移動到適當的 KDE 套件包或 extragear 模塊。

我不想失去我的 SVN 歷史。

This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.

什麼是 kdebindings？

It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

功能凍結是否適用於 playground？

不，playground 不會發布套件。kdereview 和 extragear 也是相同的：他們沒有凍結和發布。但如果你希望你的應用程式轉移到套件包，請在 beta 發布之前先詢問。

可以同時有穩定和不穩定的 KDE 在同一台電腦上嗎？

Yes, check the Building 2 Versions documentation.

我怎麼知道我使用的 Qt/KDE 版本？

Launch the KDE Control Center. The splash screen includes Kde version information.

kde-config and all kde programs accept --version as argument.

Qt-copy 或 qt.nokia.com 的 Qt：如果用其中一個做 trunk 建構，是可行的嗎？

任何一個您都可以使用。它們是二進位相容的（往前和往後）。但 qt-copy 修正幾個 Qt 最新版中的 bug。特別是從 qt-copy 建構，要注意補丁腳本。

How can I checkout a single directory from a SVN module?

Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'

For instance, to get only reaktivate from playground/utils:

svn co -N /playground/utils; svn up reaktivate

Then compile as usual.

The same answer applies to the question "How do I get a single language out of kde-i18n?".

If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

如何取得其中一個 KDE 應用程式作為一個獨立的壓縮檔？

kdesdk/scripts/svn2dist 是一個從 KDE 原始碼樹中提取應用程式的腳本，並打包為一個獨立的應用程式。

如何關閉我自己的 bug 報告？

If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.

You can do that from your Subversion commit. To do so, append to your commit message a line like this:

BUG: XXXXX
Where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.

Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

如何創建 SSH 密鑰？

SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.

Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.

If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.

For the practical part, the following command can be used to generate a SSH private/public key pair with

ssh-keygen -t dsa

This will create a private key as ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub.

There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,

Host svn.kde.org 
IdentityFile ~/.ssh/id_dsa_kde 

In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

如何監控別人所做的更改？

The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.