Fading Memories

KDE 4.1 on Windows is really amazing. Some parts are buggy, of course, other parts aren't there yet -- but with 4.1, Dolphin starts up in the wink of an eye, kwrite is stable and useful, the games are lots of fun. Pity Umbrello and Akregator aren't all that stable yet -- but neither are they on Linux. Really impressive work by the KDE-on-Windows team!

And KDE on windows is, at least until the end of the month, a godsent for me. I don't use it at home, but at work. And when my current employer is too cheap to pay for, for instance, enough licenses of Paintshop Pro, so when I have to update the logo, I need to find another solution. Enter Krita. Kate is a better editor than most, and especially better than the monstrosity that is the Borland 2007 IDE -- which cannot even properly remember your indentation preferences and tends to give an index-out-of-range exception when editing source file.

But all in all, despite the great work done by the KDE on Windows people, I will be glad if I get the chance to stop being a Windows user. Windows is not a pleasant environment. My current contract terminates end of this month, with a small chance of an extension to October 1st, but I am busy looking for something that will allow me to work on Linux and KDE again. And, important, too, with open source tools and libraries. I have learned a lot, but the central point is this: with regards to productivity and developer-friendliness, we have already won. From Borland at least, and if I look at the hoops MS-Build makes you jump through, even Maven looks good.

For months, everything seemed fine in tablet-on-linux-with-Qt land. Or relatively fine. I could sketch with impunity using Krita 1.x and Krita trunk (unless I tried to paint outside the image itself, that is). A first gentle reminder of the state of tablet support under Linux/X11 came when Naomi wanted to try the Gimp for a change and she noticed that there was an offset of about a hundred pixels between her pointer on screen and where the drawing went. I shrugged and told her she'd better use Krita then.

Then Krita started crashing whenever I tried to use the stylus on my tablet notebook. Lukas Tvrdy suddenly lost tablet support. Cyrille Berger went on to investigate and discovered that we were getting spurious mouse events between the tablet events. Now KOffice is pretty smart in that it tries to map every input device, every individual wacom stylus, art pen or whatever the user has to its own tool. Spurious events that belong to another input device mean that tools started switching in mid-drawing, which in turn deletes the brush engine we were drawing with before we are done drawing. Ouch. A workaround is possible, of course, but workarounds have a nasty habit of coming back to bite the developer in the fleshy parts.

But plain painting with a tablet at least used to work without crashing -- and I have no idea what has changed. And, unfortunately, there is a host of issues with Qt's tablet support anyway: ranging from being hard-coded to certain names in X11.org (stylus and eraser, cursor isn't supported at all), which means Qt effectively doesn't have tablet support on OpenSUSE, to event compression (which means that we don't get all tablet events, which in turn means ugly lines because we cannot track exactly the artist's hand movement.

For reference, these are the Qt issues we're dealing with:

• 193856 - Allow disabling of compression for mouse/tablet events
• 160626 - Tablet events are incorrect when leaving the QWidget
• 187372 - Qt does not recognize all input devices on X11
• 210132 - Qt expects hardcoded wacom device identifiers from xorg.conf
• 207389 - When the tablet device changes after the application has been started, QTabletEvent::device() still refers to the old one
• 193475 - Mac; Graphire 2 tablet stylus device not detected properly

None of them seem close to being closed. The last one is for OS X -- I'm not sure how good the support for tablets on Windows is since I cannot test Krita on Windows with my tablet due to Microsoft messing up their upgrades. (In order to have a Windows in a virtual machine, I first need a Windows installer, and those are not free.)

So... What now? We have basically two choices: try to improve Qt's tablet support and submit a patch to Trolltech (or try to get paid for improving it?), or re-instate our old Krita 1.x tablet code. It had the same problems with detecting devices that aren't called "stylus" and "eraser", but at least we handled the "cursor" device and we managed to handle the event compression very well. Detecting when a user had changed between tablet and mouse was quite buggy, though, in 1.6. And if we resurrect our old code, we can do so for just Krita, or for all of KOffice. Or we could disable the code that maps an input device to a tool instance, but that would suck big time for artists who have gotten used to pan with the mouse and paint with the pen (like me).

Lukas Tvrdy, the Krita Google Summer of Code student currently has one of the two wacom Intuos tablets with art pens the community has sponsored us with. (The other is with Emanuale Tamponi). One of the goals of us having these fancy tablets is making sure Krita does interesting things with features like tilt and rotation, and one of the goals of Lukas' summer of code project is to make a chinese brush brush engine that takes these parameters into account. But, of course, serendipity is always welcome:

I've asked Lukas to make sure that we won't lose this effect through over-eager debugging :-)

Well, only a soft freeze, not hard yet. But that means that we won't add new features to KOffice anymore that haven't yet been announced in our feature plan. And those features, even though in the plan, that haven't been at least a little credibly implemented by September 16th won't make the cut for 2.0.

What does that mean? Well, our blogs will become a lot more boring. We'll be doing more and more stabilisation work. And more and more bug fixing. And more and more smoothing out of wrinkles. And more and more things no-one can interpret as a "promise", even though it's only the enthusiastic articulation of a developer in the heat of the hunt.

On the other hand, we've been working on KOffice 2.0 since 2006. That's right -- we started porting KOffice to Qt4 and KDE4 March 27th, 2006. And it's no denying the road has been gruelling. Really, I totally grok the GTK people who don't want an api break for GTK 3.0. On the other hand, unless GTK gets gingered up a lot, any GTK app will be too nineties for words in a year or two.

And moving an app over to a new API is only the beginning. Frictions among KOffice developers, chasing the taillights of kdelibs, Qt4 that wasn't really as excellent as it should have been until 4.3, personal things like job or house changes, an increase in bad manners among the general public (although I remember saying the dot wasn't any fun anymore in 2006 already). Sometimes the fun and excitement was hard to find. And now we're in boring stabilisation mode again...

And I'm still worried about sustainability. I worry whether it's possible to write world class office software with more or less one part-time coder per application. Especially when that part-time aspect gets eroded by days jobs. That is why it's so great that NLnet sponsors us, with money for logos and money for Girish Ramakrishnan to really focus on some issues. But we really need more people!

You don't need to know C++ -- we can teach you that, no problem. And despite the aforementioned frictions we're a nice bunch of people, really. And we're pretty patient with questions. We cannot promise money or riches, but we can guarantee fame and fun! And we're committed -- we'l go on and on, alpha after alpha until we have something we dare call a beta -- and then we'll go on and on until we've got a release candidate.

This year KDE tried another system for alotting slots to subprojects: some subprojects were allowed to predetermine their list of preferred projects and then got a certain number of slots guaranteed. It didn't quite work out, and I'm not totally happy with the way we executed this idea. The problem is, KDE, with 47 slots and 300 applications is just too big to handle. The mentors cannot read so many proposals, and the Google web interface doesn't scale to 300 applications either.

Anyway, I'm really excited by these KOffice projects, even though there's just one Krita project:

• Kexi Web Forms by Lorenzo Villani, mentored by Jaroslaw Staniek
• Converting the old KPresenter format KPR to ODF by Carlos Manuel Licea Vázquez, mentored by Casper Boemann
• Sumi-e brush engine for Krita by Lukáš Tvrdý, mentored by Boudewijn Rempt
• Calligraphy support in Karbon by Fela Winkelmolen, mentored by Jan Hambrecht
• Notes and Presenter View Support for KPresenter by Fredy Yanardi, mentored by Thorsten Zachmann
• Improve ISO OpenDocument support by Pierre Ducroquet, mentored by Sebastian Sauer
• Improve KWord MS Word filter by Benjamin Richard Cail, mentored by Boudewijn Rempt

I think this is a nice mixture between new features and work on improving the core of KOffice

But... There's another, very cool project that will benefit KOffice a lot, though it isn't even among the KDE projects: KDE Control Panel for Color Management.

Krita already had filter plugins: filters take pixels as input and produce possibly different pixels as output. Filters in Krita can be used destructively: to change a layer or a mask directly. They can also be used dynamically: either in adjustment layers that filter the result of the layers under the adjustment layer in the layer stack, or as filter masks, that filter the contents of a single layer. Or you can paint with them, and in the future you can associated filter parameters with the pressure, rotation and other types of input from your input device. I'm working on that...

But now, requested by Matthew Woehlke, there's another type of plugin: generators. Generators take parameters but not pixels as input, and create pixels as output. That's ideal for things like Apophysis-like plugins. Right now you can only use these generators in Krita on paint devices, as fill types (similar to solid colors or patterns) with the fill tool or as dynamic layers. Painting should be possible, too, but that needs some work. And it would be nice to use this kind of noise in a transparency mask or in a filter mask: that's already possible, but not in a dynamic way.

There's just one snag: I'm not a mathematician, so I depend on other people to write nice generator plugins! Matthew has promised to do something Apophysis-like, but we need lots more: flames, clouds, checkers, waves, marbling -- for someone with the right kind of knowledge or no compunction about copying code from other free software, the possibilities are endless!

So today the Wacom Art Pen arrived -- thanks are due to Cornelius Schumacher, Thorsten Zachmann and Eva Brucherseifer and Axel Jäger who busied themselves with paying, ordering, checking, sending on after a misdelivery! The art pen has a very nice feel on the tablet, a kind of resistance that makes drawing a lot of fun. And there appears to be not a single X11 application that makes use of its rotation feature.

To celebrate the new tablet I have started working again on my Chinese brush simulation. I'm working on the research done by Clara Chan. The Krita version works -- somewhat. The lines the brush bristles draw are not anti-aliased. There is some support for tilt, but not for rotation yet -- which would be quite interesting since rotation of the brush is one the ways to get the right effects when painting in the xiao pin style.

Apart from the cool things we can now develop for the tilt and rotation features there is another thing: the koffice input device architecture goes way beyond what other applications do. In an application like Photoshop or Corel Painter there is only one active tool, no matter which input device you pick up. If you paint freehand with your art pen, and then grab the mouse, click the pan tool, then pick up your art pen again, your art pen pans.

Already with Krita 1.6, you can select the pan tool with your mouse and a paint tool with your stylus. To me, this feels like a very natural style of working. If I paint with real oils, I tend to hold the active brush in my left hand, and in my right hand the palette and a quiver of other brushes of different sizes and with dabs of different colors. If I work with pencil or charcoal, I have a stick of charcoal in one hand and an old cloth in my other hand to soften the lines.

With KOffice 2.0, every input device, even every pen you've got for your wacom has its own tool. So, if you've got an airbrush, a stylus and a mouse, your airbrush can be associated with the freehand tool and the airbrush paintop, your stylus with the freehand tool and the chinese brush paintop and your mouse with the pan tool. And if you've got three styluses, each one can be associated with a certain tool or paintop. Without needing to configure stuff, of course, you can just select tool and paintop by clicking on them. We have already implemented this, but testing with different wacom input devices was a bit hard.

What doesn't work because of an unfortunate but fixable design oversight is having different active colors for different input devices: that would be the ultimate (although expensive) analogy to working with real brushes! (We'll also have to persist the state between sessions, too)