Sound like magic you say?

I'd say you're right!

The White Wizard (also known as Volker Krause) has embedded a powerful spell in the KResource framework which summons a golem (also known as kres-migrator) and commands it to carefully transform your contact and calendar resources into a respective Akonadi setup.

As of last night the magical barrier holding the spell's power has been removed, so that all brave souls testing our snapshots and the upcoming 4.2 beta1 can help us improve the minion's capabilities to everbody's satisfaction.

Since a carefully crafted illusion is more popular with the common folks than just songs and stories, lets see what we can do about that.

KAddressBook when started with a traditional setup: three KResource plugins for different data backends.

Progress of Akonadi server startup

Report of the migration results: The "dir" and "LDAP" plugin based resources have been migrated using our compatibility bridges, the "file" plugin based resource has been migrated to the native Akonadi VCard handler.

KAddressBook after the migration: a new Akonadi based plugin containing all three data sources as "folders". The three traditional plugins are still present but have been deactivated.

Beware! The dark side hasn't slept either!
We have heard rumors that the following jinx can put an unholy barrier around our spell, effectively keeping the poor victim deprived of any Akonadi goodness:

% kwriteconfig --file kres-migratorrc --group Migration --key Enabled --type bool false

> Read More... | Digg This!

Szymon Stefanek's KMail GSoC project was merged into trunk today.

Stunning. You've got to try it. KMail has been re-launched!

r881321

To quote the commit message:
"... New features include grouping, multiline items and the ability to customize just about everything of the look of the message list.
Also, we have a tabbed interface for opening more than one folder at once now..."

Fantastic work Syzmon and Thomas.

> Read More... | Digg This!

The hard-working Danny Allen put out a new Commit Digest, and the resulting discussion on the Dot raised a few comments about Microsoft Exchange support in kdepim.

The short version is that it isn't going to make it for KDE 4.2. Maybe 4.3. Maybe not for 4.3 either. Sorry.

The longer version is that I had some real-life work intrude (I'm only a volunteer developer), and also did some work on something I really do plan to use (being the .snp generator for Okular). More recently I've also been working on the underlying libraries (OpenChange). Those are hopefully going to be of some use to some of you too. I do believe this stuff is important, but it isn't the most important thing to me all of the time (in particular, when I have to work, or travel, or catch up on some sleep).

When dealing with MS Exchange, people often suggest "just use IMAP". I don't think that mail is the real reason why people use Exchange and Outlook. There are lots of ways to use IMAP clients (including Outlook) and servers (including Exchange) for mail. If it was just email, there wouldn't be much point to OpenChange. The real lock-in for most Outlook / Exchange houses is the shared calendaring (including Free/Busy), big use of contact lists, and Public Folders.

The good news is that OpenChange is well advanced in supporting those, and the work that Alan Alvarez has done on the Akonadi OpenChange resource has set us up well for making some use of that.

The bad news is that right now the resource won't even compile (because of some changes of API in OpenChange), and Free/Busy isn't supported in Akonadi yet. There is a long way to go.

It does seem to be taking a long time, and that is probably a fair criticism. Please understand that the Exchange protocol is very complex (some 20+ documents in the specification set, and some of them are into the hundreds of pages) and no-one is working on this stuff full time. Julien Kerihuel is the closest we have to a full time developer of OpenChange, and he is mostly doing it on a self-funded basis. Certainly a lot of time invested and some great work, but still only a single developer. I'd also like to recognise the work of Jelmer Vernooij. So, not many people working on it, and a lot of work to do. When we get OpenChange into shape, I still have to put the work in the Akonadi resource.

Sorry.

> Read More... | Digg This!

I originally planned to do that in time for the KDE PIM special feature which has been published as part of one of the recent commit digests, but I didn't find enough time to it then and almost forgot about it later.

But today I sat down and recorded by first screencast ever and several takes due to tons of stupid mistakes, I present to you the screencast about Akonadi KResource bridges.

Video available as OGG Theora and Flash on blip.tv

Since the audio volume is quite low and am not such a good speaker, I'll explain the most important scenes.

I started with launching KAddressBook and added a new entry to its default file based resource.

After that I began the process of adding the first half of the Akonadi bridge, the application side plugin, just like I would add any other traditional address book plugin.

The configuration dialog for this special plugin also allows to perform Akonadi management tasks, such as adding new Akonadi resources (in the screencast and the UI I called that "Address Book Sources" to avoid the resource ambiguity).

Using the second half of the bridge, the Akonadi resource operating on KResource plugins, I gained access to the very same address book file the default resource is pointing to.

After removing this duplication by removing the default plugin, I launched a second Akonadi enabled application called akonadiconsole.
This isn't a nice userfriendly one because it is meant as a developer tool, but unfortunately I didn't have any other option available at this point due to not many applications using Akonadi yet.

The demonstration continues with showing Akonadi's change notification handling, e.g. that adding a second resource in akonadiconsole has it automatically available in KAddressBook as well and that changing data (removing the email address) is also automatically relayed.

If anyone is interested in trying this as part of the upcoming KDE PIM bug squashing I would really appreciate any feedback and will try to be available on IRC during most of the day (my nick is krake there as well).

> Read More... | Digg This!

While browsing through kde-look.org I found a cool idea for visualizing a daily agenda.

This reminds me of the Akonadi architecture diagram and I even have code (probably not up to date) for drawing this kind of diagrams. So I guess it would be doable without too much effort to implement a daily agenda viewer like this. Would be a fun project.

> Read More... | Digg This!

The eGroupWare resource in KDE-PIM hasn't gotten much love and attention in a long time. It compiles, but we have no idea if it really works, nor do we have anyone on the PIM team who uses it.

This is an open call for either 1) someone to take over the maintainership of the eGroupWare kresource or 2) someone to at least help us by testing patches and giving feedback.

Else... we may be forced to remove this resource in KDE-PIM 4.2.

Volunteers please contact me directly or send a message to the kde-pim mailing list.

> Read More... | Digg This!

As we near the first release ever of KDE-PIM for KDE4, I want to take this opportunity to thank the many folks who helped the kdepim team move to a stable release in a short 6 months.

On behalf of our small group of KDE-PIM developers, Thank You! to the KDE BugSquad, the people who hang out on IRC and help with quick testing of new code, the beta testers and bug reporters, the triagers, and everyone else who gave us kind words of encouragement. We really couldn't have made it happen without you.

If you asked me 6 months ago if we would see KDE-PIM released with KDE 4.1 I would have said.. I doubt it. In fact, I probably did somewhere if you search our mailing list archives We still have plenty of bugs to fix, and features to implement; but, for the first time in years I feel confident that KDE-PIM will enjoy a successful future in KDE4. On to Akonadi and KDE 4.2!

Regards,
Allen, KDE-PIM Module Coordinator

> Read More... | Digg This!

Akonadi is hot. I completely realized that when I saw the fantastic submission by Nuno and Thomas for the Akonadi logo contest. This logo captures the essence of the Akonadi architecture in a very beautiful way. I remember well when I drew the first version of the Akonadi architecture on the whiteboard at the Osnabrück 4 meeting more than two years ago. The round shapes made it hard to put it in digital form, though. So after taking a tour through the drawing applications of the free software world without lasting success, I decided to write a program to create the diagram. When I saw the Akonadi logo contest and some of the submissions there, I thought it would be great to have a three dimensional version of the architecture diagram, and now Nuno and Thomas just did that. Wonderful!

But why is Akonadi hot? I think the main reason is that it's living the KDE 4 vision. It's the condensed experience of ten years of KDE PIM development put into a beautiful architecture. It has portability built in by the platform-independent central storage and the toolkit-neutral access protocol. The Akonadi backend has recently been moved to kdesupport to be usable by non-KDE projects as well. Finally Akonadi really implements the promise of KDE 3 in terms of functionality of a central PIM storage which is conveniently avaliable all over the desktop.

Akonadi somehow is the missing pillar of KDE 4. With KDE 4.1 this gap will be filled and the Akonadi platform will be available for development of the next generation of PIM applications to advance free software on the desktop one more step in direction to world domination. I'm looking forward to this. Really.

> Read More... | Digg This!

speaking of logos, and while I'm in 1:N communication mode and have your kind attention, large and lovely N that you are: we're in need of a vector version of the current Kontact logo, for purposes of blowing it up indecently in size for use in a poster or two (for Linuxtag). If you, dear k in N, happen to be in possession of such, or happen to know j notin N, but the creator of said artwork, or happen to be j in N, said creator, yourself, please get in contact with me at your earliest convenience for the overall furtherance of the ascent of the K (assuming |K| > |N| without loss of generality).

> Read More... | Digg This!

As Tom announced a few days ago, the Akonadi team is looking for a logo and an icon for the little system tray application. So far we have three submissions, but us kdepim hackers at KDAB thought we'd give folks an extra incentive by donating a Canon Powershot digital camera, new and unused, to be given to the creator of the work we will chose in the end. This fine and only slightly out-of-date (as digital cameras are doomed to be the moment one takes them off the shelf) piece of gear can be yours, yes, yours, if you add your submission to the techbase page and we end up selecting it in a process that will very likely be utterly subjective, unfair, unprofessional and morally objectionable. So there. Keep those submissions coming!

> Read More... | Digg This!

Last weekend I was invited to the KDE-PIM meeting in Osnabrück to represent Nepomuk. First of all I have to say: thanks a lot for inviting me, guys. The meeting was a lot of fun (although staying awake got harder during the course of the three days you crazy work-maniacs!) and it was great to see known faces again and meet new nice people. As they have during the last years Intevation hosted the event and I want to give a quick thanks to them, too.

So much for the introduction. Let's dive into the good stuff now. The main focus of the meeting were the plans for KDE 4.1 and the integration of Aknoadi. However, the part that is most interesting to me is the Nepomuk integration. And this is were I was very pleasantly surprised. I did not have to do any convincing or argumenting at all. It was obvious that Nepomuk would be the solution for search in Akonadi. And not only that. The understanding of the concepts was flawless.

So what are the plans for Akonadi-Nepomuk integration?

• Taging in KDE-PIM: The most obvious integration at the momment is without a doubt the replacement of categories in KDE-PIM with Nepomuk tags. This would relate PIM resources with tagged files (and of course any other resource type in the future).
• Akonadi Agents to push data into Nepomuk: Akonadi has the concept of agents. Agents are plugins (although running in their own process) that act on changed data in the Akonadi store. In this case the agents will gather changed data and push it into the Nepomuk storage so it gets searchable and indexed properly. Tobias König already started a first agent which handles contact data, meaning that it converts the Akonadi items into NCO resources which are then stored into Nepomuk.
• Virtual folders in KMail: KMail will combine the current static folder layout with virtual folders based on live searches. A virtual folder selects a set of emails based on a Nepomuk query. This can turn out to be very powerful since one can define queries that do simple things like "select all emails that contain picture attachments" or more complex stuff like "select all emails that were sent by someone who participated in events tagged with 'KDE-PIM'" or even very fuzzy ones like "select all emails relating to a certain topic". For this to work Tobias and I started to create a higher level query interface. Although it is currently possible to do these queries, one has to do so by using the Soprano SPARQL query interface which may be too much for many applications.

While this is by no means a complete list it shows the direction Nepomuk integration will take in KDE-PIM. A fact I am very happy about.

So much for the high level report about the KDE-PIM meeting. More technical details about the implementation and the problems that still have to be solved later...

> Read More... | Digg This!

Here's the first blog in my life. KDE PIM meetings are for hackers like a bottle of water in a desert. Finally time to hack, hack, hack and only sporadic meetings. And those meetings about development topics. This meeting took place from friday 2008-02-01 till 2008-02-03. This time I remembered to take vacation for the friday. At 10:00 am, I departed from Alzey and arrived shortly after 14:00 in Osnabrück at Intevation who hosted this meeting (thanks!). Some guys were already there. I finally got to know Thomas who had shown me how to use kdevelop for KDE 4. I used this day to get KDE compile on my notebook. We left the office at 1 am.

krep

On Saturday, I gave a presentation about my pet project, simplified debugging, see
I showed how you increase your productivity by using a combination of add_trace and krep.
My pain points are:

• with grep, I filter away either too much or too less
• changing the pattern for grep requires grep's restart
• grep's restart requires the restart of the application whose output you are sending to grep.

This makes debugging hard.

You use add_trace to change your KDE source code so that every function outputs its name first when called:

Here, the kDebug-line has been added by add_trace. You compile again then and watch the output using krep. This way, you can almost create a call tree. And as soon as I manage to make debugging output as soon as you leave a function, you will actually be able.
You would start e.g.

krep then allows you to shrink or expand your view of ktimetracker's output.

Windows debugging

After my presentation, Jaroslaw gave his presentation about debugging KDE on Windows. There you can use MS Visual C's ide and you have a similar functionality as krep. It was also impressive to see the call stack being displayed while debugging and the performance of the system.

KDE 4.1 discussion

Interesting discussion about our proceeding for KDE 4.1. Good meeting minutes on the mailing list.

Akonadi

Akonadi for insiders. Discussing about the state (that I do not know). I preferred finally improving the KDE code.

debugging output

I asked how you compile your KDE programs so that kDebug messages are not output. The correct answer is use

 cmake -DCMAKE_BUILD_TYPE=Release .

Dinner

at the italian

kmail

Discussion with Ingo about kmail bugs. If we manage to get the body structure (documented in some rfc), the body information, we might be able to close bug 80995.

key signing party

My kmail is now secured thanks to Ingo taking me into the web of trust by signing my gpg key. The key server even had my old key that I had signed by c't at CeBit 2001.

HTML editor

Mike recommends me to try QTextEdit, QTextBrowser and QTextDocument for an HTML editor.

David

Hacking session with David on krep. You should replace

 foo(QString bar)

by

 
 foo(const QString& bar)

whenever possible for the reasons:
* const prevents you from accidentially changing bar
* QString& is in contrast to QString a pass-by-reference, not a pass-by-value. You save the time of copying a QString.

 QString blah;

is by default equivalent to

 QString blah=QString();

for QString blah; uses the default constructor to construct the object (unless adviced otherwise). This is also valid in a header-file. This is valid for all non-trivial data types, for all data types that have a constructor. So, you still need to initialize an int like this:

 int i=0;

And, pay attention, the following will have a NON DEFINED value:

 QString* qs;

You need to initialize it:

 QString* qs=new QString();

or

 QString* qs=0;

Thinking complicated is the cool and the ugly part of C programming (C++ is a dialect of C).

We created a benchmark for krep:

it took 17 seconds (in revision 770163), then we worsened it, then it took 10 seconds (in revision 770188), then 2 seconds (in revision 770205).

Deleting a pointer ? Best set it to 0 afterwards so you know it is useless.

We left the office shortly after 2am.

commitfilter

During the breakfast, we discussed about various things, e.g. the strangest bug reports and mails on mailing lists. There was a discussion that the term "spouse" (e.g. in an address book) is discriminating people who live in relations and cannot marry because e.g. they are gay and live in intolerant countries. So it was proposed to change "spouse" to "partner". I think, so far this is good and understandable. But soon, a guy came up demanding to support polygamy for tolerance's sake. Or, there was a guy stating the letter K would make people commit suicide and demanding from us to change our logo...

What I also learned during breakfast: Did you know that you can easily watch changes in KDE's code base by registering at http://commitfilter.kde.org ? This site will send you a mail when the svn branch (can also be trunk that you select changes. Thanks Thomas for the tip.

kexi

Talked with Jaroslaw about using kexi as database backend for ktimetracker. Also akonadi could be used. I could start with my kexi experiences at http://websvn.kde.org/trunk/koffice/kexi/tests/newapi/. Writing this blog, I discovered, that even german Autobahnen (motorways) are subjects of ENGLISH wikipedia's articles, so, here is one of these important topics, including pictures.

kcal error messages

Discussion with Cornelius and the others about error message handling problems with kcal. As this involves adding of virtual functions, we will not be able to get the fix in before KDE 5. And then, we will have Akonadi.

> Read More... | Digg This!

One of the nice aspects of being a software developer is that sometimes users come up with using your software in creative ways you never have thought of. They discover surprise features. I particularly like these because they show that you have great users and they often also are a sign that you took some right design decisions.

Some time ago a user discovered such a surprise feature in the combination of KNotes and KDesktop. He implemented an Eisenhower Matrix, which is a matrix consisting of four quadrants ordering task by importance and urgency. He did this in a truly creative way by using a special desktop background representing the matrix and putting in the tasks in the form of KNotes notes. Amazing!

For putting a task into the matrix you have to decide if it has high or low importance and if it has high or low urgency. This way you get four possible combinations which are reflected by the four quadrants. Now the usual way to address these tasks is as follows: The tasks which are unimportant and not urgent are discarded. That's the waste. The tasks which are not important but urgent are delegated to somebody else who considers them to be more important. The tasks which are urgent and important you handle yourself immediately and the tasks which are important but not urgent you plan for doing yourself.

Especially when it comes to planning, the surprise feature implementation reaches its limits. Here it would be nice to have some integration with KOrganizer to keep track of deadlines and support time planning. This could for example be a special view in KOrganizer managing tasks in the four quadrants, or maybe KNotes could be adapted to be able to associate or represent KOrganizer tasks in notes. This certainly would be a fun project. If somebody feels inspired to work it, don't wait, the code base is ready to get some creative treatment.

By the way, the name of the matrix goes back to a quote of the former president of the United States Dwight D. Eisenhower:

> Read More... | Digg This!

Once again we have friends visiting, here at the KDAB Berlin office. So far Will Stephenson, Bruno Virlet, Thomas McGuire, Volker Krause and Kris Koehntopp have arrived for a weekend of Akonadi hacking. Kris (of MySQL) has kindly agreed to have a look at our usage of their system and point out the various errors of our ways. It's already been very productive, we now have a much better idea of what not to do and how to debug what we are currently doing. The rest of the guys are working on benchmarking the other layers, with the goal of proving that Akonadi can actually deliver the kind of performance we need. Bruno has been doing great work on the models for Qt4's model/view framework, on top of Akonadi, as part of his Summer of Code project, and it's great to meet him in person. The picture below shows him in animated discussion with Kris. More exciting things to come as the weekend progresses, I'm sure.

> Read More... | Digg This!

A few days ago a kind soul reminded me of kandy.kde.org, the ancient home page of Kandy, an application to sync mobile phones I wrote six years ago.

I still remember the happy feeling when I had transferred the phonebook of my mobile phone to my computer for the first time. I also still like the cheesy name "Kandy", the triple pun on "Handy", the German word for mobile phone, "Candy", and the KDE naming convention. It once was a sweet application, so please bear with me.

These days this is only a distant memory. Development of Kandy never got beyond the point where it was useful to handle more than the class of phone I owned myself. So while some people, including me, enjoyed having Kandy available for a couple of years, it's obsolete by now. The mobile phone I use today isn't able to talk to Kandy anymore and with OpenSync we have a much more powerful tool to sync not only mobile phones, but also the rest of mobile devices and desktop applications.

Goodbye Kandy.

> Read More... | Digg This!