Wednesday, September 30, 2009

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.

31 comments:

Claudio said...

Is there any plan to make it easy to send contacts by bluetooth?

Will Stephenson said...

The Nepomuk project promises interesting ways to relate data, using the PIMO ontology to structure PIM data. I assume there is no simple mapping from this to the RFC2426-derived KABC data classes. Is there a plan how to make Nepomuk's ontologies and PIM's data work together?

Daniel Beck said...

Hi Tobias,

the new UI of the KAddressbook looks much better, and is certainly much easier to use.

Benjamin Meyer wrote a blog some time ago, where he pointed out some of the design flaws of [the current] addressbook UI. In my eyes, you seem to have fixed most of them.

Thanks :-)

Chris said...

what about using the marble component @ the location tab ?

Oliwier said...

"This has been a complete rewrite and I integrated only the features that made really sense IMHO."
And PLEASE do not clutter interface with useless features ony pro-users want. Please let stay it simple.
Advanced features should be coded as plugins IMO. So GUI will be still simple and easy to use by mo sister.

Oliwier said...

"This has been a complete rewrite and I integrated only the features that made really sense IMHO."
And PLEASE do not clutter interface with useless features ony pro-users want. Please let stay it simple.
Advanced features should be coded as plugins IMO. So GUI will be still simple and easy to use by mo sister.

Luke Plant said...

In my experience Akonadi is nothing like stable. Please do not inflict it on us.

benjamin said...

Hwo come there's "Don Sanders" and "Faure, David" in the list? Do you really only have a single "Name" field? I think there should be at least title, firstname and lastname.

How else are you going to sync this with other devices? Did I miss something?

Unknown said...

Over the time and computer changes I have acumulated a lot of duplicate contacts. To that you can add all the duplicates in google contacts, ldap servers, etc. How does akonadi and KAddressBook deal with this duplication of information and is there a way akonadi itself can keep them in sync if it knows it is all the same person?

Unknown said...

Wouldn't it be nice if you could directly add custom fields specifying the name and the value.
Example:
Instead of having 3 fixed phone number fileds one could easily replace them with a variable amount of custom fields. They would be named by the user: e.g. "Home", "Mobile (Carrier1)", "Mobile (Carrier2)", "Office", "Mobile (work)", etc. They would still hold phone numbers, but be much more expressive. As they still are in the Phones section they would be recognized/tagged as phone numbers.

This can be similarly shown for messenger contacts, E-Mail addresses, family members, etc.

I think this would make KAddressBook a very powerful tool.

Janne said...

Why are the contacts a subselection of "All Contacts"? I think that they should be the toplevel selection, as opposed to something that is buried on the second level.

So how about making "personal contacts" toplevel choice? Alongside it could be "professional contacts" and what have you. You could then also have "All contacts" at the toplevel, which would aggregate the contents of every other addresbook in to it.

The current solution seems that most of the time the "All contacts" will be the sole item on the toplevel, and users contacts are then buried somewhere under it. And that would be more complicated than needed. Instead of burying stuff in sublevels, make them toplevel instead.

Of course there could be subselections as user desires "Personal contacts" could have subselections called "family" and "friends" for example.

This way we would eliminate the issue of having a one item on the toplevel, with everything else buried underneath it, while retaining flexibility.

Unknown said...

Oh, I'm going to love this new addressbook!! :)

A small question: What is this "All Contacts" top level entry good for? What else besides my personal contacts could be there? At the moment it looks a bit redundant and confusing...

And will the Akonadi managed addressbook also be located in $HOME/.kde/share/apps/kabc/std.vcf or will it be stored in some database?

This is btw. a major problem I have with Akonadi: This entire resource management is completely confusing for me as a user :)

tokoe said...

@Frosklis I guess there will be a plugin sooner or later, but not for 4.4

@Bille Akonadi already feeds the contacts it is aware of (that means all contacts it caches) into Nepomuk, so all contacts from Akonadi are searchable in Nepomuk. We use the PersonContact ontologie object for this purpose which can be referenced with PIMO later on

@Chris I didn't want to have a further dependency in KAddressBook and loading marble makes opening the editor slow. However in the future maybe there'll be an additional editor plugin that supports marble

@aasd I'll keep an eye on that for sure :)

@LukePlant It is not Akonadi that is unstable but the migration tools and the bridge resources... a clean Akonadi setup is rock stable ;) But we'll improve the migration tools for 4.4...

@benjamin The name is parsed into its single components automatically

@JC Merging contacts is out of scope of KAddressBook, that is something Nepomuk can/will be used for with the PIMO ontology

@riyad The number of phone numbers is not fixed, neither the number of emails or addresses

@Janne When selecting 'All Contacts', all available contacts from _all_ address books will be listed in the middle view. In the screenshots I have only one local address book (the 'Personal Contacts') in my setup, however there can be more address books below the 'All Contacts' entry, for example groupware servers or ldap servers.

@Some The default address book ('Personal Contacts') is stored under $HOME/.local/share/contacts as mentioned in the blog. A resource for this one will be created automatically.

Chani said...

awesomeness. :)

-would it make sense to have a "notes" box on the personal tab too?

-I thought the distribution lists would be represented as folders on the left... actually I still can't find any in your screenshots so I don't understand where they'll show up.

-where does kopete integration fit in? I never used the chat links but liked seeing the status icon :)

I agree that the "all contacts" thing can be awkward for those of us who only have one addressbook, one calendar, etc. maybe it could be magically hidden when it's only got the one child?

Chani said...

oh, and can gmail be my "groupware server" someday? :)

Yuriy said...

Looks good, but why the huge column for address books on the left? Most people will only have one or two. With one that pane is entirely useless. With two or three it's a waste of space and likely the least used part of the interface. I don't think the "simple" view is a solution to this because it doesn't give you a list of contacts.

I'm glad things are finally being moved to Akonadi, though I would really like to see KMail ready in 4.4.

P.S. No OpenID login for comments?

tokoe said...

@Chani The vCard format we use as standard storage format provides only one 'NOTE' field, so we can't have two as merging and splitting them will not work. I put the note into the business tab because there has been space left...
Contact groups will appear in the middle view as well and if you click on them, the details view on the right will show the entries of the contact group. There is no kopete integration yet, no idea how it would fit in best...

@Yuriy The 3 views are located on a splitter widget, that means you can collapse each of these columns. So if you have only one address book and don't need the left column, just collapse it and work with the lasting two ones

Rezza said...

Is it possible to set one default contact book and hide the list on the left and use left space to more detailed contact list? I'd like to see something similar to current Amarok playlist.

benjamin said...

Tokoe, I can't quite believe that... Does that mean that e.g.

Prof. Dr. h.c. John M. von Neumann Jr.

or

Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Freiherr von und zu Guttenberg

will be parsed correctly?

Kevin Krammer said...

@some
You can still use $HOME/.kde/share/apps/kabc/std.vcf with Akonadi.

Data is never stored just inside Akonadi's database, always in a common form, e.g. contacts vin card file, directory of vcard files, groupware server, etc.

Unknown said...

@riyad
Long time ago I've build a dialer application (in Delphi) with a very effective way to store multiple phone / email / etc. info, and I've suggested it to KdePIM. Recently I've re-posted the issue, since all older ones have been "closed" because of akonadi.
Have a look at:
https://bugs.kde.org/show_bug.cgi?id=208719
and see if it could fit your needs also, if so, vote for it :)

Anonymous said...

Hi Tobias

It all looks good and if I am honest the only reason my business runs Kmail is because of the quality of it's contact management so an important subject for us.

Could you outline the plans, if any, for integration of the contact manager with hosted e-mail services, our particular interest is gmail. Many small business use these services in preference to the hassle of running our own servers and being able to access your contacts regardless of the terminal your working from is a huge advantage of such services.
Will we still be able to search across multiple addressbooks transparently, not being able to do this is one of the real binds of Thunderbird.
Will we still be able to create custom fields and search on them ?
Are there plans to provide a DDI phone field ?

Thanks :)

Edward said...

What would you recommend for merging contacts that exist in the same address book?

xeros said...

I wonder how will behave my addressbook in KDE 4.4 and my Nokia E51 phone when I'll try to sync using syncml/opensync configured for KDE <= 4.3.x.

Anonymous said...

Hmm...but why didn't you implement CATEGORIES tag from vcf anymore? Now I have them in nepomuk as multiplied tags but not there, where they're intended: as categories in kaddressbook (resp. kontact). Please don't tell me we all have to create subfolders for categories, because most of us have the categories right in the vcf-file already.

Erik Wessman said...

Deleting "Categories" is a horrible mistake from my perspective.

Eliminating functionality in order to clean up code is a bad move - the cleanest code is none at all.

Anonymous said...

Hi Tobias

I have been running KDE as my secondary desktop for some time, just waiting for it to stabilize sufficiently for daily business use.

My main interest in KDE was in fact the functionality of KAddressbook which was just unsurpassed. I have been prepared to put up with all the bugs and even the kmail shortcomings because KAddressbook was so good.

I put down 4.4.3 with great expectations only to find no more categories in address book, no tags or well anything really useful any more. Yes it has a new look and feel but now only delivers the same functionality as Thunderbird!

Could you lay out the road map for us please. I caught a bug post mentioning the introduction of tag's .. no date, versions or function description.

If the road map doesn't include the re-introduction of categories, the ability to define them, search and export them to a CSV please consider adding these back in.

Thanks bewildered of Cambridge

Frédéric Boutet said...

Graham: "Yes it has a new look and feel but now only delivers the same functionality as Thunderbird!"

So, let's use Thunderbird then!
I've been using kmail for five years and will leave it now because of putting categories to the trash. I'm just wondering what is a world in which all people and programs have exactly the same functionality.

Unknown said...

Since KDE 4.4 in kubuntu I've desperately been trying to use kaddressbook in conjunction with kmail (what else ? right ?)

* no possibility to 'right click' on a contact to send a mail

* basically impossible to use contact groups/distribution lists to send mails.

I would say these are really the basics. I'd prefer to have this, and wait longer for the rest. Any plan for these features ?

Karl Fasbracke said...

I am not happy with akonadi. AFAICS all I want is an addressbook and what do I get? aknondi and nepomuk and they flood my .xsession-errors. This just does not feel right. Will probably abandon kde altogether.

Karl Fasbracke said...

I am not happy with akonadi. AFAICS all I want is an addressbook and what do I get? aknondi and nepomuk and they flood my .xsession-errors. This just does not feel right. Will probably abandon kde altogether.