Fading Memories

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. Something that looks a bit like this, but less like a progressbar:

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!

---

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 it's 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...

---

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!

---

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 64x64 pattern tiles

---

Oh the shame! It so happens that I have only two running versions of Krita: 1.6, to compare trunk with, and trunk. Now, as I said earlier, I happen to be working on loading and saving, and I suddenly thought that it would be way cool to be able to test loading Krita images saved from older versions.

But I don't have those versions, and I don't have images saved with those versions either... So: todays plea for help is "anyone who has Krita images, preferably with more than one layer, saved with Krita version 1.4 and 1.5, please, please contact me -- then I can test whether Krita trunk can still load old images."

---

It's really, really, really a pity KOffice is in feature freeze: just after the freeze went into effect, Lukas Tvrdy, the Summer of Code student who created the sumi-e brush engine (which simulates brush hairs), created another way cool brush engine: the deform brush, apparently inspired by the Gimp's iWarp filter. (Is that really with a small i and capital W?). This means that you can paint deformation on you canvas, and that's just so must fun!

For instance, quickly throw down a couple of semi-transparent radial gradients, and then use the star tool to paint star-shaped deformation onto the canvas:

In other news, there are people out there in the real world using Krita, which is always gratifying: Creating Storyboards.

And thirdly, I've done a lot of work on our brush engines lately, but right now I'm first going to finish our saving and loading code. I feel I have to, having read Cyrille's latest blog entry! (But in a good, gung-ho, way)

---

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 :-)

---

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)

---