Re: proposal of GtkFileSeletion replacement's API

[Maciej Stachowiak <mjs eazel com>]

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.

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

 - Maciej