Re: Merging gio into glib
- From: Alp Toker <alp atoker com>
- To: Alexander Larsson <alexl redhat com>
- Cc: Behdad Esfahbod <behdad behdad org>, gtk-devel-list <gtk-devel-list gnome org>, Havoc Pennington <hp redhat com>
- Subject: Re: Merging gio into glib
- Date: Wed, 14 Nov 2007 11:39:37 +0000
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]