Fading Memories

It's that it's been around since 1997, and can do a lot more than we, but take a look at

It's even got a performance tests menu item :-). I'm impressed by the application, not just by its price tag, but also by the fact that the author has made a more-or-less complete photoshop clone _and_ has written his own cross-platform widget set for it.

In other news: Michael Thaler has improved the performance of our scaling routines by more than 100% while still retaining the excellent quality. We can now not only scale with the best, but also with the quickest!

A new crop of painting applications: Photoshop CS2, Deep Paint, Corel Painter IX and Microsoft Code Named Acrylic. Deep Paint is a gratis download nowadays, after having been discontinued by its company. Visit download.com to get it. Acrylic is Microsoft's Adobe killing bargain basket purchase from Hong Kong. Corel Painter IX, finally, is much, much, much better than the previous garbage. Oh, and I found a screenshot of the old Procreate Painter I got with my Wacom pad.

Read more ...

Yesterday, Krita reached a major milestone. We can now load, manipulate and save rgba images with 16 bits to the channel. This is really, really great. The only free software gui application that can do this too (that I know of) is cinepaint. ImageMagick can load, save & manipulate (and in fact, we still use ImageMagick to load and save the images), but it isn't a gui application.

Of course, there are limitations, currently. Painting works, and you can invert images, select bits and scale the image. The filters, histogram and color adjustment tools don't work yet. But that's only a matter of time.

RAW and openEXR, here we come!

Warning: this is a very, very vertical blog entry... It's about toolboxes.

I'm busy redesigning the way Krita uses its toolbox. As you can see, we have a lot of buttons, and they are badly organized.

Currently, we've got an ordinary toolbar with all our tools, more or less like Paintshop Pro, with fold out buttons to select more specialized buttons.

This is similar to Photoshop, which looks a little more disorganized. perhaps because of the two columns.

Another style, one that is more often used with paint applications, is that of Procreate Painter. Here, we find a small set of tools. There's one central, tool, a single paintbrush that is used for all the freehand paint effects.

This the style that Corel Painter IX uses:

Deep paint 2D is practically the same as Corel Painter IX, except that the order of the buttons is different:

Finally, Microsoft Code Named Acrylic follows this lead but manages to have small, almost unrecognizable icons:

As users of Krita 1.4 know, Krita visualizes selections through a mask. If the default mask colour doesn't fit the image, you can select a different colour for your mask through the colour well in the selection tool panel. That's easy enough, but just a mask doesn't allow for a very precise manipulation of the selection. Today, Casper Boemann added an outline mode to the selection. Still just an outline, no marching ants. And frankly, I'm not even sure marching ants are necessary: they are so eighties.

Of course, we'll have to do some work to make the color combination tasteful and clear at the same time. For instance, the bluish mask color Casper chose doesn't work all that well with black and white photographs.

While some brave and intrepid souls dip their toes into the cold water of an application in alpha release, the real bugs that only surface in real use will only get reported when the application is well and truly out of the door and onto the users' desktops. And then it's too late... And of course, there's the category of bugs that are caused through fixing the bugs reported by the brave beta testers. One of those hit up on use today: Bram found that we had broken the select-all, copy sequence. That's a nasty one, and if we'd found it on Monday, we'd have called "showstopper!" and delayed the release. Oh well, it's fixed now.

Bram also wonders why Krita is in KOffice (and hence in the office menu) and not in the graphics menu. Historical reasons, my dear boy, historical reasons.In the balmy days of yesteryear, or rather 1999 (when some current KDE contributors were still in primary school...), KImageShop was started in the KOffice cvs. No doubt it would have had more loving and care if it had been a kdegraphics app, but there, that's where it was, and that's where it grew in fits and starts.

Of course, there's a case to be made for a move, and many people have made that case. On the other hand, if we manage to make Krita embed other KOffice docs as layers (with layer effects applied to them), then the integration is indisputable. In the meantime, think of Krita and Karbon as the KDE CS suite, that happens to be part of KOffice.

Which doesn't mean I don't want to see Krita included in Digikam's context menu!

Hibernate in Action is a really, really good book. In my previous life as a Python hacker I have spent quite a few evenings hacking together an object/relational mapping framework much like hibernate, only in python. This book starts with a very good, very thorough, very clear introduction to the whole problem of mapping objects to relational databases. The remaining chapters are clear, concise, well-paced and well-written, too. My next book on a Java topic is going to be a Manning book, too.

It's a bit of a pity then that Hibernate is a typical Java library. It comes with a slew of dependencies, it needs ant, but doesn't build out of the box. The readme isn't accurate enough to fix that, you need to go to the faq to find out which libs are missing... Oh, well, I'm going to try to port a Java app I've just finished to Hibernate anyway, to see if it works.

September 28th, 2003 -- four days earlier I had bought my wacom tablet as a birthday present. The 28th I decided that the Gimp wasn't good enough for painting, so I started coding a paint app. I knew the looks of the interface I wanted, something that would evoke the idea of painting, so I took a couple of snapshots of my old brushes to use in the gui.

Of course, my first attempt was done in PyQt, and it was too slow. I futzed about with other approaches until I remembered Kimageshop^WKrayon^WKrita, and decided to see how easy it would be to get into that codebase and start adding what I needed to reach my goal. That was October 1st, and the first tablet support was added at the 4th.

And today I checked in the first bit of code that made use of the old imagery:

All the other painting tools need to have a nice image, too, and I naturally want photo's of real brushes for the real media tools, and slick artwork of pixelized brushes for the Shoup-model tools -- but it's a milestone!

KOffice 1.4 and thus Krita are released!. We even managed to fix some bugs since the last release candidate. And of course, the Krita hackers are already back into the yoke: Casper is working on colorspace independence and a curves widget, Cyrille on scripting, Bart on tile caching, Grzegorz on YUV support, Adrian on performance fixes and I'm back with Wet & Sticky. Already the released version of Krita seems quaint to me. "Ah, yes, those were the days..."

Which doesn't mean that I'm extraordinarily chuffed :-)

Okay, so I've only been working with C++ for slightly more than a year and a half, but still... I should have known what Ruurd, Michael and Christian have been explaining. It's all in Effective C++, item 11, no less.

But in the heat of coding one tends to think one doesn't have to open a book, after all, let's just try one more little thing, and then it'll surely work. Not that I wouldn't have had time time to open the book; the KisColor class is so fundamental that any change in the header means recompiling all of Krita, which takes a lot of time, even on a 3Gh computer with 1 Gb of memory and a fast hard disk...

Well, I'm back to Java for the day's work now, which does have the advantage of being able to compile a few hundred classes in less than a minute. On the other hand, Tim Bray shows that Java is growing up: it's starting to be as confusing as C++

But I still should take the time to memorize the table of contents of Effective C++.

Dicom servers are apt to give problems. Moving Krita to total colorspace independence using a KisColor class was almost beyond my C++ capabilities. Why the deuce do I need an operator= when I've already got a perfectly good copy constructor defined? Anyway, I'm tired now so I did a little holiday snap browsing. I'm leaving the best snaps for the next time, for when I'm really down... Anyway: the next installment of the interminable holiday travelogue

So I've booked for Akademy... Even entered a proposal for a talk about Krita on the users conference. Now I'm a bad traveler -- I get nervous about forgetting about arrangements, I hate flying, I hate having to take more luggage than my laptop bag, I don't like going to a country I don't speak the language, and I don't have time to learn Spanish (or should I learn Catalan -- must consult map) before Akademy, not with all the cool things I need to hack into Krita to make my presentation worthwhile. Ah, yes, presentations. I'm bad at presentations. Since I know what I'm going to say already, and what I know is no longer interesting, I cannot imagine people will be interested either, which makes me even more nervous.

Ew... And the first mishap already happened. In order to be in time, I need to take the 6:50 plane from Amsterdam, meaning a taxi from Deventer. And I was sure I had selected an 20:00 plane from Malaga back, but somehow the stupid website disregarded that and booked me on the 7:00 plane... No hacking for me, the second day of the hackathon. And another taxi, probably.

On the plus side, we're going to have our own little Krita hackathon in Deventer -- not sure who will come, Casper has booked already and Michael has promised he'll come. Rob Buis (of Karbon and ksvg2) has said he might come the Saturday to discuss re-use of gui between Karbon and Krita. I'm looking forward to that a lot.

I would like to draw the attention of the esteemed readership of Planet KDE to the following blog entry by my wife: I have a new KDE, regarding her recent upgrade to KDE 3.4.

You must know that my wife is a pretty accomplished user, but no KDE or Linux guru. She started coding macros on a Wang in the seventies and has been using computers ever since. Still, not a hobbyist or a developer -- just a loyal KDE user since the very first public release.

Now there are a couple of common reactions to this that I'm not interested in hearing about at all.

The first is: "have you entered these bugs in bugzilla? Ought to enter everything in bugzilla." That's shirking of responsibility. Bugzilla is hardly usable for developers at the moment, let alone for users. Besides, many of these things are not easy to pinpoint to a particular component unless you know too much about KDE's internals anyway or are just changes that somehow work out wrong.

And that's the second thing I don't want to hear. The "people are naturally resistant to change so their opinion don't count" fallacy. The expanded syllogism is "people don't like change because they are lazy. Being lazy is despicable. Therefore, not liking changes is despicable. Ergo: change is good." But, frankly, many changes are just wrong. (Like the second "to" line that pops up in KMail nowadays. Suddenly appearing gui elements are always wrong, wrong, wrong -- they disrupt motor memories, expectations and leave people confused because they'll only notice something has changed on screen when something goes wrong and they finally look at what's happening.) If you manage to confuse a loyal user with an upgrade, you have made a mistake, not an improvement.

And finally, the third wrong response would be "just remove a couple of old config files, and everything will be fine." Or, "That's obviously the distro's fault." Bugs that interrupt someone's workflow are grave problems.

The right response is "Eek! We goofed! Let's do this better next time. Let's make a rule to never, ever, trash a user's settings, to never ever change the behavior of an application for existing users unless there's a very solid reason, and then warn them of the change the first time they run the upgraded application.