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?