Today several news sources reported that Sweden revoked their support for ooxml. This is good news. Not only because ooxml is a Bad Thing, but even more important: there is justice!

In the days before the vote twenty (20!) new companies bought a voting right from the Swedish Standards Institute. That way the vote was very positive for Microsoft. This was caused because all 20 were affiliated with Microsoft.

Yesterday I said to my co-workers: “how can we ever win these types of battles when Microsoft just buys their way in everything?” Today I was proven wrong, the Institute has revoked their support. It is a small step, but it proves Open Source has the future and it makes me proud. Every battle is a battle.

Jure Repinc posted a small review of the book The Book of Qt 4
The Art of Building Qt Applications by Daniel Molkentin. My copy arrived yesterday from amazon.de. After hacking all day in PHP – I love that language, but I deny I ever said that when asked in public – I thought I read some chapters.

It’s indeed a very nice book. It explains understandably why you should put things on the stack or the heap, it’s better to remember when you understand why something is done a certain way then just doing so. Also I never understood what was meant by implicitly sharing. All clear now. Qt is smart.

I also came to some solution for Mailody. In the KDE3-series it was optmized to show a large amount of headers in threads quickly. Of course in Qt4 this can all be thrown away. Even more, the whole system of the header list was rewritten in a model/view. But I never got the same performance of the KDE3 Mailody. This due to a combination of bad implementation of the model/view framework and the previous optimalisations now biting me.

The Book pointed me to the obvious answer to my problem though. Mailody uses a sqlite backend for caching the mails. Qt now has Sql classes, so it should be possible to use Qt for accessing the database, which alse removes the dependency on libsqlite (I think). Using those classes is not spectacular, but what is spectacular that there is a Qt model for the Sql-database. This means I can get rid of the whole model part I wrote (and that stinks) and use a standard QSqlQueryModel in combination with a slightly adjusted QTreeView.

It would have been nice if the book told me something about the performance of all those classes. In what ways are the qt-sqlite classes faster then the regular implementation? What is the performance of the model/view approach. For Qt3 I made a system that only parses the main part of the headers when the those headers had to be shown in the headerview. So as long as the user is at the bottom of the mailbox, the headers of the messages at the top are not yet filled in, only when the user scrolls up and the headers are needed, those were parsed and shown. Which makes it pretty fast, as the parsing of the messages is the time consuming part. It would have been nice to get a feeling how it’s done in Qt’s-Interview, but I can also understand that’s out of scope for the book.

When I have the model/view setup correctly, the threading part should be done in the mapToSource() and mapFromSource() within the proxy, but that can be done at a much later date. Till already told me to do it in the proxy and the book told me the same. I better listen and do it that way.

I’ve not been very active on Mailody lately, but that might change. But ideally I would finish the book first. And the one from Johan Thelin too. And finish RSIBreak.

Yesterday I took the afternoon off – considering that I was up very early for maintance on our Fiber internet connection at work, I already had some hours of work done – and I decided to deal with my Sharp Zaurus CL-3200.

Last weekend I removed the dust of it, I used my Tungsten C to that moment, but it really gave up on me this weekend. Below the dust there was an OpenZaurus image installed on the Sharp. When I wanted to upgrade to a newer version, I was made aware that the development on that has halted and the developers switched to the Ångström Distribution. I admit I copy & pasted that, I’ve no idea how to type that.

After installing their image, my DLink DCF-660W Compact Flash WiFi card did not work anymore. Well, it worked, but packet loss was enormous. I could not even ipkg update anymore.

Yesterday I decided I needed to solve that. I received some help on the #angstrom channel, and it seems the prism-firmware version was bugging me. After the removal of that fimware it worked again as I want it.

The next excercise was to get a mail client. People know I’m kinda picky about that ;-). The distro carries Claws and a couple of others. Which is behaving so weird in where you need to tap and nowhere where I could setup imap-subscriptions. It was better as opie-mail. O far better then opie-mail. Speeking of which, I dont have a clue about what desktop I’m runnning on the Zaurus now, I’m guessing it is GPE though.

I really would like something Qt-ish. Opie is in development for Angstrom, but something like Qtopia would be even better.

In the end I decided not to use any graphical mail client, just because they all have their issues. I installed good old mutt, tweaked it (I have not seen an app with such bad defaults in a while) and now I’m a happy mail junky again.

Whenever I have time, I need to port Mailody, should not be that hard, except I need to remove all KDELIBS stuff, as that is not available as far as I can see. Ah, dreams, I wont have time for it anyhow.

And openmoko-rss-reader makes it possible to read planetkde.org. What else could someone want?

All set, I hope this setup will last for a while. Now I only have to tell Ade and VanRijn that my Tungsten C is in very bad shape and ask if they still want it for KPilot tests. I promised them a working goodie.

I proposed it september 2005, but we never implemented it: I think it would be good to close all bugs which are reported as soon as there is a new major release.

We now face a bugzilla which is poluted with an enormous amount of bugs. We have a couple of bughunters which try to keep it neat and tidy and without duplicates, but some reports are really silly. Btw: give the bughunters a cookie when you meet them, I don’t know how they keep it up.

So why close all those bugs? The silly ones need no explanation. Sometimes bugs are not understandable or not reproducable. With the arrival of KDE4 you can ask yourself what the rate would be of successfully reproducing bugs which are reported in KDE3 or even older versions of KDE.

Should we at least try to reproduce? No, of course not. Say there are 10 developers and 100 users. It would be logical that the users try to report clear bugreports, make sure it is confirmed by another user and reproducable. The 10 developers can pick up the confirmed bugs and solve them. Saving so much precious time. The group of users is always bigger then the group of developers. The biggest part of the bug (the clear reporting) should be done by them.

Isn’t it unfair to the user who reported them? Again no. We deliver software to them, we don’t ask money or anything else in return.
We just kindly ask to re-open any closed bugs which still exists after a major release. Do you think that is too much to ask?

Summary: I would vote for closing all bugs after we release RC1, users can reopen their bugs when they see that bug still exists in KDE4. This way developers have a clear view of valid bugs.

There are a dozen or more ways to make a list of top committers. One of the statistics provided by cia.vc is shown on the author page. It tells you how much time on average there is between two commits. I think that is a nice indication of the persons activity.

There are a couple of flaws, one is that it is an overall average, that means that if received an account 2 hours ago and you have done two commits, you would have been on the top of the list.

I took the top 100 committers of last week and added dfaure to the list, as that is the man to beat I thought up front. Btw, did you know the commit-digest has settings?

So here is the list, I hope all figures are correct, I needed quite some ugly scripts to get/parse the data, again the time mentioned, is the average time between commits: