If you have time on the Friday the 12th of February you should come. I will be there, but more importantly Jos will be there. There will be drinks and Jos will do one of his always impressive demo’s of this new version of KDE.

Developers, users and interested people are welcome, please put your name in the wiki at http://community.kde.org/Promo/ReleaseParties/4.4#Netherlands. That way we at least know how many people will come. If you want to do a presentation, you are more than welcome. Just drop in #kde-nl on freenode irc and talk to us!

Login into the admin, go to the ‘General Options’, half way down there is a section ‘Notifications’, where the option is for the monthly password reminders.

It’s the default for new lists KDE sysadmin creates, but there are still a few mailing lists which have that bit set. If you need help, ping me on irc or file a sysadmin bugreport, the address is in the footer of bugs.kde.org.

This is a screenshot of the current kdepimlibs build status on CDash. In the first column you can see the different build setups that have committed a build. There are builds from FreeBSD, SunOS, Linux, with different kind of CMake versions and differnt versions of GCC.

After that you can see the results of the different stages of the build: Update, Configure, Build and the Tests. The ‘Min’ column indicates how long that stage took. The most interesting column for me are the warnings in the build section. I’m trying to get that number down to the real warnings, removing all the non interesting warnings. On some line you can see 8 with -20 just below it. That means that in the last run the amount of warnings dropped from 28 to 20. Simalary you can see that there currently is a build error on one of the build machines…

CDash provides the possibility to subscribe to projects, with that subscription you can automatically receive build errors if you like to. You can also indicate that you only want to receive mail when your svn account is one of the possible causes of a build failure.

Contributing your build to the dashboard is easy. Just start your build as usual with cmake. Then instead of typing ‘make’, type ‘ctest -D Experimental’. It will build it and upload the data to CDash automatically.

So, next time your build fails and you need help on IRC, you might as well through your build on CDash and put the link to your build on IRC. Nightly builds are also important. It would be nice if we get as much as possibile different setups to report there. That would make releasing a KDE SC easy, as we can have detected build errors on certain platforms in a very early stage.

Summarized:

• Please contribute builds to dashboards
• Subscribe to build errors for your pet project
• Module maintainers should monitor their module
• If you have a minuted, fix some build warnings, it is fun!

Friday was the day everyone arrived, some came in during dinner time, so before that we could not start with any group wide activities. We did do some discussions about threading mails though. Stephen – proxy – Kelly is working on infrastructure (read: proxymodel) which makes threading manageable. That means the threading can be described in a certain matter, and it will be show in the view to the user. For example when you select two folders at the same time in KMail, the combined messages of those two folders are shown, and threading should merge messages from two folders in one thread, if they belong to the same thread.

The discussion we had was about how to store the threading information efficiently. You can imagen that you do not want to parse each and every message again and again to find out if it is a child of another message or a parent of another. Especially you don’t want that to do that when the user already requested the folder. You want to do that before the user clicks on it. And Akonadi provides that possibility.

Saturday the real kickoff happened with the announcement that KDAB and Intevation have secured sizeable funding, allowing them to to stabilize Akonadi and bring it into the mobile space. Which you can read as: the kdepim technologies will run on the Nokia N900, but also on a Windows Mobile device. It probably will be new pim applications, as those screens require a different gui. The past few years we have separated most of the technologies into separate frameworks, so this should be possible. That will also mean the frameworks should be present on no less than 5 different platforms: Linux, Windows, MacOS and the two new ones: Windows Mobile and Maemo. This is really exciting news.

After lunch we took the group picture. It was a delayed because a bunch of excited and energetic developers entered an area with fresh snow and a lot of room. It all started with a perfectly aimed snow ball, i’ll leave the rest to your imagination… If you see some white stains on the group photo, you know why now…

After that Patrick Ohly gave a presentation about his work on SyncEvolution. This desktop independent project aims to give a practical solution to the big syncing problem. People simply want to sync their phones with an address book or sync their address book within different computers. It uses the SyncML protocol to communicate. Sascha Peilicke already wrote an akonadi resource using SyncML, so this project could very well fit in there. Too bad Sasha could not make it. The big advantage in my opinion for choosing to work with SyncEvolution is that Patrick is employed by Intel to work on SyncEvolution full time, it means there are resources available and someone to talk to.

After his presentation we moved on to a discussion about the goals for 4.5. For KDE SC 4.4 ( next month) KAddressBook will be the first pim application which will use Akonadi. For many, many users it will be the first contact with an Akonadi based application. We assume that will give us a good shake down of this technology and its dependencies. KDE SC 4.5 (august 2010), will has as goal to have KMail, KOrganizer, KJots and probably also Akregator based on Akonadi and Nepomuk. Next week the work branch where all the porting is happening will be merged back to trunk and the guys working on achieving these goals will continue in trunk. Without doubt that will be rough in the beginning. You have been warned!

To conclude the afternoon we brainstormed about kdepim, the perception of the kdepim within KDE and the marketing we do, for example to assimilate new contributors within the team. We came up with a gazillion of ideas, we continued on Sunday with a really check of those items and setting out the big lines for the coming year. I won’t give the details about the great big plans we made, you will notice. We will be more visible than ever this year…

Then we went to the restaurant, which wasn’t equipped to handle such a group probably as it took ages before they delivered the food. It did help to try out exotic pineapple drinks though. After dinner I went back to the hotel to get some sleep.

Sunday morning started with the discussion of the Marketing meeting and after that Volker showed a demo of CDash. This system can be used to show the results of a compilation. It can show when a build is broken due to a commit. This is essential if you consider that some of us are developing for the 5 platforms mentioned above. It is impossible to check if your changes compile on all those platforms before you commit. CDash provides a solution for that, it will simply mail you if you broke the compilation on one of those platforms. To my surprise large parts of KDE are already present there. But breaking the build is not the only thing CDash does (it wouldn’t be sexy enough). It can also show which parts of your code base is covered by unit tests. That way you can see for example that certain parts of your code are not tested at all, for example an important else-branch. Or if your existing unit test actually cover what you think they cover. But there is more (this wasn’t sexy enough I guess): it also shows the execution time of each test, which in practice means that you get to see a graph which shows you the execution time of a certain over a certain period. That way you can catch important performance regressions in your code.

The final discussion was a brainstorm about GSOC ideas for kdepim for this year. I leave it for someone else to tell what came out of that discussion as I wasn’t present.

It was a nice and productive meeting, with a lot of discussions. There was almost no time to relax and do hacking, but that’s fine, that’s the goal of such a meeting, coordinating the important stuff and have snow ball fights. Big thanks to Intevation for hosting it and sponsoring the dinners together with KDAB. Very appreciated. Hope there will be a version 9 of this meeting.

The lyrics were fascinating and mostly cryptic. for those that want a taste of dutch culture, here is a nice song, the title catches aspects of life and translates to: sing, fight, cry, pray, laugh, work and admire. The clip shows appropriate stills at each word.

That’s my result of a weekend hacking in Essen. You probably don’t understand it. So I’ll add some explanation. You are looking at akonadiconsole, the debugging application of Akonadi. I’ve extended an existing resource where you can configure the filesystem path of your images. It will list all subdirectories and when clicked on a folder, it will list all images. When you click on an image, it will fetch the thumbnail of the image and show it.

That covers the most basic functionality that is needed for Digikam as far as I can tell. Of course a lot of work has to be done in Digikam to ever support Akonadi resources.

It’s just a start of a resource which shows how the Digikam and KIPI-plugin people can integrate Akonadi in their application. I know Colin Guthrie (the original author of the resource) and Luka Renko are interested in working on this more. I hope this will give them a head start, and I’m happy to assist where possible and add some code here and there.

I arrived there in the afternoon. It was nice to finally meet the people behind Digikam and the kipi-plugins. A few years ago I learned C++/Qt hacking while working on Digikam. It was a wonderful time. Since then I’ve moved on, but I’ve returned to this sprint to give a presentation about Akonadi. As Akonadi is fully type independent, it is able to be used for Digikam. It would open a nice new set of oppertunities.

For example, you could organize your images while your offline. Not only the images on your local hard disk, but also on your Facebook, Flickr or Gallery based website. As soon as you connect to the internet again, it would execute all the moves. Can make that train trip to Berlin so much more productive, right?

Another feature would be to use your image based resources to attach an image as an attachment to an email. No longer select an image from disk, but select an image from an album, as you would see them in Digikam.

I’ve not realized that at a Digikam meeting there would be a lot of people with digital camera’s around. We already decided that it looks a lot more like Digikam Next Top Model, instead of a Digikam sprint….

After that I worked to get the manual expunge code, which I explained on Friday. The DBus interfaces were added by Kevin and I adapted Mailody to use them. So that was one of the last goals I had for the meeting. In the meanwhile Thomas McGuire yelled that his rewrite of the pop3-resource was pretty much complete and passed his unit tests.

Day 3 was somehow a bit more relaxed than the other days. We briefly looked over the last bit of API we had to review. It was coming from the KMime library. KMime is a library that has been around for ages and was written with the intend to replace mimelib which is used by KMail. But that never happened.

KMime is the library that is responsible for creating the actual message after you press the send button in an email composer, but also deals with extracting the different parts from a message to display them, extracting the plain part, the HTML part, maybe some attachments, but also dealing with all kinds of encoding and decoding problems which are used to send the actual mail in.

When I started Mailody, I first tried to do that all on my own, but I soon realized that was not something I wanted to do, and Volker pointed me to the – at that moment unused – KMime library. After we removed the dust, we discovered some bad API and for KDE4, we removed most of the ugly API (like methods returning QList* (yes returning pointers to a list with pointers). Mailody then turned into a happy user with KMime. With the akonadification of KMail, it is needed that KMail also used KMime internally. Akonadi delivers the messages in that form to KMail, so it needs to. Andras Mantia has been actively working on this conversion for KMail. I’ve big respect for that work. I know it is a big task and probably not the most fun to do.

That also mean there is a new user of that stuff, and that means some API changes are wanted. We are still not completely happy with existing API, so that makes the extensions to that API somewhat less critical to get absolutely perfect. This is one of the candidates for a rewrite for KDE5. Still reading? Sorry to be a bit verbose on this stuff, just want to make sure you get a feeling why an akonadified KMail is not available yet. From one big monolithic application, it is being teared down to separate components, which will make the codebase a lot easier.

You have to have bad api’s to realize the value of good API’s.

After this mandatory part of the meeting, we quickly went over to the other mandatory part and did the Group Photo. I’ve not seen it yet, but I’m sure it will appear on the Dot or Planet soonish. There were a couple of discussions between various people. It’s fun to see that the base of Akonadi works nicely for a lot of people and we are slowly arriving at the phase were we can extend it further. Hot Topics in that area are:

• Search. You can basically split up two types of searches. The first one is in the messages within Akonadi. We will use Nepomuk for that. Especially now Virtuoso back-end for Nepomuk seems to be performing nicely, we can go ahead and implement them further. The ground work is already present; Akonadi supports creating virtual search folders, containing links to messages in other folders. Also each message passed into Akonadi is being indexed by Nepomuk. Just need to finish up that work as far as I know, like creating a user interface for creating such a search folder. The second type of searches are server side searches. Take IMAP. It allows you to search for messages directly on the server. We need to support that too.
• Filtering. Basically you have the same difference. There is a local filtering of messages, which is implemented by a summer of code student. It means that a special type of resource gets the messages before it gets added to the final destination folder. That special resource can filter it to another folder for example. This should all be finished, but it’s not completely ready yet. There is also filtering on the server side. For example IMAP filtering is (and should) be done on the server side, for example with Sieve. Volker and I briefly brainstormed about the possibility to create an application which can deal with that. Should not be too much work if we can base it on the work already done by the SOC student.

I briefly brought up Google Wave. I think Akonadi can easily provide a resource for it, although there wasn’t much interest from the participants of the meeting to work on it, so we probably will not work on it ourselves. Of course if the resource is created, you’d still need an application to edit the waves. So if anyone wants Google Wave integration into KDE, please use Akonadi as base. We can help you with the stuff, we just don’t have time to do it ourselves.

That pretty much concludes my coverage from the meeting. I know there will be a dot story outlining more stuff that has been done during the meeting, outside the little box I have lived in. It was fun to be there again.

After that we started with API-Review of the Mailtransport classes. Around 1920 everyone used to use their local sendmail application to deliver mail. That was ordered to deliver the mail as soon as the 14k4 modem has made a connection to the internet. A bit later people started to depend on the SMTP method to send mail. The application send the email to the provider which provides your internet connection and then it’s done. But now we are starting to support Microsoft Exchange Servers, we need a new way of sending mail. The feature Microsoft Exchange offers is that it also deals not only with incoming mail but also with outgoing mail. That means we needed to adapt our Mailtransport library to know which Akonadi Resources are capable of sending email.

When you compose a mail you have a selection bar, where you can indicate which provider/transport should be used for sending. That now has been extended to also show the resources that are capable of sending it. And that required a lot of changes. We combined it with nice features as sending messages after a specific date and time and moving messages after they have been send to a certain folder. To our surprise the whole morning was filled with reviewing the API and we have a pretty long list of stuff that has to change there.

After lunch we continued with the API review of IdentityManager. In this KDE cycle support has been added for images within signatures. Signatures in the context of mail messages which can hold company disclaimers for example. A much requested feature was that people (or company policy) needed to insert there company logo in the signature. A couple of KDE releases ago we added support for html based signatures and now we added the support for images. And those images need to be stored somewhere. But in a application independent way. The identities you setup are shared between KMail and Mailody and we need to prevent that breaks with the set image in the signature when you switch between those clients.

Continuing with yet more API review (really a weekend is to short for this). We continued with the API review of the widgets and classes provided by the new address book application. The classes are all in a library so other application can make use of them. One of the discussion points was about the dialog. When you for example click on a phone number and you have a voip phone, it can actually dial that phone number, the same goes for an email address. When you click it the default mail client is opened and the composer is launched. But if you show the dialog in an open composer, you want to add that address to the addressee list of that composer. Implementing that without making the API ugly needed some thinking.

In the evening Brad showed us the progress on Exchange support. He demonstrated Akonadi fetching mails, addresses and appointments from the Exchange server. Although it is in pre-alpha stage, it already shows that the resource is on the right track. From his side, there are pending requests for free-busy listing support and support for filtering. Both will be implemented sooner or later. His biggest problem, the mail sending part, is solved recently.