On Mon, 2009-08-24 at 03:15 +0100, Chen, Congwu wrote:
Hi,
I have a task to write a "How-to tutorial" for SyncEvolution[1] as
part of the moblin-sdk program[2].
Excellent! Is this something which can co-publish on syncevolution.org?
I found the blog article "SyncML Client Do-It-Yourself
Style" [2]
written by Patrick fits this quite well. I will probably adapt this a
little to fit into SyncEvolution 0.9 API.
Does anyone has suggestions on this?
I think we should replace the 0.9 backend API as soon as possible. In
other words, review and merge the backend-api into master, then after a
short testing/release cycle release 0.9.1 as replacement for 0.9. This
should include everything that was held back during the feature freeze
for 0.9 (message resend!). A revised GUI D-Bus interface would be nice
too, but is risky.
The "do-it-yourself" guide is indeed a good starting point. There is one
major limitation: the guide and the underlying code + make rules are
designed for people who want to build their own SyncEvolution tailored
for their own backends. Backends are not truly plugable.
The changes necessary to fix this are a bit intrusive, but not
particularly risky:
* install libsyncevolution header files in a standard
path: /usr/include/syncevolution/*.h
* change the #include rules inside these .h files so that they use
"syncevolution/" as prefix for all of them, rename "core"
directory to "syncevolution"
* don't depend on config.h in the header files (apps might not
have the same defines in their own config.h)
* install libsyncevolution.la and add a .pc file for it
* scan a directory for backends to open dynamically in
SyncSource.cpp instead of using a hard-coded list (should also
work when running inside the build directory, with backends in
backends/*/.libs)
Is this something that you could do in combination with updating the
guide?
--
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.