Revision as of 04:34, 4 August 2012 by Fengchao (Talk | contribs)

Jump to: navigation, search
Other languages:Greek 34% • ‎English 100% • ‎Spanish 40% • ‎Finnish 72% • ‎French 79% • ‎Galician 100% • ‎Japanese 56% • ‎Korean 51% • ‎Dutch 98% • ‎Polish 95% • ‎Brazilian Portuguese 95% • ‎Slovak 13% • ‎Chinese (China) 96%

此页面简要介绍 KDE 开发的不同方面,特别是编程相关的问题,KDE 项目欢迎所有愿意提供帮助的人加入。

不会编程?请访问KDE页面 如何参与 获得其它贡献方式。参见: Bugsquad!



KDE项目的大方向是由实际工作者决定的 - KDE将变成什么样并没有一个统一的计划。


可能是了解 KDE 开发进展的最好方式,归档位于 这里
获 KDE 中感兴趣领域的代码提交通知。
KDE 提交摘要
每周 KDE 项目源代码提交的摘要。
The Dot
KDE 新闻站点。


最简单的贡献方式是使用KDE Bug 管理系统 (Bugzilla)报告使用KDE时遇到的问题

如果正在使用的应用程序崩溃,那么工具Dr Konqi将出现,并引导您报告遇到的崩溃。更多内容,请阅读如何提交有用的崩溃报告


开始为 KDE 编程只需要找到一个需要修复地方,并改好它。您可能需要查看模块的概述,以找到需要的信息;修复了问题后,需要发送一个补丁。这样做了几次之后,可以申请 KDE 贡献帐户,之后就可以直接提交代码。


KDE大部分是用C++写成的。如果你不熟悉C++,你至少需要对它进行一些学习。有一些很好的关于C++的书,其中一本非常出色的教程叫做 Bruce Eckel的 "Thinking in C++",你可以自由而免费地下载它,同样你也能将其打印成书面文档。在参与KDE之前,你不需要对它的所有东西都有个透彻的理解,但你至少需要懂得基本的语法和操作。


要想精通KDE编程,你应当对Qt toolkit有较好的理解。如果不熟悉Qt,应当学习Qt 参考文件中的相关指南。

If you need a gentler introduction to Qt, or would just like an alternative view, then you may wish to look at the The Independent Qt Tutorial (Currently offline due to book contract).

If you prefer to learn Qt by reading a traditional book, take a look at the Books about Qt page. More suggestions on becoming familiar with Qt4 are available How to Learn Qt page.


A range of information on KDE techniques is available in the tutorial section. Note that some of these tutorials still target KDE3, though they should be at least partly applicable.

You will also find useful information on KDE coding in the FAQs section. This information may also be somewhat dated for KDE4, however much of it is broadly applicable, even outside KDE.

You can also read KDE coding books.

Last, but by no means least, KDE comes with extensive class (Application Programmer Interface) documentation. This is available in the KDE API Reference Manuals section, which also contains a number of useful links on how to write or update the class documentation. You can also generate these on your own machine, or refer to a more up-to-date online version at API Reference.

A more detailed description of the steps above is available in our Programming Guide.

Context Help: Whatsthis

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: WhatsThis Tutorial, by Aaron J. Seigo.

Getting Involved in Bug Hunting and Application Quality

There is a large number of applications within KDE, and not all of them have a maintainer dedicated to managing bugs and generally helping out with all the issues associated with turning some working code into a polished application.

If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the Quality Team website for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called Junior Jobs to encourage new contributions.

Of course, you can become involved in bug hunting without being part of the KDE Quality Team - just create yourself an account on the KDE bug tracking system, and start searching / sorting through the bugs. Again, you don't have to have programming skills - it helps the programmers enormously just to have a procedure that allows a bug to be consistently reproduced.

The Bugsquad tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; in fact it is a great way to return something to the KDE community if you cannot program.

User Interface

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.

The KDE Usability Mailing List is very active and a good place for discussing your ideas, and their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Some documents guiding documents include the KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles).

Some projects for analysis of user interfaces may include: checking that shortcut keys are coherent across KDE applications, making sure that dialogs are directly relevant to the interaction that the user would expect, and finding users of KDE software to see how they perform common workflows.

Getting Answers to Your Questions

If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:

  • Read the Developer FAQ. Many common developer questions have been answered in the KDE Developer FAQ
  • Search/browse KDE websites. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the KDE TechBase website. And if possible, help edit it for clarity, and use the talk page if something is unclear.
  • Search mailing lists. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists either at lists.kde.org. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
  • Search engines. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also search the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.

A full list of KDE mailing lists is available here and here.

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal