The KOffice Project Krita Developer Information
Developing Krita
Boudewijn Rempt
Contents
Overview of the Krita Architecture
Krita has been designed as a full-featured bitmap paint application. That means that is not based on the QPainter/QPaintdevice combo (as KPaint is), but that it seeks to provide its own low-level 2d canvas library. This naturally makes for some complexity, and this document attempts to provide an overview of the Krita architecture for would-be hackers. (Who would be very, very welcome.)
This document contains my understanding of Krita, as I came to grasp it after a long series of email exchanges with Krita's architect, Patrick Julien in October 2003 on the Krita mailing list. Corrections are welcome.
When reading the Krita source, a copy of the GOF book, Design Patterns is very useful. You will find many patterns used in Krita — strategy, flyweight, facade, factory. Many of the classes are even named after the pattern they use.
Krita has been through at least three architectural phases, and traces from earlier phases can still be found everywhere in the code. Don't let references to KisKrayon or KisPixelPacket confuse you; those are obsolete. There is little doubt that these redesigns were necessary as new generations of developers discovered problems with earlier code, but the effect has been that Krita still isn't anywhere near usefulness, even after four years. Let's change that by cheerfully building on what we have now, and never, ever breaking a feature again!
The Core
The Krita core is a 2d canvas, comparable to QPainter/ QPaintDevice, but designed for large images. It supports alpha transparency, multiple color models (RGB, CMYK) and compositing. This part of Krita could potentially be decoupled from the application and form the basis of a 2d graphics library like ImageMagick or LibArt. Potentially, because the API KisPainter and KisPaintDevice provide is used throughout the application.
Paint actions are generally implemented in KisPainter, but as soon as color compositing is necessary, the action is deferred to the correct color strategy (which have KisColorSpace as a base), for instance KisRgbColorSpace. In a sense, KisPainter is a facade for the color strategies.
Image data is stored in paint devices: KisPaintDevice. To display this image data, a KisPaintDevice can be used to create a KisPaintLayer, a subclass of KisLayer. In order to show the image on screen, all layers are composited using the KisMergeVisitor, which visits the different kinds of KisLayer (which are grouped in a tree-like structure with the KisGroupLayer class). The composited result is put in a KisPaintDevice, which is then rendered to a QImage in the convertToQImage method of the relevant color strategy.
Krita's core is tile-based, as with all good paint applications. Tiles contain the actual pixel data, that is the chunk of memory where three, four of five bytes in a row represent the red, green, blue, alpha or cyan, magenta, yellow, black and alpha components that form one pixel. Whenever a pixel in a 64x64 pixel tile changes, the tile is saved to make it possible to undo the change. This is encapsulated in the beginTransaction and endTransaction methods of KisPainter.
See Paint devices and Painters for more information on working with raster images and Krita.
Images and documents
The document model of Krita is contained in KisDoc. A document contains one or more images and each image can contain one or more layers.
User interface
Krita is a KOffice application and therefore uses the standard KOffice GUI wrapper that creates a multiple document/view shell with toolbars, menubars and all that sort of thing. The basis is in KisView; this class constructs all the user interface features like the brush selector or the color selectors. Code for dialogs and widgets is kept in the ui directory. However, it must be admitted that Krita's UI is mess currently; some of the dialogs don't work, and what there is looks not too polished. This is a prime area for an ambitious hacker to put in some good work...
Tools
This is a severely underdesigned part of Krita. A tool, like a brush, a lasso, a convolver or an painter's knife, is based on KisToolPaint or KisToolNonPaint, both ultimately based on KisTool, and should provide:
- An icon to show up in the tool palette
- A dialog to configure properties
- Code in KisPainter that implements the tool's action if it is a painting tool, or other code somewhere else if it is a non-painting tool, like a selection.
- Code to give immediate visual feedback on-screen, like the marching ants rectangle for a rectangular select.
Tool code is in tools. Tools, like lot of other parts of Krita, are actually loaded as plugins. This makes it easy to develop new tools outside of the Krita tree.
Tools can make use of KisResources. Resources are, for instance, patterns, brushes (based on Gimp's brushes) or gradients. Krita can also use Gimp's pipe brushes.
There is no support for fancy procedural brushes yet. (But look at the KisImagePipeBrush class for an example of how it could be done.)
Krita is has a very modular approach, using the Plugin concept of KParts. Most tools, paint operations, filters, colorspaces, and parts of the UI are implemented as plugins. Most of them can be found in the plugins directory (the colorspaces are in colorspaces)
Design documents
The most relevant design documents can be found in Krita's SVN, and is in doc (although some documents are very specific or outdated). Earlier design documents, with a mostly historical interest are Overall Design and Gui Design.
Envoi
Krita has the potential to become a very nice, possibly even a great, paint application. Keeping in mind that the Gimp has the image-messing niche pretty much sewn up, and that a bitmap paint app is not a vector mangle app, the direction for Krita seems clear: a creative paint application, easy to use, exciting to work with.
