Re: [SyncEvolution] SyncEvolution 1.1.99.2 ready for testing
On Mi, 2011-02-09 at 22:28 +0000, Peter Robinson wrote:
Two issues. First one is easy, is there a source file? :-)
Yes, but I have been hiding it so that people don't start packaging
it ;-)
http://downloads.syncevolution.org/syncevolution/sources/experimental/syn...
Seriously, I'd rather have some folks here on this list test that
version before it gets rolled out to some unsuspecting distro users. The
next version should be suitable for an unstable distro again.
Second one is a query about the libgdbus fork. Its causing me a lot
of
problems in Fedora. There are now a number of packages using the
upstream version including gupnp (which is now used by parts of gnome
3) which is causing problems in Fedora and basically makes
syncevolution unusable in a lot of cases. What are the plans on
getting your patches upstream?
If you talk about the gdbus in glib [1], that is not the upstream of the
code in SyncEvolution. The upstream is the older gdbus from Marcel
Holtmann [2] from the Bluez tools.
Why is the usage of the Bluez gdbus a problem? I thought we had resolved
the name clash by renaming the symbols in the SyncEvolution source code.
If someone has a patch which allows to switch between the Bluez gdbus
and glib gdbus, then I'd be happy to include it. I just don't have time
to do that myself.
Oh and does it have the option to use both gtk2 and gtk3 as
evolution
and e-d-s for gnome3 will require it if you use any of the e-d-s/evo
gui components.
No, there's no support for gtk3. The sync-ui is the only component using
GTK. It's a stand-alone process, so hopefully it'll continue to work
even if the rest of the system moves to gtk3. The EDS backends will need
some work to cope with API changes in Evolution 3.0 - not done yet,
patches welcome :-/
[1] http://library.gnome.org/devel//gio/2.26/gdbus.html
[2] http://git.kernel.org/?p=bluetooth/libgdbus.git;a=summary
--
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.