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