Re: Thinking about GtkFileSystem

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-03-14 at 05:48, Michael Meeks wrote:

> > This is going to be a semi-public API .. that is
> 
> 	Great; hopefully it being inside Gtk+ will stop people from re-using it
> in silly places as well.

I think that if we don't have any way to _load_ the URIs that
you get, and restrict it to strictly the stuff that GtkFileChooser
needs, that will pretty much kill silly usage.

> > I'd really appreciate feedback from people with experience
> > with GnomeVFS as to whether this looks reasonable
> > to write a GnomeVFS backend for, and whether it will work
> > in the slow-filesystem case.
> 
> 	I just read the nautilus code for this; some notes on how to untangle
> that for others to read:

[...]

Thanks for the summary.

> >  - Listing the roots of a multi-rooted filesystem. 
> 
> 	I'm slightly confused by the multi-rooted nature of all this, what
> particular application is that for ?

See:

http://people.redhat.com/otaylor/fosdem2003/file-selector.html#multiple-roots

Basically:
 
 - Usability ... make /home/otaylor and / separate roots
 - Windows
 - Network browsing .. make smb: a root of the file system

> > I think it's probably better to do this detailed mirroring in
> > GUI code...
> 
> 	That seems best to me; Nautilus of course passes the (substantial)
> NautilusFile (which is also a NautilusIconData incidentally) object
> around, thus keeping the data singly, while referring to it in both
> NautilusDirectory and the icon view. Is there really a need to have
> anything but a master GtkTreeModel into which this data is shoved ?

There are a lot of possible ways of implementing the
TreeModel/FileSystem interface ... a few that occur to me:

 - Use a GtkTreeStore to store all the data we cache from
   the file system, use EggModelFilter to select out a
   folder to show in a list view. (Q: I know EggModelFilter
   can re-root a GtkTreeModel ... but can it make a folder
   with children that are folders look flat?) 

 - Write a custom GtkTreeModel that exports a single
   folder from our custom data data storage.

 - Use a completely custom data storage, just fill into
   a GtkListStore to display a list view.

I'm not sure I can say what is the right way without trying
to implement it.

> > For remote network filesystems, incremental filling of 
> > directories is interesting. Hopefully we can simply use the
> > change-notification mechanism to accomplish this. 
> > Considerations:
> > 
> >  - It means that we can only do incremental filling for
>  >    directories that are currently being monitored.
> 
> 	What is the purpose of monitoring, and/or how will the user be shown
> that loading is underway / completed  vs. eg. FAM monitoring changes ?
> or am I confused ?

Monitoring here is still a bit of a vague concept, but basically
I'm thinking that we can combine three things together:

 - FAM style change notification. I think it is important
   to be able to have this in the file selection ... we're 
   doing well in making GNOME feel very immediate and responsive
   elsewhere.

 - Incremental loading... if a backend wants to do this,
   when it is asked to list a directory, it immediately returns
   an empty list, then reports 

 - Interest in a folder, similar to gtk_tree_model_ref_node() ...
   to let the file system object know what portions of the
   file system it's OK to cache.

I don't think we need to separate out incremental loading
just to get throbber-style indication. If we want that
we should just add  
get_is_loading()/::start-loading/::end-loading
to GtkFileFolder (a.k.a GtkFolderMonitor).

> > It probably makes sense to have a single call similar to stat()
> > that can get any combination of items.
> 
> 	The 'stat' call is intrinsically synchronous; would it not be better to
> do this via the 'change notification' API ? Ditto for 'list_children'.

Going with a "please tell me about" and "please tell me
about in the future" API is not a ridiculous idea (clearly, since
Nautilus works like that, and GConf, internally.) And it does have 
a nice side  benefit of reducing the size of the API.

Still, it's not a form of API that I'm particularly comfortable
with - it feels a bit backwards to me and adds even more
asynchronicity. 

So, my inclination is to try to go with the standard GTK+
"get + change notification" and see how that works in practice.

> >   void (*file_added)   (GtkFolderMonitor *monitor,
> > 		        const gchar      *uri);
> 
> 	It may also be worth using lists of URIs, and passing the FileInfo for
> each as well. Alternatively - perhaps having a 'begin_chunk' /
> 'end_chunk' API for a burst of serial additions/changes might be a more
> binding-friendly alternative to GList.

Hmm. Certainly worth thinking about whether we need some
chunking facility here for performance reasons.

Binding-friendliness shouldn't really matter, considering
the semi-public nature of the API. I'm not that concerned about
people writing new file system implementions in Python.

Thanks for the feedback,
                                          Owen