Re: Thinking about GtkFileSystem

[Michael Meeks <michael ximian com>]

Hi Owen,

	Firstly, this looks nice :-) the use of mime types is particularly
nice.

> 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'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:

	It all starts when a 'load_location' call comes in:

	src/file-manager/fm_directory_view.c (load_location_callback)
					     -> (load_directory)

	This then does some async stuff on the directory metadata etc. etc.
resulting in (via. a torturous chain):

	src/file-manager/fm-directory-view.c (finish_loading)

	Which despite the name is the cue to start loading the directory, (more
the end of the beginning rather than ... AFAICS).

	This connects to the libbautilus-private/nautilus-directory.c
'files_added' / 'files_changed' methods, 

	These look like:

	void (*files_added) (NautilusDirectory      *dir,
			     GList <NautilusFile *> *files);

	same for files_changed.

	Nautilus then pulls out the fields it believes are valid, and
everything is good. I believe that slow things such as mime/sniff /
embedded text result in a 'files_changed' signal being emitted.

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

> My preference here is to avoid the opaque objects and just use
> the URI strings. This could clearly lead to some inefficiency,
> but not having to convert back-and-forth is going to simplify
> the API a bunch.

	Sounds great.

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

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

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

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

> - Is additional information needed in GtkFileInfo - 
>   is-symlink? atime? ctime? permissions?

	IMHO not worth having, and your FileInfo structure is beautifully
opaque, and expandable so it's not a problem for later surely.

	Anyway, I hope I didn't understand things too badly,

	HTH,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot