Re: Nautilus View / Listeners compared with Windows Namespace extension questions

[Alexander Larsson <alexl redhat com>]

On Tue, 2003-10-14 at 00:23, Matthew J Hicks wrote:
> 
> 
> I have been working with Nautlius Views, Listeners, GNOME VFS's, etc. to
> try and mimic the functionality provided by Windows Namespaces (or Shell)
> extensions in GNOME.  It seems like some of the concepts are slightly
> different, so I was wondering if anyone could clear some of this up for me.

Cool stuff. Any chance you could hint about what you want to use this
for? :)

> What I think I know:
> 1. It appears that the best way to control the actual contents of the file
> manager is through a GNOME VFS (to provide a virtual view of some data).

Mostly, yes. However, as I'd like to point out, I much prefer any actual
vfs backend to be as true to the filesystem idea as possible. Already
the semantics of file handling using gnome-vfs is a bit vague, and for
every vfs backend with strange filesystems semantics the less reliable
gnome-vfs will be. A vfs backend is used by applications, and
application writers need to be able to rely on some standard semantics,
or they'll easily get confused. (Nautilus already has to have
workarounds for some wonky behaviour in the vfolder vfs backend.)

Also, adding vfs extensions in this way doesn't really integrate that
well in the system at the moment. You have to *know* the new uri is
there and manually type it in (or follow some link someone else made).
The plans for Gnome 2.6 is to allow some vfs methods to emit "I'm now
availible" signals in some way so that something can become visible in
the UI. This is meant to be used for plugging in e.g. hardware that
stores files, but isn't mountable as a normal unix filesystem. Used for
things like non-usb-storage cameras, mp3-players etc. You just plug em
in, and you get an icon on the desktop and in the nautilus tree.

Also, we hope in the future we'll be able to hide the vfs URIs from the
user interface a bit better. 

> 2. The right-context menu can be controlled by implementing a
> Bonobo/Listener - are there any other / better ways?

You can also add a script to ~/.gnome2/nautilus-scripts/, but this is
meant more for users or sysadmins.

> What I know I don't know:
> Here are the areas that I can provide using a Windows Namespace extension,
> but haven't figured out how to do it in Nautilus yet:
> 
> 1.  Merge menu's into the Nautilus toolbars while still in user's same
> view.  For instance, to be able to add 'Foo' to the File menu while still
> in the icon view.  I have been able to implement a new view and then do
> menu merging, but I want to be able to modify the main menus and still let
> the users choose between icon view / list view, etc.

There is no way to do this currently. However, we have realized that
views, as they exist now, are pretty useless when it comes to extending
nautilus since you have to reimplement everything to have a view that
isn't broken. What most people really want is to be able to modify the
standard directory views. So, for Gnome 2.6 we're gonna make a new
plugin system that allows you to do things like add columns to the list
view and otherwise add to the directory views. Dave Camp is working on
this, and if you have any specific wishes you should talk to him so that
the new design allows you to do what you want.

So, really we want people to sort of ignore views, at least for
directories, and tell us what sort of extensions they want to do of the
standard directory views.

> 2.  Control / modify the tree view in the left pane of the file explorer.
> For instance, when viewing the burn:/// vfs, the tree view in the left pane
> still displays the regular file menu (/ etc boot, etc.).  Are there any
> hooks into that view to be able to add vfs's etc. to the tree?

The tree is not supposed to be related to what is currently visible in
the view. Its supposed to be more of a global view of the system,
containing all the filesystem "roots" of the system. So, if you plug in
a CD it'll show up there. This is much like the letter-drives in a
windows system. Currently the tree is hardcoded to only show /, $home
and removable media mountpoints, but as I discussed about VFS above, in
the future we want to allow non-file:// gnome-vfs to signal that
something has been "mounted", which means it'll show up in the tree.

Also, the roots listed in the tree isn't only shown there, they will
also appear in the file selector and other places.

> 3. Moving the vfs url's (or some form of them) into the standard GTK dialog
> boxes.  Although I don't think this is as critical a subject, it is the
> last thing that the Windows namespace provides that I haven't figured out
> how to do in GNOME.

There is currently work going on in Gtk+ for a new fileselector dialog.
This dialog has the filesystem abstracted out, and there is a gnome-vfs
based implementation for it. The idea is that this automatically gets
used for Gnome apps, so you'll get much wider integration of gnome-vfs.

> I've got to say that I am really impressed with all the work that has gone
> into Nautilus - quite impressive!

Thanks.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an uncontrollable zombie cowboy from a doomed world. She's a man-hating 
tempestuous mermaid looking for love in all the wrong places. They fight 
crime!