Question

“In my 20+ year experience managing projects I learned that tools or systems don’t manage anything, people do, and if people need tools they’ll get them or make them”

—Ton Roosendaal, on #blendercoders

Some parts of the contributor’s manual are for people who wish to help with the more technical parts of contributing to an open source project.

Because technical computer terms are very hard to translate, people who wish to do technical contributions must know English. This is not just because these pages would be hard to translate, but also because the main developers who work on the program will have a hard time figuring out the names of technical terms in languages other than English. Therefore, these pages will not be translated.

Outside these pages we also recommend taking a look at…

• The KDE API Documentation Guidelines

• KDE wide Guidelines and How-tos

Contents:

• Automated Krita builds on CI matrix
• Brush GUI Design with Lager
• Building Krita from Source
• CMake Settings for Developers
• Enable static analyzer
• How to patch Qt
• Introduction to Hacking Krita
• The Krita Palette format KPL
• Krita SVG Extensions
• Modern C++ usage guidelines for the Krita codebase
• Developing Features
• Optimize Image Processing with XSIMD
• Optimizing tips and tools for Krita
• Google Summer of Code
• Advanced Merge Request Guide
• Python Developer Tools
• Introduction to Quality Assurance
• Making a release
• Reporting Bugs
• Strokes queue
• Strokes public API
• Internals of the freehand tool
• Scheduled Undo/Redo
• Processings framework
• Testing Strategy
• Triaging Bugs
• Unittests in Krita