On Mon, 2015-12-21 at 20:45 +0000, Emanoil Kotsev wrote:
>> May I ask for your opinion please - what would be the steps
or send me
>> web links to docs as I'm getting lost in the documentation?
>Depending on the kind of PIM storage you need to interface with you need
>to implement different interfaces. Most storages support
>importing/exporting items in a standard format (like vCard or iCalendar)
>and offer some kind of item listing. The TrackingSyncSource is a good
>base class for this and comes with full documentation of all virtua
>methods that one may have to implement.
TDE is the former KDE3 project. I'll need to have a look into the
details on the interfaces, but it looks possible.
I don't know how far back KCal goes, but perhaps at least that API is
>> 1. Is there a way to sync with TDE without writing backends
>> I ask this in the bluetooth/usb context.
>I don't know what kind of storage TDE supports. It's likely that you
>will have to write a backend for its PIM API.
Thanks I had a look in the past days just to find out that new bluez5
works much different (and perhaps better), but still could be the real
SyncEvolution interfaces to Bluetooth via libopenobex, which talks
directly to the kernel. That part should work right away, also with
>> 2. Where do I start and what process should I follow to
>> code into the build and in the gui?
>Backends get detected automatically when placed in src/backends, so just
>copy-and-paste, modify, then re-run autogen + configure + make.
Oh, thanks, however I have seen some checks and options to
disable/enable KDE4+ and Gnome linking in the code (I got from git).
So the question was more about how could I disable nearly everything
else except for what I want to test. Is there any (documented) process
on how to modify or just hack the automake files
Once you ran autogen.sh, the resulting configure has enable/disable
options for all backends. There's no need to change the autotools source
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.