Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

Federico Mena Quintero wrote:
> 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?).

Agreed wholeheartedly. These two APIs are good enough that nobody wants 
to fix them and bad/wrong enough that nobody wants to be stuck with them 
forever. (panel-applet is also somewhat in that category IMHO, though 
it's a more special-purpose thing rather than something all apps want.)

Don't know the solution; maybe some kind of hacky wrapper that provides 
the most basic features of the API while walling off the current messy 
implementation, I don't know. Or hey, someone could just fix the 
things... as I like to mention every year or so I did document the 3 
important items to fix in gconf ;-)
http://www.gnome.org/projects/gconf/plans.html

Could probably be done in a month or less.
Fixing gnome-vfs is a lot harder and less well-defined though...

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

In fact (see my blog) I was just suffering since gnome-vfs still has the 
crappy low-level POSIX interface to backends, vs. something sanely 
high-level where one can do high-tech stuff like provide icons for files...

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

People like to rag on libegg, but I'm not sure cut-and-paste code that 
also lives in a canonical central repo is worse than code written from 
scratch in each app. Meaning, people seem to feel that if two apps have 
the same code cut-and-pasted, that is worse than two apps having code 
that does the same thing, but not cut-and-pasted. I'm not sure that's true.

Neither is as good as a shared lib, but shared libs do have a 
maintenance cost and every app is going to have to reinvent a few small 
wheels, it's not the end of the world. In the end shared libs are only 
worth it if they are of relatively general interest, and there's someone 
with time to do a _good_ job maintaining the shared lib. Sharing too 
much can be a negative that gives the whole codebase rigor mortis.

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

Seems worth a shot.

Havoc