Re: Merging gio into glib



Alexander Larsson wrote:
On Wed, 2007-11-07 at 16:18 -0500, Behdad Esfahbod wrote:
On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote:
glib would need dbus as a build requirement for this to work (needs the
dbus types), and the glib header for the function would have to be
separate (with a separate .pc file for it) so that it can include
dbus.h, but it would work, and avoid an extra library. And if you squint
and ignore the implementation details it would be quite easy to use.
Just link to glib and dbus, then call the function.
Assuming the scheme I wrote about in my other mail, this is nothing
different.  Yet another glib module.  Lets call it gdbus.  By default,
glib build will put it in a separate .so, same for gthread, probably
gmodule, and any other glib "module" that has external dependencies.
But there will be configure options to build them all in one .so, or
build them all separately, or add/remove on a one-by-one basis.  What's
the problem afterall to have libglib.so depend on dbus on fedora?  It's
the distributor dealing with the headache.  It's transparent to
applications.

It will mean that applications linking to libglib will suddenly pull in
more dependencies however. Thats not something that really happens with
e.g. gobject, and for gmodule the extra library is from glibc.

For instance, isn't glib used on the Fedora initrd these days? That
would mean we'd have to add dbus to the initrd too.

Alex, this topic seems to become popular again every few weeks, and will probably keep doing so until work is started on some kind of real libgdesktop module.

GTK+ is used by applications and platforms that don't support libdbus fully (Win32), use alternative D-Bus implementations (Java, CLR) or provide completely different IPC systems. GTK+ is used in many contexts outside of GNOME, some of which we will never hear about, and D-Bus is often inappropriate for these users.

It's not just the dependency that's inappropriate, but also the features D-Bus is intended to provide. Things like FreeDesktop Notifications, settings/registry systems and screensaver suppression are great for GNOME, but are handled very differently in other GTK+-based platforms. GTK+ is universal, while these features are basically specific and tailored for GNOME desktop (and maybe Xfce). They aren't even necessarily the best choice for lighter GNOME Mobile systems.

I'm not making these comments because I have some kind of issue with D-Bus, Notifications or anything else. Quite the contrary, the D-Bus library I maintain is used by more than 30 applications, many of them part of GNOME. The Freedesktop Notifications library I co-maintain is deployed pretty widely too.

So yeah, basically libdbus-based functionality needs to go into a libgdesktop library unless someone can offer a very compelling technical reason why it should go into GTK+ proper. Note that psychological resentment to having a new "libgnome" is not a good justification.

libgnome must die, but it is going to need a successor.


(PS. It was suggested that the GNOMEy features proposed for GTK+ could be made a configure option. Indeed, there is precedent for conditionally compiled platform-specific API like gdkx, which provides a handful of entry points to access the underlying windowing system. I don't think that making large chunks of high level API a configure switch is a sensible direction for a portable toolkit.)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]