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