Volume handling proposal

[Alexander Larsson <alexl redhat com>]

This email discusses the way volumes and volume-like elements should be
handled in the gnome desktop. I hope it will start a discussion about
this, and end up with a model we can work towards in the future. All of
the implementation might not be done immediately, but its much easier to
do it in steps if you know the final goal.

In order to create an understandable and usable model for them we need
to take a step back from the feature additions and design an interface
where you can easily do the things you commonly need to in a way that is
consistent and easy to understand for new users.

I present first the elements that play a part in this
problem, then discuss what people need to be able to do and various
issues that need to be handle. Then we describe a user interface that
I think make sense for Gnome, and finally there is some discussions on
the implementation of it. 

The Players
-----------

First lets look at the types of volumes we want to handle:

The filesystem root. This is not that often used, but there really
needs to be a way to reach it. Maybe not everywhere, but at least
somewhere.

Standard removable media:
Floppy, CD, DVD

Removable hardware that is mounted as a normal filesystem:
usb storage devices of various sorts (including e.g. cameras),
flashcard readers, external HDs

Local HD partitions that the user might want to see as a toplevel item
rather than just somewhere in the filesystem:
windows partition, shared data partition

filesystem-like hardware that isn't mounted as a filesystem, but might
make sense as a vfs backend:
mp3 players, non-usb-storage cameras

Network filesystem that are mounted somewhere in the filesystem
hierarchy:
NFS mounts, smbfs mounts

Discoverable network filesystems:
local smb shares, zeroconf webdav servers

Non-discoverable network filesystems:
webdav, ftp, ssh

Other special kinds of volumes:
burn

These then need to be exposed to the user in the user interface. There
are a few places where this is possible in a typical desktop
environment:

* Icons on the desktop
* "Go" menu in the file manager
* File manager toolbar
* Gnome main menu
* virtual locations like the MacOSX "Computer" or the Windows "My Computer"
* The fileselector
* The tree view in the file manager

Issues
------

There are some issues we need to think about when we design out system:

On some systems we can detect when the user inserts a CD/DVD or even a
floppy, but Gnome in general cannot depend on this feature in order to
work. Therefore we must somehow allow you to access the device before
the volume is mounted, so that you can mount it using the user
interface.

Its not always clear which local mounts (appart from removable media)
are supposed to be visible in the user interface. Nautilus currently
looks for user mountable mountpoints and exposes them as visible
volumes. This is right sometimes, and sometimes not, and when it fails
there is no way to fix it.

Its might make sense to present some other hardware elements in the
same way as volumes, even though these are not really
filesystems. Things like printers and scanners. This can be useful, 
since these highly-visible external hardware elements otherwise have
no corresponding in-desktop element. However, it is also a bit
dangerous, since these items will look like files but really will be
something completely different, therefore they might break the users
conceptual model (what happens if you copy one to a remote share? Can
you rename them? What happens if you drop one in the trash? What are
their size? What happens if an application decides to load such a
"file"?). 

Usage
-----

The desktop are used in various ways, some use it to store the
documents they're currently working on, some store *all* their stuff
on the desktop, some don't use it much, some keep it really clean and
use it mostly to launch stuff. We should try to design something that
works for all these use cases. At all times we should respect the fact
that the Desktop is fully owned by the user, and not modify files or
otherwise mess it up. We handle desktop icons by making them virual
in-memory objects to avoid cluttering the users Desktop directory with
strange files. 

The home directory is the users primary storage for his/her own
files. This makes it a very common directory to show, so it should be
accessible in multiple fast ways.

Network mounts are typically used in two ways:
The most common one is when a person is working in a group or a
project and they share some server where they store their files, or
you work alone but often use a particular storage server. In this
case you typically get told exactly what share to use, and you never
really use any other shares.
The less common case is in more ad-hoc style network such as
university dorms where lots of people have machines set up and you
want to browse them all looking for some file. Once you've found the
file you typically aren't interested in that server anymore.


Proposed Model
--------------

I've looked at what MacOS X, WinXP and KDE does, and this proposal is
sort of a mix of MacOS X and WinXP. The idea is to have only the most
used things on the desktop to avoid desktop clutter, but still have a
way to reach every interesting volume in a few clicks. There should
also be several ways to reach things without using the desktop icons.

Three new concepts are introduced:

First concept is a virtual location called "Computer", which is a
"root" of all the volumes in the system, much like "My Computer" in
WinXP and "Computer" in MacOSX. 

Second one is the MacOS X concept of connected network
volumes. You select "Connect to server" in a menu, and then using
either manual typing or a browser for some types of servers you select
a server and directory. This location is then saved between sessions
and easily accessible. This allows you to quickly access commonly used
shares, and is also a way to introduce a way to intelligently handle
non-discoverable network shares. At the very least you only have to
figure out/get told that strange ssh: uri once.

Third one is the "Network" location. Ideally this contains all the
servers in the current windows workgroup, all zeroconf webdav servers
on the local net and all other discoverable network shares. It also
contains a "Windows Network" icon linking to smb://. Windows XP does
this a little bit different, they list every share on every server in
the workgroup as "<share> on <server>". There might be quite a lot of
these though, and querying for them requires you contact each
computer, so this is probably not a good idea.

In the gnome menu there are menu items for "Computer", and
$HOME. And probably "Navigate Filesystem" or something like that which
opens a navigation-model window (see recent nautilus post) which
probably opens in $HOME too.

The desktop will contain the current Home link and trash can. Home is
here since it is a really frequently visited location, basically being
the unix version of "My Documents". Some people dislike this because
it creates a loop (Desktop is in Home, Desktop points to home), but I
think its more important to have quick access to home than being
"loop-free". 
The desktop will also show icons for:
* removable media (cd/dvd/floppy) with media mounted.
* all the connected servers
* mounted removable hardware filesystems
* active non-mountable external/removable hardware (i.e. mp3 players,
  etc). These are basically links to non-file uris like
  "camera://foo_cam/1/".
  In order to handle detection of such hardware and generate the
  proper url to use for it we will need some extensions to gnome-vfs.
Note that this does not include the root, nor "Computer". I think
these are not used often enough to require a desktop icon.
  
The navigation file manager windows will have Home and Computer on the
toolbar and in the Go menu. Spatial windows will only have the go
menu.

The tree sidebar will have roots for home, filesystem (/), and
the items on the desktop.

The Computer location will contain all the items on the desktop, plus
filesystem (/) and a link to "Network". It will also contain all
removable media devices that doesn't have media mounted, and will
allow them to be mounted if there is no support for
auto-detecting-and-mounting. It might be a good idea if just clicking
on an unmounted icon here tried to mount it before opening.
Basically, "Computer" a sort of user-level root where you can get to
all the usable mounts in the system. 

Note that neither NFS mounts or smbfs-mounted smb shares show up
anywhere by default, neither are random mounted local HD
partitions. This is because these are often used for things that is
supposed to be hidden parts of the implementation of the
filesystem. If you really want something to show up on e.g. the
desktop you can use the "connect to" feature.

I'm not sure what roots we want in the fileselector. At the minimum we
want the desktop ones, but do we want e.g. unmounted floppies/CDs there?

Note: the described behaviour is the default. Some of this will be
made configurable, but hopefully not that many prefs will be needed.

Implementation
--------------

Since we want to share volumes with apps using the new file selector
its clear that the code can't be all in Nautilus. This means that the
code in NautilusVolumeManager has to be split out from Nautilus
(probably rewritten, it stinks) and put in some common library, such
as gnome-vfs or libgnome. We should probably do the actual probing etc
in a separate process so that not all apps have to do this. This
matches well with the current plans for a gnome-vfs daemon. So
gnome-vfs might be a good place for this. It also makes sense for
gnome-vfs to handle the "connect to server" backend code.

Supporting detecting plugged in hardware in gnome-vfs
(e.g. camera:) will need some extra interfaces for gnome-vfs modules
that gets run in the daemon. Basically the vfs modules will generate a
uri when it detects a supported device being plugged in.

Since we need to handle the list of volumes in various ways in
different places it makes sense to make the volume api a real api (not
some vfs module).

Implementing "Computer" is probably done best as a vfs module,
although it would rarely be used by other apps than nautilus (the
important roots from computer are already exposed in the file
selector). 

"Network" is a bit hard, since it has to be a combination of data from
various vfs backends. It needs some thinking, but I think its implementable.

Open Issues
-----------

How do we handle burn:? I really like the way where its sort of
invisible in the UI until you insert a blank cd and magicdev detects
it. This doesn't work without magicdev, but maybe clicking on the CD
in computer could try to detect a blank cd and go to burn:. Of course,
this gives problems with rewriting CD-RWs and burning .iso images, so
i guess this has to be visible some other way in the UI too. Maybe
right click on the cd device icon and select "burn to cd"?

Still not sure what roots make sense in the file selector. Do we want
to allow mounting of e.g. floppies from the file selector?

What about printers etc? "Computer" is essentially only "filesystems
accessible on the computer" right now, but it *could* be extended to
be more like a "hardware connected to the computer", although that
makes network filesystems not fit in there as good, and introducing
non-files in the filesystem is dangerous as noted above.

I've deliberately avoided mentioning start-here:, applications: and all
the software gnome-vfs locations we currently have. This is because I
don't think we should get them tangled up in the volume handling
model.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an immortal day-dreaming cowboy looking for 'the Big One.' She's a 
chain-smoking kleptomaniac lawyer in the witness protection program. They 
fight crime!