How about Total Commander like dual pane view?

[Mesh]

I'm not saying using a compare tool to do it systematically, but the view in these tools is meant for comparing items. The interface is set up for the exact task that you're trying to accomplish.

Right, because it's dual pane!

In the case where you're trying to compare files that are of different names, types, contents, sizes, dates, attributes, and everything else, the compare tool is still better suited for the task because it's interface was created for comparing and not for managing.

That's what you don't seem to understand. For the scenarios in question, no application is going to be able to do the comparison for you. The only thing that's going to take care of it is the human brain. Which means that using a second app achieves absolutely nothing but wasting time. And the other part of what you seem to be missing is that other than the brain being used for the actual comparison, what's needed from the application *IS* managing. This is, after all, about file *management*. Which means that the only thing missing is that part of the interface which allows you to best facilitate using the brain to compare lists of files - dual pane!

It really seems to me that the core problem is not that XY needs an always available DP view, but that it needs a good method for comparing folders visually.

A good method for comparing folders visually... Ooo, I know, I know! Dual pane?


On an aside, I never said it needed an always available DP view (by which I'm interpreting that to mean that the interface is always DP). The way I used Powerdesk was to keep it on single pane most of the time, but as soon as I needed DP, I hit Ctrl-2, and voila! Dual panes. I'd do what I needed to do, and then hit Ctrl-1, and I'm back to single pane. That's what I'm asking for - not a permanent DP setup.

[admin]

And while I can't speak for anyone else, I know that my money will certainly be leaping out of my pocket as soon as XY has a good dual pane implementation.

As it might not surprise you, I'm not going into the DP discussion again here and now. However, I want to let you know that I read every word of your longish posts because I saw them well written and thought out. And they indeed made me curious: can you show me a good dual pane implementation? Is one existing somewhere, and if yes, for what percentage of all users (would you estimate) is it that good?

[Mesh]

As it might not surprise you, I'm not going into the DP discussion again here and now. However, I want to let you know that I read every word of your longish posts because I saw them well written and thought out. And they indeed made me curious: can you show me a good dual pane implementation? Is one existing somewhere, and if yes, for what percentage of all users (would you estimate) is it that good?

Well, in general, Dual Pane is relatively simple. It only gets messy when a developer tries to get cute with it (such as with Xplorer2).

PowerDesk Pro 6.0.4.2 has a simple and clean implementation of it. I'll give you the characteristics that, in my opinion, make for a good Dual Pane implementation (most of which are covered by PowerDesk Pro):

----------------------------------------------------

1. Quick to turn on and quick to turn off.

We're not looking to lock a file manager into one or the other, but give a quick way to switch to whatever is needed. As I mentioned in a prior post, in PowerDesk, I keep it in single pane mode most of the time. When I need dual pane, I hit Ctrl-2, and dual pane pops up. When I'm done, I'll hit Ctrl-1, and I'm back to single pane (with the active pane being the one that remains when switching to single pane mode). Being able to switch quickly, cleanly, and via keyboard shortcuts is a must.


2. Resizeable panes.

Self explanatory, you should be able to drag the boundry where you need it, and have an easy way to reset it to the default halfway point (such as double-clicking the boundry point). There is a seperate but related issue, regarding the column layout in the file portion of the panes. In PowerDesk, any changes made to the column layout (such as which columns are displayed, sort order, column sizing, etc...) is remembered for the second pane, and restored whenever it's brought up again. I think it's important to allow each pane to be configured seperately - but people will have different opinions as to whether they want those changes remembered, or if the second pane should always come up configured identically to the first.


3. Seperate trees for each pane!

To me, this is an absolute must, because - while counterintuitive - having a single shared tree is significantly *less* efficient than having seperate trees for each pane.

First of all, if you're working with two seperate directory trees, located far apart - you don't want to have to constantly be scrolling between them, as you shift which directories you are loading into each pane.

Also, as I previously illustrated with XPlorer2, you will - on average - need to make twice as many clicks with a single tree than you would with dual trees. With seperate trees, you click once to change the directory of the top pane, and once more to click the directory of the bottom pane. But with a shared tree, you click the top pane first to make it active, then you click to change its directory. Then you have to click a third time to make the bottom pane active, and then a fourth to change *that* directory.

There is absolutely no good reason that I can see to have a single tree. You're not saving any screen space, because either approach takes the same width on the left side of the screen. The only advantage of a single tree is that you get the full height to work with - but that does not come close to overcoming all the disadvantages.


4. The file manager should remember the last used directory for the second pane.

Now here, I can see there being some legitimate disagreements. What I would recommend is that you should have a general configuration option for the file manager to behave in one of two ways:

Option 1 - Remember the last used directory for the second pane and restore that whenever the second pane is brought up. If the directory doesn't exist, don't generate an error, but just go to the topmost root of the tree.

Option 2 - Set a Home Directory that the second pane will always open up to. Respond the same way as Option 1 if it can't find the directory.


PowerDesk functions with Option 1's behavior. Personally, I would prefer Option 2's behavior, but the absolute best way would be to give users the choice.


5. Have a *subtle* way of differentiating which pane is active.

Even if you have a seperate tree for each pane, you still need to always have one pane set as the active pane. This is necessary to account for many actions that could be executed - KB shortcuts, for example. However, personally, I find it extremely annoying when the entire background of the pane changes color to indicate this. As I said in an earlier post, I feel like I'm about to have an epileptic seizure when I'm constantly switching from one pane to the other.

PowerDesk Pro has a good implementation of this - it has a single header bar for each pane which lists the path of the directory that's active in that pane. The active pane has that bar shaded in gray. This way, it's easy to tell which pane is active, but it's a subtle change when you switch from one to the other.


6. Proper integration with the file manager's features.

Simply put, anything you can do while in single pane mode, you should be able to do in dual pane mode - with respect to the active pane. The file manager should never need to be crippled when working in dual pane mode, and each pane should be treated seperately. You can implement *additional* actions that will affect both panes, but never take away the default actions that work on a per-pane basis. Let me give an example: As it pertains to XY, Shift-/ closes all branches except the active one. If you're in dual pane mode, Shift-/ should only work on the active pane. If you like, you can implement an *additional* KB shortcut that will do this in both panes simultaneously - but don't take away the default option of acting on only the active pane.

----------------------------------------------------


Off the top of my head, that's what I can think of at the moment for what would make a good, clean dual pane implementation.


That aside, thank you for reading my posts - I'm sure it was a thorough test of endurance.

[admin]

As it might not surprise you, I'm not going into the DP discussion again here and now. However, I want to let you know that I read every word of your longish posts because I saw them well written and thought out. And they indeed made me curious: can you show me a good dual pane implementation? Is one existing somewhere, and if yes, for what percentage of all users (would you estimate) is it that good?

Well, in general, Dual Pane is relatively simple. ...

Thank you. I hope other DP folks will read your post and contribute to it.

For me, this is an experiment. And I will pay back with a promise: If it turns out that the DP folks here in the forum can join in one clear and simple DP concept, I will implement (this kind of) DP in XYplorer 8.0. Naturally, XYDP should (1) fit into the overall feel of XY and (2) satisfy the majority of DP enthusiasts, so that (3) they finally stop begging!

[j_c_hallgren]

3. Seperate trees for each pane!

To me, this is an absolute must, because - while counterintuitive - having a single shared tree is significantly *less* efficient than having seperate trees for each pane.

I think this may be true for some users but not all users! I, for one, am perfectly happy with x2's single tree...were there a few times when a dual tree would have helped even more? Yes, but not enough for me to want it all the time, so it'd definitely need to be an option that could be set easily.

First of all, if you're working with two seperate directory trees, located far apart - you don't want to have to constantly be scrolling between them, as you shift which directories you are loading into each pane.

With x2, I mostly use the clickable parts of path name in pane title/head to relocate my position...XY at this point, doesn't have that ability quite as easily...close, but not quite.

Also, as I previously illustrated with XPlorer2, you will - on average - need to make twice as many clicks with a single tree than you would with dual trees. With seperate trees, you click once to change the directory of the top pane, and once more to click the directory of the bottom pane. But with a shared tree, you click the top pane first to make it active, then you click to change its directory. Then you have to click a third time to make the bottom pane active, and then a fourth to change *that* directory.

You mention top and bottom pane, but my view of dual panes in the most productive manner is to have them side-by-side left/right...so just how would you accomplish that? Ok, so I did provide a mock-up screen some month ago showing a dual list pane that was top/bottom but that was to have the least possible impact on current overall layout...so that Info Panel would stay as is, and tree/catalog also as is.

If one is using DP to manually compare lists, having them side-by-side is MUCH more efficient than one-over-other...I worked on a mainframe editor for many years that only allowed dual panes in a top/bottom layout and it was workable but not ideal...but we also had shortcut keys that would scroll both panes by one line or one 'page', so keeping them in sync was somewhat possible.

There is absolutely no good reason that I can see to have a single tree. You're not saving any screen space, because either approach takes the same width on the left side of the screen. The only advantage of a single tree is that you get the full height to work with - but that does not come close to overcoming all the disadvantages.

In order to provide a side-by-side pane layout with dual trees mean there would be almost no room to see any columns of the list, except for name! Even with a single tree, the amount of room left for list data is restricted enough so that one can't easily view needed data.

[Mesh]

Thank you. I hope other DP folks will read your post and contribute to it.

For me, this is an experiment. And I will pay back with a promise: If it turns out that the DP folks here in the forum can join in one clear and simple DP concept, I will implement (this kind of) DP in XYplorer 8.0. Naturally, XYDP should (1) fit into the overall feel of XY and (2) satisfy the majority of DP enthusiasts, so that (3) they finally stop begging!

It doesn't seem enough for me to simply say "thank you", but I admit to being at a loss to find something stronger. Well, that's not quite true - but being in the US, I've had a very difficult time finding a business in Koln that I can pay to deliver beer to you (and I'm dead serious that I've spent no small amount of time looking - originally it was meant to be as a friendly bri... <ahem> gesture. But now, it would have been in thanks).


To everyone else, it's time to get cracking!

[admin]

Thank you. I hope other DP folks will read your post and contribute to it.

For me, this is an experiment. And I will pay back with a promise: If it turns out that the DP folks here in the forum can join in one clear and simple DP concept, I will implement (this kind of) DP in XYplorer 8.0. Naturally, XYDP should (1) fit into the overall feel of XY and (2) satisfy the majority of DP enthusiasts, so that (3) they finally stop begging!

It doesn't seem enough for me to simply say "thank you", but I admit to being at a loss to find something stronger. Well, that's not quite true - but being in the US, I've had a very difficult time finding a business in Koln that I can pay to deliver beer to you (and I'm dead serious that I've spent no small amount of time looking - originally it was meant to be as a friendly bri... <ahem> gesture. But now, it would have been in thanks).


To everyone else, it's time to get cracking!

Kate Winslet is currently in Cologne shooting a movie. She could bring me some bottles on your behalf. You happen to have her number?

[Mesh]

3. Seperate trees for each pane!

To me, this is an absolute must, because - while counterintuitive - having a single shared tree is significantly *less* efficient than having seperate trees for each pane.

I think this may be true for some users but not all users! I, for one, am perfectly happy with x2's single tree...were there a few times when a dual tree would have helped even more? Yes, but not enough for me to want it all the time, so it'd definitely need to be an option that could be set easily.

I would be perfectly happy compromising on a user-selectable setting. But in the interests of trying to keep the coding simple, I'm curious as to whether a general consensus can be reached on a single option. I'm usually pretty good at indicating where a feature is likely to have legitimately differing views on workflow. You state that you're perfectly happy with X2's single tree, and you state that there are times when seperate trees would have helped more. But you didn't say anything as to why you might *prefer* a shared tree. Can you elaborate as to why you might prefer a shared tree over seperate trees?

First of all, if you're working with two seperate directory trees, located far apart - you don't want to have to constantly be scrolling between them, as you shift which directories you are loading into each pane.

With x2, I mostly use the clickable parts of path name in pane title/head to relocate my position...XY at this point, doesn't have that ability quite as easily...close, but not quite.

That only works if you're changing directories within the same absolute path. That method doesn't work if you're moving outside of that.

Also, as I previously illustrated with XPlorer2, you will - on average - need to make twice as many clicks with a single tree than you would with dual trees. With seperate trees, you click once to change the directory of the top pane, and once more to click the directory of the bottom pane. But with a shared tree, you click the top pane first to make it active, then you click to change its directory. Then you have to click a third time to make the bottom pane active, and then a fourth to change *that* directory.

You mention top and bottom pane, but my view of dual panes in the most productive manner is to have them side-by-side left/right...so just how would you accomplish that? Ok, so I did provide a mock-up screen some month ago showing a dual list pane that was top/bottom but that was to have the least possible impact on current overall layout...so that Info Panel would stay as is, and tree/catalog also as is.

If one is using DP to manually compare lists, having them side-by-side is MUCH more efficient than one-over-other...I worked on a mainframe editor for many years that only allowed dual panes in a top/bottom layout and it was workable but not ideal...but we also had shortcut keys that would scroll both panes by one line or one 'page', so keeping them in sync was somewhat possible.

In order to provide a side-by-side pane layout with dual trees mean there would be almost no room to see any columns of the list, except for name! Even with a single tree, the amount of room left for list data is restricted enough so that one can't easily view needed data.

I forgot about a side-by-side implementation, because I've never used it. I work in Details view, and I need the width in order to get all the columns visible, so I've always used a top/bottom pane approach. However, you bring up a good point that left/right is sometimes more useful.

What do you think of this - allow XY to work in either left/right or top/bottom modes, and let it behave as such:

1. If dual pane is used in top/bottom mode, it will work as I described, with seperate trees on the left, taking up the same space as the current single tree.

2. If dual pane is used in left/right mode, there is a simple header bar above both panes, which show the absolute path of each pane. Clicking the bar over either pane brings up a dual tree panel above the two file lists, which still give you seperate trees, but do not take any width away from the file lists. The panel is resizeable, so you can make the trees as shallow or as deep as you like. And you can choose whether this tree panel autohides, or if it stays open until manually collapsed.


Off the top of my head, this approach would give absolute maximum flexibility to users of either left/right or top/bottom modes, without sacrificing screen space.

What do you think?

[Mesh]

Kate Winslet is currently in Cologne shooting a movie. She could bring me some bottles on your behalf. You happen to have her number?

Sad to say, but I don't. However, if I find a business that does this (and speaks English), I'll do my best to make good on it.

[admin]

Kate Winslet is currently in Cologne shooting a movie. She could bring me some bottles on your behalf. You happen to have her number?

Sad to say, but I don't. However, if I find a business that does this (and speaks English), I'll do my best to make good on it.

Good luck!

[j_c_hallgren]

You state that you're perfectly happy with X2's single tree, and you state that there are times when seperate trees would have helped more. But you didn't say anything as to why you might *prefer* a shared tree. Can you elaborate as to why you might prefer a shared tree over seperate trees?

I think I covered that aspect later in my posting, as it's the screen space that dual trees (left/right) chew up that could be used better for list area...in a top-bottom DP, the space isn't as much of an issue, but even there, a single tree allows one to have more of a given area/section visible at one time, like being able to see most, if not all, of my entire "My Documents" sub-folders as compared to only 1/2 of that.

That only works if you're changing directories within the same absolute path. That method doesn't work if you're moving outside of that.

With x2, I can easily move back up the path as far as the drive, and then click back via folders to get to another, so it's never been a problem for me...and I can also use the tree to select alternatively.

I forgot about a side-by-side implementation, because I've never used it. I work in Details view, and I need the width in order to get all the columns visible, so I've always used a top/bottom pane approach. However, you bring up a good point that left/right is sometimes more useful.

I've used both styles, and depending on function that I'm trying to do, I've found that left/right works more often as best choice for me, even though amount of columns visible is more limited that way...

1. If dual pane is used in top/bottom mode, it will work as I described, with seperate trees on the left, taking up the same space as the current single tree.

As one option, yes...as the only option, no, as single tree works better as described in some cases and other posts....see my quote at bottom for one possible approach I had...

2. If dual pane is used in left/right mode, there is a simple header bar above both panes, which show the absolute path of each pane. Clicking the bar over either pane brings up a dual tree panel above the two file lists, which still give you seperate trees, but do not take any width away from the file lists. The panel is resizeable, so you can make the trees as shallow or as deep as you like. And you can choose whether this tree panel autohides, or if it stays open until manually collapsed.

Not exactly sure how this would look/work, but if you're saying to put the tree(s) above the list, then the amount of vertical tree one could see without compromising list area significantly wouldn't make it useful, it seems to me...a tree showing only 2-3 lines vertically doesn't do much for me, but that's just my opinion.

-------------------------------------------
From much earlier in this thread, and copied here for reference

Having a dual list with a single tree would be perfectly acceptable to me, and probably many DP requestors, but if there was a possibility of a dual tree, that would likely make it more desirable to some...

Quite some time ago, I created the following mock-up of how a simple DP implementation could look...since some are new here, I'll put it here as clickable thumb so y'all can see what I was proposing...ok, so having the dual panes horizontal isn't ideal, but I thought it would be the easiest to implement...

And in this proposal, the 2nd tab on right would be the "header" for the lower pane, and would need to be marked in some manner to indicate such.

BTW, I'm having a bit of trouble replying to this today as I had eye surgery today and that one is covered now by a patch until tomorrow...quite irritating.

Oh, about the gift/bottles...I'm sure that Don would be more than happy to take a monetary donation and convert it to the desired product!

[Mesh]

I think I covered that aspect later in my posting, as it's the screen space that dual trees (left/right) chew up that could be used better for list area...in a top-bottom DP, the space isn't as much of an issue, but even there, a single tree allows one to have more of a given area/section visible at one time, like being able to see most, if not all, of my entire "My Documents" sub-folders as compared to only 1/2 of that.

Personally, I don't think that comes close to overcoming all the disadvantages. However, to each his own. If people feel strongly enough about this, we'll work a user-selectable choice into the final proposal.

That only works if you're changing directories within the same absolute path. That method doesn't work if you're moving outside of that.

With x2, I can easily move back up the path as far as the drive, and then click back via folders to get to another, so it's never been a problem for me...and I can also use the tree to select alternatively.

To me, that seems awkward and cumbersome - but I'll post a few mock ups after this post (if the forum will take them), and we'll see how that goes.

Not exactly sure how this would look/work, but if you're saying to put the tree(s) above the list, then the amount of vertical tree one could see without compromising list area significantly wouldn't make it useful, it seems to me...a tree showing only 2-3 lines vertically doesn't do much for me, but that's just my opinion.

Well, it wouldn't have to be 2-3 lines. It would be as large as you want. If you're okay with the ability to easily collapse the tree pane and/or set it on autohide, it wouldn't matter.

[Mesh]

Here are some mockups I did to show the general idea:

The full size versions are 1920 px wide. The reduced size versions are 1024 px wide. But because these were created at 1920, the reduced size versions are going to be fuzzy. I'd recommend the full size for people who don't mind panning.


---------------------------------------------
Full Size


Top Bottom




Left Right - No Tree




Left Right - Tree





---------------------------------------------
Reduced Size - 1024 px wide (Warning - Fuzzy)

XY - Top Bottom




XY - Left Right - No Tree




XY - Left Right - Tree

[j_c_hallgren]

Here are some mockups I did to show the general idea:

Could you possibly resize these down a bit so that we can see entire "screen" on a typical 1024x768... and also post a thumbnail link as I did above? Thanks!

[Mesh]

Could you possibly resize these down a bit so that we can see entire "screen" on a typical 1024x768... and also post a thumbnail link as I did above? Thanks!

Done. I edited my original post. Although I don't recommend the reduced sizes for people who are willing to pan, as they're fuzzy from the downsampling.