Re: proposal of GtkFileSeletion replacement's API

[Vlad Harchev <hvv hippo ru>]

On 3 Sep 2000, Maciej Stachowiak wrote:

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

 Hmm, probably you are right - GtkEditable is designed this way. The only
advantage of the use of engines is ability for them to relay to use another
engine if the current default engine decides that another engine will be
better for that particular set of options (for example, when multifile
selector is requested). But probably with some tweaks it will be possible to
provide such functionality of relaying to other subclass for subclasses.
   
> > > [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.

 Window managers and DND works this way in X..

 To smooth the ugliness, we can introduce global 'GtkData
filesel_global_options;' public "variable", so app will be able to 
     gtk_object_set_data(GTK_OBJECT(filesel_global_options),"-gnome-vfs-ok",
             GINT_TO_POINTER(1));
only once (or it will be done in gnome_init()).

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

 Doesn't it fit into API proposed by me that much?

>  - Maciej
> 

 Best regards,
  -Vlad