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.

RSIBreak is in good shape for KDE4, all the basic stuff works, just some bugs left. And those will take large amounts of time to solve probably. 90% of the task you do in 10% of the time, the other 10% will take 90%.

Today I sat down, and read up on Plasma. My last blog entry triggered comments about making rsibreak work with Plasma. After reading the example I made the Plasma applet. The screenie:

[img_assist|nid=165|title=rsibreakplasma|desc=|link=none|align=center|width=193|height=199]

It’s not graphically very appealing, but I don’t own the skills to do that yet, so I’ve to learn those before it gets visually more attractive.

Yes, it’s a bit late to start porting an app now, but I needed a break from Mailody for a while and I need an RSIBreak app for KDE4 anyway and I’m the maintainer of that app, so I feel the need to do something with it.

Anyway, RSIBreak is highly focussed as being a tray application. That means, there is no real main window which should popup when clicking on the tray. And that’s where I’ve some problems. As soon as I open the configuration from the context menu of the tray icon and close it again, RSIBreak exit(0)’s. And it does that for all the about screens as well. I’ve no idea why.

Another problem (or the same?) is that KSystemTrayIcon is no longer a QWidget, that means I can not intercept left clicks on the Icon – or catch the hover event. The latter problem I tackled with hooking into the tooltip event, but that’s far from ideal.

When RSIBreak starts for the very first time or when RSIBreak is started while running, it shows a popup with a screenshot of the system tray with the icon in there. Up to now I used (borrowed code from Konversation though) a QMimeSourceFactory to store the image, like in:


QMimeSourceFactory::defaultFactory()->setPixmap( "systray_shot", QPixmapOfTheTrayIcon );


then i could use that in a dialog:


KMessageBox::information(this,
i18n("<p>RSIBreak is already running<p><p>It is located here:")
+ "<p><center><img source=\"systray_shot\"></center></p><p>",
i18n("Already Running"));


But there is bad news, QMimeSourceFactory is not available in Qt4. The porting document tells me to look at Qt resource system, but that’s not the use case here. So I have the pixmap and I’ve a messagebox, just need to find an easy way to show the image there. I need to peek at Konversation again to see how they solved it.

Just some random issues you run into when porting… The good news is that there will be a RSIBreak ready, probably before the final release of KDE.

RSIBreak has been made Package of the Day. It’s nice to get this kind of publicity. I’ve not been blogging about it for a while and to be honest, have not worked on it for a while.

The main reason for it is that it does what I want it to do. I use it daily. Some days I don’t see it reminding me for a break at all – usually slow days – and sometimes it popups up every 20 minutes – busy days. I try to honor it’s suggestions usually.

It’s on my list to port to KDE4, because I want to keep using it there as well. It is interesting to see that when you give regular attention to an application in the form of blogs, the project becomes active and lively. For RSIBreak I see that there are usually no visitors on the irc channel, no patches, etc. While when it was in heavy development there were people in the channel and patches. But I guess there are written multiple e-books about ‘managing an open source community’.

Anyhow, it’s great to be Package of the Day!

While we are preparing RSIBreak 0.7.0, it is time to think about the next release. The feature which is at the top of my wanted list is the possibility to show exercises during breaks.

You can imagine different ways to show them, they can be an animated konqi, sitting behind a computer showing one exercises per break.

Or some very expressive drawings, maybe something like the card with emergency instructions in a plane.

All RSIBreak-like application have instructions and I consider it a must have for the near future. So if you want to work on this, please make a comment or drop by at irc.kde.org, channel #rsibreak