Difference between revisions of "Contribute/nl"

Jump to: navigation, search
(Created page with "De Bugsquad probeert om fouten in KDE-software in de gaten te houden, en echte rapportages onder de aandacht te brengen van ontwikkelaars. Je hoeft (al...")
(Created page with "Het is simpel om een vlugge gebruikersinterface te ontwerpen, maar het is lastig om mensen ervan te overtuigen dat een interface veranderd moet worden. Een goede, overtuigende...")
Line 86: Line 86:
 
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.
 
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.
+
Het is simpel om een vlugge gebruikersinterface te ontwerpen, maar het is lastig om mensen ervan te overtuigen dat een interface veranderd moet worden. Een goede, overtuigende analyse kan een hoop aan waarde winnen als hij informatie uit de KDE-richtlijnen bevat, een analyse van concurrerende programma's, algemene ontwerpprincipes die in vele boeken staan, tests op gebruikers, of individuele feedback (anekdotes). Het is een vrijwilligersproject, en zelfs als iedereen het met je eens is, moet iemand het wel implementeren.
  
 
The [http://mail.kde.org/mailman/listinfo/kde-usability 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 [http://www.openusability.org/ OpenUsability.org], a project that brings open source developers and usability experts together, and is collaborating closely with KDE.
 
The [http://mail.kde.org/mailman/listinfo/kde-usability 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 [http://www.openusability.org/ OpenUsability.org], a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Revision as of 15:39, 20 December 2012

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.

Gelukkig is deze taak vaak niet heel moeilijk, want er zijn goede programma's om te werken aan het ontwerpen van gebruikersinterfaces. Bovendien zul je de opgedane kennis later weer kunnen gebruiken bij het ontwerpen van gebruikersinterfaces in het algemeen. Met het Qt-framework (Qt is de basis van de KDE-technologie) is het mogelijk om de code en de gebruikersinterface van elkaar te scheiden. Er zijn twee gevallen: de interface is geschreven samen met de algemene code van de applicatie (meestal .cpp-bestanden) of in Qt Designer-bestanden (.ui-bestanden, dit zijn XML-documenten). Het is het beste om te beginnen met het tweede geval, want hiermee is makkelijker te werken. Als Qt Designer niet geïnstalleerd is, dan kun je dat doen door het ontwikkelingspakket voor Qt te installeren via je distributie, of (als je distributie kleine pakketten heeft) het Qt Designer-pakket.

Onder de volgende link staat een gedetailleerd overzicht voor het schrijven van whatsthis, zowel met Qt Designer als direct met de broncode: WhatsThis Tutorial, door Aaron J. Seigo.

Bugs oplossen en kwaliteitscontrole

Een groot aantal applicaties valt onder KDE, en niet al die programma's hebben iemand die het onderhoudt door foutrapporten bij te houden en te helpen met het omzetten van slechts een werkend stuk code in een gelikte applicatie.

Wil je meehelpen met KDE, maar weet je niet waar te beginnen, kan het je aanspreken om lid te worden van het KDE Quality Team - zie hun website voor meer informatie. Je hoeft geen enkele ervaring met programmeren te hebben om aan KDE mee te doen. Ontwikkelaars publiceren vaak zogenaamde Junior Jobs (kleine taken voor beginners) om nieuwe bijdragers te werven.

Je kunt natuurlijk ook meedoen aan het oplossen van fouten zonder dat je bij het KDE Quality Team gaat - maak een account aan op het foutenrapportage-systeem en begin eens door de rapporten heen te spitten. Ook hier hoef je niets van programmeren te weten - het helpt de programmeurs enorm als er een procedure is om een defect consistent te reproduceren.

De Bugsquad probeert om fouten in KDE-software in de gaten te houden, en echte rapportages onder de aandacht te brengen van ontwikkelaars. Je hoeft (alweer) geen programmeerervaring te hebben om in de Bugsquad te zitten; het is een goede manier om iets terug te doen voor de KDE-gemeenschap als je niet kunt programmeren.

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.

Het is simpel om een vlugge gebruikersinterface te ontwerpen, maar het is lastig om mensen ervan te overtuigen dat een interface veranderd moet worden. Een goede, overtuigende analyse kan een hoop aan waarde winnen als hij informatie uit de KDE-richtlijnen bevat, een analyse van concurrerende programma's, algemene ontwerpprincipes die in vele boeken staan, tests op gebruikers, of individuele feedback (anekdotes). Het is een vrijwilligersproject, en zelfs als iedereen het met je eens is, moet iemand het wel implementeren.

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.

Antwoorden op uw vragen krijgen

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.


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