Dual Pane - Formal Proposal Thread

[j_c_hallgren]

My suggestion was not about how to assign an shortcut but to implement the option to copy/move from one panel to the other

Ah...ok...the way you wrote it didn't really make that clear, as you emphasized the shortcut vs the actual function, so I natually responded to that, especially since it was your first posting and thus you might be new to XY.

[admin]

Thanks for the welcome.

My suggestion was not about how to assign an shortcut
but to implement the option to copy/move from one panel to the other
by using an internal command... (and then assign the "right" shortcut to this commands)

Perhaps using existing "Edit > Copy to" with refilled target panel?

Yes, even as a non-born dual paner myself I would say these commands should definitely come with it, since my impression is that most people use dual pane for copying/moving from one pane to the other.

[Mesh]

Yes, even as a non-born dual paner myself I would say these commands should definitely come with it, since my impression is that most people use dual pane for copying/moving from one pane to the other.

And with your blessing, I have just added this to the proposal specs.

[Stefan]

more Keyboard Shortcut Actions

- TAB => switch to other panel, and back

- "Ctrl + Arrow right" in left panel ==> open current folder (or archive) in right panel
- "Ctrl + Arrow left" in right panel ==> vice versa

- "Shift+Alt+Space" ==> zoom current panel to x% of screen width, and back. (x% is an ini setting like ZoomWidth%=90)
Perhaps it is possible to use ZoomWidth%=20;50;80;100 to toggle width by circling the steps by key press?

(BTW, maybe "Ctrl+Alt+Space" could set the high between the file list and the preview window?) EDIT: i found this feature already as "Min/Max Info Panel Shift+F12"


- ? ==> swap panels

---

- while implementing DP one should keep in mind the possibility to use the preview window as "other" panel
so we can browse txt or pics on the left and see them on the right in big size.



Perhaps keep the possibility to use different layouts?


Panel | Preview



Panel | Panel
- Preview -


Panel | Pre
Panel | view


Panel
Panel
Preview

?

---

Perhaps
- Feature to Compare the two panels
- Scripting and UDC: options to access left or right, active or passive panel
- Option to select left an file and right an file and call an script or extern app (f.ex. compare to text files)
- split panels horizontally
-

What do you think?

(i don't say: do this all right now. But while developing keep this mind.)

[Mesh]

more Keyboard Shortcut Actions

We're keeping the proposal relatively simple right now. Having keyboard actions to copy/move from one pane to the other was a good addition, as is the action of changing focus from one panel to the other (although I would *not* recommend making it Tab - as that key is used to switch between the tree and list panes). Obviously, having the requisite support for scripting is also a good idea.

But we don't want to overload things from the start. Also, remember when you're suggesting keyboard actions that it's the action itself that's important to add, not the specific key mapping. You don't need to suggest a key mapping, because everyone will have different preferences - and as long as it's available as a keyboard action, you can map it to whatever you like.

[Stefan]

You don't need to suggest a key mapping, because everyone will have different preferences

I know this, but there will be default key mapping for an feature, and those i suggest along with my improvement ideas.

And i didn't want to have this all from start.... but all this must be preconceived while implement such an huge feature
to not cut an possible feature by not thinking about this in the planing phase.

By knowing what's could be the developer can design his project with
wise foresightedness and build-in possibilities by using "place holders" in his code.



I hope i have found the right words in english...

[Mesh]

And i didn't want to have this all from start.... but all this must be preconceived while implement such an huge feature
to not cut an possible feature by not thinking about this in the planing phase.

By knowing what's could be the developer can design his project with
wise foresightedness and build-in possibilities by using "place holders" in his code.

I completely understand what you're saying. And in a way, you're absolutely correct. However, by the same token, Don required that we provide a simple proprosal. If we provide one that is too complicated, we risk him saying no.

That's why we want to try and stick to the necessities. That being said, you still presented several excellent suggestions, some of which I have already added to the proposal.

[j_c_hallgren]

That's why we want to try and stick to the necessities. That being said, you still presented several excellent suggestions, some of which I have already added to the proposal.

And some of these type of features could well be the basis for DP v2.0, but not v1.0...I agree with Mesh in that we need the core functionality first but with enough vison to not make future enhancements difficult/impossible...it's a very hard task, and I'm sure Don will be up to the challenge.

[Stefan]

Yes i understand and have already mentioned the basics for DP only,
dropped the more advantaged ideas (for DP 2.0) on my own already

[erickleal]

I think the best implementation of Dual Pane is used xplorer².
That use less space and is simple.
I'll love if xyplorer implement like that.
Oh' I'm a brazilian guy, sorry for any problem with the english.

[admin]

Fundamental DP Design for XY

In the last weeks I meditated about the various options for a DP design that would fit as smoothly as possible into XYplorer -- from the user's (GUI, usability) and the developer's (technical feasability) perspective. I took into consideration the ideas expressed here in the "Dual Pane - Formal Proposal Thread", and I looked at the ways various DP file managers are doing it. And I travelled to India to find deeper knowledge about the true nature of dual pane.

FYI, this is my current design plan:
- A separate tab bar for each list pane.
Note that this has effect on the current layout (even if you opt for single pane!): The tab bar will only have the width of its list! It will not appear on top of the tree anymore. So the tree will be about one row higher than now, but the horizontal space for tabs will be smaller.

- All other elements are shared between the list panes: toolbar, tree, catalog, statusbar, info panel. IOW, they remain single.

- Methods of differentiating which pane is active: difficult. I don't like coloring the tabs (plus there are technical limitations to that) nor coloring the list. The easiest option would be to add (quoting Mesh) "a single header bar for each pane which lists the path of the directory that's active in that pane." The (configurable) coloring of that header bar would make clear which one is active. However, this would cost space, and it would make the interface more loaded than it already is. So, I'm not really happy with any of the possible solutions I'm seeing so far.

And some very obvious things:
- DP is optional and, apart from the tab bar being smaller than now (see above), everything will be exactly as it is now when you opt for single pane.

- In DP mode all action will go to and come from the active pane (just as if it would be the only/single pane) -- the other/inactive pane will just passively hang around to watched, dropped upon, copied to etc.

- You will get a couple of DP specific commands (maybe in a new top menu, or under the Window menu) which will care for things like swapping the panes, choosing the layout (left/right, top/bottom), synch scrolling, copy/move from one to the other, and the like...

[jacky]

- Methods of differentiating which pane is active: difficult. I don't like coloring the tabs (plus there are technical limitations to that) nor coloring the list. The easiest option would be to add (quoting Mesh) "a single header bar for each pane which lists the path of the directory that's active in that pane." The (configurable) coloring of that header bar would make clear which one is active. However, this would cost space, and it would make the interface more loaded than it already is. So, I'm not really happy with any of the possible solutions I'm seeing so far.

Unless you count that as coloring the list, since I assume each pane will have its own header already, aka Columns headers, why not simply use that and make the Columns headers for the inactive pane look disabled or something?

[Mesh]

- All other elements are shared between the list panes: toolbar, tree, catalog, statusbar, info panel. IOW, they remain single.

Good to hear from you, Don! We've missed you!

As for what you mentioned, I would strongly request having the option of a dual tree. I find it more efficient to be able to see the directory branching for each pane, and having only a single click per change. With a dual tree, each directory change for either tree requires a single click. With a shared tree, each directory change requires two clicks - one to mark the pane you want to change, and then the click to change directories. Looking at a single instance, it doesn't seem like much, but when you're doing heavy file management, it's double the effort, and it builds up quickly.

Please reconsider this one.

- Methods of differentiating which pane is active: difficult. I don't like coloring the tabs (plus there are technical limitations to that) nor coloring the list. The easiest option would be to add (quoting Mesh) "a single header bar for each pane which lists the path of the directory that's active in that pane." The (configurable) coloring of that header bar would make clear which one is active. However, this would cost space, and it would make the interface more loaded than it already is. So, I'm not really happy with any of the possible solutions I'm seeing so far.

Well, it wouldn't cost space if people could turn off the Tab bar for both panes, but I understand if you don't like that idea. Honestly, the tab idea was the one I thought you would be most agreeable to, and the one I thought was most compatible with the aesthetics of XY.

Barring that, another idea would be a thin line under the tab bar - and the active one would have a configurable color, while the inactive one would be grey.

[/quote]

[admin]

It's not possible to custom color column headers or tab headers. These are drawn by system functions and look very different depending on your OS.

The alternative would be to draw them myself (like e.g. Firefox draws its tab headers), but I'm not into this at all.

[Demset]

- All other elements are shared between the list panes: toolbar, tree, catalog, statusbar, info panel. IOW, they remain single.

As for what you mentioned, I would strongly request having the option of a dual tree. I find it more efficient to be able to see the directory branching for each pane, and having only a single click per change. With a dual tree, each directory change for either tree requires a single click. With a shared tree, each directory change requires two clicks - one to mark the pane you want to change, and then the click to change directories. Looking at a single instance, it doesn't seem like much, but when you're doing heavy file management, it's double the effort, and it builds up quickly.

Please reconsider this one.

I have to second this request. I've used progs that use both single and dual trees, and I can't stand the shared tree method. Not only can't I see where everything is, I often drag files into neighboring folders. With the dual tree, I can drag files from one pane into a nearby folder of the tree in the second pane. I can't do that with a shared tree.

And Mesh is absolutely right about the extra clicks. Looking at it now, it seems like nothing, but when you're working with it for a long time, it drives you absolutely batty.