Get Involved/development

By joining the ranks of KDE developers, you will get to implement new features and defeat bugs both daunting and simple, all while collaborating to make coherent and stable releases. Developers collaborate in teams based on what area they are working in. These can be small teams working on a single application, up to large teams working on a group of related pieces of software. Many developers are in more than one team.

KDE runs or participates in several mentoring programs to help new developers, including an informal list of people who are willing to help newcomers get started. See the Mentoring page for more details.

Prerequisites

Skills

Most KDE software is written in C++ using the Qt toolkit and KDE Frameworks. Though prior experience with these technologies or other programming languages is helpful, you don't need to be a C++ programmer to get started! For example, no programming knowledge whatsoever is required to do things like improve text labels.

If you'd like to dive deeper, the Qt wiki contains a list of online books for learning Qt programming. Qt also provides lots of examples you can look at. For visual learners, this YouTube playlist of QML tutorials by KDE patron KDAB may be useful. Finally, information about KDE Frameworks can be found on the KDE Developer Platform and KDE API website. Even more learning resources can be found here.

Operating system

For KDE development, we recommend a Linux operating system installed on your computer or in a virtual machine. Those that are best suited for development provide relatively recent versions of libraries needed by KDE software, and use the rolling-release model. Some examples are Arch, openSUSE Tumbleweed, and KDE neon. The latest versions of Fedora KDE or Kubuntu can work as well.

Support for Windows and macOS is still experimental, and you may likewise have a better experience doing your development in a virtual machine using a Linux distribution. Setting up a development environment on other operating systems--including FreeBSD--is an advanced topic.

The main way to develop KDE software: kdesrc-build

KDE uses a custom tool called kdesrc-build for setting up a development environment and building KDE software. You only need to set your environment up once, and then you can compile (and recompile) as often as needed.

Setting up your environment on a Linux machine is fairly simple. You will need to install a few programs to get started.

Set up a development environment with kdesrc-build

Once you have a development environment set up, you will be able to compile single applications or entire software stacks with kdesrc-build. One particular use that makes kdesrc-build convenient is the ability to compile a full Plasma session and be able to log in to it.

Start compiling KDE software using kdesrc-build

Once you have done changes to the program you chose, you will need to submit those changes to KDE. We use Invent, a Gitlab instance, which has a web interface to manage code submissions (called patches, or Merge Requests), and this can be done from the terminal as well.

Submit your new software changes for review

Once you have finished learning how to use kdesrc-build, you might see yourself having certain needs, such as having a separate build of KDE based on Qt5 in addition to your current Qt6 one, managing different branch groups, or managing builds using your preferred Integrated Development Environment (IDE). Those are all covered in the advanced section. This section is optional.

Advanced kdesrc-build features and troubleshooting

Choose what to work on

A good place to start is with a small bug or feature in an existing piece of software that affects you personally ("scratch your own itch"). Get in touch with the existing developers (see Communicate with the dev team, below) and they can help you out, by pointing you to the right place in the code and giving advice about how to tackle the problem.

Try not to start by proposing or working on major features or significant design changes. These can be controversial, and the smoothest way to get going is by working on relatively non-controversial bugfixes. Start slowly and build trust!

Here are some other ideas for starting points:

• Improve awkwardly-worded messages and labels that are written in English. This is a great way for non-programmers to contribute! If you can compile software and have a good grasp of English, you can make a big difference here.
• Work on Junior Jobs, which are small tasks that are suitable for beginners (both bugs and features).
• Work on Bugs related to KDE's Usability & Productivity initiative, many of which are small and easy.
• More easy tasks.

Make your changes and test them

Once you've made some changes, make sure the project still compiles and installs, and make sure the changes have the desired effect when you run the software. Then it's time to run the project's test suite. For example, in KCalc:

cd ~/kde/build/kcalc
source prefix.sh
ctest --output-on-failure

If any test fails, that needs to be investigated and fixed before you can proceed. Once the tests pass, then run the software again to make sure it still behaves properly. If it doesn't, then go back and work on your patch some more, then re-compile and re-deploy, and test again, until the program does what you'd like it to do and all tests pass.

Communicate with the dev team

There are several ways to get in touch with KDE developers, either generally or for a specific project. The most important communications channels are:

• Real-time chat: #kde-devel room on Matrix
• Forum: Development forum on discuss.kde.org
• Mailing list: : kde-devel (Learn more about mailing lists)

These are general KDE development communication channels, and you may get directed to a more appropriate place for the project you are interested in. There is a list of mailing lists if you want to find a mailing list for a specific team directly. Many teams have their own real-time chat channels, too.

You can also try looking for the team's section on the Main Page of this wiki. Many teams have information there for new contributors.

Source code cross referencing

To search for a class, method, signal name... etc in all KDE repos, KDE uses a code referencing tool to index code in the various KDE repositories, you can search using the web interface available at https://lxr.kde.org/ . This is a very useful tool if you e.g. want to search for code usage examples in existing code... etc.

Usage:

• From the Branch group menu, you can select either kf5-qt5, to search the code in the Git master branches or stable-kf5-qt5 to search only the stable (released) branches
• There are two search modes:
  • On the Identifier search page, you can search for (note that this is case sensitive):
    • class names, e.g. RenameDialog, StatJob, and of course any Qt class (used in KDE code, which is pretty much all of them), QLatin1String, QListWidget
    • method names, e.g. addConfigSources() (from the KConfig framework) and signal names e.g. mimeTypeFound()
  • on the General search page, you can search for strings, e.g. in Dolphin's context menu (accessed by right- clicking any empty space) there is Paste Clipboard Contents, if you want to find in which source file this string is defined, search for Paste Clipboard Contents; this search includes classes/methods/signals names.

Other ways to search across all of the KDE git repositories:

• If you have a github.com account. Log into github.com. Go to https://github.com/KDE , in the top left search bar, search for your search term e.g. KMessageBox, select "In this organization".
• kdesrc-build --src-only will download the source code of more than 300 KDE git repositories in ~/kde/src. Search inside this directory. E.g. using Microsoft Visual Studio Code code ~/kde/src, from the vscode main menu > Edit > Find in Files Ctrl+Shift+F.

Next steps

Sharpen your skills by going through the KDE development tutorials.

After you have had several drama-free patches accepted, a KDE developer is likely to suggest you get a Developer account, which will allow you to commit directly to KDE projects. With very few limits on where you can commit, you will be expected to act responsibly. At this point, congratulations! You are officially a KDE developer!

Best practices & other useful information

• Frequently discussed topics and lessons learned regarding the development of user-facing GUI software
• Debugging
• Unit testing
• Validating code
• Writing API documentation (related: https://api.kde.org).
• Correctly state license information
• Writing Wayland-friendly code
• Running applications and their unit tests without first installing them
• How to review merge requests

Advanced Topics

This page continues with more advanced topics.