Drag & drop copy operation prevented by tree auto-collapsing

The auto-collapse mode for non-selected branches of the folder tree is always (at least) triggered if the active tab is changed. I would propose to change this a little bit because a common use-cases is prevented by this behaviour.

Let's say you have a single file on the screen that is shown in the active tab of the left file-display and you want to copy this file to a certain folder on an USB-stick but the right file-display currently has the focus (which active tab pointing to an arbitrary other folder). Now you start to expand the USB-stick in the folder tree and then you want to drag the visible file from the active tab of the left file-display to the recently expanded folder in the tree. As soon as you click to the active tab of the left file-display it gains the focus and the tree is collapsed preventing you from achieving the drag & drop operation. In other words you have to ensure that the correct file-display has the focus before you start expanding the folder tree. Otherwise the tree is collapsed in the moment when you click the active tab of the wrong file-display (even if the tab was visible and active all the time).

I would propose to only trigger the auto-collapse mode if the active tab is changed within the same file-display independent of the focus. If the right file-display gains the focus but the active tab isn't changed that should not trigger the auto-collapse mode to allow the user to perform drag & drop operations using the current folder tree expansion state.

I think it works how it is supposed to work, since it's meant to keep the tree tidy as you switch between folders and tabs. (Though with the sub-option, to not collapse folders which are open in other tabs, turned on, maybe my argument isn't quite as solid.)

The option inherently gets in the way of using randomly expanded folders in the tree as drag & drop targets. You could open separate trees for each side of the lister, or use one of the many other ways to drag/copy files from A to B. Sometimes two concepts don't fit together, and I think the option would be made worse in general (even if it's better for this specific case) by making it not collapse when changing tabs.

I noticed that too and I thought it was a minor bug of this nice auto collapse feature. To be honest I couldn't reproduce it but it feels buggy each time it occurs to me.

But if it is realized this way by intention where is the advantage of the current behaviour? Or the other way round: is there any disadvantage if the tree is not auto-collapsed if the active tab of the destination panel is focussed?

No no, the tree should collapse each time the user actually changes the active tab. But in case that there is one folder tree configured to be shared for both file-displays the tree is associated with two active tabs at the same time. And both of them have equal rights which means that the tree should not be collapsed if there is only a focus change between the active tabs. :wink:

So from my point of view if the tree has the focus (and the two active tabs not) the tree should not auto-collapse if an active tab is just focussed but not changed. It's a total different situation if there is an actual navigation operation (e.g. go back) or if an other tab from the background was activated (brought to the top). These are actual tab-changes and the tree should collapse each time (as it is already realized).

I think my proposal doesn't describe a different behaviour it's just a small improvement of how it is currently realized to make it a little bit more flexible for DnD operation without any (obvious) disadvantages? In other words, the proposed behaviour has both advantages at the same time: (1) the tree is kept always tidy because it is auto-collapsed on each tab change but (2) a manually expanded tree can be used with both active tabs (the tree is responsible for) for DnD operations having the tree as drop-target.

Here is a screenshot of the situation we are talking about. The tree has the focus and T:\Install\Foobar was manually expanded and there are several opened tabs around but two of them are naturally in the front and have the focus. Now comes the problem: If the user wants to perform a DnD operation to the recently expanded T:\Install\Foobar folder he can only use 'A' from the left file-display (blue background) because if he start to drag 'B' from the right file-display the tree is auto-collapsed.


According to the screenshot I would expect that I can drag A as well as B and drop it to Foobar. But it's just a minor problem for me.

By the way: Your GUI looks some of kind ... simplified. Is that the actual configuration you use all the time (without any action toolbars etc.)?

According to the screenshot I would expect that I can drag A as well as B and drop it to Foobar. But it's just a minor problem for me.

By the way: Your GUI looks some of kind ... simplified. Is that the actual configuration you use all the time (without any action toolbars etc.)?

I only use keyboard shortcuts to control DOpus! And as Leo regrets, I have much of them! :wink: And yes I know them all!

There's only ever one active tab, even in a dual display window. (Active = Source)

Another way you can avoid the problem is by making the tab you want to drag from active before you drag from it.