I m still waiting to get a stable KDE PIM (4.6) to work on. I currently get
my KDE PIM from Project Neon(for Ubuntu) and Its been broken for the past 2
weeks.(dont know if it was working before that) So couldn't really check
anything out. :(
On a different note, I've contacted the KAddressbook maintainer about the
extensions problem and here is the summary of things:
The "key" is s suppsed to be a unique identifier for an akonadi setup. The
user's akonadi stores the mapping between the "key"s and "title"s.
guess, we can't sync custom fields without an Akonadi <-> Akonadi sync. So
preserving the extensions locally seems to be the best available option.
Also, may be this will be a useful information for us When a vCard
containing the custom field, say "X-KADDRESSBOOK-abcd" s is imported into
another akonadi, in there, the title "abcd" is generated for the given
The Neon Guys promised to get it running by this weekend though.. So may be
I can look into things after that.
On Mon, Jan 31, 2011 at 7:29 PM, Patrick Ohly <patrick.ohly(a)intel.com>wrote:
On Mo, 2011-01-10 at 16:12 +0000, Patrick Ohly wrote:
> > X-KADDRESSBOOK-abc:asdf
> > X-KADDRESSBOOK-abcd:2000-01-01T00:00:00
> > One can actually define the "key" after X-KADDRESSBOOK-*.
> > My Guess is that the key is supposed to be unique (or else all but the
> > data from the last key is wiped out, if the key is of the same
> > "datatype", if the key is of different data type, the data is being
> > reset), because the user can define a "Title" for each field he
> > and assign a "Value" to the title, and KAddressbook will take care
> > the mapping from keys to titles. I will confirm this with the
> > maintainer soon.
> Knowing that would indeed be useful.
Any update? Note that Lukas has implemented support for preserving
arbitrary extensions (see his "luz" branch or the "master" branch on
), but it is not enabled yet in the SyncEvolution
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.