Re: gnome desktop integration library

[Federico Mena Quintero <federico ximian com>]

On Tue, 2006-09-05 at 13:45 -0400, Havoc Pennington wrote:

> This has never made sense to me - what would be not able to go in gtk or 
> other appropriate lib? There just isn't anything. I'd say the definition 
> of gtk is an API for writing GUI apps. So if something is usually needed 
> to write GUI apps, gtk should have it, or something is busted.
> 
> http://live.gnome.org/ProjectRidley breaks out these "B" and "C" 
> categories of X or GNOME specific stuff; I don't think that is a good 
> way to break it down. If a general-purpose app really needs particular 
> functionality, gtk has to provide some way for the app to do it, 
> cross-platform or not. There's a gdk/gdkx.h for a reason, and the file 
> selector can backend to gnome-vfs for a reason.

There's no reason to have a library separate to GTK+.  I agree with
that.  We do need to consolidate the gnome-ish stuff into GTK+ proper.

However, we need to *finally* bite the bullet and do something about the
two big problems in the base platform:  GConf and Gnome-VFS.  We haven't
put them under the GTK+ umbrella for semi-good reasons which turn out to
be semi-bad excuses in the end (sucky API?  clean it up already!  not
documented?  write the goddamn docs!  CORBA?  do you even care that it
is an implementation detail?).

[I hate myself for having had to add a custom way to save settings to
GtkFileChooser, and that way is *not* GConf simply because I can't use
it.  And I definitely hate having to maintain both GtkFileSystemGnomeVFS
(the one I care about), and GtkFilesystemUnix (for the three people who
want to run GTK+ by itself).]

[This is also a good excuse to start deprecating the POSIX-y stuff in
Gnome-VFS, leaving in place only the meaty stuff like
GnomeVFSVolumeMonitor, the URL-mangling utilities, etc.]

> Another way to put it: there's no possible objection to putting stuff in 
> gtk that doesn't also apply to putting stuff in a public GNOME platform API.

At the risk of sounding bureaucratic, I think this is the perfect time
to lay down some hard rules on what can make it into the GTK+/GNOME
platform library:

1. API/ABI stable, documented, etc.

2. No new major API can go in unless it is used by three apps.  This
lets us ensure that the API is good and that it is generally useful.  

A consequence of (2) is that we need a staging area for APIs that are
not folded in yet.  Libegg was a nice experiment with disastrous
results.  I don't really know what to do about this.  I do think that
*not* letting apps in the desktop suite use unstable APIs is a good
starting point.  They are free to use all the experimental stuff they
want in their development branch, but the stable branch must only use
the platform libraries.

Maybe we can have an experimental/ directory under the GTK+ source tree,
or some #define GTK_I_REALLY_WANT_TO_USE_UNSTABLE_CRAP.  In any case,
apps in the desktop suite should not be allowed to use unstable APIs
until they are moved into the main platform.

This is to prevent upgrades from giving you software that doesn't work.

  Federico