Re: proposal of GtkFileSeletion replacement's API

[Maciej Stachowiak <mjs eazel com>]

Vlad Harchev <hvv@hippo.ru> writes:

> On 3 Sep 2000, Maciej Stachowiak wrote:
> 
> > 
> > You go to a lot of trouble below to specify an interface between the
> > file selector and the file selection engine, but since the engine does
> > all the real work and all the real display except for drawing the
> > window itself, this seems like overkill. Why not make
> > NautilusFileSelection an abstract class and have subclasses which
> > implement the exact same API with whatever widgetry they desire, some
> > calls to register the concrete subclass to use, and have a
> > gtk_file_selector_get() call which instantiates the current preferred
> > subclass? It seems like that would be much simpler conceptually and
> > involve a lot less code.
> 
>  Hmm, I don't fully understand your idea. How subclasses will be able to
> support the same API without using virtual functions (as used in my approach)?
>

All the file selector API calls should use virtual functions, however,
there is no need to introduce the additional "engine" class or the
interface between it and the file selector. You are inserting layers
of complexity for no apparent reason.
  
> > [snip 400 lines of specification]
> > 
> > While this spec looks OK for being able to plug in your choice of
> > widgetry, it doesn't look to me like it would be able to handle a
> > gnome-vfs based file selector very well, since the interfaces assume
> > filenames (it would be rather evil for some engines to return
> > filenames to apps and others to return URIs).
> 
>  Since this filesel should work for plain gtk apps, without dependancy on
> gnome-vfs. I think nothing prevents file engines to return URIs if they know
> app support them. App can tell engine that it supports URIs (and wishes to
> handle URIs) by, for example,
> 	gtk_object_set_data(GTK_OBJECT(file_selector),"-gnome-vfs-ok",
> 		GINT_TO_POINTER(1));
> Theme will then check the value of that key on "-gnome-vfs-ok" on the widget
> (using gtk_object_get_data) when deciding whether to dig into vfs. That
> gtk_object_set_data can be called by the libgnomeui glue, I think. And, if the
> app sets that key, all signal handler it installs should be gnome-cfs aware,
> and IMO everything will work fine since even in URI there is a filename part
> and the rest (can be considered as directory name). So, I don't see any
> problem integrating with gnome-vfs.

Your gtk_object_set_data suggestion is about the most horrible API
kludge idea I have heard in a long time.

I think that a nautilus-based/enabled file selector will probably
require a different API, though, so I wouldn't worry too much about
this point.

 - Maciej