我们都同意需要编写大量的 KDE 应用程序。但同时也有很多现有的 KDE 应用程序需要你的帮助。
Before starting a new application, it's always a good idea to check KDE-Apps.org and other open source software hosting services like GitHub, Google Code, and SourceForge for existing applications and to ask on the kde-devel mailing-list whether someone is already working on a similar project.
尽管 Calligra 和 KDevelop 受到高度赞赏，它们只有极少数开发者，所以你可以从这里开始。提供帮助并不仅仅体现在加入 KDE 工作空间或 KDE 平台库的开发。KDE 是高度模块化的，所以你不必了解整个系统就能每次改善某个独立的方面。
您也可以在 kde-devel 邮件列表问问是否有人需要协助。使用最新版 KDE 并且关注需要的东西。一个主题生成器？一个 konsole 计划编辑器？改善一个游戏？这些项目总是有小功能缺失。去实现它吧！
你是熟悉或关注于特定领域吗？查看是否有相关的应用程序，可以获得您的帮助。或者自己写一个。KDE 需要更多非 geek 导向的应用程序。
You need to know C++. Read the Qt tutorials and browse the Qt docs to get familiar with what's available with Qt. Then read the KDE tutorials and browse architecture and documentation. You can also read the KDE Book, it can not harm. But you don't have to be familiar with the whole KDE architecture to become a KDE developer. Using KDE's technologies is quite easy, so concentrate on what you really need, you can learn the other bits later on. KDE TechBase and doc.qt.digia.com (also in your $QTDIR/doc/html) are invaluable resources, take advantage of them. Then, browse the source, look for the examples directories, see how the other did code their applications. Reading and writing code is the best way to learn.
Yes. There are many ways to do this:
You need to add the ignore list to the [miscellany] group in your ~/.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 "$@"
不要忘了将 /usr/local/bin/_svndiff 设置为可执行。
There are three requirements:
See also the next question.
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 KDE's repositories. We usually don't put software in KDE's repositories unless the author wishes to do so. The other way around, if the author prefers to work on his application elsewhere 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.但...您把程序代码以开源授权放在 KDE 仓库就相当于同意整个世界，特别是KDE，使用您的程序代码。KDE 将斟酌使用此权利，以保护 KDE 的利益，即使违背作者当下的意愿。
知道这个是重要的，但不要害怕。通常，事情进展得很好。在五年里，这仅仅发生了一次：一个开发者把他的作品保留在 KDE 中，尽管他想移除它。
See full article at Get a KDE Contributor Account.
Go to KDE Identity, fill out the form and describe why you need write access. Make sure to specify your full name and e-mail address.
Please also 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 KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (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 are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on Schedules page)
A detailed list of rules you should follow when committing to KDE repositories are listed in the KDE Commit Policy.
第一步，我们可以把它放在 playground（"kde-alpha"）。在那里开发它，完善后，申请将应用程序移动到适当的 KDE 包或 extragear 模块。
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that. Note that for git this is not an issue.
它包含 Qt 的 Ruby、PHP 和 C# 绑定、KDE 的 Ruby、C# 和 python 绑定以及让非 KDE 的应用程序作为 KPart 嵌入的 XParts。请见 TechBase 的 绑定页面。
不，playground 不会发布套件。kdereview 和 extragear 也是相同的：他们没有冻结和发布。但如果你希望你的应用程序转移到套件包，请在 beta 发布之前先询问。
Yes, check Building KDE Software from git.kde.org video series:
kde-config and all KDE programs accept --version as argument.
任何一个您都可以使用。它们是二进制兼容的（往前和往后）。但 qt-copy 修正几个 Qt 最新版中的 bug。特别是从 qt-copy 建构，要注意补丁脚本。
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.
kdesdk/scripts/svn2dist 是一个从 KDE 原始码树中提取应用程序的脚本，并打包为一个独立的应用程序。
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 happen 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 unreproducible, some without enough information to be corrected, etc. If you can help by managing and updating the list of outstanding bugs, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.
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 separate 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.