I've been trying to use Kontact for a number of months, but it always seems to be not in a real usable state. I am currently using 4.6.1 so I thought I'd share a few of my frustrations here in hopes that I could get some simple answers. If you share the same frustrations please leave a comment so that the concerns will be noted.

1. This is a general 'rant' but I don't know how else to address the problem. After using kontact for months/years and then kmail singularly before that, it seems to me that there is a breakdown in coordination between the maintainers of Kontact, KDE/PIM, & the various apps that make up the kontact suite. Kontact aims to be a Microsoft Office style replacement, but even on the KDE Forum under Office & Productivity "Kontact" is not listed as a subgroup? That seems counter intuitive.

2. The relationship between Akonadi, KDEPIM, & kaddressbook seems confused or convoluted. At the least I cannot find clear documentation. There seems to be a lack of communication or understanding between the maintainers of these programs & modules. Please consider the following:

2a: Kadressbook say's that addressbooks will be saved for the local user in ~/.kde4/share/apps/kabc/
2b: Akonadi say's that addressbooks will be saved for the local user in ~/.local/share/contacts/

2c: Akonadi creates a differently named addressbook than does Kaddressbook. Personal Contacts vs. Default Address book. Why? This leads to needless confusion! Can't the maintainers get together and agree on a standard location for data storage? Can't they come together and decide on a default name to minimize confusion? At the very least couldn't the named resource state "Personal Contacts: Created by Anakondi," and "Default Addressbook: Created by Kaddressbook." ??

3. So I imported an addressbook and saved it to "Default Addressbook" because that made common sense to me. When I opened Kontact I then saw two address books available. I never intended to create two. This is needless confusion! And to top it off each of my addressbooks was stored in a different directory as previously noted. Again needless confusion. I deleted both address books then went back to Kontact and "Personal Contacts" was automatically created by Akonadi again. No problem... so this time I entered a few addresses in. They are saved in a database somewhere in my .kde4 directory, but I cannot locate the saved addressbook in either .kde4/share/apps/kabc/ or in .local/share/contacts/

So where is my address book? It is somewhere because the addresses are saved, but I can't find it. Nor can I find documentation on-line that answers any of these questions! Is there a rift in coordination between the maintainers of the various parts of kdepim? Many people stay with M$ because of the M$ Office suite. If it is that important I would think there would be better cohesion between the various entities affiliated with Kontact.

Please forgive me if you think I am ranting. I believe my concerns are valid and to the point.

I found the following resource which confirmed my findings and gave explanation to my concerns in part.

http://userbase.kde.org/Akonadi_and_AddressBook#Examining_your_Resources

Still wonder why Akonadi is so adamant on storing it's data in "~/HOME/.local/ ..." It is strictly a KDE resource, right? So why not keep things simple and store the data in ".kde4/share" ?

I guess my frustration is the same old question everyone has with KDE. Why isn't there better coordination among lead-developers to ensure interoperability between KDE applications?

And in addition to this question I do hope someone will answer my concerns listed in my previous post.

If you read the other pages referenced in that group referring to Akonadi, KAddressBook etc., you might find that you have a better understanding of what is being constructed. To answer a few of your points -

~/.kde/share/apps/kabc/std.vcf was the old addressbook. Kontact now follows the ISO standard by putting data in ~/.local/share/yada

Akonadi is not KDE-centric. It's not even Linux-centric, as it can work with other platforms. It therefore makes no sense to store data in a KDE directory.

You are not adding your resources in the way that is described on UserBase, and that is causing some of your problems. Time to do some more reading.

annew wrote:If you read the other pages referenced in that group referring to Akonadi, KAddressBook etc., you might find that you have a better understanding of what is being constructed. To answer a few of your points -

~/.kde/share/apps/kabc/std.vcf was the old addressbook. Kontact now follows the ISO standard by putting data in ~/.local/share/yada

...ok..... Will the rest of the kde apps also follow this standard, or will we continue to have different locations for storage of data?

Akonadi is not KDE-centric. It's not even Linux-centric, as it can work with other platforms. It therefore makes no sense to store data in a KDE directory.

I was not aware of this. I assumed that Akonadi was developed by a kde-development team and therefore was considered a kde app. Upon review of the Akonadi website http://community.kde.org/KDE_PIM/Akonadi I dsicovered that the mission statement for Akonadi does indeed read:

"We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval."

Just curious what other desktop or environment has shown an interest in using Akonadi? I think Akonadi is a great idea, but I'd surely doubt that another environment gives it serious consideration based upon the difficulties KDE users are experiencing. Come on... time to focus on reality. Akonadi is a KDE app. Developers need to fine tune & streamline Akonadi to better work within the KDE environment before thinking the product is worthy of other considerations!

You are not adding your resources in the way that is described on UserBase, and that is causing some of your problems. Time to do some more reading.

And I thought that all I had to do was install it and start using it... Silly user! I should have known that you can't expect that... That would be to simple and logical! [Sarcasm font!]

Come on! Userbase should be a resource for additional fine-tuning of an app that works as is. Akonadi is not at that point for many users! Userbase should be for tips & tricks... not for proper installation! If I buy a new automobile I don't intend to go to a userbase website to learn how to turn on the radio! It should be intuitive...

If I still had questions I should be able to go to a handbook containing documentation. Well, the documentation included with my distro is the latest published by KDE. Guess what? It's out of date! Big surprise, right? In my example above I am using Kontact and trying to get Kontact/Contacts to work so I pull up the help documentation for Kontact. it was written in 2005!!! There is a link for "the kontact administrator's Guide" so I pull it up. It was written in 2009. The KDE documentation website also shows these files as the most current info. http://http://docs.kde.org/

I shouldn't have to go to the web just to get my address book working correctly, but thank goodness we have that resource. However, the KDE Documents page does not even show a listing or a sub listing for Kontact. Unbelievable! So I had to type it in as an application name and the page comes up. cross-referencing the online docs with those installed on my up-to-date installation confirms that the most recent Kontact docs are from Revision 1.1.1 (2005-09-04).

So I review the Kontact documentation. I invite you to do the same. http://docs.kde.org/development/en/kdepim/kontact/index.html
It lists a link for "KMail -> KAddressBook" clicking on it takes me to a page with a link for "KAddressBook's main window." clicking on it takes me to a blank page. In my installed documentation clicking on that link takes me to a page called "Documentation not Found."

Do I really need to go on...? Ok... I will!

So I'm just a user trying to use his email/contact software... so Kontact doc's are no help. So I go online and on the kde doc's page there is no entry for kaddressbook. There is no documentation for it stored on my system either. There is a link for it, but it too tries to open a web page that is non-existent. So I understand NOW from your post that the KaddressBook is not and will not be the way contact data is stored on KDE now or in the future? Ok... So It's Akonadi now... Where is this documented?

So I go back to KDE's trusty official and up-to-date documentation...

Guess what? Akonadi is not listed under any of the linked choices. again, I invite you to go and see for yourself. http://docs.kde.org So in the "Application Name" search box I type "Akonadi" and it brings up NO documentation...!!!!!

Now how the hell is a typical user suppossed to figure out how to set-up his Kontact address book if he has questions or trouble?

"Userbase" you say?

I did find some limited info there but come on!
Time for me to do some reading...? Time for the team to do some documenting!

Annew, I truly respect what you do here. You are quite helpful, but on this issue it would serve the team well to view the problem through the lense of the average/new user. I hope this is helpful.

Surprised that as of the time/date I am reviewing what I wrote there have been 101 views of this topic yet only 1 reply other than from myself. This is curious. I wonder if I am the only one with this particular frustration; if, just like me, nobody else knows how to 'fix' the issues either; or whether KDE users in general are just apathetic to this particular issue and consider my post primarily a rant?

To self critique some there is a bit of an element of 'rant' in my post. Maybe it's the 'tone' of my comments. Perhaps it's no good to type that kind of thing in the moments following such frustrations.

But there is also quite a bit of truth in what I posted. Curious that at the least none of the developers or maintainers of Akonadi, Kontact or Kaddressbook stepped forward to explain or defend the reasoning behind their contributions?

Apathy?

I'm one of those who (until now) only viewed your issues and rant. I agree the documentation is dated, but being an open source project I'm sure they'll welcome offers to update it.

I'm not here to condone or condemn KDE, but I will say this. I have no expectations beyond what it already does. Do I wish it did more? Of course I do. My wish list is likely as long as anyone else's. If I had more time and inclination to do so I would have helped doing documentation and if my coding skills were beyond using Object Pascal (Delphi in a Windoze environment) I would like to wrap my mind around Kmail et al.

Be that as it may, given my investment in KDE so far, I'm not in a position to ****. I can always jump to Gnome or go back to Winblows (the latter having been paid for).

The specific reason I didn't offer to help initially is simply that after the revelation that I should stop using the old resource files, life with Kontact got better, but the problem is I tried so many things in so many combinations I'm not sure exactly what I did to have it work in it's current state (as compared to when I had issues).

Believe me, if you ask a question that I know the answer to, I would do so without hesitation.

<rant mode off, please deposit additional funds>

Surprised that as of the time/date I am reviewing what I wrote there have been 101 views of this topic yet only 1 reply other than from myself. This is curious. I wonder if I am the only one with this particular frustration; if, just like me, nobody else knows how to 'fix' the issues either; or whether KDE users in general are just apathetic to this particular issue and consider my post primarily a rant?

I came across your post today after trying to figure out where kde 4 stores address book data. I found your post to be very reasonable, and it reflects my own concerns as well. The lack of documentation makes it very difficult to solve problems. (In my case the problem was that all my address book data had disappeared!) Like you, I really appreciate all the hard work developers have done with kde, but I agree with you that ordinary users should not have to do this much digging simply to get an address book to work properly!

mshelby: You said that you had read the UserBase pages, yet you still can't find the addressbook entries? The informationb is all there.

For those that haven't read them - more information from the developers would be welcome, but those pages do have quite a lot. KMail uses addresses from two sources. Recent addresses are stored in kmailrc, and can be edited from the kmail configuration pages. The main addressbook is stored in ~/.local/share/contacts - according to the ISO standard.

mshelby wrote:

annew wrote:If you read the other pages referenced in that group referring to Akonadi, KAddressBook etc., you might find that you have a better understanding of what is being constructed. To answer a few of your points -

~/.kde/share/apps/kabc/std.vcf was the old addressbook. Kontact now follows the ISO standard by putting data in ~/.local/share/yada

...ok..... Will the rest of the kde apps also follow this standard, or will we continue to have different locations for storage of data?

This is very likely. The XDG base dir spec (which among other things specifies ~/local/share as the default for user local application data) came a bit to late for KDE's first 4 series release so legacy locations were being kept.

There are a few other things in ~/.kde that are not yet available in the XDG base dir spec (e.g. path for sockets) but these might be available before the next major release has to decide on locations.

Strictly speaking the personal contacts resource could have used a KDE specific location since it is a KDE program.

I am not entirely sure why the migration path for standard addressbook is done by importing the single file based address book into one-file-per-contact personal contacts since there is a backend handler for single file vcard files available as well.

mshelby wrote:

Akonadi is not KDE-centric. It's not even Linux-centric, as it can work with other platforms. It therefore makes no sense to store data in a KDE directory.

I was not aware of this. I assumed that Akonadi was developed by a kde-development team and therefore was considered a kde app.

Since all current Akonadi developers are also KDE developers I can see how this impression might have manifested. It is, however, quite common that developers associated with one of the larger Free Software desktop projects also form communities to develop infrastructure for desktops, e.g. GStreamer, NetworkManager, etc.

Depending on choice of technology some of these infrastructure projects find developers more easily (or sometimes even exclusively) from the larger community the original team came from.

mshelby wrote:Upon review of the Akonadi website http://community.kde.org/KDE_PIM/Akonadi I dsicovered that the mission statement for Akonadi does indeed read:

"We intend to design an extensible cross-desktop storage service for PIM data and meta data providing concurrent read, write, and query access. It will provide unique desktop wide object identification and retrieval."

Just curious what other desktop or environment has shown an interest in using Akonadi?

There had been some interest from GNOME and Evolution developers at early stages, but as usual politics got into the way ("wrong" choice of technologies). Doesn't rule out that some developer on other Free Software desktop applications want to base their decisions on actual use cases.

mshelby wrote:I think Akonadi is a great idea, but I'd surely doubt that another environment gives it serious consideration based upon the difficulties KDE users are experiencing.

Do you refer to the initial problems with MySQL due to things like distribution interference or difficulties with KDE specific things like data migration?

mshelby wrote:Come on... time to focus on reality. Akonadi is a KDE app.

Akonadi itself, i.e. the Akonadi server, is not.
It does not in any way depend on KDE, only Qt.

mshelby wrote:Developers need to fine tune & streamline Akonadi to better work within the KDE environment before thinking the product is worthy of other considerations!

Agreed, almost all problems orginate from the migration from previous PIM infrastructure and applications not having been migrated yet.

Which of course would independently apply to other applications, since they would have to handle their own migration as well.
It mainly depends on whether two way cached data access is an application's main functionality, which usually means they already have some kind of partially comparable piece of technology in use.

But as with any other infrastructure technology it is often likely that a point is reached where maintaining one's own solution is more work than migrating to a sharedly maintained one.

mshelby wrote:

You are not adding your resources in the way that is described on UserBase, and that is causing some of your problems. Time to do some more reading.

And I thought that all I had to do was install it and start using it...

Sarcasm aside, this is the way it is intended to work and will work for any new setup. Unfortunately migration seesm to be always way more difficult than anticipated and strongly dependent on a user's config and data.

The situation of not enough resources being available to migrate all PIM applications at the same time (not even talking about non-PIM applications using PIM data) did of course not make this any easier.

mshelby wrote:So I understand NOW from your post that the KaddressBook is not and will not be the way contact data is stored on KDE now or in the future? Ok... So It's Akonadi now... Where is this documented?

KAddressBook has not been the way to store contact data since early KDE 3 series days (might even not have been in KDE 2 series, but I can't remember).

Akonadi is replacing (among other things) the contact data access framework being used by KAddressBook and other applications.

KAddressBook remains to be the main user interface for contact data, though separation of contact related components (even UI) makes it more viable now to create alternative means of contact handling.

Cheers,
_

Just wanted to say to anda_skoa, thank you for the insightful replies! I still have issues with the coordination between developers regarding the migration issues you mentioned. Just seems like akonadi dev's are in their own little bubble. Were they exiled there or are they there by choice?

Anyway, As far as KDE goes, from what I can see kontact is the suite that utilizes Akonadi most for my desktop -so I still say that those two teams need to work more closely together.

People stick with the M$ product in part because of it's great M$ Office & Outlook suite of products. KDE would do well to remind themselves that Kontact is the closest thing KDE has to approaching Outlook. It should be one of the cornerstone apps for the KDE desktop. Right now it's not. It really is counter-productive to use it even though it clearly offers so much promise.

My observations were an attempt to say that it appears the various kontact devs seem to have decided it's time to deliver the kontact "vehicle" (to use an analogy) to the public 'as is' when really two out of four tires are still flat! Happy driving! You just can't sit in the vehicle and say 'my how nice these leather seats are' and 'gosh, I bet everybody would love the way my stereo fine tunes itself' etc... etc... those things are nice, but they'll all be left in the dust if you can't really drive the thing where you want it to take you!

If the kontact dev's aren't careful the ideas and innovations put forward will end up on the ash-heap of history along with other great ideas that never really went anywhere.

C'mon devs... give me an email suite that does the basics well! Give me a workable addressbook for gosh sakes! Gimmie, gimmie, gimmie....! (stamps feet like a two year old.)

mshelby wrote:Just seems like akonadi dev's are in their own little bubble. Were they exiled there or are they there by choice?

There is actually quite an overlap, which incidentally doesn't help very much when it comes to human resources.

mshelby wrote:Anyway, As far as KDE goes, from what I can see kontact is the suite that utilizes Akonadi most for my desktop -so I still say that those two teams need to work more closely together.

Obviously Kontact as a groupware suite (or its individual applications) is the main user of a framework initially conceived to handle PIM data.
It also had to be ported first in order to serve as a starting point for other application developers, i.e. so they can check some reference code when pondering ideas or implementing them.

If you follow the blogs in planetkde.org you'll occasionally see entries about other use cases, e.g. Christian Mollekopf's recent one about his note/todo managment prototype or Sebastian Kügler's Lionmail Plasma applet.

The separation of backend access from user interface has already numbers of developers working on backend access (i.e. not requiring developers with backend know-how to dive into quite complex UI code) and will hopefully have a similar effect on UI side of things.

Since there quite some different backends have already been implemented and shipped, developers in this area had this advantage of somewhere to look for answers themselves, while this will only become viable for UI side developers in the near future.

As a result the positive impact has up until now mostly benefitted behind-the-scenes developers or developers working on prototypes or research projects.

mshelby wrote:My observations were an attempt to say that it appears the various kontact devs seem to have decided it's time to deliver the kontact "vehicle" (to use an analogy) to the public 'as is' when really two out of four tires are still flat! Happy driving! You just can't sit in the vehicle and say 'my how nice these leather seats are' and 'gosh, I bet everybody would love the way my stereo fine tunes itself' etc... etc... those things are nice, but they'll all be left in the dust if you can't really drive the thing where you want it to take you!

Well, aside from the fact that car analogies never really explain IT concepts closely enough, the situation is rather a fully function car but with manual-only transmission with limited gears, fixed mounted seats and not extras.
Automatic transmission and adjustable seats coming shortly though

mshelby wrote:If the kontact dev's aren't careful the ideas and innovations put forward will end up on the ash-heap of history along with other great ideas that never really went anywhere.

Possible but not very likely. The used technologies have already showns to be viable for deploying smart client groupware software on something as foreign as a Windows CE smart phone.

Cheers,
_

So, could somebody please give us a short answer and clear instructions? Where and how we should save our contacts?

I like kmail very much, but such small and annoying problem makes me thinking about something like gmail.

Please read http://userbase.kde.org/KAddressBook and the pages linked from there. Once you understand the setting up of resources you will find your addresses migrated to ~/.local/share/contacts.

Thank you. This seems clear now.