Re: Volume handling proposal

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi Alex,

About detecting when a camera is plugged in, can't we use the hal stuff
from freedesktop.org for that (http://pdx.freedesktop.org/~hal)? (still
in pre-0.0.1 though, but the ideas behind it look good).

Regards,

Jeroen

On Tue, 2003-09-16 at 15:40, Alexander Larsson wrote:
> 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! 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>