[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Merging gio into glib
From:       Alp Toker <alp () atoker ! com>
Date:       2007-11-14 11:39:37
Message-ID: 473ADE79.2070709 () atoker ! com
[Download RAW message or body]

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.)
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]