Download is available on the RSBreak site.

What is RSIBreak
Repetitive Strain Injury (RSI) is an illness which can occur as a result of continuous work with a mouse and keyboard. The risk of suffering injury increases the longer users work without breaks. RSIBreak simply offers reminders to take a break now and then.

After the start it will show up in your system tray and will monitor your activity. Whenever it detects that you have been active for a certain amount of time (configurable) it will prompt you for a break. It has some settings so if you walk away from your keyboard, it can reset the timers, so you will not be bothered with a break right after you return from that coffee break.

You can setup RSIBreak to popup a tiny notification popup to remind you to take a break, but you can also configure it to black out your screen so you can not continue working. All to your liking. As full screen work prevention methods, there is the possibility to gray out the screen, show a slideshow with your images or show the plasma dashboard (read only).

RSIBreak also provides statistics about the amount of time you actively worked, the amount of time you were idle, how many breaks you skipped, etc, etc.

RSIBreak is an open source application with a GPL license and is free software – both in money and in code. At this moment this application is only for Linux/X11 systems.

For the last couple years, I ran KDE from trunk from svn. That meant that I only had a need for a basic Linux OS. Debian was fine for that. Combined with Equives I could still use some distro packages while compiling most of it myself. But there were problems. Mostly these were caused by my own lazyness in configuring the right stuff in the right way.

Dealing with Virtuoso, Mysql embedded, OSS, Phonon, packagekit, consolekit, hal, udisk, polkit and all that stuff became a boring and silly exercise, I never got it all right, which meant working with no sound for a while, having no permission to change the time from within KDE and that kind of little annoying setup bugs. Compiling the stuff became harder too, as you sometimes only noticed when compiling kdebase that a kdesupport lib had moved to git and you had to fix that.

But my life has changed too. I no longer hack on various stuff, I’m happy to work as a KDE sysadmin with a great group of people. The only thing I want to keep working on now and then is RSIBreak, but for that I don’t exactly need the whole of KDE from SVN. But I also do some work for the Release Team, so I can not be running to behind with the KDE version I’m running.

That made me decide to switch away from Debian. They are doing great work on KDE and I’m sad to move away, but they just don’t provide bleeding edge packages currently. Which is absolutely understandable as they have focus on a rock solid stable experience for users. I choose Fedora because I was told they rock in packaging KDE and are providing packages days after releases.

And I’m so happy so far. Installing it was kind of hard as I ended up in GNome, without having indication how to switch to KDM and KDE. But after solving that, I’m pretty happy. There is stuff to explore, like those SELinux warnings (yes, this time I did not disable it right after installing the distro) and there is stuff that just works. Like sound. I’ve no idea if I’m running OSS or PulseAudio, or which phonon backend I’m using. And I don’t care, it just works. Just like polkit, which I never ever got to work.

So up to now, big compliments to the Fedora team. Nice job, and that needs to be said too sometimes!

The site is powered by Redmine software. It’s very powerful software which can also be used for bug reporting, bug tracking, time tracking, file management, wiki and lots more. But for now there is no plan to use all these features.

An important link is a link I rather not give, but have to do, it is the link to the overview of all projects. I rather not give it, because the current layout is less than crap, I hope we will be able to theme it soonish. It can be a lot better, but that’s work in progress.

After you click through one of the projects, you can basically see 3 or 4 tabs. One of them is the activity-tab. It contains a summary of activity within the projects, basically an aggregation of the commits and news for now, an RSS feed is provided, so that’s the RSS feed you want to be kept up to date about everything that is happening.

News
Each project can use the News section to publish the latest news for that project. You can announce new releases or use it as a project blog, or whatever you like. The fun part is that the homepage of projects.kde.org will show the latest news, so you can promote your project. Of course a RSS feed for the news is available. Currently there is no project which has provided news, but I invite everyone to use it, so the homepage gets a bit more interesting.

Repository viewer
Another tab leads to the repository viewer. Let’s take a look at the repository of Yakuake (I know Eike likes it to be used as an example :)), see http://projects.kde.org/projects/yakuake/repository. The first important block is that at top, it explains the way you can clone the git repository. It also indicates which methods give you read-only access and which gives you read-write access. Read-write access is available for all kde-developers. I’ve said it before, but if you have a svn account, you also have write access to all KDE git repositories.

Below that block, there is the ‘filesystem’ display which you can browse. Pretty similar to what websvn.kde.org provides for our subversion repository. It has pretty much all the features you would need to browse the source, switch to a branch or to find out who is to blame for a certain line of code. And all that a lot faster than websvn.kde.org.

Below that there is a list of the last commits that have taken place. You can just hit ‘View differences’ to see the difference for the last commit. You can see the diff inline, but also next to each other or as unified diff. There is an RSS feed as well, so you can keep an eye on all the changes easily, without needing commitfilter for example.

Also nice are the statistics. It gives you a quick overview about how active the project has been in the last couple of months, or to get an idea about who is involved in the project. Unfortunately for bigger repositories like Amarok this feature is pretty much unusable, due to the high amount of different committers, but I’m sure we get around talking to upstream about that one day.

That leaves the homepage of each project. That’s the main place for your project, it should contain a description and links to common development places for your project, like the bug tracker, irc channel or whatever.

When you request a git repository, you get the project page automatically. You don’t have to use the project page, but you are able to use it if you like. Certainly for small projects it could replace the usual one page website that gets created for it. For example RSIBreak, it would not need to use a website like rsibreak.org (btw, released a new beta last week, try it!), but simply use the project page to provide all the info for fellow developers. Especially if we enable more features in the future, for example if we connect the file management Redmine module with ftp.kde.org, just to name one of my secret plans…

• Fix detection of additional screens
• Make popup time configurable
• Require Qt 4.6.0 and KDE 4.4.0
• Fix timers when lock button is pressed
• Add the possibility to remove the lock button
• Remove buggy screenshot to show RSIBreak in the systray at startup and when launching a second time
• Add notification settings to the config
• Don’t restart timers when leaving config and timers has not been changed
• Slideshoweffect: make the visibility of small images optional. ( Juan Luis Baptiste )
• Make popup visibly more attractive ( Juan Luis Baptiste)
• Make timers work for Qt=>4.4 ( Chani Armitage )
• Fix plasma category ( Balcaen John )
• Use KIdle library from kdelibs, instead of directly asking X.

Get it from rsibreak.org

The rest of this blog is about the presentations I saw, so if you don’t need those details, skip the rest ;-). The first presentation I saw was about the Spider engine for MySQL. Most of you know MyISAM and InnoDB. Spider is another one. This one makes it possible to store tables on different servers. The spider enabled server forwards the request to the remote server and passes it back to the requester. Not so useful you might think. Well, it also has the ability to forward sections of a table to different servers. Say you have 2000 records, you can store id 0-1000 on one server and 1000-2000 on another one. When a client requests id 1500, it will be passed on to the right server. As that server only holds 1000 records, the record is easily found and returned. For the client this whole process is transparent. You can imagine that searching for a keyword on two servers with half the records in parallel is much faster than searching it in one server which holds all records.

The second talk was about phpunit. This framework makes it possible to make unit tests for your php applications and libraries. He talked a lot about the reasons to do it and best practices. As I work on quite some php applications during day time, I think it makes sense to start using such a framework when possible. I think it also tells a bit about the matureness of an application when it contains unit tests. There are also some tools that can show which lines of your code are unittested. Something I did not know existed. I wonder if such a tool exists for C++ and if it does, what amount of lines are unittested within KDE libs.

After that I attended the keynote about Cloud Computing. Simon Wardley is a prefect keynote speaker. He brought statistical graphs, fighting cats and Tom Cruise together in something like 369 slides, without getting boring for a second. Although the topic was about Cloud Computing, it gave a good insight about the evolution of a technological invention. From the invention through a product until it reaches a service and about how that cycle has all the room for improvements, related inventions. I think I’m going to watch the video of the presentation to get a good understanding of everything he explained. Presentation of the day in my book.

After that the only possibility is disappointment of course. And it was. The presentation about a new mysqltuner was not so good. She arrived late, the beamer would not cooperate nicely, the laptop had issues with the mysql server and the presentation was largely about what the current mysqltuner script is doing wrong and at 5 minutes before the finish line she started to very quickly show the version she has written. I don’t consider the new version so much better, the mysqltuner script gives a nice summary of the state of your mysql server, after that you can start investigating what to do to make the thing faster. I don’t think any script can give a complete overview about how to tune the mysql-server best. Ah well, she has improved the output of some things, so it’s not that bad, I just expected more. Like output in html, a database which stores results over time, a deeper analysis of the most common queries, or whatever.

After that I returned to the main track where Alexandra Leisse had a talk about Community Building 101. It was something completely different and that was nice. I enjoyed the presentation very much, I think she used 5 slides for the whole presentation and they mostly contained pictures, hurray! She talked a lot about the aspects of maintaining a healthy community within a project. Some of that was really obvious, at least for me, but it’s nice to have it spelled out, some things are not so obvious and I learned some new tricks. Maybe I’ll now manage to create a community behind RSIBreak or Mailody ;-).

Finally I ended with a presentation about common mistakes in php unit testing. unfortunately it contained quite some overlap with the earlier presentation about phpunit, but that one too contained some things I did not know and things to remember when I ever start using testcases in PHP.

So tomorrow will be day 2. I’m looking forward to that. I made a list of things I want to attend, now the challenge is to not forget that list, like i did today.

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…

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.

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.

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.