I'm testing KDE 4.4 beta 1 and I lost all my contact in Kontact.

The file still is there with data in ~/.kde4/share/apps/kabc/std.vcf but I don't know what must to do to see it.

I tried "Add address book" option but unsuccessfully.

Any solution to this problem?

Solved, I don't know why but there are two akonadi running so I kill both, delete akonadi folder, run again Kontact and problem was solved.

As I can see, Akonadi starts when I run Kontact but don't stops when I shutdown it. A bug?

On the other hand, Akonadi uses a lot of memory only to manage my contacts and can't be disabled like in KDE 4.3. I'm not sure if this is a good idea because Akonadi is not finished, I not interesting at all in the functionalities that offers me, probably other people has the same opinion, and I'm really happy with old easy to read text files.

I notice a tendency among the developers of KDE 4 in forcing users to use certain technologies without alternatives. I think that this is not a good idea when old methods works fine and new are plenty of bugs or don't works.

Akonadi is started automatically whenever an application needs its services. It stops when the KDE session terminates.

Akonadi will be used far more extensively in KDE 4.5, since many of the application ports will be arriving then.

You can use the command "akonadictl stop" to shut it down, however make sure that any Akonadi using applications are shutdown first.

bcooksley wrote:Akonadi is started automatically whenever an application needs its services. It stops when the KDE session terminates.

Akonadi will be used far more extensively in KDE 4.5, since many of the application ports will be arriving then.

You can use the command "akonadictl stop" to shut it down, however make sure that any Akonadi using applications are shutdown first.

I see that command in documentation but, this not disable Akonadi because when I run Kontact Akonadi starts again.

I don't try to be boring because I done the same question many times before in other post but, if Akonadi will be used far more extensively in KDE 4.5 why we are forced to used a partial version in KDE 4.4 and eat a lot of resources to do a simple task?

Seems like KDE developers don't learn too much with past Nepomuk problems and persist in doing the same mistake again with Akonadi, and I stop here to avoid off-topic.

The command I provided temporarily shuts down Akonadi, and does not disable it in any way.

The reason why Akonadi must be used now is because the PIM team does not have sufficient developer power to port all the applications in one release period. The porting is being done in a branch in KDE SVN and all bug fixes they make have to be applied to both trunk and the branch, which is not easy to do.

As a result, to reduce the maintenance cost of this branch, and to commence the migration of data into an Akonadi based system, KContactManager ( which was slated for inclusion into KDE 4.3, but wasn't fully complete at the time ) was merged into KDE 4.4, to replace the aging KAddressBook which simultaneously put Akonadi into real use, and solved many feature requests and bugs that were present with KAddressBook.

bcooksley wrote:As a result, to reduce the maintenance cost of this branch, and to commence the migration of data into an Akonadi based system, KContactManager ( which was slated for inclusion into KDE 4.3, but wasn't fully complete at the time ) was merged into KDE 4.4, to replace the aging KAddressBook which simultaneously put Akonadi into real use, and solved many feature requests and bugs that were present with KAddressBook.

I understand the problems of developing and available hands, sometimes things like these happens in my job, but you don't answer my question. I'm asking about forcing users not about the reasons to add a partial Akonadi in KDE 4.4 because I could imagine by myself.

Maintain the old code of KAddressBook in Kontact, basically a kparts application, don't seems to be a very complex task and take the users the last decision to test or not Akonadi would be more polite with users.

I do not know why the PIM team didn't follow that path, likely because the benefits in terms of new features / bug fixes inherent in a rewrite outweighed any percieved negatives. Note that they do not percieve Akonadi as a negative, but as a positive.

Also, they probably wish to adjust users to having Akonadi present, and use it to discover and fix bugs so that KMail, etc. will have a rock solid system underneath to power them.

bcooksley wrote:I do not know why the PIM team didn't follow that path, likely because the benefits in terms of new features / bug fixes inherent in a rewrite outweighed any percieved negatives. Note that they do not percieve Akonadi as a negative, but as a positive.

I hope that is true because if they perceive as negative we have a problem .

bcooksley wrote:Also, they probably wish to adjust users to having Akonadi present, and use it to discover and fix bugs so that KMail, etc. will have a rock solid system underneath to power them.

Yes, I think that was the true reason but, at least for me, I beginning to get tired of that force me to be a guinea pig. Sometimes I want to be one, I'm testing KDE 4.4, but other times I need a working and stable application and I like take this kind of decisions myself.

I wait and see but, in my case, I think that will pass the same with Kontact than with Konqueror, I will stop using it because I don't want an unstable application in my daily basics.

I don't know all the details but it might have been possible to release two address book application.
Not that this would make it any easier for anyone, certainly not for any person doing user support

Since all libraries are backward compatible, one could run an older version of KAddressBook instead of the new one.

It is indeed annoying that KAddressBook is the only application available for Akonadi use. KOrganizer has been heavily worked on but didn't make it in time for feature freeze.

Cheers,
_