Get Involved/development: Difference between revisions

From KDE Community Wiki
m (Fix minor typo)
(→‎Next steps: GitLab forks)
 
(346 intermediate revisions by 72 users not shown)
Line 1: Line 1:
[[File:Konqui dev close cropped.png|right|x200px|]]
[[File:Mascot konqi-app-dev.png|right|x250px|]]
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.
By joining the ranks of KDE developers, you will get to implement new features and defeat bugs both daunting and simple. Developers collaborate in teams based on what area they are working on. These can be small teams working on a single application, up to large teams working on a group of related pieces of software, or even meta-teams working on broader topics such as QA or automation. Many developers participate 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.
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.


== New to C++/Qt software development? ==
== Where to find the development team ==
Most KDE software is written in C++ using the [https://www.qt.io Qt toolkit] and [[Frameworks | 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.


{{Note|The Qt wiki contains [https://wiki.qt.io/Books a list of online books] for learning Qt programming. Qt also provides [http://doc.qt.io/qt-5/qtexamplesandtutorials.html lots of examples] you can look at. Information about KDE Frameworks can be found on the [https://techbase.kde.org TechBase wiki], and a [[Books | book]] is available.}}
The KDE developers are here to assist you if you need any help following this guide.


== One-time setup: your development environment ==
There are several ways to get in touch with KDE developers, either generally or for a specific project. The most important communication channels are:
To build software, you need a '''development environment''': a set of tools that allows you to access and edit source code, compile it into a form that the computer can run, and deploy it to a safe location. We will now go through the process of setting one up. To accomplish these tasks, you will need to enter commands using a terminal program, such as KDE's Konsole (any terminal program will suffice though).
* '''Real-time chat:''' [irc://irc.libera.chat/kde-devel #kde-devel] room on the [http://libera.chat/ Libera Chat] IRC network (which is mirrored to the [https://webchat.kde.org/#/room/#kde-devel:kde.org #kde-devel] room on [[Matrix]])
* '''Forum:''' [https://discuss.kde.org/c/development/10 Development forum] on discuss.kde.org
* '''Mailing list:''' [https://mail.kde.org/mailman/listinfo/kde-devel kde-devel] ([http://kde.org/support/#mailinglists Learn more about mailing lists])


{{Note|If you're not familiar with the command line interface, you can [https://lifehacker.com/5633909/who-needs-a-mouse-learn-to-use-the-command-line-for-almost-anything find a reasonable tutorial here]. However advanced command-line skills are not required, and you will learn what you need along the way!}}
These are general KDE development communication channels, and you may be directed to a more appropriate place for the project you're interested in.


'''Everything in this section only needs to be done once.''' Once you've done it, your development environment is set up and you can use it to submit patches and develop KDE Software!
* Many projects and teams have their own real-time chat channels, which can be found on the [[Matrix#Rooms|Matrix Rooms]] page.
* There is a [http://www.kde.org/mailinglists/ list of mailing lists] if you want to find a mailing list for a specific team directly.


The [[Main Page]] of this wiki includes links to specific development teams and the [[Get Involved]] page includes links to more general contribution teams.


=== Install basic tools ===
== Prerequisites ==
First you will need to use your operating system's package manager to install some basic tools:
* Arch/Antergos/Manjaro: <code>sudo pacman -S git cmake dialog</code>
* Fedora: <code>sudo dnf install git cmake dialog</code>
* KDE Neon/Kubuntu/Ubuntu/Debian: <code>sudo apt install git cmake dialog</code>
* openSUSE Leap & Tumbleweed: <code>sudo zypper install git cmake dialog</code>
<br />
Some operating systems also require that you turn on the source repositories before you can install build dependencies (more about that later). Do that now, if necessary:
* Kubuntu/Ubuntu/Debian: https://askubuntu.com/questions/158871/how-do-i-enable-the-source-code-repositories
* openSUSE Leap & Tumbleweed: <code>sudo zypper mr -e $(zypper repos | awk '/source/{print $5}'))</code>


=== Skills ===


=== Configure Git ===
Most KDE software is written in C++ using the [https://www.qt.io Qt toolkit] and [https://develop.kde.org/products/frameworks/ 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 improving text labels.
We need to set your authorship information properly so that any changes you make can be properly attributed to you:
<pre>
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
</pre>


Now we will set up a '''Git prefix''' to make it easier to interact with KDE's remote Git repositories. Use a text editor to open the <tt>~/.gitconfig</tt> file and add the following:
If you'd like to dive deeper, the Qt wiki contains [https://wiki.qt.io/Books a list of online books] for learning Qt programming. Qt also provides [https://doc.qt.io/qt-5/qtexamplesandtutorials.html lots of examples] you can look at. For visual learners, [https://www.youtube.com/watch?v=JxyTkXLbcV4&list=PL6CJYn40gN6hdNC1IGQZfVI707dh9DPRc this YouTube playlist of QML tutorials] by KDE patron [https://www.kdab.com KDAB] may be useful. Finally, information about KDE Frameworks can be found on the [https://develop.kde.org/docs KDE Developer Platform] and [https://api.kde.org/ KDE API website]. We also provide a [[Get_Involved/development/Learn|wiki page full of learning resources]].


<syntaxhighlight lang="ini">
=== Operating system ===
[url "https://anongit.kde.org/"]
    insteadOf = kde:
    pushInsteadOf = kde:
</syntaxhighlight>


Then save the file and close it. This essentially tells Git to accept "kde:" in place of "https://anongit.kde.org/", which allows us to check out repositories more easily, as we will soon see.
For KDE development, we recommend a Linux operating system installed on your computer or in a [[/Developing_in_a_virtual_machine|virtual machine]]. The ones best suited for development provide relatively recent versions of libraries needed by KDE software, and use the "[https://en.wikipedia.org/wiki/Rolling_release rolling release]" model. Some examples are Arch Linux, openSUSE Tumbleweed, Solus and KDE neon User Edition. The latest version of Fedora KDE usually works as well.


We recommend that you use the KDE Plasma desktop on your Linux operating system.


=== Set up kdesrc-build ===
Support for Windows and macOS are still experimental, and you may have a better experience [[/Developing in a virtual machine|doing your development in a virtual machine using a Linux distribution]]. Setting up a development environment on [[/More#Other_operating_systems|other operating systems--including FreeBSD]]--is an advanced topic.
Next, we need a method of '''managing dependencies'''. All software has dependencies: other pieces of software that provide functionality they rely on. In order to compile any piece of software, its dependencies must be available.


Most Linux-based operating systems do not provide development packages that are up-to-date enough for working on KDE software, so we will compile all the KDE dependencies ourselves. To do this, we use a command-line tool called <code>kdesrc-build</code> to download, manage, and build KDE source code repositories. Let's set it up now:
== The main way to develop KDE software: kde-builder ==


<pre>
KDE uses a custom tool called '''kde-builder''' for setting up a development environment and building KDE software. You only need to set up your environment once, and then you can compile (and recompile) KDE software as often as needed.
mkdir ~/kde
cd ~/kde
git clone kde:kdesrc-build
cd kdesrc-build
</pre>


Notice how we're using the "kde:" prefix in our <code>git clone</code> command!
Setting up your environment on a Linux machine is fairly simple. You'll need to install a few programs to get started.


We want to add <code>kdesrc-build</code> to your system's <tt>$PATH</tt> variable so you can access it from anywhere, not just when you're inside <tt>~/kde/kdesrc-build</tt>. Use a text editor to open the <tt>~/.bashrc</tt> file and add <tt>export PATH=~/kde/kdesrc-build:$PATH</tt>. Then save the file and close it.


Next, set up <code>kdesrc-build</code> using its built-in wizard. The default options should be ok, but feel free to customize anything:
{{CenteredButtonExt|text=Set up a development environment with kde-builder|link=https://develop.kde.org/docs/getting-started/building/kde-builder-setup/}}
<pre>
./kdesrc-build-setup
</pre>
{{Note|Do not quote or escape any file paths entered in the wizard}}




=== Set up a runtime environment ===
Once you have a development environment set up, you'll be able to compile single applications or entire software stacks with kde-builder. One particular use that kde-builder makes convenient is compiling a full KDE Plasma session so you can dive into it.
In order to run the software that you're going to compile and install, you need to set up your '''runtime environment''': a method to run installed software from a particular location. The operating system sets one up automatically for any software installed to <tt>/usr</tt>, but since we've installed our custom-compiled software to <tt>~/kde/usr</tt>, we'll need to set up a runtime environment to let us run software from there.


Create a new file called <tt>~/kde/.setup-env</tt> and copy the following text into it:


<syntaxhighlight lang="sh">
{{CenteredButtonExt|text=Start compiling KDE software using kde-builder|link=https://develop.kde.org/docs/getting-started/building/kde-builder-compile/}}
export KF5=$HOME/kde/usr
export QTDIR=/usr 
export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH 
export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share 
export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg 
export PATH=$KF5/bin:$QTDIR/bin:$PATH 
export QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH 
# (lib64 instead of lib on some systems, like openSUSE)
export QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml 
export QML_IMPORT_PATH=$QML2_IMPORT_PATH 
export KDE_SESSION_VERSION=5 
export KDE_FULL_SESSION=true
export SASL_PATH=/usr/lib/sasl2:$KF5/lib/sasl2
# (lib64 instead of lib on some systems, like openSUSE)
PS1="(kdesrc) $PS1"
</syntaxhighlight>


Now your development environment is set up and ready to build software! Let's take it for a spin and compile some software.


Once you've made some changes to a piece of KDE software, you'll need to submit those changes to KDE for inclusion in the next release. We use a GitLab instance hosted at invent.kde.org, which has a web interface to manage source code submissions (called "Merge Requests"), and this can be done from the terminal as well.


== Build some software ==
{{CenteredButton|text=Submit your new software changes for review|link=Infrastructure/GitLab#Submitting_a_merge_request}}
Remember our earlier discussion about dependencies? We use <code>kdesrc-build</code> to manage dependencies on other KDE software, but most pieces of KDE software also depend on system libraries that are not owned or controlled by KDE. We use the operating system's package manager to get these.


Let's now do this to fetch the dependencies for a simple test project: <tt>extra-cmake-modules</tt>
* Arch/Antergos/Manjaro: <code>sudo pacman -S extra-cmake-modules</code>
* Fedora: <code>sudo dnf builddep extra-cmake-modules</code>
* KDE Neon/Kubuntu/Ubuntu/Debian <code>sudo apt build-dep extra-cmake-modules</code>
* openSUSE Leap & Tumbleweed: <code>sudo zypper si -d extra-cmake-modules</code>
<br />
Now let's use <code>kdesrc-build</code> to download, compile, and install <tt>extra-cmake-modules</tt>:
<pre>
cd ~/kde
kdesrc-build extra-cmake-modules
</pre>


Did that work? Great! Now let's build the Dolphin file manager. First download the non-KDE dependencies:
Once you've got kde-builder set up, you might also want to configure an IDE of your choice for a more convenient workflow. This is optional.
* Arch/Antergos/Manjaro: <code>sudo pacman -S dolphin</code>
* Fedora: <code>sudo dnf builddep dolphin</code>
* KDE Neon/Kubuntu/Ubuntu/Debian <code>sudo apt build-dep dolphin</code>
* openSUSE Leap & Tumbleweed: <code>sudo zypper si -d dolphin</code>
<br />
...Then use <code>kdesrc-build</code> to download and compile Dolphin's KDE dependencies and then finally Dolphin itself:
<pre>
cd ~/kde
kdesrc-build dolphin
</pre>


Did everything work? Fantastic. As a part of this process, Dolphin was installed to <tt>~/kde/usr/bin/dolphin</tt>. <tt>source</tt> the <tt>~/kde/.setup-env</tt> file every time you want to run your custom-compiled KDE software:
<pre>
source ~/kde/.setup-env
~/kde/usr/bin/dolphin
</pre>


Did it run? If so, then '''congratulations, you just compiled your own version of Dolphin from source code!'''
{{CenteredButtonExt|text=Configure the Integrated Development Environment|link=https://develop.kde.org/docs/getting-started/building/ide/}}




== Choose what to do ==
Once you've finished learning how to use kde-builder, you might see yourself having certain needs, such as managing different branch groups or having separate builds of KDE software based on Qt6 and Qt5. Those topics are covered in the advanced section. This section is optional.
Now that you can compile and deploy custom versions of KDE software, you can open your editor and get hacking! The code for the version of Dolphin hat you just built is located at <tt>cd ~/kde/build/kde/applications/dolphin/</tt>; other projects you use <code>kdesrc-build</code> to download will be in similar locations.


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 [[#Communicating with the team|Communicating with the 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
{{CenteredButton|text=Advanced kde-builder features and troubleshooting|link=Get_Involved/development/More}}


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 bug-fixes. Start slowly and build trust!
== 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 [[#Where to find the development team|Where to find the development 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:
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.
* 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 [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&list_id=1340815 Junior Jobs], which are small tasks that are suitable for beginners (both bugs and features).
* Work on Junior Jobs, which are small tasks that are suitable for beginners (both bugs and features). You can find them available both on [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&list_id=1340815 Bugzilla] and [https://invent.kde.org/dashboard/issues?sort=created_date&state=opened&label_name%5B%5D=Junior+Job Gitlab].
* Work on [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=usability&keywords_type=allwords&list_id=1493316&order=product%2Cchangeddate%20DESC%2Cbug_status%20DESC%2Cresolution%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced Bugs related to] KDE's [[Goals/Usability_%26_Productivity | Usability & Productivity initiative]], many of which are small and easy.
* Work on [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&keywords=usability&keywords_type=allwords&list_id=1493316&order=product%2Cchangeddate%20DESC%2Cbug_status%20DESC%2Cresolution%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced Bugs related to] KDE's [[Goals/Usability_%26_Productivity | Usability & Productivity initiative]], many of which are small and easy.
* [http://www.englishbreakfastnetwork.org/ The English Breakfast Network] searches out simple, common issues in code that should be fixed, and going through the problems on there can provide a good overview of the code.
* Write [[App ideas|small useful apps]].
 
 
== Test your patch ==
At this point, you have a patch. Make sure the project still compiles and installs, and make sure the patch has the desired effect when you run the software. Now it's time to run the project's unit tests:
<pre>
source ~/kde/.setup-env
cd ~/kde/build/kde/applications/dolphin/<project>
make test
</pre>
 
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.
 
 
== Submit your patch ==
Once you're happy with your patch and have verified that it does what you want, it's time to '''generate a diff.''' A diff is a textual representation of the differences between original versions of the files you changed, and the new ones you've produced. You can generate a diff by running <code>git diff</code>, but we recommend using the <code>arc</code> tool, which will generate a diff and submit the patch for you! You can learn how to set it up [https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches here].


KDE uses [https://phabricator.kde.org Phabricator] for patch submission and review. [[Infrastructure/Phabricator | Learn how to submit a patch with Phabricator]].
== Source code cross-referencing ==


To search for an identifier (e.g. class name, method name, signal name) or for free-text search in all KDE git repositories, KDE provides a code referencing tool 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.


== Communicate with the team ==
Usage:
There are several ways to get in touch with KDE developers, either generally or for a specific project. The two most important communications channels are:
* From the '''Branch group''' menu, you can select either '''kf6-qt6''', to search the code in the Git ''master'' branches or '''stable-kf6-qt6''' to search only the stable (released) branches.
* The [http://webchat.freenode.net/?channels=kde-vdg #kde-devel] freenode [[Internet Relay Chat | IRC channel]], which is where KDE developers chat in real time about their work
* There are two search ''modes'':
* The [https://mail.kde.org/mailman/listinfo/kde-devel kde-devel mailing list] is the primary development mailing list. [http://kde.org/support/#mailinglists learn more about mailing lists].
** 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''
Both of 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 [http://www.kde.org/mailinglists/ list of mailing lists] if you want to find a mailing list for a specific team directly. Many teams have their own [[Telegram]] rooms, too.
*** 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.
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.


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 , at the top of the page in the search bar ("Type / to search"), write your search term e.g. <code>KMessageBox</code>, select "In this organization". In order to search case sensitive and whole words, you can use case sensitive regex e.g. <code>org:KDE /(?-i)\bKMessageBox\b/</code>.
* <code>kde-builder --src-only</code> will download the source code of more than 300 KDE git repositories in <code>~/kde/src</code>. Search inside this directory. E.g. using Microsoft Visual Studio Code, from a terminal run the command line <code>code ~/kde/src</code>, from the vscode main menu > Edit > Find in Files Ctrl+Shift+F.


== Next steps ==
== Next steps ==
After you have had several patches accepted, a KDE developer is likely to suggest you get a [[Infrastructure/Get a Developer Account|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!
Sharpen your skills by going through the [https://develop.kde.org/docs/ KDE development tutorials].


You may also want to set up a more permanent or advanced development environment, which will be very handy to start working on KDE Frameworks or Plasma itself. See [[Guidelines and HOWTOs/Build from source]]
After you have had several drama-free patches accepted, a KDE developer is likely to suggest you get a [[Infrastructure/Get a Developer Account|Developer account]], which will allow you to do git commits directly to KDE projects without the need of GitLab forks. 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 ==


== Best practices & other useful information==
* [[Get Involved/Design/Frequently Discussed Topics|Frequently discussed topics and lessons learned regarding the development of user-facing GUI software]]
* [[Guidelines_and_HOWTOs/Debugging|Debugging]]
* [[Guidelines_and_HOWTOs/Debugging|Debugging]]
* [[Guidelines and HOWTOs/UnitTests|Unit testing]]
* [[Guidelines and HOWTOs/UnitTests|Unit testing]]
* [[Guidelines and HOWTOs/Code_Checking| Validating code]]
* [[Guidelines and HOWTOs/Code_Checking| Validating code]]
* [[Guidelines and HOWTOs/API Documentation|Writing API documentation]] (related: https://api.kde.org).
* [[Guidelines and HOWTOs/API Documentation|Writing API documentation]] (related: https://api.kde.org).
* [[Guidelines and HOWTOs/Licensing|Correctly state license information]]
* [[Guidelines_and_HOWTOs/Wayland_Porting_Notes|Writing Wayland-friendly code]]
* [[Guidelines_and_HOWTOs/Wayland_Porting_Notes|Writing Wayland-friendly code]]
* [[Frameworks/Porting_Notes|Porting from KDE 4 to Frameworks 5]]
* [[Guidelines_and_HOWTOs/Making_apps_run_uninstalled|Running applications and their unit tests without first installing them]]
* [[Guidelines_and_HOWTOs/Making_apps_run_uninstalled|Running applications and their unit tests without first installing them]]
* [http://www.kdevelop.org Using KDevelop], a KDE IDE
* [[Infrastructure/GitLab#Testing_someone_else's_merge_request|How to review merge requests]]
 
== Advanced Topics ==
 
This page continues with [[Get_Involved/development/More|more advanced topics]].

Latest revision as of 18:21, 26 October 2024

By joining the ranks of KDE developers, you will get to implement new features and defeat bugs both daunting and simple. Developers collaborate in teams based on what area they are working on. These can be small teams working on a single application, up to large teams working on a group of related pieces of software, or even meta-teams working on broader topics such as QA or automation. Many developers participate 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.

Where to find the development team

The KDE developers are here to assist you if you need any help following this guide.

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

These are general KDE development communication channels, and you may be directed to a more appropriate place for the project you're interested in.

  • Many projects and teams have their own real-time chat channels, which can be found on the Matrix Rooms page.
  • There is a list of mailing lists if you want to find a mailing list for a specific team directly.

The Main Page of this wiki includes links to specific development teams and the Get Involved page includes links to more general contribution teams.

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 improving 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. We also provide a wiki page full of learning resources.

Operating system

For KDE development, we recommend a Linux operating system installed on your computer or in a virtual machine. The ones best suited for development provide relatively recent versions of libraries needed by KDE software, and use the "rolling release" model. Some examples are Arch Linux, openSUSE Tumbleweed, Solus and KDE neon User Edition. The latest version of Fedora KDE usually works as well.

We recommend that you use the KDE Plasma desktop on your Linux operating system.

Support for Windows and macOS are still experimental, and you may 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: kde-builder

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

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


Set up a development environment with kde-builder


Once you have a development environment set up, you'll be able to compile single applications or entire software stacks with kde-builder. One particular use that kde-builder makes convenient is compiling a full KDE Plasma session so you can dive into it.


Start compiling KDE software using kde-builder


Once you've made some changes to a piece of KDE software, you'll need to submit those changes to KDE for inclusion in the next release. We use a GitLab instance hosted at invent.kde.org, which has a web interface to manage source code submissions (called "Merge Requests"), and this can be done from the terminal as well.

Submit your new software changes for review


Once you've got kde-builder set up, you might also want to configure an IDE of your choice for a more convenient workflow. This is optional.


Configure the Integrated Development Environment


Once you've finished learning how to use kde-builder, you might see yourself having certain needs, such as managing different branch groups or having separate builds of KDE software based on Qt6 and Qt5. Those topics are covered in the advanced section. This section is optional.

Advanced kde-builder 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 Where to find the development 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). You can find them available both on Bugzilla and Gitlab.
  • Work on Bugs related to KDE's Usability & Productivity initiative, many of which are small and easy.
  • Write small useful apps.

Source code cross-referencing

To search for an identifier (e.g. class name, method name, signal name) or for free-text search in all KDE git repositories, KDE provides a code referencing tool 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.

Usage:

  • From the Branch group menu, you can select either kf6-qt6, to search the code in the Git master branches or stable-kf6-qt6 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 , at the top of the page in the search bar ("Type / to search"), write your search term e.g. KMessageBox, select "In this organization". In order to search case sensitive and whole words, you can use case sensitive regex e.g. org:KDE /(?-i)\bKMessageBox\b/.
  • kde-builder --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, from a terminal run the command line 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 do git commits directly to KDE projects without the need of GitLab forks. 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

Advanced Topics

This page continues with more advanced topics.

Retrieved from "https://community.kde.org/index.php?title=Get_Involved/development&oldid=102034"