Krita on Windows

Sven posted his thoughs on the difficulties supporting Krita on Windows. I’d like to dig in a bit deeper here. The first question is, is it worth it?

Well, the highly experimental Calligra installer has been downloaded about 15.000 times. That’s a lot of downloads! Judging from the ratio of referrals from and, Krita is probably the reason for two-thirds of those downloads.

So, apparently there is a demand for Krita on Windows that makes people download it even though we’re extremely explict about its extremely experimental status!

We also know that there are bugs specific to Windows, like the slow move tool, a bug with duplicated layers being broken and so on. We know that the top toolbar looks ugly and that there are other issues where being non-native really is apparent.

Another thing I know is that developing on Windows really is no fun. As the Tomahawk Windows dude says:

We do need developers on Windows too, but no-one in a sane state of mind wants to develop there.. 😉

So what Krita needs is to find a volunteer who completely and utterly disagrees with that quote… Someone who loves Windows, cares about the look and feel of an application on Windows, and who simply loves developing on Windows. If you’re that person, contact me!

The other option would, of course, be to find the money to pay someone to work on Windows.

But we’re not talking 1000 euro/month here — we’re out of the student summer job territory! At a conservative estimate, we’d need between five and seven times as much: 5000-7000 euros of regular income to hire a full-time developer. So we’re out of donations territory, out of Summer of Code territory. It’s a big job, which needs to be done well.

If there are 15.000 downloads of an experimental version of Krita in about three months — maybe there is a market. Maybe we could package Krita, put it in an app store like Intel’s app-up, on Amazon, sell it directly, go with a pay-what-you-like model like Ardour. Whatever — and use the proceeds pay a full-time developer to work on the Windows version of Krita. It’ll, indirectly and directly, also benefit Krita on its main platform.

I’m seriously investigating all the options here, including finding some kick-start funding.

(Note: Krita is GPL, but that doesn’t stop us from charging money for a binary, even though we can’t stop anyone from copying the binary around or reselling it — and I don’t even want to do that. Free software is Free software. Being GPL, proprietary extras and improvements are also out of the question. And that’s the way I like it.)

Oh, and as a side-node: next to the highly experimental Calligra 2.4 installer that includes Krita next to the other apps, there’s also an extremely experimental Krita-only installer that packages Krita fresh from git master. Just to help me figure out how to do it. Get yours while it’s fresh at KO GmbH’s download page.

Call for Photoshop documents

Call for Photoshop Documents

One of the new things in Krita 2.4 (soon to be released) is pretty decent Photoshop file import. Not everything is supported, but you should be able to load RGB, Lab and CMYK files with multiple layers, thanks to the work by Siddharth Sharma.

Next is filling in the missing parts, and export, of course!

But for that we need to have a good, representative corpus of PSD files, with known version numbers. A bit like the corpus we have for applications like Words, Stage and Sheets — trunk/tests/calligratests/.

These office documents are tested regularly using special tools Thorsten Zachmann built for Calligra. We need that for Krita as well.

So I want to call upon all readers here to contribute PSD files to our collection. I need to know the version of Photoshop they were created with and the files will be committed to this public subversion repository, so they must be appropriately licensed or be public domain.

Please help us out! You can send the files to

Packt Open Source Awards

While we’re in the middle of the beta period for Krita 2.4 (which promises to be completely amazing, of course!), I got an email from Julian from Packt Publishing, asking me to fill in a questionnaire for the judges of the 2011 Packt Open Source Awards. Nice, thorough questions.

Krita is a finalist in the multimedia category… It’s already great that we got this far: a year ago, Krita never got further than a write-in option whenever there was a vote going on! But we want to win as well!

So please go to packt’s website, register and vote!

Krita, Wacom, Qt and distributions

It’s a never-ending tale of sorrow and tears… The tale of Qt, Wacom and distributions. It happens with distressing regularity that people join us on the #krita irc channel, the krita forums or the krita mailing list. Users, but also developers. Their question? “Krita doesn’t seem to support my Wacom tablet, but Gimp and MyPaint work fine!”

This is never actually caused by Krita. Krita uses Qt’s wacom support, same as for instance Maya does. The Qt Wacom api is good, the rate of events is good, we are fine with that.

The problem is that sometimes Qt breaks when a new version of the wacom drivers is released. And sometimes distributions package the wrong version of Qt and the wrong version of the Wacom drivers together. We don’t have an exact table of what works and what doesn’t work. As developers we tend to drift to distributions that are relatively good at supporting Wacom and Qt together… OpenSUSE hasn’t failed me for a couple of years now! But just check our help forum.

And then there are situations where Qt is blameless, Wacom is blameless and the distribution is really to blame. For instance, when distributions patch Qt to achieve multitouch with an experimental patch that breaks tablet support.

I’m not sure what to do about this: the bugs get reported to the distributions, and when necessary to Qt, but in the meantime, for many people Krita breaks every time they do an upgrade. And we cannot help them!

They’re in!

Six students are going to work on KOffice this summer: Marc Pegon is going to create an awesome transformation tool for Krita. Adam Celarek is going to make selecting colors a snap. Pentalis is going to add a brush engine and impasto feature to Krita. Dmitry is going to make Krita multi-threaded (and his selection means the Krita project might very well have enough funds to help create a good manual and have it edited!). Cyril is going to build a mind-mapping application based on the KOffice libraries, validating our architecture and creating features useful for the existing apps all along, and finally, Benjamin is going make KPresenter swing by adding animations and improving the animation framework!

Yay for the students, yay for the mentors, yay for Google and especially yay for the KDE gsoc administrators, who have done and are doing an awesome job!

I’ve used the word at least twice, but I’m going to use it again: awesome!

Playing with KWin’s Paint Desktop Effect

Warning: no videos included, though they would help a lot. Also note that I’m using an Intel chipset in both my laptops (the big one also has an ATI chipset, but that doesn’t work.)

Lukas recently discovered that Krita was taking about 100% of one of his CPU’s cores. When moving the mouse over the canvas. Since X11 took about 60% of that CPU we immediately thought of painting issues, so I started testing with KWin’s Paint desktop effect enabled. That effect overlays every rect that is redrawn with a color.

It quickly became clear that for some reason, updating the mouse position lable in the statusbar would update all of Krita’s window: menu, toolbars, canvas, toolbox, dockers and statusbar. Curiously enough, Karbon only updates the statusbar. When I disabled the mouse position label in Krita, the CPU usage was gone.

Then I started playing some more, also on my other laptop and now in Ersingen for the KPresenter sprintlet, we tried the same on Thorsten’s laptop. And I’m puzzled by the results:

On my X61t, the areas covered by the tooltips of the icons in the system tray is redrawn constantly, all on top of each other. If the panel is visible, and I make Krita full-screen, the area covered by the clock, underneath the Krita window, is continuously redrawn. This runs KDE 4.4.62, on OpenSUSE.

On my W500, the whole screen is constantly completely redrawn. No wonder Desktop Effects feel slow on that laptop! If I make Krita full-screen, no matter whether the statusbar is hidden or not underneath the Krita screen, the redraws are gone. This is KDE 4.4.0 rc3, on OpenSUSE.

On Thorsten’s T60 (ATI chipset), we don’t see the whole-screen redraws, but we do see a rectangle in the middle of the top-left quadrant of his screen, near, but not exactly at, the place where Thorsten keeps his clock that gets redrawn constantly. This is KDE 4.4.0 final.

But when we are testing KPresenter’s animation framework, we see that we only redraw the shapes that are moving, so that’s good! (Except when two shapes move, then Qt apparently decides to repaint the whole rect that contains the two shapes.)

Well, I’m puzzled, so I’m posting this. Obviously minimizing repaints is trickier than I thought, and it seems especially difficult to limit repaints to the minimum necessary.

To spam or not to spam…

I’m keeping my promise to write a weekly update on what has happened in Krita. There’s usually a lot to write about, and I’m trying to add some generally interesting things, some personal, some artistic, so it’s not just a commit digest, but a little bit more.

But I’m wondering how to syndicate it — Planet KDE is meant for personal blogs, and this isn’t personal. I’m not sure about the other planets my blog is syndicated. And I’ve had complaints that having a pointer to the new issue on my blog is a bit spammy, and I think I agree with that. So I’m intentionally not linking to this time 🙂 (But it’s a good read!)

Does anybody have any bright ideas?

Update: I just learned that if I can teach to put the Last Week in Krita articles in an rss feed that’s unique for what I post, i.e, personal, but from, I’m fine. I bet our webmaster can figure out how to do that, right Kubuntiac 🙂

A new manual for Krita

An application isn’t complete without good documentation. Those fine folks at Linux Format docked a lot of points from Gimp when they reviewed their new release because the manual wasn’t updated yet… Krita 1.6 had a pretty fine manual for a free software application, but given that Krita 2.2 is going to be so much better than 1.6, the manual should be ace, too. And almost nothing from the 1.6 manual is still usable, there have been so many changes.

We have to rewrite, and make it even better this time. There is no way I can do this on my and code, it’s got to be a collaborative effort. And there should be video tutorials, as well, as part of the manual.

So… Enter It’s the perfect central place for efforts of this kind. I’ve started an outline for a new Krita manual, a manual with more than just a description of every menu option and dialog, but one that focusses on concepts, getting things done.

Also: the first Last Week in krita of 2010 is out!

Krita Hackathon

Krita Hackathon

So today I booked two bed&breakfasts to handle the overflow of Krita hackers for the coming Krita sprint last weekend of February. We’ll be seven, maybe eight developers and Peter Sikking. A weekend like this is usually more discussion, getting together and building a shared vision than hacking, but Cyrille, Sven and Lukas will stay on following the actual sprint for a whole week of what I suspect will be very intensive hacking.

Of course, an occasion like this should be marked by having its own t-shirt. The last dedicated Krita sprint was in 2005, and back then we had t-shirts designed by Nuno:

I gave the last surviving shirt to Cyrille during the Oslo KOffice sprint.

So… Is there anyone who wants to set the vestimentary tone for the 2010 sprint?