Re: Merging gio into glib

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-14 at 11:39 +0000, Alp Toker wrote:

> 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.

I'm not sure how exectly you connect this to gio merging. GIO doesn't
directly link to dbus, it just exposes APIs for handling files, and then
the gvfs implements these APIs via a dynamically loaded module (that
uses libdbus).

So, I assume you're talking about the dbus/glib mainloop integration
library havoc mentioned. (Because if you think gvfs should use some shim
to allow you to replace the dbus implementation you're out of your mind.
It uses libdbus in very complex and specific ways which is highly
unlikely to work with other implementations, and anyway the shim would
be far to complicated.) 

I do think that we should try to avoid linking libglib itself with dbus
directly, however we should make it as easy as possible to integrate
with the glib mainloop.

> 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've seen you campaining about this before, and I must say that I
totally disagree. I think Gtk+ needs to be a solid platform for what
"normal" UI applications need. This includes things like "disable
screensaver", which e.g. a presentation app or a movie player really
needs, and also things like stored application settings and (although
maybe less important) displaying notifications to the user. Now, clearly
the API should not expose dbus, nor would the implementation on win32
use dbus (so I don't understand why you bring up win32 portability?).
But there really needs to be a simple API for apps to do this. 

In no way does it make sense to force apps to link against some other
library in order to do useful things like this (especially if the reason
is some weird lowlevel implementation detail). Not only does that
increase API complexity, it also means Gtk+ itself can't use these
features where it needs them (e.g. some widget might need to disable the
screensaver while doing something).

I see you played the mobile card too. I think that is totally bogus.
First of all dbus is pretty light (and is heavily used by current mobile
players), and secondly they control how they build their gtk+ libs. If
they need a different implementation of screensaver inhibition, or if
they just want to stub it out that is very easily done. In fact, such a
patch could go upstream and be easily selected using configure switches.

> (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.)

It would be totally bizzare to make the API itself conditional, and
nobody sane would ever propose anything like that. However, the
implementation of an API can easily be pluggable (at runtime or
buildtime), and in many cases conditional (if for example your desktop
doesn't support screen saver inhibition a stubbed call is fine, and
requires no ifdef crap in the app).