XYplorer Beta Club

I vote for the changes you have made to the tree node visibility.

j_c_hallgren wrote:or have it be row 3 up from the bottom, when possible.

jacky, I'll be the first to admit my concept was likely wacko so would the quoted idea make any sense to you instead?
Just trying to have some consistency where possible...and if the selected item was either of last two rows, then obviously it would have to be different.

j_c_hallgren wrote:

j_c_hallgren wrote:or have it be row 3 up from the bottom, when possible.

jacky, I'll be the first to admit my concept was likely wacko so would the quoted idea make any sense to you instead?

hmm.. We're talking about nodes that cannot (due to their position on the bottom of the Tree) be put on top (1st/3rd row), right? So I would think the best would be to simply put them as up as possible.

Why only 3 row up when it can be more ? I see the "can't be 3rd row from top so it's the 3rd on from bottom" idea, but I'm not sure it would be so natural. Because one expects the node to be on top on the Tree, and if it's not, there could be the "what the hell?" question

But I think to see that the Tree has been scrolled as much as it could be, and the node put as high as it could be, makes more sense/seems more natural than to have it kept somewhere down. Having the node as high as possible is actually already how it behaves (well, in 5.80.000 at least) when dbl-click and the node is one of the last ones.

If only, because one wants the node on top, to see it's subfolders, but keeping it on 3rd row from bottom when it could go up by, say, 10 rows, will surely not be seen as a good thing, IMHO.

Just imagine this: the node can not be on the 3rd rom from top, so XY puts it on the 3rd row from bottom, right? But the node could actually have been put on the 4th row from top!! Don't you think you'd have liked it better on the 4th row from top??

In my present setup, I have 27 rows of tree showing...so when the selected folder is not on 3rd row, even though it's most likely marked with the gray box, spotting it is thus just a tad harder because it could be anywhere in those 27 rows...that was my reason for the suggestion...to make it more predictable.

But I do think this type of discussion is still a good thing, as we can share differing points of view, and maybe see things in a new light from that.

I changed it to:
- do not scroll if current node is visible without scrolling
- dbl-click lifts current node to top position

I'm still slightly unhappy about the 3rd row because it is so arbitrary. Why not 2nd or 4th?? I think it is confusing to the newbie.
Middle of the view would be clearer, but unfortunately it is not good (it's too low).

((jacky will like this... ) The simplest and self-explanatoriest (sorry) would be 1st row. So, to give you an impression, I simply did that, too:
- if current node is invisible auto-position it at the 1st row of the view port

The downside with row 1 is that it doesn't show any context or parent levels, so to see those, one thus has to scroll up, which is extra effort.

I personally like to see most all the parent levels to folder I'm in, thus giving me quick access to those, as my pointer may be closer to tree than breadcrumb at times.

I could see, as solution to this issue, a possible user option (or INI setting even) with value of maybe 1-5 that would allow us to decide where to put it...obviously, if the selected folder is 1st on list and you've got a value of 4, that it couldn't apply, but this would allow us who want to see selected with parents to be able to, while those who wish to have it on top could also.

j_c_hallgren wrote:The downside with row 1 is that it doesn't show any context or parent levels, so to see those, one thus has to scroll up, which is extra effort.

I could see, as solution to this issue, a possible user option (or INI setting even)...

Yes, but I find this mildly overdone. There must be some end to configurability... IMO

If three people now tell me: 3rd row was better! I'll put it back to 3rd...

admin wrote:Yes, but I find this mildly overdone. There must be some end to configurability... IMO

That's why I suggested INI setting, as I view it as similar to a Registry hack for us power/techie users only...every setting doesn't have to be available via Config panel, just the commonly used or likely to be changed more than once or twice ones.

j_c_hallgren wrote:

admin wrote:Yes, but I find this mildly overdone. There must be some end to configurability... IMO

That's why I suggested INI setting, as I view it as similar to a Registry hack for us power/techie users only...every setting doesn't have to be available via Config panel, just the commonly used or likely to be changed more than once or twice ones.

Okay, how then would you call this key? Let's hear some words no mortal has ever spoken...

I am with JC, I want to have good view of the neighboring nodes when I see the current node. It makes life lot easier. Like JC said its quite annoying to have to scroll up to see parent nodes.
It need not be middle but atleast some good number of parent nodes would be good.
Or maybe default it to first row and double clicking should center the node. or somethign like that. because for sure having able to see only lower part of tree is PITA.

admin wrote:Okay, how then would you call this key? Let's hear some words no mortal has ever spoken...

IMHO, given that value seems to relate to following terms at least: Row number, Scroll, Tree, View
Maybe: RowNbrToScrollTree?
Or RowNbrForTreeScroll?
Or DefaultTreeRowNbr?
Something along those lines...and IF any values like this (intended to be tweaked) are placed at top of a section, that would make them relatively easy to find and modify.

j_c_hallgren wrote:In my present setup, I have 27 rows of tree showing...so when the selected folder is not on 3rd row, even though it's most likely marked with the gray box, spotting it is thus just a tad harder because it could be anywhere in those 27 rows...that was my reason for the suggestion...to make it more predictable.

yeah I understand that, but to quote myself:

Just imagine this: the node can not be on the 3rd rom from top, so XY puts it on the 3rd row from bottom, right? But the node could actually have been put on the 4th row from top!! Don't you think you'd have liked it better on the 4th row from top??

..Don't you? I mean the node would have been one row below where you'd expect it, wouldn't that be easier to spot than having to realize it couldn't be there and look on the bottom?
I know to me it's easier to spot that the scroll is maxed to the bottom, and find the node as high as it can be (and I got more than 27 rows )

admin wrote:((jacky will like this... ) The simplest and self-explanatoriest (sorry) would be 1st row. So, to give you an impression, I simply did that, too:
- if current node is invisible auto-position it at the 1st row of the view port

Hell Yeah!! Indeed I love it, current way is - to me - the best it could be!!

admin wrote:I'm still slightly unhappy about the 3rd row because it is so arbitrary. Why not 2nd or 4th?? I think it is confusing to the newbie.
Middle of the view would be clearer, but unfortunately it is not good (it's too low).

((jacky will like this... ) The simplest and self-explanatoriest (sorry) would be 1st row. So, to give you an impression, I simply did that, too:
- if current node is invisible auto-position it at the 1st row of the view port

I can't offer any real reasons why 2nd, 3rd or any other row, but I do have a reason for it not to be the 1st: You can't drag&drop anything to an item that is at the very top, the tree starts scrolling (which is of course good and the right behaviour but still makes this choice worse than the others). I'd vote for 3rd row as a default, too. It gives you some room. 2nd row is so close to the 1st that you can easily miss it and land on the 1st, starting the scolling. 4th would be fine as well, maybe a bit much for low resolutions. So 3rd isn't so arbitrary after all

And I'm all for ini-settings, they don't clutter the options dialog and give configurability to those who need it, and only those.

[edit: typos]

bye
Creat

Creat wrote:I can't offer any real reasons why 2nd, 3rd or any other row, but I do have a reason for it not to be the 1st: You can't drag&drop anything to an item that is at the very top, the tree starts scrolling

/me disagrees, obviously. It's true the Tree starts to scroll, but its a known standard behavior that you must deal with, can happen on many other occasions (just like dragging files outside XY by going down to the taskbar usually makes the List scroll), and more important is: why would you drop anything on your current location? You're there, just drop on List if you need to
And if you went down to a subfolder, well then scrolling must be used yes, before or durring the d&d, but I think that's part of the normal daily life of file management...

Creat wrote:And I'm all for ini-settings, they don't clutter the options dialog and give configurability to those who need it, and only those.

Agreed. And to throw a couple ideas in:
PosForTreeAutoScroll
RowInTreeAutoScroll

TreePosForAutoScroll
with that, the meaning is actually pretty clear