Since so many students have already shown interest in working for KDE during this years Google Summer of Code, with some already having started to send in first drafts of their proposals, I thought I'd a bit of advertising for a specific idea. Well "my" idea :)

It has been mostly ignored so far, i.e. not getting a lot of obvious attention, probably because it is "hidden" in the KDE PIM section and not listed in one of the section that guarantee eternal fame.

Short personal notice: I am currently in Cologne for a business trip lasting two weeks so I am staying over the weekend. If any KDE people around Cologne want to go for a beer until next Thursday, let me know :)

So, back to the subject. This blog entry is about a rather weird behavior of QBuffer I've debugged recently.

Some friends of mine were seeing a weird problem with some of their code using Qt4 that had previously worked in Qt3.
They broke it down to this minimal test case:

A slight delay of my flight from Düsseldorf to Graz gives me time to recap the awesome time at the Desktop Summit 2011 in Berlin.

Having been part of the programme committee I was looking forward to see at least a small subset of the talks live, though I hope I will have the opportunity to see many more once the videos have been processed and are available online.

Selecting talks hadn't been easy, both because of the huge amount of proposals we've received and because deciding on suitable topics for such a wide range of attendees is no piece of cake either.

Companies often store their customer information in databases managed by customer relation management tools.

SugarCRM is one such popular (and open source) system, built on the extremly wide spread AMP stack (Apache HTTP, MySQL, PHP). Therefore its main user interface is web based, i.e. accessible through standard web browsers and thus also relatively platform independent.

I am not talking about His Steveness or this kind of jobs (congratulations to both involved parties!), I am talking about these.

Harald has asked me to organize a KDE release party here in Graz.

However, I am too lazy (wait! busy! sorry for my English, busy is the word I was looking for) to do that there won't be a dedicated event to celebrate KDE's newest achievement.

With Akonadi most operations are running behind the scenes, carried out by background helper processes called Akonadi Agents.

While we do have respective progress monitoring in KMail2, users will eventually take advantage of fact that they are no longer tied to specific applications. At which point they might want to be able to check on the status of these background processes without launching some front end applications.

After all the blogging about our (as in KDE PIM developers) Akonadi porting, I thought I'll address a couple of things other application developer might consider for the next release cycle.

The most prevalent use of PIM API seems to be KABC::StddAddressBook.

Find By Uid

A common use case is to look for a contact object by its identifier, acquired by user selection somewhen in the past.
The code to do that usually looks like this:

After my last blog I was asked whether I feel that the migrator is now ready for testing.
I think it is.

If one wants to repeat the same test scenario (or variations of it), there are a couple of tricks to do that with as less effort as possible.

As an initial step create a new user account. This ensures that the data and config on your main account is safe even in cases of anything going wrong.

After blogging about our progress on KMail's data and config migration to Akonadi for a couple of times, I felt that it was time for a screencast showing the migrator in action.

The KMail test setup migrated here has most of the common account types: POP3, IMAP, Disconnected IMAP, local MBox file and, of course, KMail's local folders.