After the couple hours sleep (‘Is this good for productivity in any way?), we started the last bit of the API review. We reviewed the akonadi changes between the KDE SC 4.4 release and current trunk, renamed method names, watched for const’s and made sure we did not do any binary incompatible changes.

After lunch, we had a small talk about deprecating all old API KDE has which deal with kresources. As Akonadi is the successor of those and that is approaching rapidely, it is time for developers to port all the remaining kresources usages. With marking that API as deprecated, they get nice little warnings while compiling….

After that we talked a bit about the development of kdepim in the next months, where in SVN that will happening, and how that matches the KDE policy around the upcoming freezes. More news on that later. We first need to talk to some more people.

In the meanwhile I adapted the accountwizard to the changes i described yesterday. And with good progress. We are now beta testing it and fixing the remaining bugs. Should be ready for the KDE-PIM 4.5.0 release.

Steven hacked on unit tests and proxymodels (what else, whahaha). Tobias fixed most issues brought up by the API-review and some small fixes in KAdressBook (of course). Volker fixed a couple of KMail bugs, answered loads of questions and stated just now ‘Now that you asked me, i did not really do that much’.

Kevin Krammer worked on the conversion tool for transferring the old data from kmail to the new akonadi based akonadi. It has challenges like reading the old cache folder, which can contain a mix between mbox and maildir files and directories. He promised to blog about that later on.

Sérgio spended his time on KOrganiser, fixed a bunch of bugs and made the journal editor working again. Matthew fixed the default layout for KMail and a bunch of bugs, for example he fixed the hated bug about the ‘kontact special date summary plugin’ (if scrabble had spaces, this would have been a winner) hang now and then. Now ported to Akonadi properly.

Thomas deprecated the KResources API and bugxing and porting on KMail. Kevin Ottens worked the past days on the kimap implementation, writing unit tests, heck a whole framework. Users can activate a logfile to provide debug output about the imap process. That logfile can then be replayed with his framework, to exactly reproduce bugs.

You can see, that we are working in very many area’s at the same time. preparing our software for the next release. More tomorrow…

After that, we did an overview of the pim current situation:

• KOrganizer: Porting is going on, but we will not manage to release an Akonadi based version for KDE 4.4, so that will show up not earlier than 4.5
• KJots: A relatively new addition to the pim module is KJots. It is fully Akonadified and will be released with 4.4 as usual.
• Work on the SyncML client is improving steadily. It will be merged into KDE 4.4. It is an Akonadi Agent and I think we still need an GUI for it, but the framework will be there. I’ll blog about it more when we have had the demo.
• We have little trust OpenSync will ever deliver what we need. That means all the code we have using that, will move to playground. That includes the KitchenSync application.
• KAddressBook is Akonadified and will be released with KDE 4.4. We still need to port some PIM application to use the new KAddressBook API instead of the old one, but that’s work in progress.
• KMail: Porting is steadily continuing and progressing nicely. Though it won’t be ready for KDE 4.4.
• KNotes, it is largely unmaintained I think. The functionality is probably taken over by KJots and the notes plasmoid. So we will remove it from kdepim.
• Wizards. Volker has a prototype for configuring your mail client, based on kross script / get hot new stuff. Basically the idea is that you can select that you have a GMail account for example. All the right settings are then provided and the user only has to enter the username and the password. GHNS can provide new or updated scripts and this makes it possible for companies to deploy there own scripts to their users.

We also discussed the possibility to get rid of KUniqueApplication for kdepim applications. With the move to Akonadi the technical problems of the back-end is gone, so we can actually can rid it of it. It has some consequences for the communication in relation to standalone vs. apps in Kontact, so that requires further investigation.

Also we decided that we want to get rid of all DBus calls which control other application. Instead of launching KAddressBook and order it over DBus to show a contact. Apps should simply show a dialog which holds the contact data, much more friendly for the users. Every application that is getting ported to Akonadi should keep that in mind; provide widgets that can be reused by other application.

After we went out for dinner, we started on the API review. Due to a lot of KDAB activity in combination with the work of some SOC students, we have an enormous amount of API to review. We started with the stuff from Akonadi core and finished way after midnight.

Here you can see Mailody embedded in Kontact. You can see it fits in there, as it always have been there. On the top of Mailody you can put your favorite folders. That way you can collapse the regular folder sidebar and have a lot more room to see your mails and the message list.

In the past I had a copy of the kontact interface classes in Mailody, because they were living in kdepim. Last month the issue was raised again why it was located there. Because, when  living in kdepim it shielded from the outside world and application developers were discouraged to using it. The main reason from my point of view was that with the upcoming move to Akonadi we would like to keep the option open to adjust Kontact if needed. Moving it to kdepimlibs would mean staying binary compatible.

On the other hand we have seen little development to kontact the last few years. I argued that the reason there has been little development might be in the fact it is not really out there for people to use. The end result of the discussion is that we all agreed to moving it to kdepimlibs. The versioning of the plugins should prevent loading binary incompatible plugins.

That means from KDE 4.4 on people can embed their application to Kontact without nasty tricks. By making that possible I hope we can see a healthy amount of application which can be embedded. One point to note is that if your application is a uniqueapplication, you should use pimuniqueapplication so launching your application for a second time will result in kontact raising and showing your part within kontact.

With opening up Kontact for external application I also hope we see some more development for Kontact itself. I think the summary view is an excellent candidate to be plasmafied. Using Plasma and writing plasmoids for each application make sense. People can put up Lionmail applet on the summary view, a nice calendar widget, but also for example the current weather or a currency converter. Currently we have no takers for this feature, if you are interested, drop by the #kontact channel.