A Vision for Krita

Another long blog post on krita without a single screenshot

The Krita hackers had an irc discussion some time ago on where Krita was headed. With Gimp gaining high-end features that were previously our province (like group layers and an increasingly attractive and polished user interface), and MyPaint becoming a really nice and comfortable paint application (material for another blog!), Krita’s relevance might be thought to have been in jeopardy. And, given that we’ve spent the past three years porting Krita, catching up with the base platforms (Qt, KDE, KOffice-libs) and adding lots and lots of experimental features, it could be argued that we might have lost focus.

So, we first needed to answer some soul-searching questions, like, “what’s the biggest problems we face”, “is it useful or detrimental to be based on KOffice”, “what use-cases do we want to implement”, “what’s better, one big app that can do all, or smaller, focused apps” and even: “Is there still a reason for Krita to exist, given that Gimp is getting more and more polished and has layer groups, and that MyPaint is getting layers and has a dream of a brush engine?”

And there are some seemingly contradictory interests too: developers want to experiment with image manipulation technologies, users want a tool that allows them to make cool art with the minimum of distraction. The interests of photographers, comic book authors, illustration painters and amateur sketchers (that’s me…) are not the same. A tablet pc has only one key: the escape key. An Intuos user has a keyboard and wants a lot of shortcuts. And so. The full discussion is on the mailing list.

Note that all this time, we carried on fixing bugs and improving Krita’s stability! Because, in the end, it’s clear that currently stability is the biggest issue everyone has who tries to work with Krita 2.1. And after stability, performance. We recognize that in our plan: see below.

But first the vision as it appeared from our discussions:


This is what we are thinking now; we are planning a Krita sprint in February and will probably be using some of that time to refine our ideas.

  • Integrated: no endless switching between two apps, but switching between modes of Krita, so no data loss because two apps don’t completely understand each other, not two color selectors or layer modes that have subtly different meaning. So, if you want to manipulate the colors of a layer, switch to the image manipulation mode, and if you want to sketch, switch to the sketching mode. I envision a slider-like widget to do this, not a complex thing like Eclipse, just two or three well-defined gui compositions, ranging from complex to spare.
  • Usable: easy things easy, like getting started with a digital pencil sketch, the rest possible and accessible. We need UI guidelines for things like filter dialogs, tool option panes and brush engine panes. Some things are hard problems, like multiple views, resource management and so on. Our line tool, our assistants really make a diffence for users.
  • Powerful: because we build on the KOffice foundations of pigment and flake (which partly derive from krita, by the way), Krita has got color management, rich text, vector layers and everything. If, in addition to Krita you install more KOffice plugins, an application like Karbon or even, if your tastes lie that way, KChart, you will get more power that nevertheless¬† doesn’t get in your way.
  • Surprising: Krita offers an unparalleled platform for developer experimentation. Things like Cyrille’s magnetic painting guides or Lukas’ deform paintop are not only unique, but just plain fun, to write and to use. But we need to control the experiments. Right now, we have a lot of half-baked experiments in our code, like Emanuelle’s color mixer. That never got the maintenance it deserved, and I really need to pick it up. We should start working in a way that only the finished, polished feature lands in a release. And we should release often, so there’s no more than two-three months between finishing a feature and releasing it.
  • Accessible: krita2d.org is moribund, the people promising to help with Drupal have all disappeared. krita.org points the koffice.org website, which is rather embryonal. I know that I cannot handle Drupal or wordpress, but what else is there? We need a faq, a gallery, tutorials. Maybe I’ll start with just plain html again… Lukas Tvrdy has set up a number of krita-specific forums on forums.kde.org that are proving to be popular. So you don’t need to be an irc-addict to contact us!
  • Hackable: we started with scripting, extended scripting through kross, broke that (will fix it!) and there’s now shiva and its ilk: we want krita to be hackable, even for artists. Procedural layers, filters and brushes, we want make krita hackable beyond traditional scripting in python or scheme, but also beyond the traditional plugins Krita supports (tools, brush engines, filters, generators, file formats, assistants, colorspaces or other extension): if someone wants to add a new layer type that comprises a real node-based system, that’s possible too. But easy user extensibility is our first priority.


A tentative roadmap, where I hope that 2.4 will be released before 2010 is a distant memory:

  • 2.1: stability
  • 2.2: out-and-out performance
  • 2.3: use-case one: bliss out the comic book author whose usecase Enkithan has written down for us.
  • 2.4: use-case two: make something like David Revoy‘s workflow possible in one, integrated application. (Why are all the good artists French?).

And then on and on!