I have had a week of holidays last week, so fixed a few little things in
syncevo , which includes adding all the custom fields, fixing an autotools
problem, and started the work on the GUI myself. I have tested it against
the Ovi servers,
and here are the current problems:
Issues in vCard:
1)The 1st ; in ADR is causing it to leave out address as a blank.... (i
Earth;Planet Earth;Planet Earth;Planet Earth;Home
2) "\" being expanded to "\\" and "," ot "\," in
(not creating any problems though)
e opaque | ,s/mime opaque
3) As expected: the custom vcard fields give a problem , so how do i test
especially these ones which are being sent (more in commit log.)
The other KABC specific vcard fields are staying safe when synced.
Also a strange behaviour is noted with some fields (ADDRESS being replaced
by BDAY , URL being deleted locally, but appearing remotely, EMAIL Replaced
by FN ).
and apart from this, Syncevolution syncs as expected. (verified with
Contacts and Calendar)
I am looking into these issues, but if it is a known bug, please let me
Apart from this, what is remaining is adding support for KJots as the Memo
Application of the KDE PIM.
in here, the issue is the data is of the format:
So how do i approach this ?
Overriding AkonadiMemoSource 's insertIem and readItem, to do the necessary
conversions (something like a bijective function mapping the content of
KJots item to VNOTE type ? ) vs. some other method like the vcard field
lists conversion (if so, please elaborate) ?
also is the vNote depricated or something and should vJournal be used in
"“The vNOTE object defined by the [IRMC] specifications was created because
there was no journal entry capability in the original Versit/IMC vCalendar
v1.0 specification. However, with adoption of the [ICAL] specification
support for the vNOTE in the [IRMC] specification should be deprecated, in
favor of support for the VJOURNAL calendar component in [ICAL]“. So,"
and as far as KDE PIM is concerned,"the journal stuff is deprecated, we
should use the kjot format"
So , going with KJots is safe right?
Also , what else is needed so as to get my code merged with the main
Syncevolution ?(Currently the plan is to release the command line tool first
and later on the the GUI, Sivan ? Rohan ?, along with the Bluedevil
On Wed, Feb 2, 2011 at 1:19 PM, Dinesh <saidinesh5(a)gmail.com> wrote:
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. So i
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
> > > reset), because the user can define a "Title" for each field he
> > > and assign a "Value" to the title, and KAddressbook will take
> > > 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
), 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.