Bijdragen

Revision as of 21:28, 16 November 2012 by Willem1 (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%

Deze pagina geeft een overzicht van de verschillende aspecten van het bijdragen aan KDE, met name voor de programmeertaken. Het KDE-project is blij met iedereen die meehelpt.

noframe
 
Note
Er zijn vele manieren om mee te doen aan de ontwikkeling van KDE, die kunnen worden onderverdeeld in de volgende categorieën:
documentatie, vertaling, ontwikkeling, gebruiksvriendelijkheid, toegankelijkheid, uiterlijk, promotie
Kunt u niet programmeren? Zie KDE's pagina's over hoe u kunt meedoen om andere manieren te ontdekken om mee te helpen. Zie ook: Bugsquad!

Contents

Nieuws en mailbronnen

De richting waar het KDE-project heengaat, wordt bepaald door degenen die het werk doen - er is geen eenduidig plan over hoe KDE er in de toekomst uit zal zien.

Als u wilt ontdekken wat er momenteel wordt gedaan, dan is er een aantal bronnen die u kunt gebruiken:

Mail-lijsten
Waarschijnlijk de beste manier om uit te vinden wat er momenteel gebeurt rondom de KDE-ontwikkeling. Er zijn hier archieven beschikbaar.
CommitFilter
Ontvang berichten over wijzigingen aan de broncode van KDE in gebieden die u interessant vindt.
KDE Commit-Digest
Een wekelijkse samenvatting van broncodewijzigingen aan KDE.
The Dot
De nieuwssite over KDE.

Fouten rapporteren

De gemakkelijkste manier om aan KDE bij te dragen is om fouten te rapporteren die u vindt in KDE met behulp van het KDE-foutensysteem (ook bekend onder de naam Bugzilla).

Als de KDE-applicatie crasht tijdens het gebruik, dan verschijnt een Dr Konqi-venster, dat u door het proces zal loodsen om de crash te rapporteren. Lees hier meer over op de pagina hoe een nuttig crash-rapport te maken.

Aan de slag met programmeren

Aan de slag gaan met programmeren in KDE is een kwestie van een probleem zoeken, en het oplossen. U kunt het moduleoverzicht raadplegen om uit te vinden waar u naar zoekt; als u iets opgelost hebt, dan kunt u een patch inzenden. Als u dat enkele keren gedaan heeft, wordt het misschien gemakkelijker om een KDE Contributor-account aan te vragen, zodat u direct dingen kunt verbeteren.

C++

KDE is voor het grootste gedeelte geschreven in C++. Bent u niet bekend met C++, dan is het nuttig om er ten minste een beetje werk in te steken. Er zijn heel wat goede boeken over C++ - een uitstekende referentie is "Thinking in C++" door Bruce Eckel. Dit boek is beschikbaar als gratis download en als gedrukte versie. Het is niet nodig om alles door te hebben voordat u aan KDE gaat werken, maar u moet wel de basis-syntaxis en -operaties kennen.

Qt

Om goed te worden in KDE-programmeren, moet u de Qt-bibliotheek begrijpen. Kent u Qt niet, dan is het goed om de tutorials uit de Qt-referentiedocumentatie volgen.

Hebt u een rustigere introductie in Qt nodig, of wilt u gewoon een andere kijk op de zaak, dan kunt u kijken naar Foundations of Qt Development.

Wilt u liever een gewoon boek lezen, kijk dan eens naar de pagina Boeken over Qt. Nog meer suggesties om vertrouwd te raken met Qt 4 staan op de pagina Hoe leer ik Qt.

KDE

Een grote hoeveelheid informatie over KDE-technieken staat in de tutorial-sectie. Let op dat sommige van deze tutorials nog over KDE 3 gaan, maar ook die zijn nog steeds minstens gedeeltelijk relevant.

Andere nuttige informatie over KDE-programmeren vindt u in de FAQ-sectie. Deze informatie kan ook enigszins verouderd zijn voor KDE 4, maar veel ervan is breed toepasbaar, zelfs buiten KDE.

U kunt ook boeken over KDE-programmeren lezen.

Ten slotte is er de uitgebreide API-documentatie die bij KDE hoort. Deze is beschikbaar in de sectie KDE API Reference Manuals, die ook een serie nuttige links bevat over hoe deze klassendocumentatie geschreven en bijgewerkt kan worden. U kunt deze documentatie ook op uw eigen computer genereren, of bekijk een recentere online-versie op API Reference.

Een meer gedetailleerde beschrijving van de bovenstaande stappen staat in onze Programmeergids.

Contexthulp (Wat is dit)

Contexthulp is onafscheidelijk verbonden met dialoogvensters en widgets, omdat die het doel van de contexthulp zijn. Feitelijk moet u, om contexthulp te schrijven, enkele programmeerhulpmiddelen gebruiken. Immers, de contexthulp is een eigenschap van widgets. In de objectgeorienteerde programmeerstijl kan een eigenschap verschillende waarden aannemen, en zich verschillend gedragen afhankelijk van de waarde. In Qt/KDE is de naam van de eigenschap "whatsthis", en zijn waarde is de tekst die in de contexthulp moet komen.

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.

Bugs oplossen en kwaliteitscontrole

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.

Gebruikersinterface

Het ontwerpen van gebruikersinterfaces is een heel breed onderwerp, en het is ook heel subjectief: iets volstrekt logisch voor de ene persoon kan idioot zijn voor anderen, en andersom. Maak daarom geen aannamen, redeneer duidelijk, waarbij de logische stappen vermeld worden. Het belangrijkste hulpmiddel tijdens het overleggen is redeneren en gezond verstand.

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