Re: gnome desktop integration library
- From: Havoc Pennington <hp redhat com>
- To: Federico Mena Quintero <federico ximian com>
- Cc: Rodrigo Moya <rodrigo gnome-db org>, Vincent Untz <vuntz gnome org>, Control Center List <gnomecc-list gnome org>, desktop-devel-list gnome org, Mark McLoughlin <mark skynet ie>
- Subject: Re: gnome desktop integration library
- Date: Tue, 05 Sep 2006 17:21:45 -0400
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.
] [Thread Prev