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.

I've been watching from the corner of my eye the life videocast from the Church of St. George today. The Patriarch of Constantinople and the Pope celebrated the Holy Liturgy of St. John Chrysostom. I was hoping for a miraculous restoration of full communion -- for the Patriarch to beckon the pope with the chalice, or something like that.

Read more ...

I've just been helping a friend of ours to get up to speed with her new Macbook Pro (latest model, very nice!). She's a theoretical physicist and a composer and needed a word processing application. Besides, there were were a couple of things about her new mac she was unsure of. Sitting next to her was as educational for as I hope it was for her. Lessons learnt:

Read more ...

Derek Kite's blog about gender mentions Leonoard Sax. I feel I have to chip in with a a warning: Sax's book "Why Gender Matters: What Parents and Teachers Need to Know About the Emerging Science of Sex Differences." has been widely exposed as pseudoscience of the worst kind.

Sax is anecdotal, overinterprets his sources and more. He has a political agenda: he is the premier proponent of single sex education. The "science of sex differences" is mostly on the same intellectual level as "Men are from Mars, Women from Venus".

Don't read Sax (at least not seriously): read Language Log instead!

I've been sitting on my hands for the whole day, ever since I read Ongoing this morning... By now I've read the blogs and seen the webcast -- and I still simply must chime in:

Hurray!

Sun is just doing everything right: the right licenses, the right language (notice the GNU/Linux on the announcement graphic? The licenses are the right licenses -- being a Java drone suddenly starts feeling right.

Of course, a move like this is going to have a lot of influence. What will happen to Mono? Even, what will happen to DotNet itself? How will Jambi fit? Will we perl KOffice into a pure Java application? May we go as far as expecting imminent peace in the Middle East?

Someone who isn't worrying is Mark Wielaard, the GNU Classpath maintainer. He's loving this: read his blog.

Krita's scaled used to be, at least in my memory, a lot better than it's now. The change came when we went from scaling code that was channel-depth dependent and scaling-specific to channel-depth independent generic transform code. Today I put the old code back and special cased it for 8 bit rgb, cmyk and grayscale code. Let's see if it makes any difference. The image was scaled from 1200 pixels width to 400 using the default settings. Just open the dialog, set the width and press enter. That's what I always do anyways.

The generic code:

Michael Thaler's quality optimized code:

Gimp:

And now blown up to 800 percent:

The generic code:

Michael Thaler's quality optimized code:

Gimp:

The Gimp may still be a little better than Michael's code, which gives results that are just a little fuzzier, but the quality difference between the generic Krita code and Michael's code show that my memory hadn't betrayed me.

Karbon in trunk has gained an amazing new shape (and because it's a Flake shape every other KOffice application can or will be able to use it, too.) Starting out with a simple star, Jan Hambrecht has created these wonderful objects:

(I defiantly scaled the image with Krita, but I must admit that we've got a regression here. At one point in time, our scaling was really good.

We're having another flake weekend at my place: Thorsten, Thomas and Sander are already here, we're waiting for Jan Hambrechts, the tireless Karbon hacker from Berlin. Sorry Ellen for abducting a Berlin KDE hacker to the Netherlands!

Tomorrow we're going to do some interaction design, decide on a common UI vision (hopefully) and do a lot of high-bandwidth code design. I want to get as much of this done, and not so much actual coding.

"I have nothing to hide" - or the Sainsbury's Lesson. It explains why Irina and I canceled our library cards when the library started keeping track of not just which of their books we had at home, but also of the books we ever borrowed.

As Terry Pratchett likes to have his characters say (Pterry being as fond of his own jokes as the next man and liking to repeat them often), a metaphor is a lie. Which makes it surprising, given the propensity of software engineers to shout "Not True!" at the drop of a hat, that metaphors are so often used in our software: everywhere from basic concepts to icons.

We're going to have a KOffice crash interaction design meeting next weekend at my place, and in preparation I'm reading up on my Cooper. One thing that has always surprised me is the use of metaphors in software. Cooper agrees: in chapter 20 of About Face 2.0 he talks about metaphors, idoms and affordances, preferring the latter two over the first. The big problem with metaphors is not that they don't fit the way humans think, we do think in metaphors, but that they don't scale and become stale so very fast. For example:

Read more ...

We have just returned from a week-long holiday in Egmond. We rented a little summer cottage for an autumn week, just like my parents used to do when I was a kid. And it was lovely -- the sea stirred by the wind, mighty grey clouds, dunes painted gold and gray by quickly changing skies. Beer and pancakes on a terrace in posh-posh Bergen, Dutch-Chinese comfort food in the Egmond Binnen Chinese restaurant, served by a waitress who was surprised that it was possible for kids to actually want to drink tea, a herd of wild horses grazing in the dunes north of Egmond aan Zee and much more.

More images available for them as likes a horsey wallpaper...

We rented bikes for a day and visited the village where my parents were living when I was born (in the hospital in Alkmaar) -- Egmond Binnen. Wonderfully preserved place. This is the church where I was baptized:

The dust removed from my lungs, energy to work on stuff has redoubled. I discovered the existence of illustrators as a likely target audience for Krita and saw Rembrandt's incomparable sketches in the Rijksmuseum.

Spurred on by discussion in bugzilla, Frédéric Coiffier implemented a level filter for Krita, one of the things Krita was notoriously lacking. Yay for Frédéric!

Oh, and I got my aKademy award, as you can see from the above screenshot. This Motorola phone George sponsored is really cool. You can even type Chinese on it. It speaks and understands English. It has gadgets galore. And the Qt interface is so easy to use that finally I've got a mobile phone that I can actually use instead of curse. And take a look at the certificate!

As Cyrille says, the people who really, really need CMYK are a limited group. Still, having CMYK is an important thing because it's the easiest "other" colorspace to implement that still needs icc profiles. (Grayscale is actually quite hard to do correctly, and the very best algorithms to convert to grayscale are horribly patent-encumbered.)

But the real fun starts with L*a*b*. As Photoshop LAB Color: The Canyon Conundrum and Other Adventures in the Most Powerful Colorspace by Dan Margulis shows, the L*a*b* colorspace really allows for some powerful image editing techniques that are nearly or totally impossible in rgb.

Which is, of course, that I'm inordinately proud that Casper Boemann and me have managed to implement L*a*b* for Krita. You can paint on it, tweak channels and everything. There are limitations: the convolution filters temporarily convert the pixels to rgb and back (fixed in trunk) and we haven't got all the filters and dialogs in place that make it easy to use the power of L*a*b* -- but that's something everyone can help with, now the hard work has been done.

KOffice is steadily growing. While we've not reached really gargantuan proportions, Krita has passed the 100,000 lines of code mark in trunk -- and that's with the color library, pigment, moved to the koffice libraries. Krita 1.6 is 108,000 lines of code, while the Gimp is 600,000 lines of code. Some of that is due to C needing more lines of code for the same functionality, some of that is generated during compilation, but there's also a difference in functionality. The Gimp has many more filters and tools: lots of stuff Krita doesn't have. Yet. And I suspect Photoshop to be in the multi-mloc range.

Last time I used sloccount on KOffice, the result was around 630.000. That was October, too. A year ago, kspread was still bigger than Krita by 10.000 lines. A year later, we're at:

Read more ...

Krita 1.6 has been released, and while there may be a 1.6.1 release in November with bug fixes, my own attention has been focused on Krita 2.0 since the end of the summer. Porting to Qt4 is mostly done; now we're starting to use Qt4 features, like the Arthur paint system and the much improved dockers and tablet support of Qt4.

Krita now shows -- faintly -- the bits of layers outside the image area in the borders of the window:

Because of the canvas work, I've disabled the dockers a bit. Qt4.2 gives excellent feedback when dragging and dropping dock windows. It is possible to place dock windows in tabbed rows and everything. There are a couple of gotcha's though:

• It's not possible to define dock windows to startup in tabbed positions.
• When tabbed, the tabs go completely mad because of KDE's automatic underscore accelerator adding -- this can take up to 99% of your cpu.
• It's not (yet?) possible to have the tabs above the docker -- necessary to achieve that perfect Photoshop look!
• While Qt automatically restores the position of the dock windows when you close and restart your application, this sometimes goes wrong
• I haven't figured out how to mix Qt's actions with kxmlgui so there are no menu options yet to show or hide the dock windows.

But I'm quite confident that these problems will be solved by Trolltech before we release KOffice 2.0

Update: Actually, Simon Hausmann mailed me to say TT solved the first problem already in Qt 4.2: http://doc.trolltech.com/4.2/qmainwindow.html#tabifyDockWidget.

The KOffice tool/pointer system is something I'm working on right now. The idea is make it possible to have a different active tool for every pointer device attached to your computer: so, if you've got a Wacom tablet, you'll be able to have, for instance, pan linked to your mouse, paint to stylus, erase to the eraser end of your stylus and maybe the paint tool but with the airbrush paintop to your airbrush. This already works a bit in Krita 1.6, but for 2.0, this will be possible in all of KOffice.

Now if I could wangle an Intuos tablet with a couple of tools, I would not only be able to test whether this code works (better than in 1.6), but I would also be able to make use of all the cool extensions to QTabletEvent in Qt 4.2.

The thread is long, yes, but to say that matters have come to a conclusion, that it is possible to even arrive at an executive summary is premature. As far as I'm concerned, there have been no conclusive arguments in favor of Scott's summary. But since the discussion is now apparently to be held in blog form, here's my summary.

Read more ...

As discussed in my blog on graphics libraries, common schemes for storing large images are tiles, scanlines and blocks of memory as big as the width * height * size_of_pixel. Tiles are the most common, though. Photoshop, JAI, Krita, GIMP, GEGL, MosfetPaint -- these all break up the image in small squares.

The big difference is in how the application or plugin developer accesses the data in the tiles.

Read more ...

There's a tremendous effort being expended in the free software world to create great raster image applications. And that means that there are also a lot of free or open source libraries that could be used as the basis for an image editor application. Still, most applications use their own core. Krita has pigment for color management and kritaimage for pixel manipulation.

Read more ...

Today I got the official award notification mail from Albert Astals Cid. Seems like it's not just honor I'm getting -- very generously Staikos Computing Services has sponsored two high-end Linux mobile telephones, one of which I'm getting.

The incredible Laurent Montel, who did the lion's share of porting KDE to Qt4, also gets one of these phones. Tink tells me it's a Motorola Rokr E2. Very cool! Apparently it doubles as an mp3-player. You should have heard the agonized squeals from my three very jealous teenage daughters!

Alexander Neundorf, who contributed so much to the success of replacing autotools with cmake has gotten a video iPod sponsored by Ricoh. I'm not sure what would have made my kids more jealous...

Linux New Media -- publishers of Linux Magazine, which is miles better than Linux Format (not a difficult feat) and which I read with more pleasure than Linux Journal nowadays, is giving all award winners a yearly subscription to one of their magazines. Yay for Linux New Media!

Today's my birthday -- and, unsuited to my age as the sentiment is, I'm impressed by the bounty I've bagged. Episode 9 in Ken Don Rosa's epic history of Uncle Scrooge. A flask of very, very nice peppermint bath foam. A box of delicious Belgian pralines. A very, very cool Danish design wrist-watch. A dvd of the 1917 Dutch moving picture "Het Geheim van Delft" (I love ancient moving pictures, I'm a complete Douglas Fairbanks aficionado) and a dvd of Eisenstein's Potemkin, a movie I've always wanted to watch.

And to cap it all, tonight Thomas Zander phoned from Dublin to tell me Krita has bagged the Best Application Akademy Award! Whee! Yippee! Hurray! No way anyone is going to believe the width, height, brightness and general enormousness of the grin I'm wearing right now.

Hey, Bart, Cyrille, Casper, Adrian, Michael, Gabor, Sven, Sander (only Krita team member actually in Dublin), Emanuele, Ronan, thanks! Krita has a great team! And all our incidental contributors, bug reporters, testers, users -- everyone who has helped making Krita a better use for processor cycles around the world, thanks!

Virtual Guinness for everyone! To Krita 1.6! And again: to Krita 2.0.

At least once a year, I type rm -rf bla * instead of rm -rf bla*... Today was this year's occasion. And before I knew what happened, the blog directory had vanished. I do have a recent backup, of course, but I cannot find it. Probably because I found a really good off-site place for it that I subsequently have forgotten. Just like a squirrel forgets his nut-cache. In any case, I found a slightly less recent backup -- we're back in May now.

The untimely demise of calcifer II, the server that was bringing you my blog entries, and the quick replacement of it by calcifer III sent me reminiscing about computers past and present.

Read more ...

On of the little frustrations of developing for KDE4 is changing to the kde4 user (I know that’s not necessary, that it is possible to work on KDE4 from your regular user account, but I’m lazy and this is the way I got it setup). And to change to my kde4 user I type sux - kde4, which, well, sucks.

Fortunately I have at my disposal all the foo-magic of Bash! One quick alias later, KDE4 no longer sux, but rocks!

alias rocks="sux - kde4"

It’s simple, silly and cosmetic, but once more all is well with the world, the snail is on the wing, the lark on the thorn and every time a daisy sneezes a little god is born.

Oh, and I’m nearly through with refactoring Pigment to make it possible to add composition operation dynamically to colorspaces for extra flexibility.

KDE’s kio slaves are incredibly useful, I couldn’t live without fish, audiocd or camera, but today I discovered another one, while doing research on Django: kio-sword.

I’m already a pretty heavy user of BibleTime, but kio-sword is even handier for finding the text of a particular verse really quick. And there’s even a Kubuntu package.

Leads to:

I bet old Basil the Great would have loved this.

Krita is quite extensible. You can add new filters, of course, and chunks of user interface like scaling dialogs, and new tools — like weird and wonderful selection tools or a path tool like the one that is right now being worked on for Google’s Summer Of Code. But also new ways for existing tools to paint. I’m working on a Chinese brush simulation based on Clara Chan’s interpretation of Strassman’s Hairy Brushes for Krita 1.6. And finally, you can add complete new colorspaces. We’ve already got various rgb, cmyk and grayscale colorspaces, and also xyz, lab, yuv and lms — but there is no end to the possibilities.

However, the best API is useless without a good tutorial, and I’ve just completed the first draft of Developing Krita Plugins. Apart from extending Krita with C++ plugins (and, if you manage to get automake and gcj to play ball, java), you can use Krita’s document scripting interface to create scripts in python and ruby. And there’s dcop, too, of course, but that’s not as well documented.

So, if you’ve always thought Krita was nothing more than a glorified icon editor, you can now change that. Go ye therefore, and code all kinds of plugins, extending Krita in weird and wonderful ways, in C++ and Java and Python and Ruby.

ps. What I also wanted to say… Krita’s got a pretty good manual, too, in case you just wanted to use this icon editor.

I’ve been quietly working on a discussion draft for an OpenRaster file format specification. The goal is to create an file format that fits right in with OpenDocument for layered raster images with extras (think adjustment layers). Dave Neary discussed this issue yesterday, which was just the kick in the pants I needed to continue work.

(I’ve been slacking a bit lately. Of course, I needed to work on the last few papers for the theology course I’m nearly done with, and after the 1.5 release Real Life wanted its Boudewijn back for various things, and I got a bit fed up with the kind of reactions that prevail on free software-centered websites lately. But that’s for another rant.) But it’s nice to read that Krita is good, too.

In any case, with the valuable input from Øyvind KolÃ¥s (alias Pippin), whose esteemed presence graces the koffice irc channel, I’ve prepared a discussion piece that after review by Cyrille Berger will be posted forthwith to the Create project (where we’ve agreed to do the initial discussions) and also be presented to people higher up in the OpenDocument community. The basic idea is to just follow OpenDocument and have a zip archive with XML and binary parts in it.

And then, after lots of discussion of details and lots of coding, we may finally be able to move images from Krita to the Gimp and vice versa without losing too much.

I think I somehow messed up my Breezy install bad enough that upgrading to Dapper just isn’t going to work, so I’m reinstalling, or rather installing Dapper from scratch. I must say, this is a good installer.

For once thing, I’m blogging this logged into my server from the laptop where Kubuntu is being installed as I’m typing this. The life cd found my neighbours’ wifi lan, cracked the key (apparently, or they have chosen to disable encryption today) and got conected.

The artwork is nice, very nice. The startup of the life cd has provision for accessibility. The life desktop is very nice, very clean. The default window theme is small and not gaudy.

Some minus points: the partitioner is completely incomprehensible to me — and I’m an experience partitioner, having repartitioned hard disks for fifteen years. After pressing ok, the screen goes black for just long enough to give me a nasty fright. And my ssh loging through the neighbour’s network sometimes halts and then continues.

Well, time to reboot. Installing is done.

Before the piccy scrolls off the mainpage. The Kubuntu picture of Konqui & KOffice is way cool. And there are no fewer than five Konqui fans in my house...

In other news, the reason I went to kubuntu.org was to find the bugs database, since upgrading to Dapper seems to have removed my gl.h file and there's something funny happening when I resume for suspend-to-ram, one time out of three.

In you don't half realize how soggy the weather is news, our family went for a day trip, today. Yep: I managed to make it possible to get a holiday by working extra-hard for a customer so I could squeeze out from the two or three work projects demanding my attention.

So we went to 's Hertogenbosch, to take the boat trip on the Binnendieze.. Despite the rain, this was rather worth it. Fascinating, in fact. And the way the old city wall is restored in one place reminds me of the intriguing way the castle in has been restored. Graceful, with respect for the original building, but working around it instead of messing it up.

Anyway, now back to my attempts at restoring sanity to this lowly Z60m.

Print magazines have a difficult time, nowadays. Not enough advertisers, not enough speed in their time-to-market. It's no wonder it turned out to be quite difficult to get a copy of the issue of Linux Format slagging KOffice 1.5.

Or maybe it's the quality of Linux Format... I mean, if one reviews the first beta release of an application suite, one should mention that little fact. If one is deficient in the wit department, one should not try to exercise that faculty. Not that KOffice is perfect, but, well, it's not that badi!

KOffice got four Summer of Code projects from the 24 allotted to KDE, which is quite nice. It was going to be five, with Ariya's Excel Export filter project as the fifth. However, since Ariya had also entered a project for Open Office, and since Google when students are chosen for two or more projects, favours the smaller, he was accepted for OpenOffice.

KDE didn't lose the slot, though, we had two backup projects: one for KOffice, one for KDE. But Google placed the other project, so KOffice is down to four. Slightly less excellent for us, but for KDE as a whole not a big deal.

And the projects KOffice has got are real dozies:

• For Krita, Thrain (or Emanuele Tamponi) is going to try to add bezier and scissors tools, under the mentorship of Bart Coppens. After meeting Emanuele yesterday on irc, I'm convinced that he fits right in with the team. Which means that he's officially declared to be as nutty as the rest of us.
• Under the stewardship of David Faure, Alfredo Beaumont Sainz is going to implement full native ODF and MathML support in KFormula. I've every confidence in the success of this project, since Alfredo is KFormula's brand-new maintainer.
• I am going to mentor Fredrik Edemar to implement two things for KWord: basic version control and heading recognition. The latter is quite interesting: Frederik wants to make KWord to assign styles to paragraphs based on text, recognizing when a user types a heading. This is something I like a lot: too often, word processors either allow the user to do all formatting, resulting in documents without structure, or force users to create structure, which they -- rightly! -- don't want to do. What a good word processor should do is recognize the way the user formats the document and create structure. That's the next level, and I'm convinced it's going to be copied a lot.
• Cyrille Berger is going to mentor amazingly erudite Gábor Lehel to turn his Krita-specific layer widget into a cool, Qt4-style compliant, model-view, generic layer/document structure/page preview widget for KOffice 2.0. This widget will go a long way to enabling us to realize the vision presented by the winner of the KOffice 2.0 design competition, Martin Pfeiffer.

This year's Summer of Code looks like it's going to be a runaway success for KOffice!

Our family prays every night -- a very, very, very short and abbreviated version of vespers -- and we like to light a karbounakia, or small bit of charcoal, and add a grain of incense. There are all kinds of good, theological and pious reasons to do so, but it's fun, too, and it helps if the living room smells like Church, when you want to pray.

Our stock, bought last year in Greece, is now sadly depleted, so I was rather interested when a bit of outre research(1) led me to the Hermitage of the Holy Cross. Here they sell incense... But it's almost as if they're selling pipe tobacco!(Note: I do not recommend smoking, not even a pipe, although it is surely something every wise wife should allow her husband, the old English proverb says "allow your man his pipe and his hobby and you've got him chained for good", but smoking etc. A hobby like KDE, though, cannot be but good for ones health.)i

In any case, Casper Boemann has just fixed the rotating-big-images bug in Krita. Hurray!

-----

¹Roey Katz on #koffice reminded me (without knowing himself) that I should check Ship of Fools, from whence I went to Monachos, where a discussion on head scarves attended me to the question of long hair and beards for men, where I learned that angels are trespassing on the 96th canon of the Sixth Ecumenical Council.

I bet I earned that penny for my thoughts now!

That's what I feel. The weather is nice and I haven't done a thing about Krita for quite a bit of time. Of course, that's partly because I have a hard time getting into the Qt4 porting; porting Qt3 to Qt4 makes me feel like I'm learning to ride a bicycle with training wheels again. Which, given that I'm as Dutch as Dutchmen come (being from mixed German and Swiss stock), you may well imagine is hard on me. Anyway, if I cannot bike, I'm going to ramble...

Read more ...

Looks like getting a new lease of life. After consultation with the publisher and Phil Thompson, I've sent the sgml sources to Phil, who's acquired a small band of volunteers to update the text for PyQt4 and, what's even nicer, bundle it with PyQt.

The only real restriction on the license of the book is that nobody but OpenDocs is allowed to publish it as a paper book. Maybe that makes it not free enough for Debian, but, well, having the book available in the PyQt package makes PyQt so much more attractive. Even if I say so myself, it is a very full and clear introduction to coding a complete application in PyQt. The University of New South Wales chose it for its introductory class in OO programming, after all. Pity they used the electronic, not the paper version.

Oh, and a Turkish translation appears to be in the works.