Improving the public visibility of Krita

Krita is a very promising application. Its problem is that the potential user currently has to build all of KOffice only to get krita.

At aKademy, Ken Wimer told about that at the artists meeting. I first thought it would be the best to get Krita out of the KOffice into kdeextragear or something, but the downside is that it would take a duplication of all the cool koffice libs features, so I had a look into the issue.

I came up with a simple solution: I only checked out the basic direcories: lib, templates and mimetypes. Afterwards, one checks out krita and filters/krita, and runs make -f Makefile.cvs, then I just compiled (yes icecream even rocks on a PowerBook, if one has the apropriate cross-compiler environment) and installed the stuff and it works.

Today, tackat asked me again on how one could get Krita more visible by regulary posting it on and make it painless for the user to install.

Simple: create a package from the libs (all directories listed above, suse has that already, so it might be worth taking a look into their source RPMs) and create one for krita. Then offer both for download. As KOffice libs are downward compatible, this should be a good way that even distributors could follow. Now if Krita wouldn't need bleeding edge CVS koffice libs (actually I didn't check), then it would be even more easy, as we didn't have to care about versioning of the libs at all.

So if anyone of the Krita guys is reading this: Do you agree that's a good idea? Tackats thesis is that if Krita is easier to install, its development can happen much faster, and I tend to agree, because contrary to kde pim, where you seldomly need only one application, this is not true for Krita, or maybe even other applications. Kexi is already released seperately afaik, and so could be Krita and Karbon, at last as development snapshots.


This makes a lot of sense to me. One issue is that it might cause problems with packing systems like RPM. It might be worth making two packages - one for the app itself and another for the libs. That way people upgading both krita and koffice separately (but at different times) would be ok.

By Richard Moore at Sat, 09/11/2004 - 15:50

I take my maintainer duties exceedingly seriously, and, besides, I read planetkde whenever I am waiting for Krita to compile.

I'm all in favour of your idea with the following provisos:

* I tend to keep Krita in sync with KOffice HEAD because otherwise too much valuable developing time gets wasted. We're still in the adding-basic-features stage, I'm afraid. That means you need to package KOffice head libs. Which means that installing a Krita-preview release can break your existing KOffice installation, and that must be made very clear.

* Having preview releases of Krita would be way cool, but at the moment we're working real hard at getting the basic things done, which means that we're not really interested in bug reports, weird as that may seem. Without blinking, I can recite at least three crash situations, six bugs prevent working without letting crash Krita and if you keep pouring the wine, I'll keep you entertained for much of an evening with the rest. Bug reports will only tell me what I know already, or what I don't want to know yet, being someone with a slight issue with focussing on what needs to be done. I'm really interested in patches, though, and I would love to have someone showing me the code for littlecms integration -- and artwork for tools and things.

* I'm not going to do much work on doing preview releases beyond writing/reviewing blurb and contributing changelogs. I've got a long-standing hate-hate relationship with software packaging tools. I've tried Roberto Alsina's checkinstall, but it didn't work well enough for Krita. Someone else needs to do the heavy lifting with rpm and things like that.

* Keep in touch with me so whenever a big, cool new feature is done, we can do a new pre-release.

I'm really full of hope that Krita will finally, after half a decade, be part of KOffice with the 1.4 release, and I think that a preview release for my birthday, September 24, would be about the best birthday present I could wish for :-).

Oh, and as an aside: we still have some basic, deep-down problems, but on the other hand, Krita's already capable of integrating plugins for color models, filters, brush types (wanna do an palette knife or charcoal stick brush -- you write the code, and I'll integrate it into a plugin for you) and more. Which means that it's easy to contribute meaningfully with code that doesn't touch the innards at all.

By boudewijn at Sat, 09/11/2004 - 18:59

I think by giving krita more exposure, you will also gain more active contributors, not only bug reports. but I sure understand your concerns. Still I don't think you'll need to be afraid of a bug flood.

By Daniel Molkentin at Sat, 09/11/2004 - 21:19

If someone starts making regular tarballs & rpms, I'm all for it. I don't think I can do that yet -- so someone else has to step forward.

By boudewijn at Sun, 09/12/2004 - 05:42

Ladies and Gentlemen, please welcome... the Krita nighly snapshots:

The only thing missing so far is the krita import/export filters, I hope to add them soon. SuSE RPMs and DEBs are on their way.

Boudewijn, if you make sure Krita's architecture is stable by the 24th, I am happy to provide you with a preview version tarball that can be announced on

By Daniel Molkentin at Sun, 09/12/2004 - 13:53

I'll keep in touch with you by mail. Thanks!

By boudewijn at Sun, 09/12/2004 - 18:49

...I would love to have someone showing me the code for littlecms integration...

While I dont have the capabilities to do this, here is a suggestion: the Scribus developers *have* integrated littlecms into their DTP software -- and it is working marvelously there. So they might be of some help to anyone attempting the same for Krita.

By Kurt Pf. at Sun, 09/12/2004 - 11:14

LittleCMS integration in Scribus works well. You will find, however, that the internals of how it's done are hard to follow, and probably not all that informative. I would not recommend it as an example of how to implement lcms integration, though if you can follow it there are some good things to be learned about its decisions and processes.

We also use conditional compilation throughout, which ... isn't pretty.

I'd personally recommend that you start with a nice C++ abstraction of a colour management interface. You could then provide an lcms-based implementation, and a 'null' implementation for users who don't want / don't have colour management.

Doing things this way would leave room for future integration of, eg, Apple's ColorSync on Mac OS X, or one of the other free CMMs. More importantly, it'd keep that icky conditional compilation crap out of your codebase.

I'd be interested in being involved in any such development, since Scribus could well benefit from it too. I'd only have an interest if the interface its self was pure C++ (and Boost if useful). Perhaps Qt too, but I'd be much happier without to make it useful for more projects (the Inkscape team come to mind) and to avoid the qt3/qt4 transition fuss. My time is limited so there's only so much I could do, but I'd still be happy to contribute.

You might find it useful to speak to Peter Linnell (mrdocs on #scribus, and he reads the ML) about colour management if you haven't already.

Craig Ringer
[email protected]
[email protected]

By ringerc at Sun, 12/25/2005 - 06:24