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

On Sat, 2009-02-21 at 16:50 +0100, Holger Berndt wrote:
> On Sa, 21.02.2009 12:54, Alexander Larsson wrote:

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

The question is, do they want just a split view, or do the want the full
nc-like app? I tested Dolphin and konqueror today. From what I can see
they don't support *any* extra operations in their split view. Its more
or less the same as having two windows next to each other. Adding the
complexity of that and then not using it even for the most common
operations (copy/move to other pane) seems kind of weird.

However, I like how they show the active pane, they disable the
path-bar, plus make the background and frame grayed out on the disabled
pane. The background makes it very obvious which one is active.

Also, i see dolphin does splits-in-tabs, not tabs-in-split. I wonder
what is most useful.

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

As a maintainer of a distro I don't quite see it the same way. There
will just be lots of pressure to install the extensions by default, just
like there is pressure to add the open terminal extension (its in fact
installed by default in RHEL). And once its installed users cannot opt
out of it. (We could have some form of dialog to disable extensions, but
that would be even worse a UI than just having it be a standard config

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

Yes, from an implementation and developers kind of view this is of
course true. But from the point of view of the user interface they have
to be two separate operations, with separate menu items, keyboard
shortcuts, etc.

I guess one way to make this less weird is to always have a "copy to"
submenu, similar to the dolphin one. It would have home, root, maybe
some bookmarks/mounts and then let you dive down into these as menus.
Then we could just add a "other pane" menu item in the split view case.
That would make it more obvious that this is a standard operation with a
different way of specifying the target.

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

I think that is doable, but the result will never be as efficient a file
manager as a real nc-style one. And I'm not sure this is really what
people clamoring for split view wants.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]