Difference between revisions of "Development/FAQs/General FAQ/nl"

Jump to: navigation, search
(Created page with "Een SDK voor Konqi is te vinden op [ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2]<br /> Deze stond eerst op artist.kde.org, ma...")
(Created page with "Dit kan niet meer met Subversion. Misschien wel weer in de toekomst, als de server is bijgewerkt en dit wel weer mogelijk maakt. Merk op: voor Git is dit geen probleem.")
(39 intermediate revisions by one user not shown)
Line 27: Line 27:
 
Deze stond eerst op artist.kde.org, maar deze site werd niet langer bijgehouden.
 
Deze stond eerst op artist.kde.org, maar deze site werd niet langer bijgehouden.
  
Further images are on [http://kde.org/stuff/clipart.php KDE merchandise].
+
Meer afbeeldingen zijn te vinden op [http://kde.org/stuff/clipart.php KDE-plaatjes].
  
== What is the level required to contribute to KDE? What should I learn? What should I read? ==
+
== Wat is het vereiste niveau om bij te dragen aan KDE? Wat moet ik leren? Wat moet ik lezen? ==
  
 
You need to know C++. Read the [http://qt.nokia.com/learning 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.  
 
You need to know C++. Read the [http://qt.nokia.com/learning 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.  
Line 35: Line 35:
 
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.
 
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.
  
== How do I get KDE software from the KDE git or SVN repositories? ==
+
== Hoe krijg ik KDE-software uit de KDE Git- of SVN-repository's? ==
  
 
See the "Building and Running KDE Software From Source" section on the [[Special:myLanguage/Getting_Started|Getting_Started]] page.
 
See the "Building and Running KDE Software From Source" section on the [[Special:myLanguage/Getting_Started|Getting_Started]] page.
  
== Can I access KDE source code online? ==
+
== Kan ik de KDE-broncode online zien? ==
  
Yes
+
Jazeker:
* Browse http://websvn.kde.org/ and https://projects.kde.org/
+
* bekijk http://websvn.kde.org/ en https://projects.kde.org/
* Search the source code at http://lxr.kde.org/search
+
* zoek door de broncode op http://lxr.kde.org/search
* Browse API docs generated from the source code at http://api.kde.org/
+
* bekijk API-documentatie die wordt gegenereerd van de broncode op http://api.kde.org/
  
== What should I put in my .subversion/config? ==
+
== Wat moet ik in mijn .subversion/config zetten? ==
  
 
<syntaxhighlight lang="text">[miscellany]
 
<syntaxhighlight lang="text">[miscellany]
Line 56: Line 56:
 
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
 
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
 
*.o *.lo *.la #*# .*.rej *.rej *.pyc</syntaxhighlight>
 
*.o *.lo *.la #*# .*.rej *.rej *.pyc</syntaxhighlight>
And to make svn diff ignore whitespace, and print function names:  
+
En verder, om svn diff witruimte te laten negeren en functienamen te laten weergeven:
 
<syntaxhighlight lang="text">[helpers]
 
<syntaxhighlight lang="text">[helpers]
 
diff-cmd = /usr/local/bin/_svndiff</syntaxhighlight>
 
diff-cmd = /usr/local/bin/_svndiff</syntaxhighlight>
  
with the following in {{path|/usr/local/bin/_svndiff}}:
+
met het volgende in {{path|/usr/local/bin/_svndiff}}:
 
<syntaxhighlight lang="text">#!/bin/sh
 
<syntaxhighlight lang="text">#!/bin/sh
 
exec /usr/bin/diff -b -u -p "$@"</syntaxhighlight>
 
exec /usr/bin/diff -b -u -p "$@"</syntaxhighlight>
  
Don't forget to make {{path|/usr/local/bin/_svndiff}} executable.
+
Vergeet niet om {{path|/usr/local/bin/_svndiff}} uitvoerbaar te maken.
  
== I want to put my app in KDE ==
+
== Ik wil mijn applicatie graag in KDE hebben... ==
  
There are three requirements:  
+
Daar zijn drie vereisten voor:
* your app must compile with the latest version of KDE (git master or SVN trunk).
+
* je programma moet compileren met de recentste KDE-versie (git master of SVN trunk);
* your app must be stable.
+
* je programma moet stabiel zijn;
* your app must be maintained. You will probably get a good deal of bug reports and wishes. People expect you to fix the bugs and implement the wishes that make sense.
+
* je programma moet onderhouden worden. Je krijgt waarschijnlijk een berg aan bug-rapporten en wensen. Mensen verwachten dat je de bugs oplost en de (nuttige) wensen inbouwt.
See also the next question.
+
Zie ook de volgende vraag.
  
== Is it better to develop inside or outside KDE? ==
+
== Kun je beter binnen of buiten KDE ontwikkelen? ==
  
As core developer Waldo Bastian explains in a copyrighted mail:  
+
Eén van de hoofd-ontwikkelaars, Waldo Bastian, legt uit in een gecopyrighte mail (vertaald uit het Engels):
 
<blockquote>
 
<blockquote>
Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
+
Onderdeel uitmaken van KDE betekent dat je zult moeten samenwerken met anderen. Zulke samenwerking brengt voordelen, maar ook verantwoordelijkheden met zich mee.
  
: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.
+
:Enkele van deze voordelen zijn: je code belandt in alle distributies, mensen gaan misschien jouw bugs oplossen, je krijgt vanzelf vertalingen en documentatie, en je krijgt ladingen aan bug-rapporten.
  
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.
+
Aan de andere kant zijn er nadelen en verantwoordelijkheden: je zult moeten communiceren met andere ontwikkelaars over je werk, andere mensen kunnen jouw code aanpassen, je moet *freezes* voor releases respecteren, je krijgt ladingen aan bug-rapporten en mensen verwachten ook nog eens dat je die oplost (wat zijn die aan het roken?), en mensen verwachten dat je je code onderhoudt.
  
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.
+
Je kunt niet kiezen voor de voordelen, en de verantwoordelijkheden die erbij horen negeren; het is een compleet pakket; het is beide of niets.
  
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.
+
In het algemeen zou het de auteur van een stuk software moeten zijn die kiest om zijn applicatie in KDE's repository's op te nemen. Meestal zetten we geen software in KDE tenzij de auteur dat graag wil. Aan de andere kant, als de auteur graag ergens anders werkt aan zijn applicatie, dan heeft hij dat recht. Tenzij er een splitsing is in de groep mensen die werkt aan de applicatie, heeft het geen zin om de ontwikkeling van een applicatie te forken om die reden.
  
'''BUT'''... by putting your code under and open source license and putting it in a KDE repository you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
+
'''MAAR'''... door je code onder een open-source-licentie te plaatsen, en het in een KDE-repository te plaatsen, geef je de hele wereld, en daarmee ook KDE in het bijzonder, het niet meer in te trekken recht om je code te gebruiken. En KDE zal dat recht, als dat nodig is, ook gebruiken om de belangen van KDE te beschermen, zelfs als dat dan tegen de wensen van de auteur ingaat.
 
</blockquote>
 
</blockquote>
  
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.
+
Dat is belangrijk om te weten, maar wees niet bang. Meestal werkt het allemaal heel goed. In 5 jaar is het maar één keer voorgekomen dat werk van een ontwikkelaar in KDE gebleven is, terwijl deze ontwikkelaar het wilde verwijderen.
  
== How do I get write access to KDE repositories? ==
+
== Hoe krijg ik schrijfrechten in de KDE-repository's? ==
  
See full article at [[Special:myLanguage/Contribute/Get_a_Contributor_Account|Contribute > Get a KDE Contributor Account]].
+
Zie het volledige artikel op [[Special:myLanguage/Contribute/Get_a_Contributor_Account|Bijdragen > Een KDE-contributor-account krijgen]].
  
 
Go to [[http://identity.kde.org KDE Identity]] , fill out the form and describe why you need write access. Make sure to specify your full name and e-mail address.
 
Go to [[http://identity.kde.org KDE Identity]] , fill out the form and describe why you need write access. Make sure to specify your full name and e-mail address.
Line 111: Line 111:
 
A detailed list of rules you should follow when committing to KDE repositories are listed in the [[Special:myLanguage/Policies/SVN_Commit_Policy|KDE  Commit Policy]].
 
A detailed list of rules you should follow when committing to KDE repositories are listed in the [[Special:myLanguage/Policies/SVN_Commit_Policy|KDE  Commit Policy]].
  
== My app is not stable but I would like to have it in KDE ==
+
== Mijn programma is niet stabiel, maar ik wil het toch in KDE hebben... ==
  
As a first step, we can put it in playground, which is essentially "kde-alpha". Develop it there and when it is ready, request that your app to be moved to the appropriate KDE package or the extragear module.
+
Als een eerste stap kunnen we het in playground zetten; dat is een soort "kde-alfa". Ontwikkel het hier en als het klaar is, vraag dan of je applicatie verplaatst kan worden naar het geschikte KDE-pakket of de extragear-module.
  
== I don't want to lose my SVN history. ==
+
== Ik wil mijn SVN-geschiedenis niet verliezen... ==
  
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.
+
Dit kan niet meer met Subversion. Misschien wel weer in de toekomst, als de server is bijgewerkt en dit wel weer mogelijk maakt. Merk op: voor Git is dit geen probleem.
  
== What is kdebindings? ==
+
== Wat betekent kdebindings? ==
  
It contains Qt bindings for Ruby, PHP, C# to use Qt classes with those langages, KDE bindings for  Ruby, C#, python to use KDE classes with those langages, and XParts to embed non-KDE apps as a KPart. Check the [[Special:myLanguage/Development/Languages|binding page]] of TechBase.  
+
Dit bevat Qt-bindings voor Ruby, PHP en C# om Qt-klassen met deze talen te gebruiken, KDE-bindings voor Ruby, C# en Python om KDE-klassen met die talen te gebruiken, en XParts om niet-KDE-applicaties als een KPart te kunnen gebruiken. Bekijk verder de [[Special:myLanguage/Development/Languages|pagina over bindings]] van TechBase.  
  
== Does the feature freeze apply to playground? ==
+
== Geldt de feature freeze ook voor playground? ==
  
No, playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.
+
Nee, want de playground bevat pakketten die niet worden uitgebracht. Hetzelfde geldt voor kdereview en extragear: die worden ook niet bevroren en uitgebracht. Maar als je je applicatie wilt overbrengen naar een pakket, vraag dat dan voor de beta-versie is uitgebracht.
  
==Can I have a stable and an unstable KDE on the same computer?==
+
== Kan ik een stabiele en een onstabiele KDE-versie op dezelfde computer gebruiken? ==
  
Yes, check the Building 2 Versions documentation.  
+
Ja, zie de documentatie over het bouwen van 2 versies.  
  
== How do I know which version of Qt/KDE I am using? ==
+
== Hoe weet ik welke versie van Qt/KDE ik gebruik? ==
  
<tt>kde-config</tt> and all kde programs accept <tt>--version</tt> as argument.
+
<tt>kde-config</tt> en alle KDE-programma's hebben <tt>--version</tt> als argument op de terminal.
  
==Qt-copy or Qt from qt.nokia.com : if one were doing a clean build of trunk, which would be preferable?==
+
== Welke zou het beste zijn: Qt-copy of Qt van qt.nokia.com, als iemand een schone build van trunk zou doen? ==
  
 
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. Especially if building from qt-copy, pay attention to the apply-patches script.
 
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. Especially if building from qt-copy, pay attention to the apply-patches script.
  
== How can I checkout a single directory from a SVN module? ==
+
== Hoe kan ik een enkele map van een SVN-module uitchecken? ==
  
 
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'
 
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'
Line 151: Line 151:
 
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.
 
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.
  
== How can I get one of the KDE application as a standalone tarball? ==
+
== Hoe kan ik één van de KDE-applicaties krijgen als een losstaande tarball? ==
  
 
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.  
 
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.  
  
== How do I close my own bug reports? ==
+
== Hoe sluit ik mijn eigen bug-rapporten? ==
  
 
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.
 
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.
Line 165: Line 165:
 
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.
 
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.
  
== How do I create a SSH key? ==
+
== Hoe maak ik een SSH-sleutel aan? ==
  
 
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.
 
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.
Line 183: Line 183:
 
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.
 
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.
  
== How can I monitor changes made by others? ==
+
== Hoe kan ik op de hoogte blijven van aanpassingen die zijn gedaan door anderen? ==
  
 
The [https://mail.kde.org/mailman/listinfo/kde-commits kde-commits] mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is [http://commitfilter.kde.org/ CommitFilter] which allows you to get notification for only those areas that interest you.
 
The [https://mail.kde.org/mailman/listinfo/kde-commits kde-commits] mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is [http://commitfilter.kde.org/ CommitFilter] which allows you to get notification for only those areas that interest you.
  
 
[[Category:FAQs]]
 
[[Category:FAQs]]

Revision as of 14:36, 4 January 2013

Other languages:Greek 14% • ‎English 100% • ‎Japanese 44% • ‎Dutch 55% • ‎Polish 27% • ‎Brazilian Portuguese 79% • ‎Turkish 8% • ‎Chinese (China) 54%

Contents

Ik wil beginnen aan een nieuw programma. Wat raad je aan?

We zijn het er allemaal over eens dat er heel veel KDE-programma's zijn die geschreven moeten worden. Maar er zijn ook veel bestaande KDE-programma's die je hulp nodig hebben.

Om te zien waar hulp nodig is, kun je deze pagina bekijken.

Voordat je een nieuwe applicatie start, is het altijd een goed idee om te kijken op KDE-Apps.org voor bestaande programma's, en op de kde-devel-maillijst te vragen of er nog niemand aan een soortgelijk project is begonnen.

Ik ben een ontwikkelaar; hoe kan ik bijdragen aan KDE-software?

Alhoewel Calligra en KDevelop zeer geliefd zijn, hebben ze maar weinig ontwikkelaars; je kunt daar eens kijken. Je hoeft geen ontwikkelaar van de KDE-werkruimte of het KDE-platform te zijn om mee te helpen. KDE-software is erg modulair, dus je kunt makkelijk één gebied verbeteren zonder te weten hoe de andere werken.

Je kunt ook vragen op kde-devel of iemand je hulp nodig heeft. Gebruik de nieuwste versie van je favoriete KDE-programma, en kijk waar er dingen nog ontbreken. Een themagenerator? Een Konsole-schemabewerker? Een spel dat verbeterd moet worden? Er is altijd wel iets wat beter kan. Implementeer dat!

Ben je bekend met een specifiek vakgebied? Kijk dan of er een gerelateerde applicatie is die je hulp kan gebruiken. Of schrijf er zelf een. KDE verwelkomt vooral wat meer applicaties die niet zijn gericht op experts.

Ik ben geen ontwikkelaar; hoe kan ik meehelpen?

Er zijn heel veel taken waarvoor geen ontwikkel-vaardigheden nodig zijn. Schrijf recenties van applicaties om publiciteit voor KDE te genereren (zie de maillijst kde-promo), help het documentatieteam (zie i18n.kde.org/doc), help de vertalers (zie i18n.kde.org), of help met het sorteren van de binnenkomende bug-rapporten (zie bugs.kde.org).

Waar kan ik afbeeldingen van het draakje Konqi vinden?

Een SDK voor Konqi is te vinden op ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
Deze stond eerst op artist.kde.org, maar deze site werd niet langer bijgehouden.

Meer afbeeldingen zijn te vinden op KDE-plaatjes.

Wat is het vereiste niveau om bij te dragen aan KDE? Wat moet ik leren? Wat moet ik lezen?

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

Hoe krijg ik KDE-software uit de KDE Git- of SVN-repository's?

See the "Building and Running KDE Software From Source" section on the Getting_Started page.

Kan ik de KDE-broncode online zien?

Jazeker:

Wat moet ik in mijn .subversion/config zetten?

[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

En verder, om svn diff witruimte te laten negeren en functienamen te laten weergeven:

[helpers]
diff-cmd = /usr/local/bin/_svndiff

met het volgende in /usr/local/bin/_svndiff:

#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"

Vergeet niet om /usr/local/bin/_svndiff uitvoerbaar te maken.

Ik wil mijn applicatie graag in KDE hebben...

Daar zijn drie vereisten voor:

  • je programma moet compileren met de recentste KDE-versie (git master of SVN trunk);
  • je programma moet stabiel zijn;
  • je programma moet onderhouden worden. Je krijgt waarschijnlijk een berg aan bug-rapporten en wensen. Mensen verwachten dat je de bugs oplost en de (nuttige) wensen inbouwt.

Zie ook de volgende vraag.

Kun je beter binnen of buiten KDE ontwikkelen?

Eén van de hoofd-ontwikkelaars, Waldo Bastian, legt uit in een gecopyrighte mail (vertaald uit het Engels):

Onderdeel uitmaken van KDE betekent dat je zult moeten samenwerken met anderen. Zulke samenwerking brengt voordelen, maar ook verantwoordelijkheden met zich mee.
Enkele van deze voordelen zijn: je code belandt in alle distributies, mensen gaan misschien jouw bugs oplossen, je krijgt vanzelf vertalingen en documentatie, en je krijgt ladingen aan bug-rapporten.
Aan de andere kant zijn er nadelen en verantwoordelijkheden: je zult moeten communiceren met andere ontwikkelaars over je werk, andere mensen kunnen jouw code aanpassen, je moet *freezes* voor releases respecteren, je krijgt ladingen aan bug-rapporten en mensen verwachten ook nog eens dat je die oplost (wat zijn die aan het roken?), en mensen verwachten dat je je code onderhoudt. Je kunt niet kiezen voor de voordelen, en de verantwoordelijkheden die erbij horen negeren; het is een compleet pakket; het is beide of niets. In het algemeen zou het de auteur van een stuk software moeten zijn die kiest om zijn applicatie in KDE's repository's op te nemen. Meestal zetten we geen software in KDE tenzij de auteur dat graag wil. Aan de andere kant, als de auteur graag ergens anders werkt aan zijn applicatie, dan heeft hij dat recht. Tenzij er een splitsing is in de groep mensen die werkt aan de applicatie, heeft het geen zin om de ontwikkeling van een applicatie te forken om die reden. MAAR... door je code onder een open-source-licentie te plaatsen, en het in een KDE-repository te plaatsen, geef je de hele wereld, en daarmee ook KDE in het bijzonder, het niet meer in te trekken recht om je code te gebruiken. En KDE zal dat recht, als dat nodig is, ook gebruiken om de belangen van KDE te beschermen, zelfs als dat dan tegen de wensen van de auteur ingaat.

Dat is belangrijk om te weten, maar wees niet bang. Meestal werkt het allemaal heel goed. In 5 jaar is het maar één keer voorgekomen dat werk van een ontwikkelaar in KDE gebleven is, terwijl deze ontwikkelaar het wilde verwijderen.

Hoe krijg ik schrijfrechten in de KDE-repository's?

Zie het volledige artikel op Bijdragen > Een KDE-contributor-account krijgen.

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 developer.kde.org)

A detailed list of rules you should follow when committing to KDE repositories are listed in the KDE Commit Policy.

Mijn programma is niet stabiel, maar ik wil het toch in KDE hebben...

Als een eerste stap kunnen we het in playground zetten; dat is een soort "kde-alfa". Ontwikkel het hier en als het klaar is, vraag dan of je applicatie verplaatst kan worden naar het geschikte KDE-pakket of de extragear-module.

Ik wil mijn SVN-geschiedenis niet verliezen...

Dit kan niet meer met Subversion. Misschien wel weer in de toekomst, als de server is bijgewerkt en dit wel weer mogelijk maakt. Merk op: voor Git is dit geen probleem.

Wat betekent kdebindings?

Dit bevat Qt-bindings voor Ruby, PHP en C# om Qt-klassen met deze talen te gebruiken, KDE-bindings voor Ruby, C# en Python om KDE-klassen met die talen te gebruiken, en XParts om niet-KDE-applicaties als een KPart te kunnen gebruiken. Bekijk verder de pagina over bindings van TechBase.

Geldt de feature freeze ook voor playground?

Nee, want de playground bevat pakketten die niet worden uitgebracht. Hetzelfde geldt voor kdereview en extragear: die worden ook niet bevroren en uitgebracht. Maar als je je applicatie wilt overbrengen naar een pakket, vraag dat dan voor de beta-versie is uitgebracht.

Kan ik een stabiele en een onstabiele KDE-versie op dezelfde computer gebruiken?

Ja, zie de documentatie over het bouwen van 2 versies.

Hoe weet ik welke versie van Qt/KDE ik gebruik?

kde-config en alle KDE-programma's hebben --version als argument op de terminal.

Welke zou het beste zijn: Qt-copy of Qt van qt.nokia.com, als iemand een schone build van trunk zou doen?

You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. Especially if building from qt-copy, pay attention to the apply-patches script.

Hoe kan ik een enkele map van een SVN-module uitchecken?

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.

Hoe kan ik één van de KDE-applicaties krijgen als een losstaande tarball?

kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

Hoe sluit ik mijn eigen bug-rapporten?

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.

Hoe maak ik een SSH-sleutel aan?

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.

Hoe kan ik op de hoogte blijven van aanpassingen die zijn gedaan door anderen?

The kde-commits mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.


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