Separate tree: Mouse behavior
Moderators: Hacker, petermad, Stefan2, white
Separate tree: Mouse behavior
Currently the separate tree has the following mouse behaviors.
Left mouse key down: The cursor moves to the item where the user has clicked. When the user moves the mouse up/down the selection changes
Left mouse key up: The directory is changed and inactive selection is removed.
I suggest to change this behavior:
Left mouse key down: The cursor moves to the item where the user has clicked. When the user moves the mouse up/down drag&drop is started.
Left mouse key up: If drag&drop operation has started finish it and change to move/copied directory. Otherwise just change to the selected direcory.
I think this improvement is necessary because drag&drop using items in the separate tree as source is completely impossible. The current up/down scrolling is fine but there are alternatives: Mouse wheel and scrollbar.
Left mouse key down: The cursor moves to the item where the user has clicked. When the user moves the mouse up/down the selection changes
Left mouse key up: The directory is changed and inactive selection is removed.
I suggest to change this behavior:
Left mouse key down: The cursor moves to the item where the user has clicked. When the user moves the mouse up/down drag&drop is started.
Left mouse key up: If drag&drop operation has started finish it and change to move/copied directory. Otherwise just change to the selected direcory.
I think this improvement is necessary because drag&drop using items in the separate tree as source is completely impossible. The current up/down scrolling is fine but there are alternatives: Mouse wheel and scrollbar.
- ghisler(Author)
- Site Admin
- Posts: 50390
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Hmm, I don't know how useful it would be to have drag&drop with only a single folder...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
I'd prefer an option... It's hard to tell which variant is more useful without testing for at least a couple of days...Lefteous wrote:What do other users think?
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
- StickyNomad
- Power Member
- Posts: 1933
- Joined: 2004-01-10, 00:15 UTC
- Location: Germany
2roentgen
Problematic selection (current implementation:
C:\Dir 1
C.\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
Here the user tries to create the same selection. First he selects the the whole subdirectory which of course includes the subdirectories when copying.
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C.\Dir 3
Then he tries to select also subdirectories of the selected directory. The selection is removed from the first level directory.
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C.\Dir 3
This solution should also be applied to the normal tree of course. Along with some other improvements I could even imagine to _use_ the normal tree.
The multiple selection in the normal tree is quite problematic and it's one of the reasons why I never really used the normal tree. It's possible to select items in different levels of the same hierarchy. Multiple selected items in the separate tree which are indepedent from from the currently selected directory could be a good idea but this and probably other problems must be solved before. The solution for this problem would be to unselect the problematic part of a selection when a new selection is performed.right click = select (multiple items)
Problematic selection (current implementation:
C:\Dir 1
C.\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
Here the user tries to create the same selection. First he selects the the whole subdirectory which of course includes the subdirectories when copying.
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C.\Dir 3
Then he tries to select also subdirectories of the selected directory. The selection is removed from the first level directory.
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C.\Dir 3
This solution should also be applied to the normal tree of course. Along with some other improvements I could even imagine to _use_ the normal tree.
2Lefteous
You're absolutely right. As I never really used any of the trees, I didn't see that far.
Anyway... your suggestion is a must.
I don't think it's programmatically difficult to automatically de-select the parent dir when some sub-dirs are selected. Or better yet: when dragging with right click automatically ignore sub-dirs and select directories at the same level.
...
... after doing some tests ...
...
The current implementation is not that bad after all (in the standard tree).
If one selects like:
c:\dir
c:\dir\subdir1
c:\dir\subdir2
Upon copy we end up with:
d:\dir (which contains its subdirs)
d:\subdir1
d:\subdir2
I see this as a feature actually. If one needs to copy only the parent dir he should be careful enough when selecting.
Better would be to have both behaviours, as options to suit everyone needs, but most of these are just dreams now...
You're absolutely right. As I never really used any of the trees, I didn't see that far.
Anyway... your suggestion is a must.
I don't think it's programmatically difficult to automatically de-select the parent dir when some sub-dirs are selected. Or better yet: when dragging with right click automatically ignore sub-dirs and select directories at the same level.
...
... after doing some tests ...

...
The current implementation is not that bad after all (in the standard tree).
If one selects like:
c:\dir
c:\dir\subdir1
c:\dir\subdir2
Upon copy we end up with:
d:\dir (which contains its subdirs)
d:\subdir1
d:\subdir2
I see this as a feature actually. If one needs to copy only the parent dir he should be careful enough when selecting.
Better would be to have both behaviours, as options to suit everyone needs, but most of these are just dreams now...

TC for Linux please!
2roentgen
Is the user really expecting to copy twice and get a whole new directory structure? I really cannot imagine that this is a feature.
In addtion you'll face name conflicts sooner or later.
Is the user really expecting to copy twice and get a whole new directory structure? I really cannot imagine that this is a feature.
In addtion you'll face name conflicts sooner or later.
Oh well - that's really not the users job.If one needs to copy only the parent dir he should be careful enough when selecting.
That's indeed a good idea but the user may intend to add directories to the current level level or select directories in a subdirectory. Maybe this could be controlled by a modifier.when dragging with right click automatically ignore sub-dirs and select directories at the same level.
Naturally, if one selects a parent folder in the tree (for copying, drag and drop, etc) the typical user would expect that all of the parent folder's subfolders would also be selected, but multiple selection schemas such as those described above are not typically supported in folder trees.
Because of that, any non-standard implementation of folder selection behavior in the TC trees could be initially very confusing. I personally "get" some of the benefits offered here, but an implementation that deviates from a typical newbie's expectations for tree behavior might inadvertently lead to unfortunate results.
Can TC please just start with something in between the currently deficient tree model and a "best of all possible worlds" model? There are a great number of exemplars already in the marketplace from which to learn what is important in a folder tree implementation.
Because of that, any non-standard implementation of folder selection behavior in the TC trees could be initially very confusing. I personally "get" some of the benefits offered here, but an implementation that deviates from a typical newbie's expectations for tree behavior might inadvertently lead to unfortunate results.
Can TC please just start with something in between the currently deficient tree model and a "best of all possible worlds" model? There are a great number of exemplars already in the marketplace from which to learn what is important in a folder tree implementation.
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
I think you may be over-simplifying things. What will happen for instance if the user tries to select the following:Lefteous wrote:The multiple selection in the normal tree is quite problematic...
<SNIP>
The solution for this problem would be to unselect the problematic part of a selection when a new selection is performed.
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir2
C:\Dir 2\Dir1\Dir2\Dir1
C:\Dir 2\Dir1\Dir3
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
TC cannot know what the user intends to select in order to unselect something. I think there are cases in which guessing is far too complicated.
Last edited by wanderer on 2007-01-19, 17:41 UTC, edited 1 time in total.
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
An idea might be to select all folders at the same level with the start of the selection but who can assure us that this is always the optimum thing to do?
For instance, in the previous example, it would select the following:
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir2
C:\Dir 2\Dir1\Dir2\Dir1
C:\Dir 2\Dir1\Dir3
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
But is it really what the user will always want to select?
For instance, in the previous example, it would select the following:
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir2
C:\Dir 2\Dir1\Dir2\Dir1
C:\Dir 2\Dir1\Dir3
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
But is it really what the user will always want to select?
Last edited by wanderer on 2007-01-19, 17:41 UTC, edited 1 time in total.
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
So, what would happen in the case i describe above? What would be the selection when the user finishes "selecting"? If i understood your idea correctly, it would become:Lefteous wrote:2wanderer
Well I made a suggestion how this could be solved...
C:\Dir 1
C:\Dir 2
C:\Dir 2\Dir1
C:\Dir 2\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir1\Dir1\Dir1
C:\Dir 2\Dir1\Dir2
C:\Dir 2\Dir1\Dir2\Dir1
C:\Dir 2\Dir1\Dir3
C:\Dir 2\Dir2
C:\Dir 2\Dir3
C:\Dir 3
Right?
Last edited by wanderer on 2007-01-19, 17:41 UTC, edited 1 time in total.
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.