Difference between revisions of "Get Involved/development"

(→‎Choosing what to do: Fixed Junior Jobs search)
 
(156 intermediate revisions by 39 users not shown)
Line 4: Line 4:
 
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.
  
 +
{{Info|While any operating system can be used to patch or develop KDE software, it's easiest if you use a Linux distribution that provides relatively recent versions of Qt and KDE Frameworks, such as Arch/Manjaro, Fedora, KDE Neon, openSUSE Tumbleweed, or non-LTS versions of Kubuntu.<br /><br />Support for Windows, macOS, and Linux distros that ship older software (such as Debian, Ubuntu/Kubuntu 18.04, and openSUSE Leap 15) is still experimental, and you may have a better experience [[Get Involved/development/Developing in a virtual machine|doing your development in a virtual machine]] when using one of the distributions mentioned above.}}
  
== Choosing what to do ==
+
== New to C++/Qt software development? ==
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
+
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.
  
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.
+
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. Information about KDE Frameworks can be found on the [https://techbase.kde.org TechBase wiki], and a [[Books | book]] is available.
  
Other ideas for starting points are:
+
== 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 the 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 (but any terminal program will suffice).
  
* [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] are small tasks that are suitable for beginners (both bugs and features)
+
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!
* [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
 
  
== New to (C++/Qt) software development? ==
+
{{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!}}
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.
 
  
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.
+
{{Note|As an alternative to the set-up process described here, you can install Docker and the [[KDE PIM/Docker|KDE PIM Docker image]]. It provides a development environment that is isolated from your day-to-day system. However, it is based on KDE Neon Unstable, which might not be to your taste.}}
  
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]].
+
=== Install basic tools ===
 +
First you will need to use your operating system's package manager to install some basic tools:
 +
* Arch/Manjaro: <code>sudo pacman -S git cmake dialog</code>
 +
* Fedora: <code>sudo dnf install git cmake dialog perl perl-IPC-Cmd</code>
 +
* KDE Neon/Kubuntu/Ubuntu/Debian: <code>sudo apt install git cmake dialog</code>
 +
* openSUSE Leap & Tumbleweed: <code>sudo zypper install git breezy cmake dialog</code>
 +
<br />
  
== Get the code ==
+
=== Configure Git ===
First you will need to use your distro's package manager to install some basic tools:
+
We need to set your authorship information properly so that any changes you make can be properly attributed to you:
* Debian/Ubuntu/KDE Neon: <pre>sudo apt install git cmake</pre>
+
{{Input|1=<nowiki>
* Fedora: <pre>sudo dnf install git cmake</pre>
+
git config --global user.name "Your Name"
* openSUSE: <pre>sudo zypper install git cmake</pre>
+
git config --global user.email "[email protected]"
* Arch/Antergos/Manjaro: <pre>sudo pacman -S git cmake</pre>
+
</nowiki>}}
  
{{Note|If you are not familiar with the [https://git-scm.com/ Git] source control system, 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>.}}
+
{{Note|The name you provide should be your actual name, not your KDE Identity username.
 +
<nowiki>
  
Next, create a folder to hold all the source code repositories you're going to be downloading!
+
</nowiki>
<pre>
+
The email address you specify above must be the same as the email address used for your https://bugs.kde.org account. If they don't match, then the <code>BUG: </code> and <code>FEATURE: </code> keywords won't work (see [https://techbase.kde.org/Development/Git/Configuration#Basic_Settings this page] for more information).}}
mkdir ~/repos
+
<br />
cd ~/repos
+
In order to authenticate yourself when pushing code changes, you need to add a ssh key to your GitLab profile as [https://invent.kde.org/help/ssh/README described here].
</pre>
+
 
 +
=== Set up kdesrc-build ===
 +
Next, we need a method of '''managing dependencies'''. Every software has dependencies: other pieces of software that provide the 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! First, we create a new directory for all the KDE source code we will be using. We then clone the source code repository that holds <code>kdesrc-build</code> in that directory, so we have a local copy of it on our computer.
 +
 
 +
{{Input|1=<nowiki>
 +
mkdir -p ~/kde/src
 +
cd ~/kde/src/
 +
git clone https://invent.kde.org/sdk/kdesrc-build.git && cd kdesrc-build
 +
</nowiki>}}
 +
 
 +
Next, it's time to set up <code>kdesrc-build</code> and pick up the changes it made to your <code>~/.bashrc</code> for the current terminal session:
 +
 
 +
{{Input|1=<nowiki>
 +
./kdesrc-build --initial-setup
 +
source ~/.bashrc
 +
</nowiki>}}
 +
 
 +
{{Warning|Do not quote or escape any file paths entered in the wizard! And do not run the command <code>kdesrc-build</code> by itself without any arguments because this will build everything, which is probably overkill right now.}}
 +
 
 +
The initial setup tries to install the basic packages for compiling Qt and KDE software on your distro. It also creates a <code>~/.kdesrc-buildrc</code> configuration file.
 +
If you want a more guided setup process for <code>kdesrc-build</code>, run the command <code>kdesrc-build-setup</code> instead. However, unlike <code>--initial-setup</code>, it won't install packages from your distro for compiling programs so you will have to do that yourself.
 +
 
 +
Consult the [https://docs.kde.org/trunk5/en/extragear-utils//kdesrc-build/ kdesrc-build manual] for more information and options.
 +
 
 +
=== Set up Qt ===
 +
By default, <code>kdesrc-build</code> will build from source all the dependencies that a program or framework needs, including the Qt toolkit itself, because the <code>include-dependencies</code> option is set as default in the <code>~/.kdesrc-buildrc</code> file.
 +
 
 +
If your Linux distribution provides a recent version of Qt (5.14 or newer), you can save some time and disk space and use that version instead of building your own. To configure <code>kdesrc-build</code> to skip building Qt, open the configuration file <code>~/.kdesrc-buildrc</code> and comment out the line with <code>qtdir</code> and any lines that begin with <code>include</code> and are related to qt5, but do not comment out the line that includes <code>kf5-qt5-build-include</code>.
 +
 
 +
For example, comment/disable (put a <code>#</code> at the start of the line) or delete these lines if you want to use your distro's Qt packages (actual paths may vary):
 +
 
 +
{{Input|1=<nowiki>
 +
qtdir  ~/kde/qt5 # Where to find Qt5
 +
include /path/to/kdesrc-build/qt5-build-include
 +
include /path/to/kdesrc-build/custom-qt5-libs-build-include
 +
</nowiki>}}
 +
 
 +
=== Disable indexing for your development environment ===
 +
You'll want to disable indexing for your development-related git repos and the files they will build and install. Add <tt>~/kde</tt> to the exclusions list in System Settings > Search, like so:
 +
 
 +
[[File:Disable indexing.jpeg|center|600px|]]
 +
 
 +
=== Download 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 non-KDE dependencies (see https://invent.kde.org/sdk/kdesrc-build/-/issues/9), which are typically acquired using your package manager. To install the required non-KDE dependencies, [[Guidelines and HOWTOs/Build from source/Install the dependencies|read this page]] and follow the instructions laid out there.
 +
 
 +
Once that's done, your development environment is set up and ready to build software! Let's take it for a spin.
 +
 
 +
== Building software with kdesrc-build ==
 +
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 (See https://invent.kde.org/sdk/kdesrc-build/-/issues/17). 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. If you don't want to build all dependencies (e.g., because you are using a rolling release distro that provides recent versions of software), edit the same configuration file and simply set <code>include-dependencies</code> to '''false''' or add the <code>--no-include-dependencies</code> option when running <code>kdesrc-build</code>.
 +
 
 +
=== Applications ===
 +
'''[https://userbase.kde.org/Applications KDE Applications]''' like [https://userbase.kde.org/Dolphin Dolphin], [https://userbase.kde.org/Okular Okular], [https://userbase.kde.org/Konsole Konsole] and [https://userbase.kde.org/Gwenview 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: <code>plasma-discover</code>) and System Settings app (git repo name: <code>systemsettings</code>) are distributed alongside Plasma, but they build like apps using the below instructions. A list of all KDE applications can be found here: https://userbase.kde.org/Applications.
 +
 
 +
The general steps required to build and run an application are described in the following using Dolphin as an example:
 +
 
 +
{{Input|1=<nowiki>
 +
kdesrc-build dolphin
 +
</nowiki>}}
 +
 
 +
As a part of this process, Dolphin was installed to <code>~/kde/usr/bin/dolphin</code>. '''There is no need to manually install anything;''' <code>kdesrc-build</code> installed it for you! Source the project's auto-generated <code>prefix.sh</code> file every time you want to run your custom-compiled version of Dolphin:
 +
 
 +
{{Input|1=<nowiki>
 +
source ~/kde/build/dolphin/prefix.sh
 +
~/kde/usr/bin/dolphin
 +
</nowiki>}}
 +
 
 +
Or using <code>kdesrc-run</code> wrapper:
 +
{{Input|1=<nowiki>
 +
kdesrc-run dolphin
 +
</nowiki>}}
 +
 
 +
Did it run? If so, then '''congratulations, you just compiled your own version of Dolphin from source code!'''
  
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/. 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; the repository name for Breeze Icons is breeze-icons. Once you've identified the correct repository, download it locally:
+
=== Frameworks ===
<pre>
+
'''[[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.
git clone git://anongit.kde.org/<repository name>.git
 
</pre>
 
  
== Set up your development environment ==
+
For example, here is how to build the KIO framework:
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.
 
  
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.
+
{{Input|1=<nowiki>
 +
kdesrc-build kio
 +
</nowiki>}}
  
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):
+
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:
=== 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:
+
source ~/kde/build/kio/prefix.sh
{{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.}}
+
~/kde/usr/bin/dolphin
<pre>
+
</nowiki>}}
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 ===
+
=== Plasma ===
First add the <insert thing here> Copr, which will upgrade your system to use newer KDE software:
+
'''[[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]]. Plasma has multiple ''shells'': [https://kde.org/plasma-desktop Plasma Desktop] for desktop, laptop, and 2-in-1 computers, [https://www.plasma-mobile.org/ Plasma Mobile] for mobile phones, Plasma Bigscreen for televisions, and so on. They all share certain common components, such as a window manager, networking stack, basic graphical components, and so on. Here is how to build them:
{{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.}}
+
{{Input|1=<nowiki>
<pre>
+
kdesrc-build plasma-workspace plasma-framework plasma-nm plasma-pa plasma-thunderbolt plasma-vault plasma-disks plasma-workspace-wallpapers kdeplasma-addons krunner milou kwin kscreen sddm-kcm plymouth-kcm breeze discover print-manager plasma-sdk kaccounts-integration kaccounts-providers kdeconnect-kde plasma-browser-integration xdg-desktop-portal-kde kde-gtk-config khotkeys --include-dependencies
[Insert method of updating KDE packages in Fedora here]
+
</nowiki>}}
</pre>
 
Then install the dependencies for the software you want to work on:
 
<pre>
 
sudo dnf builddep <repo/package name>
 
</pre>
 
  
=== openSUSE Tumbleweed ===
+
==== Plasma Desktop ====
First enable the source repository:
+
To build the plasma Desktop environment and its related apps, also build the following:
<pre>
+
{{Input|1=<nowiki>
sudo zypper mr -e repo-source
+
kdesrc-build plasma-desktop systemsettings ksysguard kinfocenter kmenuedit --include-dependencies
</pre>
+
</nowiki>}}
Then install the dependencies for the software you want to work on:
 
<pre>
 
sudo zypper si -d <repo/package name>
 
</pre>
 
  
=== Arch/Antergos/Manjaro ===
+
To run your custom-built Plasma Desktop, first make it accessible from the SDDM login screen by running the following command:
<pre>
+
{{Input|1=<nowiki>
sudo pacman -S git <repo/package name>
+
~/kde/build/plasma-workspace/login-sessions/install-sessions.sh
</pre>
+
</nowiki>}}
<br/><br/>
 
  
== Compile the software ==
+
Alternatively you can run the new version of plasma on top of your existing system for quick testing:
 +
{{Input|1=<nowiki>
 +
source ~/kde/build/plasma-desktop/prefix.sh
 +
~/kde/usr/bin/plasmashell --replace
 +
</nowiki>}}
  
Before you work on your patch, try to compile the software to make sure that your development environment is set up properly:
+
You may need to set the LD_LIBRARY_PATH environment variable properly, to be able to run Plasma desktop. This can be done, for example, by editing <tt>~/kde/usr/lib64/libexec/plasma-dev-prefix.sh</tt> by uncommenting the <tt>export LD_LIBRARY_PATH</tt> line:
  
 
<pre>
 
<pre>
mkdir build
+
# LD_LIBRARY_PATH only needed if you are building without rpath
cd build
+
export LD_LIBRARY_PATH=/home/plasmadev/kde/usr/lib64:$LD_LIBRARY_PATH
cmake -DCMAKE_INSTALL_PREFIX=/opt/kde/ ..
 
make
 
 
</pre>
 
</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.
+
In order to make DBus and KAuth actions work properly, create a file named <code>/etc/dbus-1/session-local.conf</code> and add the following text to it:
  
== Make your patch ==
+
<busconfig>
Now you can open your editor and get hacking! As before, make sure it compiles:
+
    <servicedir>/home/[your-user]/kde/usr/share/dbus-1/services</servicedir>
<pre>
+
    <servicedir>/home/[your-user]/kde/usr/share/dbus-1/system-services</servicedir>
make
+
    <includedir>/home/[your-user]/kde/usr/share/dbus-1/system.d/</includedir>
</pre>
+
</busconfig>
 +
 
 +
{{Note|<tt>/home/[your-user]/kde/usr</tt> is the default instalation for KDE applications if configured with the default settings for kdesrc-build. If you install kde software in any other place, you will need to edit the url accordingly}}
  
 +
After that, you can log out and select your new plasma session in SDDM's session chooser menu (which is located in the bottom-left corner of the screen if you're using the Breeze SDDM theme).
  
== Test your patch ==
+
{{Note |Some linux distros such as Arch Linux have a setting that forbids the usage of DBus scripts from the home folder. If you have problems with your login manager (such as sddm, gdm, lightdm) after creating the session-local.conf file, try to create a symlink for the dbus-1 folder inside of your installation to a place outside home (such as <tt>/opt/kde-dbus-scripts</tt>) and adapt the session-local file.
At this point, you have a patch, and the project still compiles. Now 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:
 
 
<pre>
 
<pre>
sudo make install
+
<busconfig>
 +
    <servicedir>/opt/kde-dbus-scripts/services</servicedir>
 +
    <servicedir>/opt/kde-dbus-scripts/system-services</servicedir>
 +
    <includedir>/opt/kde-dbus-scripts/system.d/</includedir>
 +
</busconfig>
 
</pre>
 
</pre>
 +
}}
  
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'''):
+
==== Plasma Mobile ====
 +
To build the Plasma Mobile environment and its related apps, also build the following:
 +
{{Input|1=<nowiki>
 +
kdesrc-build plasma-nano plasma-phone-components plasma-settings plasma-camera marble koko vvave okular plasma-angelfish plasma-samegame mtp-server kaidan peruse calindori index-fm maui-pix qrca keysmith --include-dependencies
 +
</nowiki>}}
  
Note: if you install into a user controlled directory e.g. ~/build you might have to set DESTDIR environment variable:
+
You can run your custom-built Plasma Mobile in a phone-sized window within your existing session like so:
<pre>
 
env DESTDIR=~/build make install
 
</pre>
 
  
<pre>
+
{{Input|1=<nowiki>
cat > ~/.kderc << "EOF"
+
export XDG_RUNTIME_DIR=/tmp/
export KF5=/opt/kde
+
export QT_QPA_PLATFORM=wayland
export QTDIR=/usr
+
export QT_QPA_PLATFORMTHEME=KDE
export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH
+
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share
+
export XDG_CURRENT_DESKTOP=KDE
export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg
+
export KSCREEN_BACKEND=QScreen
export PATH=$KF5/bin:$QTDIR/bin:$PATH
+
export KDE_FULL_SESSION=1
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_SESSION_VERSION=5
export KDE_FULL_SESSION=true
+
export QT_QUICK_CONTROLS_MOBILE=1
export SASL_PATH=/usr/lib/sasl2:$KF5/lib/sasl2
+
export PLASMA_PLATFORM=phone:handheld
EOF
+
export $(dbus-launch)
</pre>
+
dbus-run-session kwin_wayland --width 360 --height 720 --xwayland "plasmashell -p org.kde.plasma.phone"
 +
</nowiki>}}
 +
 
 +
Plasma Mobile can also be run on a mobile device itself. For information on how to do that, see https://docs.plasma-mobile.org/DevGuide.html#plasma-mobile-device-environment.
 +
 
 +
For more information, see https://docs.plasma-mobile.org/DevGuide.html.
 +
 
 +
=== Iterating on a single project ===
 +
When you're working on a project and you want to rebuild it to test your changes, you can save a lot of time by only rebuilding that project, rather than the entire stack. For example if you are working on <code>plasma-desktop</code>, you can rebuild only that project rather than everything by running <code>kdesrc-build --no-src --no-include-dependencies plasma-desktop</code>.
 +
 
 +
=== How to solve build problems ===
 +
Did one or more modules fail to build (displayed in red font) using <code>kdesrc-build</code>? Here's what to do:
 +
 
 +
# Try building the failing module again from scratch using <code>kdesrc-build [failing module] --refresh-build</code>
 +
# Make sure that you have all the dependencies for the failing module. Go back to the [[#Download non-KDE dependencies]] section and re-install the non-KDE dependencies. If that doesn't fix the problem, open the log file for the failing module, which <code>kdesrc-build</code> will print the path at the end of its output. Scroll to the bottom of the log file and read the output to see what missing dependency it is complaining about, then find and install the corresponding package using your distro's package manager your distro. If several looks relevant, install them all just to be safe. When you have the necessary dependencies, you can save time and resume from the failing module by adding <code>--resume-from [the name of the module that failed]</code> to your <code>kdesrc-build</code> command.
 +
# Check the [https://build.kde.org/view/Failing/ list of currently broken modules] on the KDE build server. If it's broken there, then it's not your fault. :)
 +
# Ask for help in the the [https://webchat.kde.org/#/room/#kde-devel:kde.org #kde-devel] channel on [[Matrix]] or freenode [[Internet Relay Chat | IRC]]. See [[Get Involved/development#Communicate with the team]]
 +
 
 +
== 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 <code>~/kde/src/dolphin/</code>; other projects you build with <code>kdesrc-build</code> 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 [[#Communicate with the team|Communicate 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 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 [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.
  
Now <tt>source</tt> it to pick up the new environment variables:
+
== Test your changes ==
<pre>
+
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:
source ~/.kderc
 
</pre>
 
  
Now you're ready to run your patched program!
+
{{Input|1=<nowiki>
<pre>
+
cd ~/kde/build/dolphin/
/opt/kde/bin/<the program>
+
source ./prefix.sh
</pre>
+
ctest --output-on-failure
 +
</nowiki>}}
  
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.
+
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.
  
== Submitting your first patch ==
+
== Submit a Merge Request ==
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]]
+
Once you're happy with your patch and have verified that it does what you want, it's time to submit your changes for review!
  
 +
KDE uses [https://invent.kde.org GitLab] for merge request submission and review. [[Infrastructure/GitLab#Submitting_a_merge_request|Learn how to submit a Merge Request with GitLab]].
  
== 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 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 [https://webchat.kde.org/#/room/#kde-devel:kde.org #kde-devel] channel on [[Matrix]] or the freenode [[Internet Relay Chat | IRC]], 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.
+
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 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.
 
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 [https://lxr.kde.org/ here]. 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.
  
 
== 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://techbase.kde.org/Development/Tutorials KDE development tutorials]. And try out [http://www.kdevelop.org KDevelop], the KDE IDE.
 +
 
 +
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 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 customized development environment. 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==
 +
* [[Get Involved/Design/Lessons Learned|Lessons learned over time regarding the development of user-facing software]]
 +
* [[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/Licensing|Correctly state license information]]
 +
* [[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]]
 +
* [https://community.kde.org/Infrastructure/GitLab#Testing_someone_else.27s_Merge_Request How to review merge requests]
 +
* [https://github.com/Wenzel/docker-kdesrc-build How to build with Docker]

Latest revision as of 16:55, 1 March 2021

Konqui dev close cropped.png

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.

Information
While any operating system can be used to patch or develop KDE software, it's easiest if you use a Linux distribution that provides relatively recent versions of Qt and KDE Frameworks, such as Arch/Manjaro, Fedora, KDE Neon, openSUSE Tumbleweed, or non-LTS versions of Kubuntu.

Support for Windows, macOS, and Linux distros that ship older software (such as Debian, Ubuntu/Kubuntu 18.04, and openSUSE Leap 15) is still experimental, and you may have a better experience doing your development in a virtual machine when using one of the distributions mentioned above.


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.

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. 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 the 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 (but any terminal program will suffice).

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!


Note
As an alternative to the set-up process described here, you can install Docker and the KDE PIM Docker image. It provides a development environment that is isolated from your day-to-day system. However, it is based on KDE Neon Unstable, which might not be to your taste.


Install basic tools

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

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


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]"
Note
The name you provide should be your actual name, not your KDE Identity username.

The email address you specify above must be the same as the email address used for your https://bugs.kde.org account. If they don't match, then the BUG: and FEATURE: keywords won't work (see this page for more information).


In order to authenticate yourself when pushing code changes, you need to add a ssh key to your GitLab profile as described here.

Set up kdesrc-build

Next, we need a method of managing dependencies. Every software has dependencies: other pieces of software that provide the 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! First, we create a new directory for all the KDE source code we will be using. We then clone the source code repository that holds kdesrc-build in that directory, so we have a local copy of it on our computer.

mkdir -p ~/kde/src
cd ~/kde/src/
git clone https://invent.kde.org/sdk/kdesrc-build.git && cd kdesrc-build

Next, it's time to set up kdesrc-build and pick up the changes it made to your ~/.bashrc for the current terminal session:

./kdesrc-build --initial-setup
source ~/.bashrc
Warning
Do not quote or escape any file paths entered in the wizard! And do not run the command kdesrc-build by itself without any arguments because this will build everything, which is probably overkill right now.


The initial setup tries to install the basic packages for compiling Qt and KDE software on your distro. It also creates a ~/.kdesrc-buildrc configuration file. If you want a more guided setup process for kdesrc-build, run the command kdesrc-build-setup instead. However, unlike --initial-setup, it won't install packages from your distro for compiling programs so you will have to do that yourself.

Consult the kdesrc-build manual for more information and options.

Set up Qt

By default, kdesrc-build will build from source all the dependencies that a program or framework needs, including the Qt toolkit itself, because the include-dependencies option is set as default in the ~/.kdesrc-buildrc file.

If your Linux distribution provides a recent version of Qt (5.14 or newer), you can save some time and disk space and use that version instead of building your own. To configure kdesrc-build to skip building Qt, open the configuration file ~/.kdesrc-buildrc and comment out the line with qtdir and any lines that begin with include and are related to qt5, but do not comment out the line that includes kf5-qt5-build-include.

For example, comment/disable (put a # at the start of the line) or delete these lines if you want to use your distro's Qt packages (actual paths may vary):

qtdir  ~/kde/qt5 # Where to find Qt5
include /path/to/kdesrc-build/qt5-build-include
include /path/to/kdesrc-build/custom-qt5-libs-build-include

Disable indexing for your development environment

You'll want to disable indexing for your development-related git repos and the files they will build and install. Add ~/kde to the exclusions list in System Settings > Search, like so:

Disable indexing.jpeg

Download 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 non-KDE dependencies (see https://invent.kde.org/sdk/kdesrc-build/-/issues/9), which are typically acquired using your package manager. To install the required non-KDE dependencies, read this page and follow the instructions laid out there.

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

Building software with kdesrc-build

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 (See https://invent.kde.org/sdk/kdesrc-build/-/issues/17). 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. If you don't want to build all dependencies (e.g., because you are using a rolling release distro that provides recent versions of software), edit the same configuration file and simply set include-dependencies to false or add the --no-include-dependencies option when running kdesrc-build.

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 using the below instructions. A list of all KDE applications can be found here: https://userbase.kde.org/Applications.

The general steps required to build and run an application are described in the following using Dolphin as an example:

kdesrc-build dolphin

As a part of this process, Dolphin was installed to ~/kde/usr/bin/dolphin. There is no need to manually install anything; kdesrc-build installed it for you! Source the project's auto-generated prefix.sh file every time you want to run your custom-compiled version of Dolphin:

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

Or using kdesrc-run wrapper:

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

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/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. Plasma has multiple shells: Plasma Desktop for desktop, laptop, and 2-in-1 computers, Plasma Mobile for mobile phones, Plasma Bigscreen for televisions, and so on. They all share certain common components, such as a window manager, networking stack, basic graphical components, and so on. Here is how to build them:

kdesrc-build plasma-workspace plasma-framework plasma-nm plasma-pa plasma-thunderbolt plasma-vault plasma-disks plasma-workspace-wallpapers kdeplasma-addons krunner milou kwin kscreen sddm-kcm plymouth-kcm breeze discover print-manager plasma-sdk kaccounts-integration kaccounts-providers kdeconnect-kde plasma-browser-integration xdg-desktop-portal-kde kde-gtk-config khotkeys --include-dependencies

Plasma Desktop

To build the plasma Desktop environment and its related apps, also build the following:

kdesrc-build plasma-desktop systemsettings ksysguard kinfocenter kmenuedit --include-dependencies

To run your custom-built Plasma Desktop, first make it accessible from the SDDM login screen by running the following command:

~/kde/build/plasma-workspace/login-sessions/install-sessions.sh

Alternatively you can run the new version of plasma on top of your existing system for quick testing:

source ~/kde/build/plasma-desktop/prefix.sh
~/kde/usr/bin/plasmashell --replace

You may need to set the LD_LIBRARY_PATH environment variable properly, to be able to run Plasma desktop. This can be done, for example, by editing ~/kde/usr/lib64/libexec/plasma-dev-prefix.sh by uncommenting the export LD_LIBRARY_PATH line:

# LD_LIBRARY_PATH only needed if you are building without rpath
export LD_LIBRARY_PATH=/home/plasmadev/kde/usr/lib64:$LD_LIBRARY_PATH

In order to make DBus and KAuth actions work properly, create a file named /etc/dbus-1/session-local.conf and add the following text to it:

<busconfig>
    <servicedir>/home/[your-user]/kde/usr/share/dbus-1/services</servicedir>
    <servicedir>/home/[your-user]/kde/usr/share/dbus-1/system-services</servicedir>
    <includedir>/home/[your-user]/kde/usr/share/dbus-1/system.d/</includedir>
</busconfig>
Note
/home/[your-user]/kde/usr is the default instalation for KDE applications if configured with the default settings for kdesrc-build. If you install kde software in any other place, you will need to edit the url accordingly


After that, you can log out and select your new plasma session in SDDM's session chooser menu (which is located in the bottom-left corner of the screen if you're using the Breeze SDDM theme).

Note
Some linux distros such as Arch Linux have a setting that forbids the usage of DBus scripts from the home folder. If you have problems with your login manager (such as sddm, gdm, lightdm) after creating the session-local.conf file, try to create a symlink for the dbus-1 folder inside of your installation to a place outside home (such as /opt/kde-dbus-scripts) and adapt the session-local file.
<busconfig>
    <servicedir>/opt/kde-dbus-scripts/services</servicedir>
    <servicedir>/opt/kde-dbus-scripts/system-services</servicedir>
    <includedir>/opt/kde-dbus-scripts/system.d/</includedir>
</busconfig>


Plasma Mobile

To build the Plasma Mobile environment and its related apps, also build the following:

kdesrc-build plasma-nano plasma-phone-components plasma-settings plasma-camera marble koko vvave okular plasma-angelfish plasma-samegame mtp-server kaidan peruse calindori index-fm maui-pix qrca keysmith --include-dependencies

You can run your custom-built Plasma Mobile in a phone-sized window within your existing session like so:

export XDG_RUNTIME_DIR=/tmp/
export QT_QPA_PLATFORM=wayland
export QT_QPA_PLATFORMTHEME=KDE
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export XDG_CURRENT_DESKTOP=KDE
export KSCREEN_BACKEND=QScreen
export KDE_FULL_SESSION=1
export KDE_SESSION_VERSION=5
export QT_QUICK_CONTROLS_MOBILE=1
export PLASMA_PLATFORM=phone:handheld
export $(dbus-launch)
dbus-run-session kwin_wayland --width 360 --height 720 --xwayland "plasmashell -p org.kde.plasma.phone"

Plasma Mobile can also be run on a mobile device itself. For information on how to do that, see https://docs.plasma-mobile.org/DevGuide.html#plasma-mobile-device-environment.

For more information, see https://docs.plasma-mobile.org/DevGuide.html.

Iterating on a single project

When you're working on a project and you want to rebuild it to test your changes, you can save a lot of time by only rebuilding that project, rather than the entire stack. For example if you are working on plasma-desktop, you can rebuild only that project rather than everything by running kdesrc-build --no-src --no-include-dependencies plasma-desktop.

How to solve build problems

Did one or more modules fail to build (displayed in red font) using kdesrc-build? Here's what to do:

  1. Try building the failing module again from scratch using kdesrc-build [failing module] --refresh-build
  2. Make sure that you have all the dependencies for the failing module. Go back to the #Download non-KDE dependencies section and re-install the non-KDE dependencies. If that doesn't fix the problem, open the log file for the failing module, which kdesrc-build will print the path at the end of its output. Scroll to the bottom of the log file and read the output to see what missing dependency it is complaining about, then find and install the corresponding package using your distro's package manager your distro. If several looks relevant, install them all just to be safe. When you have the necessary dependencies, you can save time and resume from the failing module by adding --resume-from [the name of the module that failed] to your kdesrc-build command.
  3. Check the list of currently broken modules on the KDE build server. If it's broken there, then it's not your fault. :)
  4. Ask for help in the the #kde-devel channel on Matrix or freenode IRC. See Get Involved/development#Communicate with the team

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

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/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 Merge Request

Once you're happy with your patch and have verified that it does what you want, it's time to submit your changes for review!

KDE uses GitLab for merge request submission and review. Learn how to submit a Merge Request with GitLab.

Communicate with the 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:

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

Next steps

Sharpen your skills by going through the KDE development tutorials. And try out KDevelop, the KDE IDE.

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!

You may also want to set up a more customized development environment. See Guidelines and HOWTOs/Build from source.

Best practices & other useful information


This page was last edited on 1 March 2021, at 16:55. Content is available under Creative Commons License SA 4.0 unless otherwise noted.