Re: Split/dual pane view again (but this time with code)

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-02-20 at 16:08 +0100, Holger Berndt wrote:
> On Fri, 20 Feb 2009 12:16:33 +0000 Alexander Larsson wrote:
> 
> > If you
> > even start Norton Commander chances are that you're gonna do some
> > heavy file management, like restructuring a set of folders or
> > something.
> 
> Well, I don't know if people really switch file browser applications
> depending on what they are about to do.. Typically, you choose one
> tool, and then stick to it, as you have your bookmarks there and know
> your way through the interface.
> 
> I agree in so far as that default tool is likely to be Norton
> Commander-like when heavy-duty filesystem work is a common task for
> the user.

I understand what you mean and I agree that people don't use e.g. both
mc and some other similar tool. However, that is not what I meant, and I
think the issue is caused by applying the term "file manager" to things
that are not quite the same.

Let me explain by an example user. He is a terminal-only user, that
likes to use mc (midnight commander). However, most of the time he's
working on normal stuff is not spent in mc, it is spent in the shell,
using "cd", "ls", "less", and starting programs with filenames (often
using tab completion from cwd). Sometimes he just needs to copy/move a
single file somewhere, so he uses cp and mv a bit too. However, when
he's gonna do a large amount of copying, moving around, renaming, or
restructuring he starts mc, because that is a more efficient way to do
this.

So, there are two kinds of uses here. One is the ordinary shell
navigation stuff, and the other one is "file management". Now, nautilus
sort of has the label "file manager", but it is really more of a
graphical shell (thus the pun with the name). In other words, its the
non-shell-users version of ls, cd, and command launching, with support
of some other things like cp, mv, etc.

I don't think even most mc users spend the majority of their time in mc,
that is just not a good interface for normal work. In much the same way
we don't want to turn nautilus into something that is mainly for heavy
file management, because if we do we *remove* the only shell-like thing
which is where most people spend most of their time.

I think this is also a general source of much of the negative comments
nautilus gets. I.E. people who use the terminal for normal use and think
that Nautilus is a good app to use when they want to stray from the
"normal shell use" and do heavy file management similarly to mc.

> > However, what I fear is that introduction of a
> > split view will lead to more and more creaping of the application
> > model towards the norton commander style of application.
> 
> That is true. As a matter of fact, there's at least one more feature
> building on split-view that I'd personally like very much:
> Meld-integration to diff the directories or selected files of the two
> panes.

This is the slippery slope in action. For each feature like this you add
you get another user that "just" wants his favourite mc operation.
Arguing against each single change is hard, after all its just one menu
entry. However, that total end result is that you shift the style of the
application.

> > Also, I don't like the "Side Pane" toplevel menu. Menu operations
> > should be arranged by what they do, not what application feature
> > enable them. So, file copy operations should be in edit just like
> > other such operations
> > 
> > Generally we don't hide menu items that are not availible atm, we just
> > make them insensitive
> 
> Now, this is indeed a dilemma. On the one hand I completely understand
> your reasoning. On the other hand, all this "extra" functionality
> should not bother the non-split-view user at all, and I don't think
> insensitive split-view menu items sprinkled all over the place are
> a good idea. As a non-user, I'd be annoyed.
> 
> Maybe it can be seen as a different "mode". We have spatial mode, we
> have navigation mode, and this could be an "extended" navigation mode
> that can be toggled on and off on the fly.

In my mind this is the only sane approach to something like split view.
A nc-style application model is just fundamentally different from a
browser/viewer style application. The basic concepts is that you specify
two arguments in the UI, which is what makes this more powerful than
just two browser windows next to each other. However, this affects how
you implement almost all file operations, for instance copy goes from
dnd/cut-n-paste to copy-to-the-selected-destination. So, you'd have to
duplicate the operations and then you'd end up with twice the number of
operations and half of them are useless and confusing in the split view
case. And the split view ones are either useless in the non-split view
case, or you hide them and make the "split view" toggle unexpectedly
also change a lot of the menu structures, etc.

At the core of good application design is to do one thing, and do it
well. This is for instance why the spatial mode was completely separated
from the browser mode in the UI, so that each could be the best they can
at how they are used. We didn't just add "open in a new window" to the
standard browser window, nor did the requirements for little screen
estate use in spatial windows affect how we designed browser windows.

So, if we were to have a split view feature in nautilus it should really
be a completely different kind of window/app in the eyes of the user.
One designed to have all the advantages of a mc style app and none of
the non-useful leftovers from the browser/spatial window. In other
words, a nc clone based on the nautilus codebase, sharing code and user
data (like bookmarks, mounts, emblems, metadata and history).

I also agree with Rui Tiago Cação Matos that in the grand scheme of
computer UI progress the more interesting approach is not to create
tools that let the user do the frustrating manual crapwork managing
files more efficient, but rather try to move away from having to do
manual file management at all. This would rather lead to a focus on
better previewing, better search, better tagging/metadata and automatic
file mangement/structuring. Of course, this is a more experimental area
with less known solutions, and the fact is that some people will still
need to do manual file management for the forseeable future.

How would a nautilus-based "mc clone" look? How would it integrate with
the rest of nautilus (browser and spatial)? What names would we use for
it? Would it be confusing for users with both browser and dual pane
windows? These are interesting questions, and they need thinking and
research.

It might be interesting to look a bit in more detail how other file
managers with an optional split view work and look. Things like
konqueror, dolphin, etc.

> > as otherwise the menus change in weird ways
> > depending on app state, which causes for instance other operations to
> > move in the menus. See the Gnome HIG for details. 
> 
> Maybe I got this wrong, but this should not be a real problem when the
> menus hook into proper UI-manager placeholders.

Only if the added items are at the end of existing menus, otherwise
everything below an addition moves down. There are other reasons why
this is bad too, see the HIG,