Get Involved/development: Difference between revisions

From KDE Community Wiki
No edit summary
(Undo revision 82382 by Ngraham (talk))
(34 intermediate revisions by 8 users not shown)
Line 5: Line 5:




= Choosing what to do =
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.


Other starting points are:
== New to C++/Qt software development? ==
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.}}
 
 
 
== One-time setup: your development environment ==
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).
 
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!
 
{{Note|'''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!}}
 
 
=== Install basic tools ===
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>
 
 
=== Configure Git ===
We need to set your authorship information properly so that any changes you make can be properly attributed to you:
{{Input|1=<nowiki>
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
</nowiki>}}
 
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:
 
<syntaxhighlight lang="ini">
[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.
 
 
=== Set up kdesrc-build ===
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:
 
{{Input|1=<nowiki>
mkdir -p ~/kde
cd ~/kde</code>
git clone kde:kdesrc-build
</nowiki>}}
 
Notice how we're using the "kde:" prefix in our <code>git clone</code> command!
 
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:
{{Input|1=<nowiki>
kdesrc-build --initial-setup
</nowiki>}}
{{Note|Do not quote or escape any file paths entered in the wizard}}
 
 
=== Download the non-KDE dependencies ===
Even though <code>kdesrc-build</code> will take care of the KDE dependencies for you, it does not yet have the ability to install the non-KDE dependencies (see https://bugs.kde.org/show_bug.cgi?id=402428), which are typically acquired using your package manager. Go [[Guidelines and HOWTOs/Build from source/Install the dependencies|install the non-KDE dependencies]] now.
 
Once that's done, your development environment is set up and ready to build software! Let's take it for a spin.
 
{{Note|It can take an hour or more to compile a KDE Application, Framework, or Plasma itself for the first time. The reason for this is that <code>kdesrc-build</code> is compiling ''all'' of the KDE dependencies. The next time you want to compile that or any other piece of KDE software, it will be much faster since most of the dependencies will have already been compiled.}}
 
 
 
== Build some software ==
=== Applications ===
'''[[KDE Applications]]''' like Dolphin, Okular, Konsole and Gwenview are standalone apps that can be run on multiple platforms, such as Plasma, GNOME, even macOS and Windows! New versions of KDE Applications are [[Schedules/Applications/18.12 Release Schedule|released three times a year]]. Note that the Discover app store (git repo name: <tt>plasma-discover</tt>) and System Settings app (git repo name: <tt>systemsettings</tt>) are distributed alongside Plasma, but they build like apps app using the below instructions. A list of all KDE applications can be found here: https://userbase.kde.org/Applications
 
For example, here is how to build Dolphin, the KDE file manager:
 
{{Input|1=<nowiki>
kdesrc-build dolphin
</nowiki>}}


* [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=junior-jobs&list_id=1340815 Junior Jobs] are small tasks that are suitable for beginners (both bugs and features)
As a part of this process, Dolphin was installed to <tt>~/kde/usr/bin/dolphin</tt>. <tt>source</tt> the project's auto-generated <tt>prefix.sh</tt> file every time you want to run your custom-compiled version of Dolphin:  
* [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 [https://phabricator.kde.org/T6831 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


= New to (C++/Qt) software development? =
{{Input|1=<nowiki>
Most KDE software is written in C++ using the [https://www.qt.io Qt framework]. There are many guides to C++ online, and which one works for you will depend on how you learn best and what previous programming experience you have.
source ~/kde/build/kde/applications/dolphin/prefix.sh
~/kde/usr/bin/dolphin
</nowiki>}}


For learning Qt, you can find [https://wiki.qt.io/Books a list of books for learning Qt] on the Qt wiki. Qt also provides [http://doc.qt.io/qt-5/qtexamplesandtutorials.html lots of examples] you can look at.
Did it run? If so, then '''congratulations, you just compiled your own version of Dolphin from source code!'''


Most KDE software is also built on other KDE software, particularly the KDE Frameworks. The [https://techbase.kde.org TechBase wiki] has documentation about using these libraries, and a [[Books | book]] is available. See also [[Guidelines and HOWTOs/Development]].


= Get the code =
=== Frameworks ===
First you will need to use your distro's package manager to install some basic tools:
'''[[Frameworks|KDE Frameworks]]''' are libraries of tools and features that can be used by any application or Plasma itself. New versions of KDE Frameworks are [[Schedules/Frameworks|released once a month]]. A list of all frameworks can be found here: https://api.kde.org/frameworks/index.html
* Debian/Ubuntu/KDE Neon: <pre>sudo apt install git cmake</pre>
* Fedora: <pre>sudo dnf install git cmake</pre>
* openSUSE: <pre>sudo zypper install git cmake</pre>
* Arch/Antergos/Manjaro: <pre>sudo pacman -S git cmake</pre>


Next, create a folder to hold all the source code repositories you're going to be downloading!
For example, here is how to build the KIO framework:
<pre>
mkdir ~/repos
cd ~/repos
</pre>


Now download the source code for the project you would like to work on. All the KDE git repositories can be found at [https://cgit.kde.org/ here]. If you are not familiar with [https://git-scm.com/ Git], the [https://git-scm.com/book Git Book] is a good introduction, but you will learn what you need here if you're new to <tt>git</tt>.
{{Input|1=<nowiki>
kdesrc-build kio
</nowiki>}}


Now find the official project/repository name of the software you want to work on. most are identical to the software's name; e.g. the repository name for Okular is okular. You can find the full list at https://cgit.kde.org/. Then clone the repo:
Now you can run an existing app using your custom-made version of the framework! For example, the following will run Dolphin, but it will be using the KIO library that you just built:
<pre>
git clone git://anongit.kde.org/<project/repository name>.git
</pre>


= Set up your development environment =
{{Input|1=<nowiki>
First of all, don't worry about this process destabilizing your machine. Your existing software is installed to <tt>/usr</tt>, and when you produce own patched software, it will be installed to <tt>/opt/kde</tt> leaving the original software untouched.
source ~/kde/build/frameworks/kio/prefix.sh
~/kde/usr/bin/dolphin
</nowiki>}}


In order to compile a piece of KDE software, you will first need to use your distro's package manager to download the dependencies for the project you would like to patch, so that it will compile.  
=== Plasma ===
'''[[Plasma|KDE Plasma]]''' is the environment in which you can run apps. Plasma is responsible for providing a desktop with wallpaper, app launchers, and widgets; displaying notifications; managing wired and wireless networks; and similar operating-system level tasks. New versions of Plasma are [[Schedules/Plasma 5|released three times a year]].


The way to do this varies according to your distro (If you don't see it listed below, it is not a recommended development platform):
Here is how to will build the Plasma desktop environment and its window manager, KWin:
=== KDE Neon ===
<pre>
sudo apt build-dep <repo/package name>
</pre>


=== Kubuntu ===
{{Input|1=<nowiki>
First add the [https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports Kubuntu Backports PPA], which will upgrade your system to use newer KDE software:
kdesrc-build plasma-desktop plasma-workspace plasma-framework kwin
{{Warning|Due to the nature of package dependencies, this will upgrade the entire KDE software stack. Do not proceed unless you are okay with this.}}
</nowiki>}}
<pre>
sudo add-apt-repository ppa:kubuntu-ppa/backports
sudo apt update
sudo apt full-upgrade
</pre>
Then install the dependencies for the software you want to work on:
<pre>
sudo apt build-dep <repo/package name>
</pre>


=== Fedora ===
To run your custom-built Plasma, [[Guidelines and HOWTOs/Build from source/Test plasma|follow these instructions]].
First add the <insert thing here> Copr, which will upgrade your system to use newer KDE software:
{{Warning|Due to the nature of package dependencies, this will upgrade the entire KDE software stack. Do not proceed unless you are okay with this.}}
<pre>
[Insert method of updating KDE packages in Fedora here]
</pre>
Then install the dependencies for the software you want to work on:
<pre>
sudo dnf builddep <repo/package name>
</pre>


=== openSUSE Tumbleweed ===
First enable the source repository:
<pre>
sudo zypper mr -e repo-source
</pre>
Then install the dependencies for the software you want to work on:
<pre>
sudo zypper si -d <repo/package name>
</pre>


=== Arch/Antergos/Manjaro ===
== Choose what to do ==
<pre>
Now that you can compile and deploy custom versions of KDE software, you can open your editor and start hacking on the source code! The code for the version of Dolphin that you built earlier is located at <tt>~/kde/src/kde/applications/dolphin/</tt>; other projects you build with <code>kdesrc-build</code> will live in similar locations.
sudo pacman -S git <repo/package name>
</pre>
<br/><br/>


== Compile the software ==
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.


Before you work on your patch, try to compile the software to make sure that your development environment is set up properly:
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!


<pre>
Here are some other ideas for starting points:
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/kde/ ..
make
</pre>
(Notice how we are telling CMake to install to <tt>/opt/kde/</tt> instead of <tt>/usr/</tt> (which is the normal location). This is because we don't want to overwrite the software provided by your distro, which could destabilize the system.


Did the project compile? Great! Move onto the next section. If you run into problems, see this page for what to do about it.
* 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 [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.


= Make your patch =
Now you can open your editor and get hacking! As before, make sure it compiles:
<pre>
make
</pre>




= Test your patch =
== Test your changes ==
At this point, you have a patch, and the project still compiles. Now it's time to run the project's unit tests:
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 unit tests:
<pre>
make test
</pre>


If any test fails, that needs to be investigated before you can proceed. If the tests pass, then it's time to install your patched software:
{{Input|1=<nowiki>
<pre>
cd ~/kde/build/kde/applications/dolphin/
sudo make install
source ./prefix.sh
</pre>
ctest --output-on-failure
</nowiki>}}


This will install the software to <tt>/opt/kde/</tt>. To actually run it, you will need to set some environment variables to account for the non-standard location. First, create a file with the environment variables ('''this only needs to be done once'''):
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.


<pre>
cat > ~/.kderc << "EOF"
export KF5=/opt/kde
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
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
EOF
</pre>


Now <tt>source</tt> it to pick up the new environment variables:
<pre>
source ~/.kderc
</pre>


Now you're ready to run your patched program!
== Submit a patch ==
<pre>
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 it for review very quickly and easily! You can learn how to set it up [https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches here].
/opt/kde/bin/<the program>
</pre>


Does it behave as you expect? Great! If not, 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.
KDE uses [https://phabricator.kde.org Phabricator] for patch submission and review. [[Infrastructure/Phabricator|Learn more about how to submit a patch with Phabricator]].


= Submitting your first patch =
Once you're happy with your patch and have verified that it does what you want, you need to send it to other KDE developers for review. KDE uses [https://phabricator.kde.org Phabricator] for this. [[Infrastructure/Phabricator | Learn how to submit a patch with Phabricator]]




= Communicating with the team =
== Communicate with the team ==
There are several ways to get in touch with KDE developers, and developers for a specific project. The two most important are:
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:
* the IRC channel [irc://irc.kde.org/kde-devel <nowiki>#kde-devel</nowiki>] on [http://freenode.net/ the freenode network] ([http://kde.org/support/#irc learn more about IRC]) is the core channel for developers
* 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
* The primary development mailing list is the [https://mail.kde.org/mailman/listinfo/kde-devel kde-devel list] ([http://kde.org/support/#mailinglists learn more about mailing lists])
* 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].


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


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




Line 173: Line 182:


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]]
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]]
== Best practices & other useful information==
* [[Guidelines_and_HOWTOs/Debugging|Debugging]]
* [[Guidelines and HOWTOs/UnitTests|Unit testing]]
* [[Guidelines and HOWTOs/Code_Checking| Validating code]]
* [[Guidelines and HOWTOs/API Documentation|Writing API documentation]] (related: https://api.kde.org).
* [[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]]
* [http://www.kdevelop.org Using KDevelop], a KDE IDE

Revision as of 16:19, 30 December 2018

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.


New to C++/Qt software development?

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.

Note

The Qt wiki contains a list of online books for learning Qt programming. Qt also provides lots of examples you can look at. Information about KDE Frameworks can be found on the TechBase wiki, and a book is available.



One-time setup: your development environment

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

If you're not familiar with the command line interface, you can find a reasonable tutorial here. However advanced command-line skills are not required, and you will learn what you need along the way!

Note

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!


Install basic tools

First you will need to use your operating system's package manager to install some basic tools:

  • Arch/Antergos/Manjaro: sudo pacman -S git cmake dialog
  • Fedora: sudo dnf install git cmake dialog
  • KDE Neon/Kubuntu/Ubuntu/Debian: sudo apt install git cmake dialog
  • openSUSE Leap & Tumbleweed: sudo zypper install git cmake dialog


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:


Configure Git

We need to set your authorship information properly so that any changes you make can be properly attributed to you:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

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 ~/.gitconfig file and add the following:

[url "https://anongit.kde.org/"]
    insteadOf = kde:
[url "[email protected]:"]
    pushInsteadOf = kde:

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.


Set up kdesrc-build

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 kdesrc-build to download, manage, and build KDE source code repositories. Let's set it up now:

mkdir -p ~/kde
cd ~/kde</code>
git clone kde:kdesrc-build

Notice how we're using the "kde:" prefix in our git clone command!

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

Next, set up kdesrc-build using its built-in wizard. The default options should be ok, but feel free to customize anything:

kdesrc-build --initial-setup

Note

Do not quote or escape any file paths entered in the wizard


Download the non-KDE dependencies

Even though kdesrc-build will take care of the KDE dependencies for you, it does not yet have the ability to install the non-KDE dependencies (see https://bugs.kde.org/show_bug.cgi?id=402428), which are typically acquired using your package manager. Go install the non-KDE dependencies now.

Once that's done, your development environment is set up and ready to build software! Let's take it for a spin.

Note

It can take an hour or more to compile a KDE Application, Framework, or Plasma itself for the first time. The reason for this is that kdesrc-build is compiling all of the KDE dependencies. The next time you want to compile that or any other piece of KDE software, it will be much faster since most of the dependencies will have already been compiled.



Build some software

Applications

KDE Applications like Dolphin, Okular, Konsole and Gwenview are standalone apps that can be run on multiple platforms, such as Plasma, GNOME, even macOS and Windows! New versions of KDE Applications are released three times a year. Note that the Discover app store (git repo name: plasma-discover) and System Settings app (git repo name: systemsettings) are distributed alongside Plasma, but they build like apps app using the below instructions. A list of all KDE applications can be found here: https://userbase.kde.org/Applications

For example, here is how to build Dolphin, the KDE file manager:

kdesrc-build dolphin

As a part of this process, Dolphin was installed to ~/kde/usr/bin/dolphin. source the project's auto-generated prefix.sh file every time you want to run your custom-compiled version of Dolphin:

source ~/kde/build/kde/applications/dolphin/prefix.sh
~/kde/usr/bin/dolphin

Did it run? If so, then congratulations, you just compiled your own version of Dolphin from source code!


Frameworks

KDE Frameworks are libraries of tools and features that can be used by any application or Plasma itself. New versions of KDE Frameworks are released once a month. A list of all frameworks can be found here: https://api.kde.org/frameworks/index.html

For example, here is how to build the KIO framework:

kdesrc-build kio

Now you can run an existing app using your custom-made version of the framework! For example, the following will run Dolphin, but it will be using the KIO library that you just built:

source ~/kde/build/frameworks/kio/prefix.sh
~/kde/usr/bin/dolphin

Plasma

KDE Plasma is the environment in which you can run apps. Plasma is responsible for providing a desktop with wallpaper, app launchers, and widgets; displaying notifications; managing wired and wireless networks; and similar operating-system level tasks. New versions of Plasma are released three times a year.

Here is how to will build the Plasma desktop environment and its window manager, KWin:

kdesrc-build plasma-desktop plasma-workspace plasma-framework kwin

To run your custom-built Plasma, follow these instructions.


Choose what to do

Now that you can compile and deploy custom versions of KDE software, you can open your editor and start hacking on the source code! The code for the version of Dolphin that you built earlier is located at ~/kde/src/kde/applications/dolphin/; other projects you build with kdesrc-build will live 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, 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 bug-fixes. 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.
  • 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.


Test your changes

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 unit tests:

cd ~/kde/build/kde/applications/dolphin/
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.


Submit a 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 git diff, but we recommend using the arc tool, which will generate a diff and submit it for review very quickly and easily! You can learn how to set it up here.

KDE uses Phabricator for patch submission and review. Learn more about how to submit a patch with Phabricator.


Communicate with the team

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:

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

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.


Next steps

After you have had several 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!

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


Best practices & other useful information