KAddressBook and Akonadi in KDE 4.4

On the last annual KDEPIM meeting there has been a lot of discussion how the further porting of the PIM applications (kmail, korganizer, kaddressbook etc.) shall proceed. The Akonadi server is stable and ready for day-to-day use and the client library is powerful enough to let a PIM application do most of its tasks. Because of the short time frame and the different complexity of code base, we decided to port KAddressBook to Akonadi for KDE 4.4 and port the other PIM applications for KDE 4.5. While the work on KAddressBook takes place in SVN trunk, the other work is done in a separated branch that will be merged back to trunk after the 4.4 release.

Working on the port of KAddressBook has been real fun, because I had the chance to throw away all the ugly, historically grown code and restart from scratch. On the one hand most of the storage management is handled by Akonadi now which reduces the code size enormously, on the other hand most basic functionality, like editing or viewing a contact, has been implemented as separated components, that are part of a library and therefor can now be used by other applications as well. So the whole code base of KAddressBook is much cleaner and well structured now. But also GUI wise I had the chance to improve the stale user interface from KAddressBook 3.5. The MacOS X user might recognize the overall appearance of the new KAddressBook UI, yes, I have to admit, the new design is inspired by the MacOS X address book ;)

Now I'll give you a small tour through the new KAddressBook with some nice screenies:

When you start the application you'll see a window like that one

On the left side you have the list of available address books, by default an address book 'Personal Contacts' will exists that contains all your contacts from your old KAddressBook installation (better said the ones from $HOME/.kde/share/apps/kabc/std.vcf). In the middle you see the list of all contacts that exists in the currently selected address book and its sub folders. On the right side the detailed information about the currently selected contact is shown. With the port to Akonadi, not only contacts are listed in the middle view, but also contact groups (TCGFKADL 'TheContactGroupsFormallyKnownAsDistributionLists'), so they are first class citizens now and integrate much better than in KDE 3.5.

The toolbar has been cleaned up and the user interface is as simple as possible. If the 3-pane look is still too complex for you, you can switch to the 'Simple UI Mode', than KAddressBook will look like the following:

Here you can quick search for a contact or contact group via the search line or iterate over the contacts with the 'Previous' and 'Next' buttons. This view should be enough for everybody who just wants to look up contacts quickly and seldom changes their data.

If you really want to add a new contact or change an existing one, you'll be using the new contact editor component, which is like already said available for every other application as well, so no strange dbus calls or exec('kaddressbook --new-contact') statements anymore.

In the 'Contact' tab you can enter the basic information of a person that you need to contact.


The 'Location' tab contains the addresses and coordinates of a person.


The 'Business' tab contains information that are useful for business contacts.


The 'Personal' tab contains personal information about a person.

In the future the editor will be extendable by plugins, so other applications can put there custom tabs there as well.

Let's go back to the address book and contacts view:

A right click on the address book view opens a menu where you can add, remove and modify the single address books (which in fact are Akonadi resources) and the address book folders. Yes, you can create folders and subfolders in your address book now to organize your contacts and in a later version we will also have virtual folders that allows you to group contacts by an arbitraty search query. A right click on the contacts view opens a similar menu where you can add, remove and modify contacts and contact groups.

If you right click on the header of the contacts view, a menu will appear where you can choose which columns shall be shown.

So these are the visual changes in KAddressBook, but under the hood there has been many changes as well. By default the contacts are stored now in a directory, each contact and contact group in its own file, so editing one contact will change only this file. The directory is located under $HOME/.local/share/contacts, so we can migrate later without having to care about $HOME/.kde3 vs. $HOME/.kde4 issues. Akonadi brings further features for free, for example offline mode with groupware servers, so you can do your changes offline and when you go online later on, the changes are transferred to the groupware server.

At the end of this blog only one warning, don't expect the current KAddressBook to be as feature rich as its previous version. This has been a complete rewrite and I integrated only the features that made really sense IMHO.

Pimp my Nepomuk

From time to time people show up on the #akonadi IRC channel and complain about the dependency of Akonadi on Nepomuk, because Nepomuk is so slow and takes 100% CPU when they start their desktop. The 'bad' news are, we won't drop the dependency on Nepomuk, because this is a technology no other desktop environment provides so far and it gives us all the nice features we want to have (from a Pimsters point of view ;))

So what's about the good news you might ask? Well, for those of you who have Nepomuk running with 100% CPU usage, we can make Nepomuk a lot faster!

When you execute the following command on a shell

qdbus org.kde.NepomukStorage /nepomukstorage usedSopranoBackend

you will see either 'redland' or 'semsame2' as output.

If your Nepomuk uses Sesame2 and it is still slow, your hardware must be really old (and I mean really, really old ;)), it works fine here on a Laptop with 500MHz and 256MB RAM...
For most of you, who see a high CPU usage of Nepomuk, however the Redland backend is used. So what is this backend thingy about? Nepomuk is a KDE specific high-level API for Soprano, which itself is a Qt-only storage solution for RDF (semantic) data. But Soprano doesn't implement the actual storage, it just forwards this task to its backends where currently two stable ones exists, the C++ based Redland and the Java based Sesame2. The reason for the high CPU usage is, that the Redland backend is much, much slower than the Sesame2 backend!

The careful reader might wonder now "Why is the C++ based backend slower than the Java based?" Isn't Java always slower than C++? Not in this case, the storage of RDF data and the querying involves many clever algorithms, so the C++ backend is bit here by the complexity theory. The Sesame2 backend in opposite has implemented many optimizations on the algorithm level and beats Redland performance wise.

So as strange as it sounds, to get a faster Nepomuk you have to install Java.

Yeah, I know, many people will scream now "WTF, why do I have to install this Java crap?!?", well, actually it could be that you have already installed it, OpenOffice for example brings along a JRE and to be honest, the reputation of Java is worse than the current implementations actually are. But back to pimping up Nepomuk...

If you use the KDE packages from a distribution, check whether there exists a package soprano-backend-sesame and install this one. If there is no such package available and all the other Soprano related packages do not contain a file
$KDEDIR/lib/soprano/libsoprano_sesame2backend.so bug your distributor to create them or do it yourself and publish them ;)

For the brave guys that use KDE compiled from sources, you need the following things:

• The Java development package (under Debian sun-java6-jdk)
• The Java runtime package (under Debian sun-java6-jre)

Now make sure that your compiler can find the development files by adjusting the LD_LIBRARY_PATH to contain the Java library directory:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jvm/java-6-sun/jre/lib/i386:/usr/lib/jvm/java-6-sun/jre/lib/i386/client/


(this are the needed paths under Debian, your paths might look a bit different).

Then just recompile Soprano from kdesupport (remember to clear the CMake cache before). CMake should output in the status report whether it has found the Java headers and libraries or not, if not, check your LD_LIBRARY_PATH variable again. If everything compiles fine, after a 'make install' you should have the file
$KDEDIR/lib/soprano/libsoprano_sesame2backend.so
available and after a restart of Nepomuk the qdbus command, I listed above, should return 'sesame2' now. And maybe you have already noticed, Nepomuk doesn't run with 100% CPU usage any more ;)

I hope this blog helps to reduce the prejudices against Nepomuk, because this software really rocks! Let's hope the distributors will finally ship sesame2 based Soprano packages!!!

W3C XML Schema validation with Qt

For all of you who want to make use of advanced XML processing with Qt and KDE, here is a preview story. Now we can maybe get rid of the libxml2 dependency at several places in KDE.

Size limits for trash

Some weeks ago, one of our customers asked for a nice
feature that was requested 4 years ago the first time
as far as I can see from the bug tracking system.
He wanted an option to set a maximum size for the users
trash like you can do on Windows or MacOSX to avoid situations
where the trash fills 50% of your hard disc and you wonder why
you can't download emails any more ;)

As you can see in bug 79553 and 111861, there are some more
ideas how to improve the space handling of your desktop trash,
so instead of just implementing a static size limit I started
implement most of the features requested there and 3 days later
we have a nice trash space handling now.

When you right click on your trash icon on the desktop and
choose the 'Properties' entry, the appearing dialog will
offer a new tab 'Size Limits' now as shown in the screen shot
below.


Here you can choose whether files that lie in the trash for
longer than X days shall be deleted automatically or whether
there shall be a size fixed limit.


If a size limit is set and your trash is full already, trying
to put another file into the trash will trigger an action that
can be one of the following:

• Warn user only: A dialog is shown to inform the user that his trash is full and that he has to remove files manually before he can put new files into the trash
• Delete oldest files from trash: This will remove files (beginning with the oldest one) successively from the trash until the new file fits in
• Delete biggest files from trash: This will remove files (beginning with the largest one) successively from the trash until the new file fits in

One of the nice features of the freedesktop.org trash standard is, that you can have multiple trashes, one for each mount point.
If your administrator has setup these, the trash configuration dialog will look like below:

Now you can configure different size limits for each trash.

As you may have recognized, this patch is for KDE 3.5.9, because our customer is still running that version. I'll try to push that patch
into KDE 3.5.10 and port it forward to KDE 4.2 as well.

Today I had an interview with Emanuel from kubuntu-de.org about the progress and future of Akonadi. After the interview we talked about different stuff and to my surprise Emanuel studies ethic and history on lectureship. So he is the second KDE fellow (Carsten Niehaus is the first one) I know, who will teach the pupils of the next generation how great KDE is ;)

So I thought about how to combine KDE with ethic and history. Ethic is a difficult thingy, but history is fine. I really miss a program which shows me a time line with
all important things that happened in history. Honestly I was no keen on history during school, but that has slightly changed nowadays.

So after some hours of hacking I can present a neat, little application, which reads facts about historical events from a XML file and shows them in chronological order.
For every event the file contains:

• the date of the event
• a short description
• a reference to an image
  
• a link to a source that provides more information (e.g. wikipedia article)
• a category tag

At the moment it's only a small pet project, however it can be extended for general purpose. For example you could provide a XML file that contains information about all KDE releases, with small screenshots of the desktop and links to the release announcements.

And here comes the obligatory screenshot:

When you click on the link, the wikipedia page for Martin Luther King is opened in the default browser.

Downloading links with Konqueror4

From time to time I've to download several documents from a website (e.g. university) and there is nothing more boring than right clicking on every link, choosing 'Save link as...', selecting the directory... and doing that several times.

Fortunately Konqueror has this cool embedded konsole window, so if all link addresses follow a special schema, you can do some magic with 'for i in 1 2 3 4 5; do wget http://host/doc$i.pdf; done'.

However not all professors name their documents by a special schema... so back to the 'Save link as...' solution? Not anymore! :)

I've written a plugin for Konqueror in KDE4, which allows you to select a couple of links on a website, choose a menu entry from the menu bar, selecting a destination folder and all links, independent of their names, will be downloaded. As pictures say more than 1000 words, here are the obligatory screenshots:

1) Select the links and choose 'Download selected Links...' from 'Tools' menu


2) Select the target directory


3) The download dialog will show the progress of the download


If anyone is interested in this plugin, I would commit it to extragear/base during the next days.

Never miss the bus again with Plasma

On Thursday I had a meeting with my classmates from the advanced chemistry course, some of them I haven't seen since 6 years, that was real fun! What has this information to do with KDE? Well, on the way to the Irish pub we used the bus of our local public transport (DVB). They have nice info screens (running windows, so you often see just a bluescreen ;)) with advertisement on it. These evening the showed information about a 'widget' that you can download to show the arrival/departure times of a single bus/tram stop. The next day I browsed the DVB website and found a link to this widget, it is a Yahoo Widget thingy... unfortunately the Yahoo Widget engine is not available for Linux :(

Ok, I'm a hacker, let's see whether we can fix that!

The Yahoo Widget consists of a couple of HTML, image and JavaScript files, packed into a proprietary format. Finding out the URL queried by widget to retrieve the information was no problem and the returned data are in an easy to parse format. So the rest of the work was to assemble a Plasmoid which makes use of these 'webservice'. Two days later (had to buy some xmas presents in the meantime ;)) there is a working version available:

You can see two applets which show the departure time for two different stops.
Of course this Plasmoid is only useful for all KDE users living in Dresden (maybe 10? ;)) so I'll make the code available on my private website only, or provide it by KNewStuff later.

Update: You can find the sources and the compile instructions now under http://wgess16.dyndns.org/~tobias/kde/plasma_dvb/index.html