The past week I’ve worked hard to rewrite sections of RSIBreak. I’ve just released 0.10 beta 1.

This new version is based on the 0.9 version, which was basically a port to KDE4. This new version tries to be more stable and provide a better user experience. Because it is a beta, it would be nice to receive as much feedback as possible!

I’ve rewritten most of the full screen effects and updated them to be more KDE4 like. There is a new effect called ‘Plasma effect’, which let’s you see the dashboard during a break.

The gray out effect does no longer fake transparency but uses the real stuff. Also the level of transparency is adjustable.

There is another new effect which only shows a passive popup during breaks, this serves like a permanent, but not intrusive, warning to take a break. Of course it will only disappear when you actually take that break…

Lots more tweaks and adjustments and bugfixes, just try it out…

Get it here!

I released RSIBreak beta 5 yesterday evening. I can not recall ever making 5 beta releases before in my life. Not for digiKam, kipi-plugins, libkipi, Mailody, Akonadi or RSIBreak. But the good news is that RSIBreak is now bugfree according to bugzilla and there is only one Junior Job present, which is good.

I would love to do things like a network sync so you can break together with your favorite colleague which also uses RSIBreak, but that seems to be more difficult than I thought. I browsed through some applications that uses the zeroconf KDE implementation. But it requires to much code for such a feature. I’ll check again in a few years, maybe someone has made a more high level API around zeroconf. Yes, it is the lazy option, I know.

Maybe Junior Jobs in bugzilla need more explanation. I don’t recall being on planetkde recently. Junior Jobs are jobs which are great bugs for people that want to start with KDE development and want to start with some easy to implement features. These are not bugs which the application developer does not feel like implementing because it is boring or only serves a small portion of the users, no.. I leave them open for a while in bugzilla to give people the chance to start with KDE development. So if you want to start developing for KDE, take a look at our list of Junior Jobs on bugzilla.

Next Friday is the start of a new Akonadi meeting. Goal there is to give the Akonadi Pillar a good shakedown for the next KDE release. This should be the release where Akonadi KDE Libraries should be in good shape to be used for everyday usage by users. They don’t have to know they will use Akonadi for their address book, it simply will happen ;-). But before that, we need to make sure we have the stability which is required. We’ve seen all kinds of interests from application developers. Recently I’ve seen KPilot do things with Akonadi, KJots too and the KIPI-plugins team is considering it. For this meeting KPilot and KJots authors will be available, so we can fix any issue they run into quickly. I say ‘we’, but it’s mostly ‘Volker’ btw. Credits where they belong.

I’m also looking forward to get Mailody in shape for a new release. I’ve recently fixed a large set of bugs and I hope that after this weekend I can switch permanently to Mailody4. What might help here is that Igor is flying in from the Amazon area in Brazil (he’s exchanging 30 degrees Celsius for 3 degrees Celsius; talking about motivation ;-)). This summer (that’s actually winter there, right?) he has made an Akonadi testing framework. I’m really looking forward to his presentation to see in what way we can make use of this framework. I’ll make sure I’ll blog from the event.

RSIBreak
I got some reports that the settings dialog was broken. When I checked SVN it was already fixed, so I just needed to make a new release. Will Stephenson gave the finishing touch and after that I used the createtarballs script to generate a new tarball. The only thing which stands in the way of making a release candidate is the fact that the plasma applet is currently broken. a new contributor started to work on the applet, but seems to have disapeared. So if there is someone out there with plasma knowledge, please make the rsibreak applet behave, the engine is there, the rsibreak code is nice, just requires an hour hacking. ;-)

I even updated the site together with a co-worker. She did the layout, i updated the content.

The official state of rsibreak is kind of weird, officially I’ve given up on it, not because i don’t like the app or don’t need it anymore, it is just that i’ve too little time. But it completely works, so I keep maintaining it in maintenance mode until a new eager hacker stands up and wants to take over.

Mailody
Last week I returned in hacking mode for a while. I seriously want to start using Mailody4 rather soon now. So in the private hacking weekend i had, i started to simply fix each and every bug i hit. After two days it finally got somewhere. At the end of this month there will be a Akonadi hacking weekend. I hope we find time there to squash another set of bugs on the Akonadi side, so I can use Mailody4 full time after that. Akonadi has seen a lot of progress lately. Stabalisation fixes and error handling is improved…

Release-team
The release team is kind of working allright. Now and then you simply hit the fact that it is not always easy to make decisions while you are in a group. When one person proposes something and ten people reply, it often results in some kind of deadlock which has to be resolved. In this case David Faure stepped up and pulled the tags-for-kdesupport into reality. It’s great that someone steps up and does that. Though I’m not completely sure this happens all the time, some kind of a ‘leader’ could make things easier, but we’re not a company, so that does not exists. Not that it is not possible when you are not a company, it’s just that it is not natural. Ah well, you get what I mean.

Community Working group
Another project I wish I could spend time on. Jucato already explained a lot about userbase, and I’m happy to see the other members of the CWG getting this of the ground. It seems to gain momentum. I think it is awesome that there is a techbase for users. It can serve as first stop for users to see if their problem is covered in a FAQ already.

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.