We all agree that there are plenty of KDE applications that need to be written. But there are also a lot of existing kde applications that need your help.
To see the areas where help is needed, check this page.
Before starting a new application, it's always a good idea to check www.kde-apps.org for existing applications and to ask on the email@example.com mailing-list whether someone is already working on a similar project.
Check the open jobs from the job list, there is certainly one that you can take. KOffice and KDevelop, despite being very praised, have very few developers, so you might check there. There is no need to be a KDE core-developer to help. KDE is very modular so you can perfectely improve one area without knowing how the whole system works.
You can also ask on kde-devel if someone needs help on an application. Use the latest version of KDE and spot things that are needed. A theme generator? A konsole schema editor? Improve a game? There is always a small feature missing. Go and implement it!
Are you familiar or attracted with a specific field? See if there is a related application that could use your help. Or write one. KDE needs more non-geek oriented applications.
There are plenty of tasks that don't require development skills. Write reviews of applications for the promoting of KDE (see the kde-promo mailing-list), help the documentation team (see i18n.kde.org/doc), help the translations (see i18n.kde.org), help to filter the incoming bugs (see bugs.kde.org).
The Konqi for some people SDK is at ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
It was posted to artist.kde.org before that site ceased to be updated.
Further images are on KDE merchandise.
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. http://techbase.kde.org and doc.trolltech.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.
See the Anonymous SVN page.
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
And to make svn diff ignore whitespace, and print function names:
diff-cmd = /usr/local/bin/_svndiff
with the following in /usr/local/bin/_svndiff:
exec /usr/bin/diff -b -u -p "$@"
Don't forget to make /usr/local/bin/_svndiff executable.
There are three requirements:
See also the next question.
As core developer Waldo Bastian explains in a copyrighted mail:
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.
See full article at Contribute > Get a SVN Account.
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.
Please 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 SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (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 is no restrictions on SVN rights, we expect you not to mess up 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 the KDE SVN repository are listed in the KDE SVN Commit Policy.
As a first step, we can put it in playground (=kde-alpha). Develop it there and when it is ready, ask your app to be moved to the appropriate KDE package or the extragear module.
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.
It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.
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.
Yes, check the Building 2 Versions documentation.
Launch the KDE Control Center. The splash screen includes Kde version information.
kde-config and all kde programs accept --version as argument.
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. In special, if building qt-copy, pay attention to the apply-patches script.
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.
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.
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 happens 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:
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 unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.
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 seperate 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.
The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. 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.