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:
> 
> >  Hello,
> > 
> >  There were some discussions here and on 
> > gtkfilesel-devel@lists.sourceforge.net about the API of new filesel widget.
> > Here I propose API I designed, with idea of hooking arbitrary filesel "engine"
> > in mind. This API doesn't make any assumptions on the widgets that are in the 
> > filesel window (thus it allows arbitrary file selectors, like nautilus' view
> > or selector present in current gtk-1.2) (well, both mentioned candidates won't
> > select multiplie file selection, but can be easily used for single file
> > selection). 
> > 
> >  I'm open to your ideas on this topic.
> > 
> 
> 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)?
 
> [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.
 
>  - Maciej
> 

 Best regards,
  -Vlad