It seems that Konversation can't handle akonadi contacts. Reproducible: Always Steps to Reproduce: 1. Right click on a user -> Address Book Association -> Choose Contact… 2. Search for a contact in your kaddressbook (akonadi backend) Actual Results: No contact shows up. Expected Results: The desired contact is displayed. If I add a contact with Konversation (user->Address Book Association->Creat New Contact…). This contact will show up in the above example, but it is not visible in kaddressbook.
Reproduced. This might be related to the deteriorating support for the classic address book APIs in kdepimlibs. Our plan is to port to the new kpeople library in the future.
Testing this again, the above appears to be true in some sense. When creating a new contact via Konversation, it is added to std.vcf in $KDEHOME/share/apps/kabc (where $KDEHOME is ~/.kde or ~/.kde4 depending on distro), which is the classic contact storage location for KAddressBook. It's possible to add this .vcf file as a new address book resource to Akonadi, either via File -> New -> Add Address Book in KAddressBook, or via the Akonadi Configuration section in System Settings. Pick the "VCard File" resource type and navigate to std.vcf, then enable the new address book in KAddressBook. Akonadi and KDE by default don't seem to set up any address book resources, but I assume a user setting up their first address book would probably use the "Personal Contacts" resource these days rather than intuitively above. If std.vcf already exists by the time Akonadi is first used, the automatic first-run Resource Migrator would presumably find and import it, however. As such, this isn't really a bug - it's possible to make Konversation and Akonadi talk to each other by setting up the right resource in Akonadi. However, it would be better if Konversation were more flexible and would e.g. allow the user to select the address book resources to consider, instead of using the outdated classic kdepimlibs API which is locked into operating on std.vcf. As mentioned we're aware of this requirement and plan to address this by porting to kpeople in the future. I'm going to keep this open, but rename it and reclassify it as a wishlist item, to serve as a ticket to track progress on this porting work.
Hi there, this bug has been identified to be related to nepomuk, the semantic searching system in prior versions of KDE. Please note that nepomuk has been replaced by Baloo. I'm going to close this bug due to the use of the new Baloo system. Please do file a new bug for frameworks-baloo if you happen to continue having issues with search.