Fading Memories

Bjarne Stroustrup

Buy this book.

Since October 2003 I have learned to appreciate the C++ programming language. In fact, the better I get acquainted with C++, the more I like it. So, after having read Practical C++ by Ouailline, C++ in a Nutshell by Lischmer, Accelerated C++ by Koenig and Moo and a few others, and after having touched half a million lines of C++, I thought it time to go to the master for instruction.

Which is why I bought a second hand copy of The Design and Evolution of C++, and later also The C++ Programming Language. Even though it's an old book, dating back to 1994 (stone age, practically, no mention of Java or Python in this book), TDaEoC++ was exactly right for me. I like reading the combination of a historical treatment and a discussion per "feature" or "problem area" much more than a language specification or a tutorial-style book. I feel I've got a much better understanding of why things are the way they are in C++.

Of course, it's also an advantage that Stroustrup is a clear and entertaining author: not too dry, but not trying to be overly funny either. If I wanted to niggle I'd say that Stroustrup is a little too defensive, although that's understandable given the flak that C++ has been getting since its inception.

Sven Langkamp took up my suggestion and learned Django over Christmas. The result: the very small and humble, but nonetheless promising beginings of a regression testing web application. I've just added it to KDE's subversion repository:

http://websvn.kde.org/trunk/playground/devtools/koregressions/

KDE does some excellent things, like producing great technology in a great community of great individuals. But at the same time we've got a singularly sure aim at our own feet.

With 3.0, we managed to turn away nearly all people who switched to Linux at that time because we made the ugliest widget style in history, Keramik, the default. And because that was at pretty much the hey-day of switching to Linux, we lost out big-time. Anecdotally: all my colleagues at Tryllian who were KDE users in the 2.0 days or switched to Linux in the early 3.0 days switched to Gnome because they thought KDE incredibly ugly.

And now, with KDE 4.0, we're on track to build the flickeriest desktop ever released since Windows 2.0 made its debut on monitors with a 60hz refresh rate. Applications change all their widget and window colors on focus change. (Except for the window title bar, it seems, that will stay the same color no matter what, or so I am told.) Imagine this: a 20" wide screen monitor with a sovereign application, like KWord open. Press alt-f2. Everything but the window decoration and your document will change color. Press escape. Everything will change color, again. My whole monitor will flicker.

It's a bad idea, but that's not all. Because Qt4 still is, sorry to have to say this, slow as frozen treacle when it comes down to painting on my Ati X600 card (no matter which driver), in all probability, I will have pressed escape before Qt has finished redecorating KWord to the inactive state. So, the app gets focus again, finishes painting itself as if it hasn't got focus, then start repainting itself so it looks like it's got focus.

Foot, meet gun.

1pi and 1pe are linguistic abbreviations for first person plural inclusive and first person plural exclusive respectively. Some languages, like Limbu, make this disctinction pretty thoroughly. Pronouns and verbs differ in form according to whether they "we, including you" is meant or "we, excluding you" is meant.

Read more ...

We've had quite a few release of Krita now -- 1.4.1 in July 2005, 1.4.2 in October 2005, 1.5 in April 2006, 1.5.1 in May 2006, 1.5.2 in July 2006, 1.6 in October 2006, 1.6.1 in November 2006-- and we've got 1.6.2 coming up for January and 2.0 for somewhere in 2007. The dot zero releases, 1.5 and 1.6 were accompanied by alpha, beta and rc releases. And still, with every release (except for 1.4.1) we had regressions -- features that worked in the previous releases that didn't work in the new release.

Do we suck and are too incompetent to code good software or is there another problem? Well, I've got hubris enough to believe that we don't suck, that we, on the contrary, have a great team of hackers who dedicate most, and sometimes even all, of their leisure time to working Krita.

The problem is that software is complex: fixing a bug may cause a bug, improving usability for one feature may kill an unrelated feature. The code that determines the size of a selection is a case in point: we use that in a lot of places for a lot of different things. It's used in adjustment layers, in masks, in selections. Our architecture is not fragile, we just reuse a lot of functionality. That cuts two ways: a fix often fixes a number of unrelated bugs, and a fix may hurt a number of very nearly unrelated features. It's the only way we can write software in a mere 70.000 lines of code that provides all the functionality Krita offers.

The problem is testing. And this problem is hard. For one thing, a developer is not a tester. A developer starts with a mental (or sometimes paper) model of how a certain feature is going to work. For me, that model is almost geographical, like a 3d landscape with features, landmarks and connections. From that model, the code is written, and then we usually exercise the code a few times to see if it conforms to the model. Given that we know the model behind the code it is next to impossible to come up with ways of exercising the code that don't follow the model for developers. For another thing, we're really, really pressed for time. Krita developers seldom have the time to use Krita for any tasks -- I haven't touched my real oil paints for more than a year now, let alone started a good painting in Krita.

So -- what's the solution? Is there any solution? Where should the solution come from?

To me, it's obvious that we need real regression testing prior to a release. All functionality of Krita needs to be exercised -- every feature needs to be used -- and we need to keep track of what works and what fails. Alpha and beta releases don't work for that. People installing an alpha or a beta generally do so to see whether a promised new feature is what they need. They don't test the whole application rigorously.

I think I have an idea that could work out. It combines the team spirit of our translators, the pride involved with buzz, cvs and bugzilla statistics and the accessibility of bugzilla (which, despite all claims, is not bad).

I would like a web application a little like bugzilla, where for every application testcases with test scripts can be added. The goal is to have the test cases completely cover the application's feature set. Then, when a release is looming an application is put in test mode. At first, the application has been tested 0%. Everyone with an account can join the, say, Krita 2.0 Test Sprint, and pick test cases. The goal is to reach 100% of tests executed, but it's okay if several tests are run more than once, by different people. Tests that fail are mailed to the relevant developers mailing list. Successes, too, of course.

The whole thing can be jazzed up with statistics, adding a little gentle competition between applications in release mode, chat forums, irc channels and all the other things that build a community.

I have started coding on it, using Django, but my web application skills are meager, and besides, I need to flakify Krita in a hurry. So, there isn't much more than a proposal for the data model. I might pick it up again, but I'd much rather hack on Krita -- which is why I'm writing this blog. Any volunteers? I'm not wedded to Django, and I'm prepared to install any web app environment on calcifer.valdyas.org for a test environment. If it pans out, we can look for real hosting.

Matt Welsh, Lar Kaufman

Buy this book

There's an old Dutch song by Louis Davids, later re-used by Wim Kan that goes something like "Weet je nog wel, oudje, van toen". I was irresistibly reminded of that text when I was laid up and had nothing better to do than to thumb through old Linux Journals (1995-2000) and similar.

Read more ...

Dan Margulis

Buy this book.

Larry Marso wrote to the KImageShop mailing list in January 2006 about this book (two chapters are freely available). It deals with the LAB colorspace and the ways LAB makes it easy to completely mess up, I mean, fix, your photographs. Larry wrote us because just then we had added a 16 bit/channel LAB color colorspace to Krita, more because we needed it as an intermediary than because we knew what people would actually do with it.

Now, about a year later, I decided it was time to get the whole text and see whether Krita can Do This, too, already. I haven't started with that yet, for two reasons: first, I was in hospital, second: the demo files that come with the book are not in nice application-independent TIFF (or OpenRaster...), but in PSD, PSD > version 6, to be exact. I have to hope that Cyrille Berger hurries up with his libpsd (which he's developing together with the Scribus people).

Until that's done, I'll just have to content myself with reading the book. There's no doubt that there is a lot of interesting and good information in it. I really want to give Margulis' recipes a try with Krita, and improve Krita where necessary. But at the same time -- oh my gosh! Margulis is a crashing bore. He's self-important, self-congratulatory, wordy -- in short, nearly unreadable. Still, I'll probably wrestle my way through most of it.

Patricia Bray

Buy this book

I had to go to hospital for a small operation (that nonetheless entailed my first night in a hospital), so I had to have some light reading. This book looked like the most likely satisfying on the fantasy and science fiction shelves of the local bookshop. I had never heard of the author, which is a plus for me, and the world building seemed quite nice, even if a little derivative, with strong echoes of late Byzantium and a map that looked a bit like the Black Sea. And despite being the first of a series, it didn't seem the usual hackneyed first part of a polylogy, but a rounded story.

Turns out that it was good choice: there are interesting people in the book, shades of moral good and bad, the world building is as interesting as it seemed at first blush, the intrigue is complex, but not too complex for my nose-stuffed-up-with-sponges-and-bandaged self. Only near the end it seemed as if Patricia Bray got into trouble: she has set up her various plotlines so that there simply isn't good or bad anymore and it becomes difficult to emphathize with any of the protagonists. But that's quite realistic, too, and the depictions of imperial politics, while not quite as convincing as, say, Psellus (who really was in the thick of it), are convincing.

Another strong point: the main protagonist's condition remained a mystery to me for as long as it remained a mystery to himself, despite carefully crafted hints. To me that shows that this is a well-crafted story. I'm looking forward to the second story about Josan -- even though the preview at the back seems to hint that he won't survive the first twenty pages.

Canada, here I come! Cyrille and I have just booked our tickets for Montreal for the Libre Graphics Meeting 2007! I already do not like flying, so flying for six or seven hours is definitely dreadable. But the prospect of seeing Canada is enticing -- Irina has been there before, for a roleplaying games meet of the old rpg advocacy usenet newsgroup, but it's my first time.

May... We should have something interesting to show the free graphics community by then!

Does anyone know of a good resource for designing an application around OpenGL? The Red and Orange books don't deal with that, really, just with making use of the API's. But as Frederick Brooks has famously said, "Show me your flow charts and I shall remain mystified, but show me your tables and I will be enlightened".

For Krita 2.0, we would like to take our use of OpenGL even further. Not just for rendering and zooming the canvas, but we want to make it possible to write filters and brushes in shaders, maybe even layer composition. Cyrille is laying the first stone by making it possible to replace colorspace functions in the Pigment library like convolveColors at runtime with more powerful equivalents, like MMX or AltiVec routines -- or OpenGL routines. And applications like Tom van Laerhoven's Waterverve (unfortunately not downloadable, the link goes to his Phd thesis) work entirely as Cg shaders.

But how do we best design our data backend for optimal OpenGL usage?

Like most applications, Krita uses tiles, that is memory areas of 64 by 64 pixels. I am thinking of something like this:

• Store as many of the most-recently used tiles as possible as textures in the graphics card, if OpenGL is enabled
• Store a certain number of the second-most recently used tiles uncompressed in memory.
• Compress the tiles that haven't been accessed for a long time (based on Ariya's code, we've made a start with this step)
• If memory gets tight, swap out the compressed tiles

Now there's a problem: because we really, really want to make life easy for plugin developers (and their life is very easy!), we don't expose the tiles in our API. That means that colorspaces get a pointer to a chunk of chars in memory, that tools, paintops and filters always work with iterators and so on.

But how do our optimized OpenGL shader programs get access to the pixel data? It would be a bit of a waste to copy the relevant data into a texture before letting OpenGL work on it, so the OpenGL routines must access the textures that are already in memory directly. And at this point I'm stumped.

Hence the query: is there a good book about these issues? Or does the communis opinio hold that it is impossible to write a single application that works well without OpenGL but better with?

In KOffice 1.x, Krita had its own custom ruler implementation, while KOffice had another, KOffice-wide ruler implementation. The reason for this was that KOffice uses Postscript points (of which there are 72 to the inch), while Krita uses pixels. And pixels notoriously don't have a size.

In KOffice 2.x, Krita knows how big its pixels are, so it suddenly becomes possible to re-use the KOffice ruler implementation. Which is exactly what Casper Boemann did yesterday: use the KOffice rulers in Krita:

Currently, the rulers show the scale in points: soon this will be settable, or configurable. We're discussing this: is it useful to have a widget, for instance in the top-left corner between the rulers to cycle between the units (points, millimeters, inches, pixels etc.), or is changing the unit you view your image in something so seldom done that it's better to put it in the preferences dialog?

Also note the extension to the statusbar: Monday David Vignoni will start working on icons to replace the radion buttons, but the slider and the text box will stay. This is the "view bar" where you can set the zoom level of your document. Also coded by Casper in the last week.

Joel Spolsky today on simplicity and taking features out of software. It's interesting to note that the applications people are most enthusiastic about are the do-it-all behemoths that people live in, like Amarok, WordPerfect, Photoshop, Word -- and those, if not free, are the applications that get pirated hard. Try finding an illegal copy of Photoshop Elements on bittorrent. Now try finding an illegal copy of Photoshop CS on bittorrent -- that's much, much easier.

Fabrice Mous had asked me to give a presentation on Krita and KOffice at today's NLLGG (the Dutch LUG) meeting. Which I did: you can download the Dutch presentation here. It went quite well, all in all, I think. My text and my slides diverged fairly soon, so it became more of a lecture than a presentation. Especially because there was a whiteboard, so I could sketch out concepts like brush simulation and so on.

I've touched on the history of Krita development, the way painting can be simulated, color management, krita-as-part-of-koffice and more. Usually I finish much too early, but this time I overran by about twenty minutes. Nobody seemed to mind, and near the end, when I talked about the user survey we did a while ago, a gentleman in the public told us about his use of KOffice in the school where he teaches and delivered a ringing encomium for KOffice!

Afterwards there were drinks in a restaurant close by. I went, had a nice chat with people who had only just discovered Krita (a surprising number, actually, had only heard of Krita in the past month), but left really soon. The room was very smoky and it turns out that my tolerance level for tobacco smoke has dropped more than I thought. After all, I used to smoke a pipe regularly (that is, about once a month) and I grew up in a house filled to the rafters with a permanent blue haze.

Another observation: SuSE is still really popular as is KDE. I had not realized how strong SuSE has been in the Netherlands, probably because at Tryllian there has always been a strong Debian culture with a Mandriva undercurrent.

Thursday night I upgraded calcifer, the little webserver, mailserver and more that's also bringing you my blog to OpenSUSE 10.2. For development I'm using Kubuntu, but for a server I have a hard time doing without Yast. And, having used SuSE since version 5.something, almost all my system administration skills are, in fact, SuSE skills.

That said, upgrading a SuSE system to a new version has never been smooth. This upgrade was among the smoother -- it just took a very long time, so I was disconnected from the wide world for an hour or two. But in the end, only a few relatively unimportant things broke:

• I had two soundcards on this system (it's also my upstairs desktop), now I have none.
• My laserprinter disappeared from cups, and when I added it, it mysteriously lost its ability to print landscape.
• Somehow the GD module which is used by Authen::Captcha, which makes my blog a slightly less popular fairground with comment spammers, disappeared, so my blog disappeared, too.

On the other hand, the webserver, mailserver, mailman installation and cvs are still working, and I'm looking into installing planet software for Thomas to play with -- he wants a planet that aggregates all blogs that have to do with OpenDocument and free office software.

Cyrille fixed a bug in Krita's watercolor simulation yesterday. This is a special colorspace, based on Raph Levien's Wet Dream prototype. Raph wrote this code for eventual inclusion in the Gimp, but it never got that far.

During my lunch break today I discovered why our automatic drying left nothing but small one-pixel wide trace of your last brush stroke: we flowed, dried and adsorbed the previous state of the canvas, instead of the state right after painting. The temporary fix is to make every drying step an undo stage. This sucks, but at least allows automatically drying of your wet paint:

And all this work for something that nature does without any effort!

(Note that Krita already does something Corel Painter has only learned in version IX: save and load the wet state of your painting. Close Krita, start again, load your image and it continues drying until completely dry.)

We're all working hard on Krita 2.0 -- but now and then Cyrille codes a little tasty something for the 1.6 branch. Just to keep in form. The smudge paintop is one he coded yesterday. As Bart Coppens said, so laughably simple that we could have done it three years ago. Today Bart added some more support for playing with the pressure of your tablet, and presto: a nice feature for Krita 1.6.2, which will be released in January. Ronan Zeegers, who did the great toolbox icons for Krita is going to do a nice icon for this paintop.

Paintops, by the way, are a rather a special thing in Krita. We've got the ordinary tools, like freehand and line and curves, and the ordinary potato-stamp brushes every paint application since Mac Paint 1.0 has had -- but for added power, things like airbrush, soft brush, smudge, chinese brush (in 2.0) and others are implemented as little plugins that work with every tool that wishes to draw a line, including the selection tools. I'm rather proud of this idea (I came up with it myself a year or two, three ago), and it is working out really well.

If you feel like giving coding a paintop a try, begin with reading our plugin writers' manual -- and don't hesitate to contact us on freenode, #koffice or on the mailing list!

Up to now, Krita thought in pixels, just pixels. A pixel is a pixel on screen or a dot on the printer, no questions asked, no lies told. But while I'm personally comfortable with that (I haven't got a colour printer anyway and therefore don't design for paper), it's definitely Not Good Enough. So Casper Boemann yesterday started implementing real resolution in Krita.

Read more ...

I've long wanted to give OpenSolaris a try, but the vmware images I could find didn't boot into X11 and it was generally speaking a hard slog to find anything that ran KDE. I've got an ulterior motive, of course: we sometimes get bug reports about Krita not compiling on Solaris (notably 106891 125439 and 125446, and I want to be able to test fixes. Besides, SunOS was the first Unix I worked on, and I am as sentimental as the next person.

So I was rather delighted at Aaron telling the world about Belenix. This OS must have the coolest logo ever, not to mention the cool Asterix connotations:

The Live CD booted on my laptop without any trouble, but, unfortunately, my wireless network card didn't work. This is the same card that Kubuntu uses successfully during the installation stage to hijack my neighbors w-lan.

Still, that's a minor thing: I'm not one of those who whine "just add this one little feature for me, and I'll use your stuff!" -- I'm sure I could discover how to make it work, or, alternatively, make do with a wire.

More interesting, perhaps is this: KDE really needs to have a unified system administration front end that works on all operation systems. My goodness - OpenSolaris is different -- I had no idea I had become so much indoctrinated with the Linux (Slackware, SuSE and Kubuntu) way of doing things. I couldn't find my way at all...

Another observation: the Belenix guys are cool. They show the readme notes in a real xterm inside vim. How's that for not pandering to the masses! For the rest, there are, as Aaron said, some wierdnesses on their desktop, primarily caused, I think, by having xfce as a basic with KDE overlaid on it. Still, it's cool. Much cooler than Nexenta. If only because of the logo!

Oh, and although I couldn't find, the release notes say Belenix includes KOffice! I guess my Solaris compile problems were already solved, then.