Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

Federico Mena Quintero wrote:
> I think you and Havoc agree on everything, *except* for "what stuff can
> GTK+ depend on?".

Part of it is that I think there are degrees of dependency. Here are 
some cases:

 - Hard cross-platform API dependency - the dependency is in the GTK
   headers on all platforms.
   e.g. Cairo, Pango.

 - Hard single-platform API dependency - e.g. Xlib, due to gdk/gdkx.h

 - Soft library dependency (cross-platform or single-platform) -
   the dependency is not in  pkg-config --libs gtk+-2.0,
   but GTK links to it. Dependency could in theory be removed.
   e.g. libpng.

 - Soft library dependency with side effects - e.g. D-Bus might
   be like this. This happens if the use of a library isn't
   "invisible" to the app, I'm not sure if D-Bus would be, though
   it potentially could be if handled carefully.
   If there are side effects of using a lib, then potentially
   those side effects become part of the ABI.

 - Runtime dependency - GTK dynamically dlopen()'s the lib
   if present. No current examples AFAIK.

 - Module dependency - the dependency is in a GTK+ module,
   which gnome-session or something arranges to load.

 - File or protocol dependency - GTK+ looks for and parses some
   file it expects some other app/desktop-component to write,
   or talks to some component via a protocol like XSETTINGS.

 - Out-of-process dependency - have a helper process that e.g.
   connects to D-Bus or the session manager and talks to
   GTK via pipes; this is a way to use another library/service without
   bringing it into the application's address space.

Using these creatively is one way to get stuff into GTK+ and keep app 
developers from having to write their own #ifdef GNOME hell.

For example, if there were a library that just installed all the gtk 
"hooks" for help and so forth, I'd expect that library to have one function:

void gnome_install_gtk_hooks(void);

This is an obvious candidate for being a gtk module that GNOME arranges 
to load into all GTK apps, since it has no actual API, it just needs to 
be loaded and initialized.

Take the D-Bus example - I see no reason GTK needs D-Bus in its headers 
in the way it has Cairo in them. It would just be pointless cruft.
So if you proposed that in bugzilla, I can imagine the GTK maintainers 
saying "we don't want a D-Bus dependency."

But, if GTK had a "GdkSession" interface or something, I don't see how 
it's rocket science to implement it. I mentioned a number of ways to do 
it in my big list o' kinds of dependency just now.

The basic path forward I'd suggest is to use some of the softer kinds of 
dependency I mentioned to take advantage of gnome-vfs/gconf as required, 
and consider introducing harder dependencies on vfs/configuration libs 
if someone creates less hosed vfs/configuration libs.

Right now lots of app authors are hand-rolling the soft dependency 
flavors anyway, the #ifdef GNOME syndrome. But nobody wants to have to 
do this.

Havoc