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

[Holger Berndt <berndth gmx de>]

On Fri, 20 Feb 2009 11:10:26 -0500 Brian Crockford wrote:

> It seems the menu's contents are not strictly necessary. The first two
> items in the menu - copy and move - should theoretically function
> identically to the normal copy|cut + paste commands

> It might be prudent to keep the keyboard shortcuts, for those who need
> that heavy lifting, but get rid of the menu items altogether.

Well, every single dual pane filebrowser that I ever saw used F5 for
copying to the other pane. Right now, Nautilus uses F5 to reload the
page. So there's a conflict, and the only solution I see would be to
keep Nautilus as it is, but to allow users to modify the shortcuts. So,
menu entries would indeed be handy.

Besides, having split-view specific actions (be it by shortcuts,
menus, or both), is not just prudent, but necessary, or the whole
concept looses most of its usefulness right there.

The whole point of dual pane view is to have that concept of "the other
pane" as a target for file operations. If, in order to copy files over,
one has to Ctrl+C, tab through 5 widgets to reach the target, Ctrl-V --
then there goes the whole advantage of split view in general. In that
case, one can just as well open two separate windows. The split-view
specific actions are absolutely crucial for split view to make any
sense.

> In regards to the use of TAB, what Holger mentioned is what I was more
> vaguely describing earlier: TAB would be expected to (eventually)
> bring focus to the next pane. No more than that is needed.

Again, every single dual pane filebrowser I ever used had the tab key
bound to "switch to the other pane". Immediately, not eventually. So in
split pane view, one cannot focus e.g. the toolbar via tab.

Holger