Re: GnomeVFS backend for GtkFileChooser

[Havoc Pennington <hp redhat com>]

On Thu, 2003-10-30 at 05:34, Jeff Waugh wrote:
> <quote who="Alexander Larsson">
> 
> > > What do people think?  Or does it make better sense to put this into
> > > libgnomeui [which is getting deprecated too fast for my taste, but...]
> > 
> > Can't we put the GtkFileSystem interface in glib or something, then
> > gnome-vfs can have the implementation without depending on gtk+?
> 
> (If that's doable, it would totally rock the casbah.)
> 

Why would we do this though, purely to rearrange the jhbuild build
graph? I don't see any other advantage. It doesn't make sense;
GtkFileSystem is the plugin API for GtkFileChooser, it has no other
purpose. So it logically belongs with GtkFileChooser. The
gnome-vfs-subclass of GtkFileSystem is a runtime drop-in plugin for
GtkFileChooser that enables gnome-vfs usage, so it logically belongs in
gnome-vfs or gtk+ as those are the two things it's related to. None of
this makes sense in GLib, as it's hugely GtkFileChooser-specific.

Who gives a crap if you have to build gtk+ before gnome-vfs? In fact
"jhbuild list" shows that gtk+ already builds before gnome-vfs.

The foo/fooui library splits were done to allow apps to avoid relying on
an X connection, or linking to all the X/GTK+ libs if they aren't GUI
apps. But what we're talking about here has nothing to do with that.
It's simply an issue of the build graph. And there are no requirements
on the build graph other than "no cycles"

Havoc