Archive for July, 2006

Continuing adventures of bonobo and gnome-vfs

Friday, July 7th, 2006

After some discussion with Michael Meeks about yesterdays post we decided to move the problematic gnome-vfs functions to libbonobo, so that we can totally avoid bonobo in gnome-vfs. This is ok, since these functions are useless unless you use bonobo yourself, so you’ll be linking to libbonobo if you use them. In fact all old apps are guaranteed to do this since gnome-vfs pulled in libbonobo.

So, what happens is that the function declarations are in the gnome-vfs headers, but the actual implementation is in libbonobo. This means we can now push gnome-vfs much lower in the gnome build stack. It now only depends on glib, dbus, gconf and libxml.

There is only one minor issue. Since we don’t want gnome-vfs to depend on bonobo I had to remove a bonobo include from the gnome-vfs headers. Its likely that apps that use these functions already include this header, but if they don’t they can just add that include, or define GNOME_VFS_INCLUDE_BONOBO to make gnome-vfs include it. The only application in Gnome that uses these functions is evolution, and it didn’t need any modification to keep building.

Bonobo support method: dlopen

Thursday, July 6th, 2006

Earlier today I landed the dbus-vfs branch to gnome-vfs HEAD, which uses dbus for all communications with the gnome-vfs daemon. Also, gicmo moved the gnome-vfs monikers into a separate module, so we’re ready to remove bonobo from gnome-vfs now. Unfortuntately the gnome-vfs API has these calls in the public API:

Bonobo_ServerInfo * gnome_vfs_mime_get_default_component (const char *mime_type);
GList *             gnome_vfs_mime_get_all_components    (const char *mime_type);

This is unfortunate for two reasons. First of all it calls bonobo, so we have to link to and initialize the bonobo libaries, even if most gnome-vfs applications never ever call these functions (only evolution currently uses it). Secondly, the dependency on bonobo at buildtime puts gnome-vfs at a higher level in the build chain than we would like.

To solve the first problem I added some code to (optionally at build time) lazily dlopen and initialize bonobo only when needed. This means applications don’t have to link to bonobo when they don’t use it, but bonobo is still required at build time. (Check for the “Bonobo support method” output from configure.) Its slightly better, but ideally we would just not depend on bonobo at all.

I wonder if it would be possible to move these functions into libbonobo instead (they don’t really call any other gnome-vfs functions, not do they use types or data provided by gnome-vfs). That way we could totally avoid these problems.