Re: Nautilus vs gnome-shell and the future

[Alexander Larsson <alexl redhat com>]

On Thu, 2009-12-03 at 09:58 +0100, Alexander Larsson wrote:

> I don't have a finished design here, just throwing out the idea so we
> can think about it. One approach would be a shelf area, somewhat like
> embedding a nautilus view in the shell. Another way to do it would be
> more like the old-school gnome panel drawers, or the stacks in OSX
> dock.
> 
> It all depends on what we want to do with it. Stacks/drawers/piles are
> a
> way to keep a reference to a file (or set of files) that you can
> easily
> access (since its accessible from the always visible panel), however
> its
> more limited in how you can use the reference (possible operations:
> open
> it, move/copy it somewhere, remove from stack, dnd to application,
> open
> containing folder).
> 
> A shelf area has a lot more features, being a file manager view. On
> the
> other hand it takes a lot more screen space when active. Thus covering
> other applications when showed.

Been thinking about this more. One interesting question is what kind of
location a stack/drawer/whatever is. Is it a location where you store
files, or is it a set of references (links/aliases/etc) to a set of
files.

I played around a bit with stacks in OSX. A stack there is a storage
unit. In fact you create a stack by creating a directory somewhere and
dragging the directory to the dock. The directory stays where you
created it (well, you can move it around and it'll be tracked), but its
also availible as a button on the doc that shows the content of the
folder.

An alternative approach would be that you create a stack as an abstract
thing and then put files in it, leaving the files in their old places
but also appearing in the stack. Kinda like the results of a search.
Such an approach should probably use a different look and behavior than
a folder to emphasize that it doesn't actually store the files, but just
references them.

Having the stack be a storage makes it less confusing as to where the
files are stored, as there are no aliasing and files only appear in one
place in the UI. Its also easier to implement in terms of maintaining
the stack contents as changes happen in the filesystem. It also means
you don't accidentally delete files from a stack without you knowing its
in some stack.

However, there are several problems with it too:

You risk deleting the files when you get rid of stacks or things in the
stack because you're not aware that this is the sole representation of
the file.

You can't put (i.e. move) system or read-only shared files in a stack,
as you can't move them there. You can copy them there, but then you
don't get further updates to the file in question. 

You can only put each file in one stack.

You can't use the stack as a temporary location (shelf) for files when
e.g. moving them between different directories using the file manager.
Or rather, it works but it causes you to have to move the file twice,
which is problematic if the file is on a different mount than the stack
folder (especially if the mount is remote).

Most of this can be avoided by the user manually putting links to things
in the stack instead of actual files. However this seems like putting
the onus on the user to make the system usable.

Since we're sort of merging files with other kinds of entities (like
applications) in the rest of the UI we should probably allow these
things in the UI too. This would be easier to do if the stack contents
were not tightly bound to a folder and its files. (Its doable with
desktop file links and some magic, but that doesn't seem right.)

I guess the main question is what kind of usecases we see for this and
which we want to support. One major goal is to replace the desktop and
integrate it into the shell. The desktop has a bunch or uses:

1) Its a place where you can keep around the files you're currently
   working on, for easy access and visibility while you're working on
   them.
2) A default scratch area for creating/saving files that are either
   temporary or created in an unstructured fashion before being filed
   away in some longterm location. (As opposed to figuring out the 
   archiving location before actually starting to work, or having 
   temporary files mixed up with "stored" files.)
3) Its got a trashcan that is "always" visible (if not covered)
   that can be used as a DnD target for various operations
4) Its got shortcuts to currently mounted volumes and the standard FS
   locations.
   These can be used as dnd target, but are really mostly used as
   shortcuts to open the locations, since they only point to the root
   of each volume.
5) Its a place where you can put application launchers and uri shortcuts
   (also not a goal from our side, the panel is where that was supposed
    to happen, but in practice its what many do, maybe inherited from
    windows)
6) Its a storage location 
   (This is not something we intend it to be used as, but its what
    happen in practice with things being downloaded and saved on the
    desktop and then left there, making it less useful)

I think gnome-shell already does 4 and 5 pretty well, and 6 is not
really interesting as a goal. That leaves 1 to 3.

1 sort of implies having a set of links to files stored elsewhere, while
2 is more of a storage location. For 2, the alternative to having this
on the desktop or as a container embedded in the panel is to launch the
file manager in e.g. the home directory for this. Although that makes
such an operation several step longer, and mixes up temporary files with
the other files in the home directory.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a lounge-singing alcoholic farmboy fleeing from a secret government 
programme. She's a bloodthirsty bisexual mercenary with the power to see 
death. They fight crime!