Fading Memories

Mostly my captcha system keeps spam away -- at the cost of the occasional real comment. However, I just checked an old entry and found I had contracted the vile disease again. For now, comments are closed and I've removed all of them until I've had a chance to clean up.

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!

Don't worry -- tomorrow I'll do a Last Week in Krita for krita.org, 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 krita.org 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.org.)

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 1024x768 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 think in Vancouver -- which makes our Canadian Krita hacker Vera very happy!

And Dmitry made a photo of me that I recognize myself in:

Hm... Guess I should have used Gimp to crop it :-)

Oh -- and might I bring the following to your attention:

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 days 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!

Warning: no videos included, though they would help a lot. Also note that I'm using an Intel chipset in both my laptops (the big one also has an ATI chipset, but that doesn't work.)

Lukas recently discovered that Krita was taking about 100% of one of his CPU's cores. When moving the mouse over the canvas. Since X11 took about 60% of that CPU we immediately thought of painting issues, so I started testing with KWin's Paint desktop effect enabled. That effect overlays every rect that is redrawn with a color.

It quickly became clear that for some reason, updating the mouse position lable in the statusbar would update all of Krita's window: menu, toolbars, canvas, toolbox, dockers and statusbar. Curiously enough, Karbon only updates the statusbar. When I disabled the mouse position label in Krita, the CPU usage was gone.

Then I started playing some more, also on my other laptop and now in Ersingen for the KPresenter sprintlet, we tried the same on Thorsten's laptop. And I'm puzzled by the results:

On my X61t, the areas covered by the tooltips of the icons in the system tray is redrawn constantly, all on top of each other. If the panel is visible, and I make Krita full-screen, the area covered by the clock, underneath the Krita window, is continuously redrawn. This runs KDE 4.4.62, on OpenSUSE.

On my W500, the whole screen is constantly completely redrawn. No wonder Desktop Effects feel slow on that laptop! If I make Krita full-screen, no matter whether the statusbar is hidden or not underneath the Krita screen, the redraws are gone. This is KDE 4.4.0 rc3, on OpenSUSE.

On Thorsten's T60 (ATI chipset), we don't see the whole-screen redraws, but we do see a rectangle in the middle of the top-left quadrant of his screen, near, but not exactly at, the place where Thorsten keeps his clock that gets redrawn constantly. This is KDE 4.4.0 final.

But when we are testing KPresenter's animation framework, we see that we only redraw the shapes that are moving, so that's good! (Except when two shapes move, then Qt apparently decides to repaint the whole rect that contains the two shapes.

Well, I'm puzzled, so I'm posting this. Obviously minimizing repaints is trickier than I thought, and it seems especially difficult to limit repaints to the minimum necessary.

I'm keeping my promise to write a weekly update on what has happened in Krita. There's usually a lot to write about, and I'm trying to add some generally interesting things, some personal, some artistic, so it's not just a commit digest, but a little bit more.

But I'm wondering how to syndicate it -- Planet KDE is meant for personal blogs, and this isn't personal. I'm not sure about the other planets my blog is syndicated. And I've had complaints that having a pointer to the new issue on my blog is a bit spammy, and I think I agree with that. So I'm intentionally not linking to Krita.org this time :-) (But it's a good read!)

Does anybody have any bright ideas?

Update: I just learned that if I can teach krita.org to put the Last Week in Krita articles in an rss feed that's unique for what I post, i.e, personal, but from krita.org, I'm fine. I bet our webmaster can figure out how to do that, right Kubuntiac :-)

To make allusions to Douglas Adams' work when leaving a company, so I won't. I'm just going to post a couple of pictures I made with my n900...

This is the river Amstel, for which Amsterdam is known. As you can see, it's frozen over...

And this the Hyves office building, seen through the snow.

And these are Tommy and Markus, who together with Tjerk took me out for dinner in a steakhouse. Good food, good company!

I've been working for KO for two days now, after having taken a really nice one-day vacation which ended up with a visit to Ma Brown's Restaurant. That restaurant tends to be closed when Irina and I want to go there, but last Wednesday it was open at last. A warm fire, excellent food, good service... Perfect closing to a day of gadding about both Hollands. (Note to self: Sing Kee in The Hague isn't nearly as good as it used to be, bij Tholen in Haarlem has the best coffee I've had for ages.)

So, the third day, which happened to be a Saturday, I finished my todo list and then went out to buy a proper office chair, the kitchen chair I had been using at my desk up til now being rather bad for my back:

Now I need to find a replacement for the nine hours a week on the train, minimum, that was my designated Krita hacking time. And let's see whether the sculpture classes I can finally get to in time will actually go through. It's been more than 25 years since I last did anything like that...

Oh, and Hyves is still looking for good developers!

I've just published the next installment of Last Week in Krita. Lots of cool and fun stuff has happened! We are slowly getting the 2.2 feature plan implemented.

An application isn't complete without good documentation. Those fine folks at Linux Format docked a lot of points from Gimp when they reviewed their new release because the manual wasn't updated yet... Krita 1.6 had a pretty fine manual for a free software application, but given that Krita 2.2 is going to be so much better than 1.6, the manual should be ace, too. And almost nothing from the 1.6 manual is still usable, there have been so many changes.

We have to rewrite, and make it even better this time. There is no way I can do this on my and code, it's got to be a collaborative effort. And there should be video tutorials, as well, as part of the manual. So... Enter userbase.kde.org. It's the perfect central place for efforts of this kind. I've started an outline for a new Krita manual, a manual with more than just a description of every menu option and dialog, but one that focusses on concepts, getting things done.

Also: the first Last Week in krita of 2010 is out!

About a year and a half ago I started working at Hyves. Hyves is the largest social networking website in the Netherlands -- comparable to facebook, but much more popular in the Netherlands. My task was to build a Qt-based desktop application for Hyves. There are two components: chat and photo uploading. Most of it is free software, so this link goes to the source download!

Together with Arend (who used to work on Krdc) and Girish and Roopesh we have built a really cool application. It's a combination of Qt and Javascript running inside webkit, xmpp, photo manipulation using filters and svg, geotagging -- lots and lots of cool stuff. Windows, Linux, OSX, source releases... Working on the Hyves Desktop has taught me a lot of new techniques.

But it's time for me to move on: KO GmbH is getting busy, and my first love has always been KOffice and Krita.

And that leaves a gap in the Desktop team.

So, if you are interested in living in Amsterdam, working with smart people who get things done, on a Qt app that's mostly free software -- mail me!. I've always found Hyves a very good employer, and there is still plenty of exciting work to be done on the desktop application.