Re: gnome desktop integration library

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 ;-)

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]