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!

Krita is compiling

On two laptops, prior to running the unittests again. Last time I tried them — four hours ago — I had zero failures. And yesterday, Krita’s bug count in bugzilla had dropped below 40; today it’s 42 again. And that includes a couple of nasty crashers, where we might have a choice between leak and crash, or worse: between disabling a feature and crashing. And there are some important issues among the non-crashers, too, issues that really should be solved.

But we’ve been fixing bugs like mad, mostly me and Sven Langkamp, since Lukas is working on his thesis (which is about brush engines for Krita, yay!) and Cyrille is finishing up his phd. There are a couple of bus that we really need Cyrille for, even.

The bug fixing has been very rewarding, even though our ace beta testers, Enkithan, M4v, Gaizka and Bugsbane have been doing their darnest to keep the bug count at over 42. And there’s more cool stuff: Kubuntiac (on the forum, who is Bugsbane in bugzilla) has been working on Krita’s website, and when we’ve migrated the content from the old website over, we’re ready to flick the switch and krita will have its own website, with lots of content, links to techbase and to userbase.

(Note: we have disabled the following plugins for 2.1: glsl filters, painting with the wave filter, kross-based scripting, together cooperative painting, panorama stitching, the chinese paintbrush (not sumi-e, that’s in), an experimental brush engine, the graphicsmagick import/export plugin (photoshop, gimp, gif etc.) if you have GraphicsMagick newer than 1.2 and the perspective transformation tool.)

And have you all seen Enkithan’s wonderful Dungeon girl illustration, all done in Krita? That’s why I’m spending twenty leisure hours a week on Krita!

Tomorrow Cyrille will tag the first release candidate of KOffice 2.1…

Another feature

And another contributor: Edward Apap, better known on irc as
Antiquark, has created a new dialog for krita that makes it possible
in an easy way to extend the canvas size. This is a patch that we
had in readiness for some time already, but with the imminent release
of 2.0, we can add stuff to trunk again!

Welcome to the Krita team, Antiquark!

A new feature for Krita

Yesterday, I took a day off from serious things like redesigning the library structure of KOffice, working on the Krita part of the redesigned KOffice website, trying to optimize the hell out of freehand painting and several other things, like being too sick to actually think straight for two consecutive moments and so not making much progress with any of these things.

I took a holiday, in short, a chance to add a nice little feature to Krita: image backgrounds.

An image background is a pattern that is tiled beneath the root layer, so that if there is anything transparent in your image, the pattern is seen below. Most useful to have a nice background, perhaps paper-like, when sketching.

This morning it was done.

Now this was just a little thing to play with, but there are several fun things about it: for one thing, I have resurrected a class that Patrick Julien wrote in 2002 and was originally responsible for painting the checker pattern. We’ve got different code for that now, that makes it even clearer that the checks aren’t part of your image, but this class is very well suited to painting a tiled background.

Another thing is that MyPaint has a similar feature, so ideally we’d like to be able to interchange, through OpenRaster, images made in Krita and in MyPaint. We’ll need to extend OpenRaster for that, though, since MyPaint saves the background as a layer as big as your image filled with the tiles, and Krita (will) save(s) the background as a property of the image.

And there is a small list of TODO’s caused by this little feature, todo’s that are actually almost all simple Junior Jobs:

  • enable Add, Remove, Reset buttons for background pattern management.
  • label the background patterns somehow, allow tagging
  • add solid-color background patterns and use a categorized view for them
  • add a custom-color background pattern
  • add lots of nice patterns
  • integrate with custom image widget (the one you see on startup)
  • integrate with image properties dialog
  • add to loading/saving of KisImage in .kra and .ora
  • set pattern on double click
  • allow non 64×64 pattern tiles