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