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

[Holger Berndt <berndth gmx de>]

On Sa, 21.02.2009 12:54, Alexander Larsson wrote:

>So, there are two kinds of uses here. One is the ordinary shell
>navigation stuff, and the other one is "file management".
[...]
>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.

The very emphasis of the UI proposal of the screencast was to *not*
shift the main use case for Nautilus, but to offer extended
functionality in a decent way that doesn't bloat the UI. It'd even be
fine for me if the visibility of the split pane menu entry was
controlled by a gconf-key, defaulting to off, so that the default UI
doesn't change at all.

In my eyes, this is exactly the beauty of Nautilus (and actually, all
of Gnome): Offer an intuitive, simple UI, but have more power in the
backhand for those who want/need it.

GIO and its interface are good examples for exactly that: A file-open
dialog doesn't show me a button to connect to a remote server, but I am
very happy that I can still do it.

Looping back to Nautilus: Nautilus is already used as e.g. an FTP
application. And a very good one, at that. This is a good thing,
because it lets users get their work done without annoying or confusing
non-users of network file systems.

For the very same reason, I would *not* put a button for split view in
the default toolbar (like e.g. Dolphin does). On the other hand, I
don't see why Nautilus shouldn't offer,  in a subtle way, the popular
(judging from the amount of requests) workflow of dual-pane file
management if a large (or maybe just loud) subset of its users want it.

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

Yes. But it's the beauty of extensions that something like this doesn't
have to go to the core program, and doesn't shift any user's
Nautilus style that didn't explicitely ask for it.

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

I don't see it as fundamentally different, but as an *extension* to the
navigational view. Really, all you do is to define a "default target"
for file operations.

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

No, the original operations are still meaningful and useful even in
split view mode. You just have the *additional* notation of a "default
target".

And in fact, this is exactly how "copy/move to other pane" are
currently implementated in the brach. They call the same functions as
the original operations, only with default arguments.

Actually, this is probably a good way to look at split view in general:
It is a way to define default arguments to file operations, and as such
acts as a shortcut. It's basically the difference between
 void copy_selection(destination)
and
 void copy_selection(destination="/that/other/pane");

Both can be called as
 copy_selection("/some/path")
but the latter can in addition to that also be called as
 copy_selection()

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

While I aggree, I see this as a completely different topic.

>and the fact is that some people will still
>need to do manual file management for the forseeable future.

Exactly. Personally, I am always open to and interested in new UI
concepts, but I also need to get my work done today. Nautilus is a big
help there already, otherwise I wouldn't use it. But it could suit my
workflow even better, and make me more productive. This thread and the
branch are a result of my feeling that this workflow is not exactly
un-common.

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

As described above, I feel this more to be like a subtle extension
(just like GIO sshfs support in file-open dialogs) than a completely
different concept. 

Holger