Total Commander

In the new TC trees, expanding a folder in the tree (by clicking on the "+" beside it in the tree or double-clicking the folder itself) causes that folder to scroll toward the top of the tree. Not only does the folder move toward the top of the tree, but the mouse cursor jumps to the same location!

Here is an image illustrating this behavior.

I think the reasoning behind this is to display as many of the subtree folders as is possible, which initial seems to make good sense, but consider...

After expanding the folder, the mouse cursor position, the mouse's physical position, and user's eyes all become "unsynchronized" with each other.

Consequences for this are:

Since the user's hand itself has not followed the relative position of the mouse cursor, movement of the mouse after expanding the tree (usually down the list of subfolders) can cause the mouse to drop off the mouse pad (if any) or even the desk. This is manifestly irritating/annoying/inefficent and negates any benefit from showing as many subfolders as possible.

And not only is the user's hand "out of position" after expanding the folder, but the user's eyes are too! There is a momentary cognitive confusion while the eyes track UP the tree looking for the folder which is no longer where it was when clicked.

This behavior breaks every GUI design rule in the book (well, many of them ).

So what behavior would make more sense to me?

Very simply: don't scroll the tree when expanding a folder!

I totally agree.

This, and the limited funtionality of the TC trees is the reason I do not use them.

Greetings,
Henrie

You mean this?
http://ghisler.ch/board/viewtopic.php?t=13028

Well yes in part... I hadn't seen that thread. My wife won't let me read every single word of every forum I participate in... It's OK though, she's a lot more fun than reading the forum!

There is a simple fix for this tree behavior, though, considering that it had to be deliberately coded in the first place. The TC tree doesn't look like or behave like a typical tree control at all. The highlight behavior and lack of mouse-responsive connecting lines suggests it's a list control of some kind. A toggle in the ini to simply skip over the block of code that implements this specific behavior would be just the ticket.

Other commanders have perfectly-adequate-to-superior tree + folder tab implementations, but I keep returning to these issues in this forum because I cannot do without some things in TC (I depend on many lister, file, and content plugins that are not available anywhere else).

Out of curiosity (i never use the tree otherwise), I tried it, and i must admit, it is very confusing, that the mouse pointer all of the suden just disappears from sight. I definitely hate this feature. Even if i use the keyboard, the selected folder just jumps away on opening it. No, please!

Here's another version of the same thing!

2JohnFredC
For me this is _not_ a technical problem. I performed several tests and couldn't find a reason why the TC "tree listbox" should be the problem. I agree that a new option would be great although we are already in RC1 state.
If could be interesting to see if scrolling the tree but keeping the cursor position could be another option. This is what a "normal" tree does. I guess I have to test such different behaviors to make a decision.

2Lefteous

Definitely not a technical problem... just a questionable design decision.

In my experience most trees expand downward from the cursor position, keeping the expanded folder and mouse cursor stationary. The clicked control should not move!

Illogical/irrational mouse/control movement are the fodder for prank software like the link posted above as well as this one.

So... you see I was just being somewhat sarcastic with that last post... humor, you know. April Fool's day is tomorrow!

In my experience most trees expand downward from the cursor position, keeping the expanded folder and mouse cursor stationary. The clicked control should not move!

Well in this case we have a different experience. I tried Explorer and SpeedCommander and both scroll the current item to the top.

Thanks for pointing that out. I do stand corrected.

Apparently, some trees scroll based on the number of folders being expanded. If the number of folders exceeds a certain number (say, the number that will fit vertically), then sometimes the parent folder scrolls.

Perhaps I only notice a behavior when it makes me slow down (or speeds me up). Lately this folder/cursor jumping behavior has slowed me down to the extent I have gotten upset with it. It is the movement of the mouse cursor that is the most irritating.

I definitely have an emotional "bee" in my bonnet about nearly every aspect of the new trees that has me reactively posting without doing adequate research. Will try to rein that in and experiment with a more wide range of examples before posting next time.

It is the movement of the mouse cursor that is the most irritating

I fully agree.

2ghisler(author)
Can you give us a statement on this issue please?

This isn't an issue, it's a feature! The idea is that when you open a directory in the tree, you want to see its contents - so it makes no sense to open it below the last visible line. That's why it's scrolled up. The mouse cursor is then placed on the [-] button so it can be re-closed easily.

2ghisler(Author)

This isn't an issue, it's a feature!

That's what we assumed.

The idea is that when you open a directory in the tree, you want to see its contents - so it makes no sense to open it below the last visible line. That's why it's scrolled up.

That's absolutely reasonable. This shouldn't be changed.

The mouse cursor is then placed on the [-] button so it can be re-closed easily.

That's not ok. The problem is that the user never knows if the subdirectories of an opened directory require more space than available. The consequence is that he never knows if the cursor is moved or not. This is what it makes so confusing. Please don't move the cursor (or create an option!

Well, the user doesn't NEED to worry whether the mouse cursor will be moved or not - it will always remain on the folder on which he clicked!

2ghisler(Author)
Your assumption seems to be that the typical use case is to directly closing the opened directory after opening it. All users who complained about this behavior seems to have another use case in mind: Exploring the opened directory starting from the current cursor position.