Krita/Hacking
Getting started with KDE Software
Krita is a great place to start even if you are brand new to KDE development. We'd love to have you join!
KDE has undergone big changes since a major 2014 reorganization. As a result, working with KDE software has never been easier. Unfortunately, since the changes were so widespread, the documentation has not caught up at all. If you are embarking on this journey, it would be very generous to share your discoveries with others and update pages. (=
The KDE Techbase Wiki has instructions for new developers. On top of basic tools like C++, git, and general notions such as building software libraries, some special tools that are particular to Krita are Qt, CMake, and KDE Frameworks. It can be very helpful to get started by finding some of the articles discussing these tools and reading up. Here are some of the more useful pages to get you started:
- https://techbase.kde.org/Development
- https://techbase.kde.org/Contribute
- https://techbase.kde.org/Development/Git/Configuration
- https://techbase.kde.org/Development/Tutorials
- http://flossmanuals.net/kde-guide
- http://doc.qt.io/ Qt has some of the best documentation of any software library.
Building Krita
To get started, all you need to do is get a copy of Krita and build it! This is not all that much much different from building something off GitHub... except that Krita is a very large compared to most software. There are instructions on this wiki to build on various platforms.
KDE Identity
If you intend to be a regular contributor to Krita, the first thing you will want to do is register for a KDE Identity account. This serves as your login for many places in KDE websites. (Including this wiki! Select the OpenID / Identity Login option and use your KDE Identity account.)
This is the account that is used for repository commit access as well.
Getting in touch
Patch review and issue tracking happens on Phabricator. Just search for Krita under Projects! Use your KDE Identity for the LDAP login field to log in.
Other places to talk with devs are IRC, the mailing list, and the forums. Wolthera put together a nice guide here. https://forum.kde.org/viewtopic.php?f=288&t=125955
Debugging
When you run a debug build of Krita, you may be surprised how little debug output you see. This is because most of Krita's debugging information is turned off by default. The debug statements are grouped into categories such as dbgUI, dbgKrita and so on. The output categories are controlled by an environment variable QT_LOGGING_RULES.
The list of Krita's debug categories is contained in kis_debug.h and main.cc, and the rules for the environment variable are described in the Qt reference for QLoggingCategory.
As an example, to enable most of Krita's debug output, you can run the following:
export QT_LOGGING_RULES="krita*=true"; krita
Using the rule *=true will produce a firehose, if you want it.
Calligra and Krita
In October 2015, the Krita project separated from the rest of the Calligra office suite. The new repository still clearly contains this history. Most source code files will have one of two prefixes. "Ko" stands for KOffice, the original name of Calligra office suite. These files mostly comprise basic, lower-level libraries. "Kis" stands for KImageShop, the original name of Krita. These files are where most of the painting-specific functionality is maintained.
Style guidelines
See HACKING in the codebase.
Development Philosophy
Krita is nearly ten years old, consists of around 1.1 million lines of code, and has had many individual contributors throughout the years. If you run into something in the code that doesn't make sense to you, it may very well not make sense to anyone. Developing a codebase this large is an art form, you should feel confident in making risky changes even if you're not sure they'll work, you can always go back with git checkout -- * if you mess it up!