Third Krita Sprint First Day

While I was forced by circumstances for forego the production of t-shirts for this sprint — and I feel bad about that! — the first day of the Third Krita Sprint has been great. Yesterday, our webmaster Bugsbane, a.k.a. Kubuntiac and Krita hacker Dmitry Kazakov arrived in Deventer already, and this morning we took the train to Amsterdam, to the the Blender studios. We’re crammed around the same glass table where last year selected Krita hackers saw a sneak preview of the Sintel movie. Feels weird!

Assembled today were artists David Revoy, Animtim, Silvio Heinrich and Kubuntiac, as well as hackers Adam, Dmitry, Sven, Lukas, Matus (tomorrow is his birthday!), Dmitry, Silvio (again, this guy puts in a double appearance). We got a surprise visit from a bunch of Danish game designers here for a game jam at the Binger Filmlab, who, of course, got a full demo.

The selection system in Krita was redesigned, bugs were filed and solved, lunch was consumed on a road-side terrace in the wonderful sunshine, dinner was had at the Blender team’s usual Thai restaurant — and we made plans for tomorrow.

We’ll start off around 10 with an artists session: all artists present are going to take about half an hour to work in Krita, a projector connected so we all can follow. We call it the “demo and gripe” sessions. That way the developers can learn about the way different artists really work, and we can spot glitches and issues with usability. We are going to try to record this session, both sound and screencast and make it available afterwards. No promises though, we might run into glitches there!

The afternoon is for the whole team to get a list of highly important issues that hamper artists most so we can set the priorities for the year following this sprint. After that — it’s hacking and discussion time!

Lamented unmaintained features in Krita

Krita 2.3 is really pretty good — although following the release we’ve found a number of rather serious issues, especially when working with images in the 50-100 megapixel range. But on a less important note, there are quite a few features in Krita that never really got any love after they were initially coded.

The pattern creation tool is one of those, and it’s getting more important now since it’s not possible to use patterns as a color source for freehand painting. The pattern creation popup was coded in 2006 by Bart Coppens (who is also responsible for quite a few other features in Krita but who’s too busy with his Phd these days to code for Krita).

As you can see, it’s quite simple:

There’s a preview, an update button, an use-it-now button and an add-to-predefined patterns button. If you try to make your pattern from a big image (like this 6000×4000 image), you get a warning, and the pattern will be downscaled to fit in 1000×1000. That’s because otherwise it’s pretty easy to run out of memory! Oh, and since yesterday you can select whether you want to create your pattern from the current layer or from the whole image.

What’s missing is using the selection, naming the pattern, exporting the pattern and who knows what else — I haven’t yet checked what other apps provide. Managing existing patterns is pretty primitive as well. And the layout of the popup is a bit of an embarrasment!

But there you have it — a nice small feature that’s suddenly become important. It was fine in 2006, but in 2011, we expect more of it. So… If you suddenly feel inspired to hack on this, join us on #krita on and we’ll get you started!

Speaking at Fosdem 2011

This year I’ll give a presentation at Fosdem. I’m not sure which day yet, though.. Updates will follow. The presentation will be very technical: I want to show how easy it is to build a new, custom interface on top of the Calligra Suite core engine — using QWidgets, QGraphicsView or even Qt Quick, for viewing and editing of documents.

I don’t think there’s any other office engine/application suite that makes it not just possible, but even relatively easy, to reuse the canvas, the file conversion code and even the tools in applications. Calligra is beginning to become sort of the webkit of the office document world.

There’s a lot of interest and a real need for this sort of possibility: I know for a fact that apart from Nokia’s FreOffice/Calligra Mobile, there are at least four projects working on a new Calligra user interface, using various technologies, some of them generic, some of them focussed on a particular target group, like medical information systems.

I’m really looking forward to it, but it’s going to be a weird kind of weekend for me, though, since Irina will be doing KDE booth duty, like last year, and I don’t think we have ever been away from the kids together for more than a day since they were small and still had grandparents who could care for them for a weekend.

Moving KOffice to Git

No, don’t get all worried yet! The KOffice community has been planning for a long time to move development to git, but it’s only now that all the pieces seem to fall into place. The KDE git project infrastructure is looking pretty good and ready for use.

The only thing missing for KOffice were up-to-date conversion rules and a timeline. KO GmbH decided to do something about the first, by sponsoring Ian Monroe to bring the rules up to date, run the conversion and put the first experimental KOffice git repo online:

What’s needed now is people cloning this repo, testing it, checking it for weirdnesses and getting a feel for git in general.

And the community has decided on a timeline for when development will move to Git, namely right after the branching for the 2.3 release, which should happen with the first release candidate. In other words, pretty soon!

To the Meego Conference

I’m writing this blog post actually on the plane to Dublin. There must be other conference goers on this plane, but I’ve only seen Suresh Chande, the mastermind behind FreOffice. Specially for the conference, I’m bringing a little netbook and a tablet to the conference, both with the KDE Mobile Framework installed. My N900 runs an older version of FreOffice, on Maemo. Meego isn’t really ready for use on the N900, and I need that phone as a phone!

The tablet is a WeTab, and while it certainly looks cool and has an intriguing user interface, it’s still Meego 1.0. When I got it, it was frankly crap. A couple of weeks and many updates later it’s actually really quite good. Some rough edges still, some apps, notably the eRreader, are still not very good. But the user interface, the browser, parts of the email client are good, as is repsonsiveness and speed.

The netbook is an Asus EeePC — and the first bit of hardware that is actually small enough to comfortably type on in the economy class. Lovely little thing, but it’s hard to switch between it and my thinkpad since the Fn and Ctrl keys are in the wrong order! I put MeeGo on it, of course…. There are many good things to be said about the MeeGo Netbook interface, but it’s not my preferred interface. the titlebars are too big and the window switch animation is too intrusive. And the twitter tab doesn’t have an plugin!

Anyway, the KDE Mobile Framework is an interesting story. Most people will probably know that KO GmbH has worked together with Nokia to create a mobile user interface on top of the KOffice core, called FreOffice.

FreOffice is being developed right inside the KDE subversion repository, and saw a huge amount of activity this summer when Nokia gave a dozen interns in Bangalore the chance to work on FreOffice. Jaroslaw Staniek is now spending time cleaning up — not that the interns didn’t do a great job, but the activity was so frantic that there was little time for refactoring and introspection. If you have an N900, you owe it to yourself to install this app and play with all its features. It is the only free mobile office suite in the whole wide world…

Since FreOffice is built on top of KOffice, and KOffice is built on top of KDE, we needed KDE available in one form or another on the very constrained N900. And we needed it fast, since FreOffice had to ship as soon as possible, or preferably earlier. The temporary solution we came up with was to copy the KDE libraries, cut them down and then cut them down some more. This abomination unto Nuggan was named “libkok” and packaged for Maemo.

Of course, MeeGo has this no-forks policy, and besides, it would be great if other highlights from the KDE Software Collection could make it to MeeGo. So, last week, Kevin Ottens, Marijn Kruisselbrink and me have been really busy. Kevin has been working for a long time on creating a mobile profile for the KDE libraries, stripping out deprecated stuff, separating the components and cleaning up the build. Marijn has been packaging the kde libs mobile framework for MeeGo and making it available through the MeeGo build service. KO GmbH sponsors Marijn’s packaging work.

What I’m doing is porting KOffice and FreOffice to MeeGo using those packages — run a finger-enabled FreOffice instead of OpenOffice on the WeTab.

Fast forward a very intense MeeGo Conference… I simply had no time to blog, hardly even to dent.
I’ve certainly learned a lot during this conference about what MeeGo is, about the politics around it. And I’ve used MeeGo exclusively from Sunday morning to Thursday night. It was really quite usable, but I’ve seen Plasma run on the Lenovo Ideapad already 🙂

(The IdeaPad by the way, while not an entirely unwonky piece of hardware, clearly shows the way forward for laptop/netbook manufacturers: I think everything will come with a touch screen in the near future. I see people all around me trying to touch the buttons on their thinkpad screens when switching between the ideapad and their work laptop.)

I did manage to visit the National Gallery of Ireland, where there is a great collection of C19/C20 Irish and English art, as well as some Dutch, French and Italian masterpieces I’m very happy to have seen, like Velasquez’ kitchen scene with the supper at Emmaus or “Sunlight” by Orpen.

And now I’m at the KDE Mobile sprint in Berlin, trying to make the KDE libraries into packages suitable for MeeGo, together with Marijn, Chani and a host of other people.

Compared to a KOffice sprint everyone is very quiet and hacking very hard here — though we might have made enough noise for the weekend last night at the KDAB-sponsored dinner in the Greek Restaurant.

How’s Krita shaping up?

(This is a way more personal thing that a Last Week in Krita (which I hope to be writing today as well — and I need to start working on the promo literature for 2.3, work on the manual and the first-run demonstration image) so I’m finally writing about something KDE-related on my own blog again!)

So, to the point: how’s Krita shaping up? I have several times said last year and during this year that I wanted Krita 2.3 to be end-user ready, no excuses. No longer a promising project but a solid deliverable. That doesn’t mean it needs to have every single feature conceivable, but an artist has to be able to sit down in the morning, start Krita, start sketching, painting and at the end of the day, he should have had a smooth experience, a productive day and a desire to put in some more hours in the evening because he’s having fun.

Well, we’re not quite there yet: David Revoy did try to do just this a week or so ago, but there were still annoyances and bugs he ran into. And there are still major bugs and crash bugs — and those will be in Krita 2.3 Beta 1 which should be released soon. Those bugs will block creating a release candidate for Krita 2.3 — and we’re working hard on fixing them.

For 2.3, some features we have been working on haven’t made the cut again — mostly stuff I was working on, like the PSD import filter, the MyPaint brush engine or the color mixing palette. I’ve been absorbed a bit too much by my day job (working on KOffice), writing stuff for and about Krita, and even being a maintainer of an app means that you spend a lot of time  coordinating, not coding. And there’s been a lot going on my private life as well — but that’s not an excuse.

But all in all, and with these caveats — in my opinion Krita has shaped up very well in the past nine months. We went from extremely slow, very abstürzfreudig to pretty smooth and quite dependable. Just check out the art people have created with Krita — and then imagine what is possible with the finished 2.3! (And isn’t the new showcase page nice?) Now for the final lap!

Back in Bangalore

Following hot on the heels of a week of intensive KOffice performance analysis in Helsinki and a great Akademy, I’m in Bangalore again for two weeks. Not specifically to meet again with the Bangalore interns working on FreOffice, but rather to work with Nokia on mobile KOffice. Marijn Kruisselbrink is here together with me, and when we leave, Jos van den Oever will relieve us.

I’m happily hacking away on a project that was started at the last KOffice sprint in Essen: making KOffice more flexible by allowing other canvas types than QWidget-based ones, for instance, based on QGraphicsView. Lots of interesting challenges, and also some quite nice progress already.

Instead of a boring hotel room with four attendants to serve me with a beer, we’ve hired an apartment in the Orchard Suites, about ten minutes by car from the Office.

It’s clean, roomy, the breakfast and dinners are homely (and therefore very good). There’s wifi, there’s electricity — the only minus is that we haven’t found a surefire way of getting back to the apartment from Nokia without missing cabs, auto-drivers who don’t know their way in Bangalore… The works. Tonight we asked the hotel to call us a cab to bring us to the shopping mall nearby where I’d been with Vidhya. He took us to MG Road instead — a 3 hour drive in the evening traffic, so madness!

In any case — moving from the hotel to something more local means I’m learning new things again. This weekend, we’ll be buying books at Blossoms’, seeing the sights with Amit — and then back to hacking!

Writing a custom widget…

One of the dangers of having a real interaction designer look at your application is that they are apt to suggest that some special widget might make your app much nicer, much more efficient, much more usable. And they are right, of course. Which sucks because writing a custom widget that respects the application style is not fun, at least not in Qt, but I haven’t seen any toolkit that makes it fun.

And a custom widget in this context is not a form with two or three existing widgets in a layout and some signals to connect them.

So let’s look at the widget Peter suggested we use instead of KDE’s or Qt’s spinboxes and sliders. The needs are clear: we need a numerical input widget that shows visually what part of the total is enabled. Mouse wheel, tablet tilt and drag need to decrease or increase the value, clicking somewhere in the widget needs to set the value to that level. It should show the value as numbers inside the widget. Spinbox arrows and behaviour would be nice. It should have double and int support. And finally, it should have an option for exponential or segmented behaviour (1 – 10: stepsize 1, 10-100, stepsize 10, 100-100 stepsize 100).

So, what we are creating is a sort of legitimate bastard child of a progress bar, a spinbox and a slider, all in one area.

Well… Sven has spent half a day on this, I’ve spent a day on it… I guess this is not our forte. There doesn’t seem to be much documentation on the topic of creating widgets from scratch. I’ve also been looking for exising Qt implementations, but haven’t found anything. So… If there is anyone who knows where I can find a widget like this, or who would like to help Krita by implementing it, please, please, please tell me!

Last Weekend in Krita

Don’t worry — tomorrow I’ll do a Last Week in Krita for, but it’s  so long since I last blogged about Krita personally, and besides, I need to think-think before writing down dot story and story about the Krita sprint. (Short version: it’s a blast — not everyone could come, but we have seven great people and me in one room and working together and having fun and being productive.)

So… Cyrille has already let the cat out of the bag: Peter Sikking joined us this sprint to help us define a clear vision — and stayed on afterwards to help us with our various and manifold usability and interaction problems. I think most people in the libre graphics world will know Peter from his work on the Gimp and OpenPrinting.

Well, our vision session wasn’t characterized by any real friction, but it still took many hours. In the end we arrived at a real and coherent vision. Cyrille already blogged it, but it’s still worthwhile to post it again: (I also put it up on

Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.

Modeled on existing real-world painting materials and workflows, Krita supports creative working by getting out of the way and with snappy response.

Now this is a really short statement, and as any short statement it deserves some careful parsing. Let’s go through it, because it shows what the Krita team — seven of them were present in Deventer — has decided they want to create.

Krita is a KDE program. That means we’re a program, not just an experiment, and it most importantly means we’re part of the KDE Software Collection, and that we are proud of it. It’s also important for what it doesn’t say: it doesn’t say KOffice. Now Krita is very clearly built upon KOffice technology, which sometimes gives us a lot of advantages, and at other times is, frankly, a bit of a burden. Our use of KOffice technology is not going to change for now. But we are trying to be a KDE program for sketching and painting, not an office program for working with raster images. I feel it’s good to have that clear and in the open: it is something we have been struggling with for years in our minds.

“Sketching and painting”: these are different but very related things. Sketching is freeform, exploration-oriented, not process-oriented. Painting is directed, goal-oriented, process-heavy. But there is enough overlap that it’s important to support both, otherwise, we wouldn’t be end-to-end. “End-to-end”: an artist opens Krita, starts working on his ideas, and finishes their creation. And their creation is a file: not a printout. Other apps are better in reproducing the work on paper. Not our job, in other words. And “by masters” — that means that Krita is not going to hold your hand until you’ve learned enough to graduate to another application. We feel that if we focused on beginners and intermediate users, we would punish users who learn to use Krita really well.

Note also that there’s a full-stop after this sentence: so we don’t intend to support photo collage, photo manipulation, graphical production work (make 300 pictures glossy, for instance), icons, animated smiley gifs, web mockups.

Then we are making a bit more explicit what areas we are interested in, and that is a commitment: maybe not immediately, but throughout the development of Krita, we want to explicitly support artists working on concept art, cartoons and textures. That means that if we need special features tailored to those endeavors, we will want to include them and make them as good as we can, or preferably better.

Finally, we’re making a promise: we want to make working with Krita a good experience: if you are a trained artist, Krita will not alienate you. If you want to work without all this computer-folderol around your painting process, we want to make that possible. We’re taking an artist’s process as our guideline. And we want to achieve a good performance — on master-level hardware, of course.

There are, after all, some physics laws, and you’re not going to get a 20,000 x 5,000 multilayer image in a netbook. We are still discussing the minimum screensize, since I have a 1024×768 tablet pc that I cannot replace quite yet…

Now this is my personal explanation of the vision statement: read also Cyrille’s blog.

Oh, and it seems that Canada has won the hockey thing in Vancouver — which makes our Canadian Krita hacker Vera very happy!


KPresenter Sprintlet in Kämpfelbach-Ersingen

Last weekend, Casper Boemann and Boudewijn Rempt visited Thorsten Zachmann, the KPresenter maintainer for some dedicated and focussed work on KPresenter. Not so much to discuss issues and set out future paths, but to do some high-bandwidth design and development, on bugs, but also in particular on one big missing feature in KPresenter: animations.

KPresenter, being a KOffice application, is a dedicated ODF application. ODF defines that animations are to be saved in the SMIL format (Synchronized Multimedia Integration Language). And while there was already some code that implemented animations, loading and saving was not implemented at all.

Casper and Thorsten got the basic design and implementation were done this weekend, for loading, saving and animating. Of course, there are tons of animations in other presentation applications, like Impress, Keynote or Powerpoint, and we’ve only scratched the surface. Implementing presentations would be a very rewarding and fun pursuit for a beginning hacker — or even a Google Summer of Code Project.

There were other issues, such as dealing with a long-standing OpenOffice bug (that got fixed for OpenOffice 3.2), where you’d see the contents of the master page placeholders on every slide. Boudewijn and Thorsten came up with a clever workaround for that. We investigated arrows on line-ends — unfortunately, that needs more work, as well as a bug in the handling of date and time variables. All in a day’s work, of course, but this was special, since we could be together and bounce ideas off each other at a really fast rate.

Thanks go out to the KDE e.V. for sponsoring our travel and to Margot and Thorsten for their hospitality!