Tree/Tab Expansion Memory and Focus

[Buttonpusher]

I noticed that while scrolling through the tabs (with different drives), the folder tree will expand to include the new drive from the next tab. I other words the expansion state of the tree is not linked (saved) to a tab. After going through 5 or 6 drives the tree will be very long!

Also the tree focus (which is remembered) should always default to the middle of the scroll range of the tree. Cruuently, the frist tab is always at the top and the others near the bottom of the range.

[surrender]

I noticed that while scrolling through the tabs (with different drives), the folder tree will expand to include the new drive from the next tab. I other words the expansion state of the tree is not linked (saved) to a tab. After going through 5 or 6 drives the tree will be very long!

Use ctrl+shift+F4 to make it as short as possible.

Also the tree focus (which is remembered) should always default to the middle of the scroll range of the tree. Currently, the first tab is always at the top and the others near the bottom of the range.

I agree on that one. Its good to have few pixels above and below the selected tree item. Makes navigation easier.

[surrender]

I like the changes you have made to the tree node visibility.

[jacky]

Code: Select all

    * Tree: Experimentally changed the auto-scroll-current-node-into- 
      view algorithm. Before, the strategy was to scroll as little as 
      possible while as many as possible children of the current node 
      (if expanded) were visible. Now, it is much simpler: if possible 
      the current node is positioned to the 3rd row of the view port. 
      It might be good because the position is easier predictable now 
      ... you tell me.

Well, I hate it!

No really. I mean, I can see why people didn't like it when the new selected node stayed at the bottom, I never really liked it myself, but here is what I want(/need) it : the selected node should be the FIRST one visible on Tree (not 3rd).
That is how I want it, and usually I would either get it, or dbl-click to get it (just like it works on List, btw). But now even the dbl-click gets stucked on the 3rd row!!

Seriously, you can keep it that way if you want, but you have to get the dbl-click work as it used to - and should - which is put the selected node on the 1st row.

[j_c_hallgren]

I'm still somewhat confused on when/why tree scrolls the way it does...I've tried some experiments with both prior and current vers, and neither one seems to do what I'd kinda prefer...but having it show as 3rd entry makes more sense to me as that typically keep at least part of the parents to selected child in view, so I can better see it in context.

Personally, I'd like the tree view to not be affected by what any other tab does or doesn't do, so that if tab 1's selected item is at row 12, keep it there, and where other tabs are moved to shouldn't affect tab 1's position...having the tree move to another position when I come back to it from another tab is, to me, quite irritating! If I want to see all the parent levels to my current selected, I should be able to have them stay on screen.

Is this auto-scroll on/off optional, as I don't see it currently as such?

[jacky]

Personally, I'd like the tree view to not be affected by what any other tab does or doesn't do, so that if tab 1's selected item is at row 12, keep it there, and where other tabs are moved to shouldn't affect tab 1's position...

Yeah but what you might be missing here is this: there is only one Tree, which is shared amongst all tabs.
What you describe would be like having one Tree per tab, sort of. But because there is only one Tree in XY, collapsing/expading a node on one tab can "affect" other tabs, since they share the same Tree.

Is this auto-scroll on/off optional, as I don't see it currently as such?

No it's not. But it's not really an auto-scroll option, I mean it is I beleive a very natural & expected behavior: when you change location (should it be within a tab or by changing tab) then the Tree's location is changed, so its scrolling is updated as well to have the selected node into view.

[j_c_hallgren]

Yeah but what you might be missing here is this: there is only one Tree, which is shared amongst all tabs.
What you describe would be like having one Tree per tab, sort of. But because there is only one Tree in XY, collapsing/expading a node on one tab can "affect" other tabs, since they share the same Tree.

I DO realize there is only one tree! But suppose I'm in "Program Files" (which tends to have numerous sub-folders) on tab 1 at "Adobe", and when I initially selected it, "My Music" was the top entry showing in tree...then in tab 2, I'm at "InterActual", with "Dlink" as top entry...assuming I don't do any expansion/contractions of folders, why can't those initial top entries remain as such? Seems that sometimes they do, and sometimes they don't (in which case, selected becomes 3rd row).

Putting it another way: Say I have 100 sub-folders in Program files, and I can see 20 at any one time...I select folder #10 (halfway down) so now I see #1-20 with #10 marked in tab 1...in tab 2, I scroll down and get #35-44 in view, and select #39...now whatever I do in any other tab, I would like to still have #1-20 in tab 1, and #35-44 in tab 2, unless I've done something to explode #36 in tab 3, let's say, in which case, having #39 be the fifth entry in list in tab 2 would keep the view similar to what it was.

No it's not. But it's not really an auto-scroll option, I mean it is I beleive a very natural & expected behavior: when you change location (should it be within a tab or by changing tab) then the Tree's location is changed, so its scrolling is updated as well to have the selected node into view.

Yes, keeping the selected node in view is critical, but moving the tree up/down when nothing has changed, doesn't make sense to me.

[admin]

So, we got some mixed emotions here...

Obviously, I chose the 3rd row to show some above context. Of course this is a very arbitrary choice -- but wouldn't it be overdone to make this configurable?

I see jc's point "don't scroll if the new node is visible without scrolling".

Waiting for more feedback from others...

[jacky]

Putting it another way: Say I have 100 sub-folders in Program files, and I can see 20 at any one time...I select folder #10 (halfway down) so now I see #1-20 with #10 marked in tab 1...in tab 2, I scroll down and get #35-44 in view, and select #39...now whatever I do in any other tab, I would like to still have #1-20 in tab 1, and #35-44 in tab 2, unless I've done something to explode #36 in tab 3, let's say, in which case, having #39 be the fifth entry in list in tab 2 would keep the view similar to what it was.

Yeah I see that, but right now the only thing remembered is the selected node, nothing regarding scroll position. If it could be added, then maybe we could have XY to restore the scroll position (put back on first row the same one as before) and make sure the selected node is visible, and if not then scroll it up.

Obviously, I chose the 3rd row to show some above context. Of course this is a very arbitrary choice -- but wouldn't it be overdone to make this configurable?

As I said, you can let this behavior as it is now, I could live with that, but you have to restore the way dbl-click works! It must be consistent with what's on List, and put the focused item on first row.
In other words, you were supposed to change the way the scroll position is set when changing location(/tabs/etc), so do that, but ONLY that, please do not affect the "putting into view" feature that occurs on dbl-click!

[admin]

As I said, you can let this behavior as it is now, I could live with that...

Sounds not very enthusiastic.

The dbl-click thing... yep.

[jacky]

As I said, you can let this behavior as it is now, I could live with that...

Sounds not very enthusiastic.

Well, that's because I miss my dbl-click so much!

Truth is, I liked it better the old way when the selected node would be on the first row, as it saved me a dbl-click

That said, as I mentionned, for me the very best would be the first row.
Might be me, but usually I mostly care about the folder I'm in and its subfolders, so having it on 1st row means a "cleaner" view & more of its subs than anything else I don't really care about. I could always go up or scoll if I needed to...

So yeah obviously I would like it better if it was doing it directly, all the time Using the 3rd row instead means I'll have to dbl-click more, like all the time, and that's why I'm not too enthusiactic , cause overall I think the old way suited me better, as on times it would be as I want, only on other times would a dbl-click be required...

As I said, you can let this behavior as it is now, I could live with that...

Sounds not very enthusiastic.

Yeah and actually, as times goes I become even less enthusiastic!, because now when I'm working on D:\Folder and so have put it on the 1st row on Tree, if I go to a subfolder and then go Up, that damn Tree is moved a little as the D:\Folder node is put on 3rd row!! That behavior really does annoy me (a lot)

Actually, I'm back on 5.80 (didn't kept a 5.80.001) and I really like it better that way I think the "don't scroll if the new node is visible without scrolling" really is a must.

[j_c_hallgren]

And in my case, I tend to have selected parent folders in my catalog, and when I go there initially, and then expand certain ones within that (typically only a handful), I'd like to have the original parent folder (and any above current) still visible when I return to a tab, IF they were visible when I left that tab...so I'd like to have option to say that whatever row number (within current view) the selected folder was, I'd have that upon return...this could mean that my view changes somewhat, but tree wouldn't keep going up and down...

Because when selected becomes row 3 (or row 1), I have to scroll up to get the desired "above" folders in view, and then keep doing that almost every time I return to that tab...which kinda makes me want to NOT use more than one tab, just to keep position where I want it.

Update/Addendum:Speaking of scrolling, why is that when I select most folders from my catalog, they show in tree on row 3, unless the folder is near the end of tree? For me, this makes it inconsistent and harder to spot the folder (even though it gets marked), and I'd prefer it to be shown as row 3, even if that means a lot of empty white space below it...that's just me...maybe it's not possible, and I may be only one who finds this odd behavior.

Either that, or have it be row 3 up from the bottom, when possible.

[jacky]

Update/Addendum:Speaking of scrolling, why is that when I select most folders from my catalog, they show in tree on row 3, unless the folder is near the end of tree? For me, this makes it inconsistent and harder to spot the folder (even though it gets marked), and I'd prefer it to be shown as row 3, even if that means a lot of empty white space below it...that's just me...maybe it's not possible, and I may be only one who finds this odd behavior.

You might be alone there I mean I believe this is normal/standard behavior for any Tree (or List...) in all applications, should it be explorers, favorites managers, mail apps, etc
Always, the last item will be shown on the last/bottom-most line and the scrolling ends there, never goes to have that last line be the first (and only) visible ! It would be quite odd I think, to have it that way....

[surrender]

Personally for me 3 rows is already better, but like buttonpusher said, node at the center of the scroll would be the best because you can see equal number of folders both below and above the node.
And I dont see why XY should follow any standard when this way is good for users and more informative than having node at the last line.

[jacky]

And I dont see why XY should follow any standard when this way is good for users and more informative than having node at the last line.

We all agree there I think. And just to be clear, when I mentionned standard above it was the standard that makes the last node of a Tree be visible on the bottom only, never on top (with nothing but empty space below it). Or else it would mean even when all nodes are visible you could scroll to only show the last one, which would be a very odd/unexpected behavior IMO.