For quite some time almost every blog by a KDE PIM developer is about Akonadi in one for or the other, often about "Akonadi porting" or "porting to Akonadi".

Akonadi itself can already be difficult to explain, combined with "porting" it probably has only meaning left if you are a developer.

The thing anyone else will be able to extract are delays.
Delays in the sense that we, the developers working on KDE PIM, are enthusiastic about our plans on what we want to achieve for a certain KDE release, only to be disappointed that we didn't get as far as we originally hoped for.

For example an initial guess was to have KAddressBook and KOrganizer ported in time for the 4.3 release, but lack of resources meant we didn't even get to start working on KOrganizer in any significant form and the new KAddressBook would lack some features.
So KAddressBook is held back and finished for 4.4, KOrganizer is still being worked on.

So what is all this porting business actually about and why does it take so long?

Imagine a situation where you want to cook something (well, you can imagine anything els of course, but it will greatly improve the understanding of the following example if you restrict your fantasy to cooking for now).

After you've decided what you want to cook, you'll have to get your ingredients, which usually means going out for shopping. When you get home, probably after quite some time and travelled distance, you'll have to prepare these ingredients (wash, peel, chop, etc.) and then start the actual cooking.

That works pretty well, millions of people do between that once in a while and every day.
So you meet other cooks and discover that while you have individual styles for preparing ingredients and the cooking process, you all despise the shopping chore, especially when shops are crowed, roads are jammed, weather is nasty, and so on.

On one of those lazy sunday afternoons you read about outsourcing and immediately convince your fellow cooks to outsource shopping to a shopping specialist.
You snicker at the thought of this poor fellow having to brave the nasty weather, travel the jammed roads, wait in line at stores, while you comfortably wait for the devlivery.

However, you discover that you have to adjust your approach to cooking to accomodate for this for of ingredient acquisition.
With your initial approach you knew when you would be doing what for how long (not counting unavoidable delays during shopping).
With your new approach you don't anything between placing your order and the arrival of the goods. Sure, you could be waiting at the door step, but that gets boring after a while. You can spend some time preparing everything you already have at home, but usually that won't keep you busy long enough. So you do something else instead, maybe reading Planet KDE and learning that those lazy developers have balantly copied your outsourcing idea

Switching to a different reality there is this cook called KMail (in this reality cooks are, for an unknown reason, actually called "mail user agents").
An absolut expert in preparing an ingredient called "message" (weird reality, I know), peeling of envelopes, chopping into pieces (jokingly called "multi parts"), etc. You know, the usual cooking stuff, just done expertly.

But again the shopping for "messages" at shops called "servers", with owners of sometimes questionable character, low quality offerings and so on, is making KMail's life unpleasent.
So of course outsourcing that to a shopping specialist (in this reality, weird as it is, called "Akonadi") is the way to go.

Unfortunately our cook KMail discovers, while adjusting to the different cooking approach, that all these years of shopping had resulted in acquiring certain habits (in another reality, the author of this blog has the habit of not using shopping lists because eventually he'll recognize things to buy at the shop anyway).

Habits that need to be unlearned or replaced by habits which fit the new situation better. Habits our cook might not have been aware of or vowed never to think about again.
Fortunately there is a group of motivational trainers (having the surprisingly sensible name "KDE PIM Developers") who will help to overcome those.

It takes time, but it is totally worth it.

In case you thought that reading about the Akonadi developer sprint on the dot gave you an all encompassing overview of stuff happening around Akonadi, you forgot our brazilian friends.

Adenilson Cavalcanti, also featured in one of Danny's excellent commit digests, has been working like a mad man (or a genious, thin line and all that ) on the Akonadi resources for Google's data services.

Since there is no business like show business, we hereby proudly present you, straight from the source, exclusive premium footage of these resources in action.

Video of Akonadi working with Google Contacts

Video of Akonadi working with Google Calendar

(Videos available in Flash and OGG Theora, embedded and downloadable thanks to the excellent blip.tv service)

Printing in KOrganizer is really in need of some attention. Especially now that we are providing RichText capabilities in calendar descriptions and elsewhere. You can even write journal entries entirely in RichText. But the printing system doesn't know anything about RichText.

There are dozens of outstanding bugs related to printing in KOrganizer.

The job involves knowledge of low-level drawing primitives (move-draw, set pens and brushes.. stuff like that).

I was surprised to get so much feedback about the KOrganizer agenda items after I posted the screenshots in my last blog entries. There seem to be some strong opinions about rounded corners. Michael Lentner did the right thing and sent a patch. I applied it and suddenly the agenda items look much more slick.

[image:3066 width="640" height="452" hspace=100]

There is even more space around the items, which seemed to be one of the things which disturbed some people, so I don't know how this change will be accepted. How do you like it?

It also doesn't seem to respect the resource colors anymore, but I'm not sure if that wasn't broken before already. The selection also has a slight problem as it isn't visible when there is no header displayed, but I guess that's fixable.

Hi, I'm a Google Summer Of Code student and I'm working on creating a kresource to add support to add a journal and retrieve them from a blog.

You can monitor my progress on the kresourrce in trunk/KDE/kdepim/kresources/blog/.

The next stage of my project is revamping the journal support in Kontact/Korganizer. This will not be completed by the end of the summer but I plan to keep working on it regardless.

If you have an ideas or input on either of these parts of my project then send me an email at mike@mikearthur.co.uk or talk to me on #kontact.

As I wrote in my last blog, KOrganizer now has the ability to export the calendar to all different kinds of formats using technology called XSLT transformations. The only thing that I'm missing (because I'm entirely bad at those things) are good designs that I can implement. So I'm looking for nice and visually appealing designs of how calendar exports might look. Possible export formats are e.g.

• SVG graphics
• HTML (to-do list, calendar, journal, showing just one event)
• PDF output

Just be creative! In principle, one can create anything from the calendar data, from A0 wall poster calendars to A8 pocket sheets, from SVG graphics showing the calendar with a nice holiday picture in the background to professional-looking calendar books.
Of course, with SVG and HTML it would be much easier for me to implement if your design is already in SVG or HTML.

BTW, if anyone wants to try it out, the KOrganizer plugin is currently in the kdepim-3.5.5+ branch for new features to 3.5 (branches/work/kdepim-3.5.5+/korganizer/plugins/xslt/ in SVN). To work with the 3.5 branch, just copy that directory over and it should work. You'll have to enable the plugins in korganizer's config dialog before you can see them in the "File -> Export" menu, though. There are some proof-of-concept style sheets available already (for HTML, SVG, CSV, etc.), but they are mostly dummy styles and do not really produce any useful output (and if they do, the output is plain ugly, so I won't give an example here).