KDE Frameworks/Getting Started
| Proposed for Deletion |
|---|
This page has been proposed for deletion for the following reason:
|
| Under Construction |
|---|
| This is a new page, currently under construction! |
Introduction
There are many different ways to become involved in the KDE Community, starting with simply using our software. This guide is to help you get started on the technical side of developing the software itself.
It is important to note that the version of KDE Software that is provided by your distribution or downloaded via an installer is not the same as the version that is being worked on by software developers. If you are using KDE CoolApp 1.2, the developers are working on the "development" version, usually called "KDE CoolApp master". This is the version that will become KDE CoolApp 1.3, or maybe 2.0. If you want to get involved in developing KDE Software, you will need to get hold of and build the development versions.
This guide will aim to show you how to build, run and help improve the development versions of KDE Software. We will primarily be looking at submitting a patch to change the software, but the information here is also useful if you want to test whether a bug still exists in the software, for example.
If you just want to get started building the code then you can skip to the build instructions, but it is recommended you first understand the background material presented here.
Getting Help
If you are looking for help in using KDE Plasma or KDE Applications then please visit the KDE UserBase.
Before you continue with this guide, it is a good idea to get on IRC. This is a realtime text communication system, and the primary "casual" communication tool for KDE developers.
You will need a way to connect to the freenode IRC network. We suggest Konversation (see the handbook for help in setting it up), although a convenient alternative if you want to get going quickly is freenode's online webchat. You will need to choose a nick (the name you appear on the network as), connect to freenode and join #kde-devel.
The other main channel for communication is the KDE mailing lists. To start with, you should subscribe to the kde-devel list (you will need to subscribe before you can send emails to the list).
For more information about getting help, see the main Getting Help page, and remember that applications often have their own IRC channels and mailing lists that can be better places to ask for help.
Be patient while waiting for a response, and try to work through the problem yourself: we aren't going to do it all for you. Working your way through and understanding why something doesn't work is a good way to learn how to do things the right way.
Development Policies
KDE Software is a very large, diverse and complex code base and the KDE Community has developed many policies and processes to make the KDE Software development process manageable, which are documented elsewhere in TechBase. As you become more involved in KDE Development, you will need to become familiar with them, as well as any policies specific to the projects you are contributing to, but for your first few patches you will not need to worry about most of them.
At this point, the main thing you need to read is the KDE Community Code of Conduct, because this is the basis for interacting with the KDE Community in general. You will also need to be willing for your code to be licensed under the one of the licenses listed in the licensing policy.
If you want to make changes to library code, especially the KDE Frameworks, reading the library code policy can help you write code that will satisfy the requirements of those projects.
KDE Projects
As mentioned above, there is a lot of KDE Software. You may already have a project in mind that you want to help with, in which case it is helpful to know where it fits in the overall structure of KDE Software. If you haven't chosen a specific project, knowing this structure will help you start your search for where to begin contributing.
KDE Software is divided into three main Products:
The Frameworks are the libraries that underpin all the other KDE Software. Almost all KDE Software is built on Qt, a C++ framework and GUI toolkit. The Frameworks provide additional functionality on top of Qt, and are used both within and outside KDE.
KDE Plasma is KDE's desktop environment. Applications built on top of Qt and KDE Frameworks will integrate well with KDE Plasma, but they will also integrate with other desktops. Plasma will also attempt to help other applications (such as GTK-based ones) integrate with it.
Most other KDE projects are applications that come under the KDE Applications umbrella. This contains several coherent groups, such as KDE Education, KDE Games, the Calligra Suite and the Kontact Suite.
Each of these Products has its own release cycle. For example, a new version of the Frameworks is released every month. KDE also has other projects that are not part of the above Products. These can be divided into the following groups:
- Extragear contains stable software (often applications) that have their own release cycles, separate from the above major Products.
- Playground contains software that is not yet stable.
- Review projects are waiting to move into one of the three main Products, or from Playground to Extragear.
- Unmaintained projects are no longer worked on.
- Sysadmin and Website projects are used to help manage KDE infrastructure.
Getting and Building the Source
If you are generally familiar with getting and building open source software projects, you can follow a similar strategy for KDE Software: find the repository on KDE QuickGit, clone it and build it like any other CMake project. However, KDE has a lot of interdependent projects, and you can end up spending a lot of time building the dependencies and dependencies-of-dependencies of the project you actually want to contribute to.
The approach we will present here is to use a tool that will manage building all the dependencies for you.
First, we recommend you read about how to access the KDE source code. The tool we will use to build the software will fetch the source code that it needs itself, so reading this is not strictly necessary, but it will give you an overview that will help you understand what the tool is doing, as well as potentially being useful later.
After that, you are ready to build and install KDE Software.
Testing
TODO: Running unit tests, running the software.
Making A Patch
TODO: how to find a task (junior jobs), the edit-compile-fix cycle?
Relevant: Development Tools useful in developing KDE Software.
Submitting Your Change
TODO: Reviewboard/Phabricator
Relevant: Send Patches
Maybe link to:
Next Steps
TODO: keep submitting patches, get invited to get a contributor account?