On Wed, 2011-01-05 at 12:13 -0500, Matthew Barnes wrote:
Yes, but I'll write them. They're nothing more than a bunch of
GObject properties with simple get/set functions. The marshalling of
those values to and from key files is all handled transparently by
ESource.
Writing those classes is
On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote:
The cleanest and most obvious solution is to install the backends into
separate address book and calendar directories, then have each factory
process load from the appropriate directory.
This will require a few API changes to the
On Tue, 2011-01-04 at 15:00 -0500, Matthew Barnes wrote:
That means e-addressbook-factory is loading calendar backend modules
and e-calendar-factory is loading address book backend modules. Until
now that hasn't been a problem: the foreign backend classes are
registered but remain dormant.
On Wed, 2011-01-05 at 13:17 +0100, Milan Crha wrote:
are you sure they are kept in memory? I see the factory calls
Yes, GTypes are registered permanently whether the class is loaded
statically or dynamically. This isn't about class instances.
Do you mean you are returning from the backend
On Wed, 2011-01-05 at 08:25 -0500, Matthew Barnes wrote:
Both the backend factory class and the ESource extension types have to
be registered with g_type_module_register_type(), and the GTypeModule
isn't available from the class init function.
Here's the workaround I'm currently having to add
When we moved E-D-S from Bonobo to D-Bus we split the address book and
calendar services into separate processes. But we're still installing
all the backend modules into a common extensions directory.
That means e-addressbook-factory is loading calendar backend modules and
e-calendar-factory is
