Revision as of 17:00, 8 December 2012 by FuzzyBot (Talk | contribs) (Updating to match new version of source page)

Jump to: navigation, search
Other languages:
Ελληνικά • ‎English • ‎español • ‎suomi • ‎français • ‎galego • ‎日本語 • ‎한국어 • ‎Nederlands • ‎polski • ‎português do Brasil • ‎slovenčina • ‎中文(中国大陆)‎

이 페이지에서는 KDE 개발을 비롯한 KDE의 여러 부분에 관한 정보를 제공합니다. KDE는 도와 주는 모든 사람을 환영합니다.

KDE 개발에 참여하는 데에는 여러 가지 방법이 있으며, 다음으로 크게 분류할 수 있습니다:
문서화, 번역, 개발, 사용 편의성, 접근성, 그래픽, 광고
코더가 아닌가요? KDE의 참여하는 방법 페이지를 보면 참여할 수 있는 방법을 알아볼 수 있습니다. 같이 보기: 버그 잡기!

뉴스와 메일

KDE 프로젝트의 방향은 참여하는 사람들이 결정합니다. KDE가 어떻게 나아가야 할 지를 결정하는 중앙 기관은 없습니다.

지금 일어나는 일을 알아보고 싶으면 여러 곳을 둘러보는 것이 좋습니다.

메일링 리스트
KDE 개발을 알아보는 가장 빠른 방법입니다. 여기에서 기록을 볼 수 있습니다.
KDE 소스 코드 저장소의 커밋 중 관심있는 부분의 커밋을 알려 줍니다.
KDE Commit-Digest
한 주 동안 KDE 소스 코드 저장소에 있었던 일을 요약해서 보여 줍니다.
The Dot
KDE 뉴스 사이트입니다.

버그 보고

KDE에 기여하는 가장 쉬운 방법은 사용하면서 생긴 버그를 보고하는 것입니다. 버그를 보고하려견 KDE 버그 추적 시스템을 사용하십시오.

프로그램이 충돌하면 DrKonqi 유틸리티가 나타나서 충돌을 보고하는 과정을 알려 줍니다. 유용한 충돌 정보를 만드는 법을 알아 보십시오.

코딩 시작하기

정KDE 코딩은 고칠 곳을 찾고 원하는 대로 고치는 것부터 시작합니다. 어디를 고치고 싶은 지 정확하게 알고 싶으면 모듈 정보를 보는 것을 추천합니다. 무언가를 고쳤으면 패치를 보내고 싶을 수도 있습니다. 여러 번 패치를 보내면 KDE 기여자 계정을 얻어서 직접 작업할 수도 있습니다.


KDE는 C++를 주 언어로 사용합니다. C++에 친숙하지 않으면, 최소한 C++를 익혀야 합니다. C++를 익히기 위한 좋은 책은 많이 있습니다. 추천하는 책은 Bruce Eckel의 "Thinking in C++"이며, 온라인 다운로드 및 인쇄된 책으로 볼 수 있습니다. C++의 모든 것을 알아야 할 필요는 없지만, 기본 문법과 사용 방법은 익혀야 합니다.


KDE 코딩에 익숙해지려면 Qt 툴킷을 이해해야 합니다. Qt에 친숙하지 않다면 Qt 참조 문서를 통하여 Qt를 익히십시오.

더 친절한 Qt 소개 문서를 보고 싶거나, 다른 문서를 보고 싶으면 The Independent Qt Tutorial을 참고하십시오. (출판 문제로 현재 사용할 수 없습니다.)

다른 책을 알아보고 싶으면 Qt에 관한 책 페이지를 참조하십시오. Qt에 친숙해지는 다른 방법은 Qt 배우기 페이지에 더 있습니다.


KDE에서 사용하는 기술은 튜토리얼에서 찾아볼 수 있습니다. 일부 튜토리얼은 KDE3을 대상으로 하고 있으므로, 현재 시점에서는 적합하지 않습니다.

KDE 코딩에 대한 더 많은 정보는 FAQ 페이지에서 참조할 수 있습니다. 이 정보는 KDE 4 기준으로는 오래되었지만, KDE 이외의 영역에서도 유용합니다.

KDE 코딩에 관한 책도 알아보십시오.

KDE에는 클래스 API 문서가 있습니다. API 문서는 KDE API 참조 설명서 부분에서 볼 수 있으며, 클래스 문서를 작성하거나 업데이트하는 방법도 포함하고 있습니다. 직접 문서를 생성하거나, 온라인에서 API 문서를 읽어볼 수 있습니다.

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 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.