Re: Volume handling proposal

[Ken Deeter <ktdeeter alumni princeton edu>]

Sorry I rearranged your email a bit to make what I want to say flow better.

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

Small technical question.. does this mean the gtk fileselector will
depend on the gnome-vfs? or will some gnome lib extend the gtk file selector?

seems like ideally, the querying and such of volumes should be done at
level along the lines of glib, and the specific gnome-vfs type
functionality (since it is pretty much unix specific) should be done
'below' gtk and not on top of it. 

I assume gtk on windows pretty much just uses all of windows' builtin
filesystem abstraction stuff, gtk on linux should do something similar..
its just that there isn't anythign there to build on really.. I suppose
gnome-vfs is sort of the answer, but then it really isn't clear whether
gnome depends on gtk or gtk depends on gnome-vfs? is gnome-vfs not
really gnome in that sense then?

As there is so much effort duplicated between KDE and gnome in terms of
virtual file systems, this is where we REALLY NEED a freedesktop.org
standard. I think since gnome did just make a major release, we really
should think about starting something correctly so that unix systems in general
can have a sane 'volume management' system that KDE, gnome, and whatever other
desktop can provide different interfaces to.

Since there is a HAL daemon started already, it seems only natural to
try to start up a parallel project that handles exactly what this thread
is here to discuss. I think its fairly obvious that basic VFS stuff is
not desktop interface specific, nor should it be. I would hate to see gnome and
kde especially just go down the same diverging paths they have been, and
have half-baked vfs solutions in both, when we could have a good vfs
solution common to both.

I realize the architecture is quite different, (kio versus gnome-vfs
methods) but the required functionality is so straightforward and
similar that a well-designed, well-performing solution should be easy to
adapt to both.

It seems silly that we can agree how to do thumbnails, window managers
and not VFS, considering that both the concept window managers and
images came way after filesystems did.

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

This starts to get into the HAL kind of idea, and I really really hope
that gnome developers will have just a little foresight and try to do
something that is desktop agnostic.



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

What you list here, except for 'gnome main menu' is not specific to
gnome, or any desktop. Both KDE and gnome have these, and both would
probably like to be able to query things and such. Just because we
provide services at a lower level, doesn't mean we have to provide the
same user-interfaces for them.

But I don't think teh services we are talking about here are so
complicated that KDE and gnome or any other desktop is going to even
require radically different functionality. Just look at the current state,
in both gnome and kde you type "ftp://blah blah" to get a some icons.


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

This should be a choice in interface design, not in the underlying system.
Organization access to system services is an interface issue, providing
these services has nothing to do with the desktop.

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

Windows also has the "Map network drive" which is essentially the same thing.

Even smbfs and nfs mounts on linux are sort of the same thing (just not
user level operations, but that has to do with permissions more than anything else)

My point that it is nothing specific to OS X, and especially not specifc
to OS X's interface. All OS's (at least listed here) provide some kind
of similar service, each just gives u a diff interface. If you start talking about
the ('net') commands in WinNT/2000/xp then you get very similar to 'mount'


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

Again, this is just a variation on the interface, the presentation
manner, and makes no specific requirement on the system that supports it
underneath, except to be able to say "give me a list of shares"



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

This is all interface choices, and are clearly separable from the underlying
system that we need.


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

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

Exactly! why not libvfs? forget anything about gnome, nothing we would
put in this lib would be gnome-specific. We just need to make sure that
it implements all the features that we would want it to to make the
interface we wish possible. We could probably steal a whole bunch of
code from kde too.


[Gnome]         [Kde]               [Desktop x]
    |             |                    |
  [gtk]       [qt, kdelibs, kio]    [whatever]
    |             |                    |
[libvfs and vfsd, hal daemon, image thumbnails, vfolder, iconv]

I really think this is the kind of situation we need to be going for. If
we can add stuff to the bottom layer that is appropriate, then we really
should go for it.

Hey, we can even put vfsd and hald to gether and just call it desktopd!
And make it have plugins and then wow, we can do a whole lot of stuff in
any desktop. This is the power of open source, and yet we choose to not
leverage it if we just assume gnome is the only thing out there.

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

The problem with this one is that it doesn't really fit the semantics
of a filesystem as the other gnome-vfs type modules do. burn:// is
really an application, not a volume. Although it is a nifty way to 
re-use nautilus components, I would argue that the best thing to do is
to think of it as a separate application altogether.. just one that has a very
'familiar' interface. Its defining characteristic is that it has operations
other than what a FS traditionally has, namely, 'burn' and 'blank cd'.

it would be the same if we had printer:// or something, we would need buttons
probably for 'delete job' 'change prioriy' etc. etc... I'm all for making
these things heavily re-use nautilus components, but it may be much to try
to force them into a filesystem concept.

If we go down that path, then we get to the 'everything is a file' idea,
which is great for 'us programmers', but not so great for 'us users' ;-)

I'm sorry this kinda sounds like a rant (and sorry Alex, its not really
aimed at you.. you just brought it up, and its been bothering me for a
while), but the main point is, If we're gonna have to write all this
from pretty much scratch anyways (as there arent really any equivalents
available on linux, unless u count lufs), there's really no point making
it GNOME-specific. I think we owe it to everyone who volunteers their
hours to free software projects to differentiate what we want to do with
our interface, and what we need to implement at the system level. Doing
it correctly is not that much more work, and the benefits are
tremendous.

------

 +----------------------------------------------+
(  Ken Deeter (Kentarou SHINOHARA)             (
 )                                              )
(  "If only God were alive to see this.. "     (
 )                             -Homer Simpson   )
+----------------------------------------------+