Tree problems and suggestions

[Spliff]

(Given that tree order is manual.)

a) Unwanted vertical jumps (automatic vertical scrolling) in general

I navigate a lot within the tree (in a simple way, without automatic expand/collapse of subtrees), within some vicinity, i.e. within the visual part of the tree (around 60, 70 items visible at the same time). Even then, after manually expanding and recollapsing even tiny subtrees, there are a lot of vertical jumps within the tree control, i.e. it seems the control tries to think for the user, and most of the time, those automatic scrolls are not what I want. Could this be changed somewhat, after discussion with other users what would make more sense, or could there be implemented a switch that would stop the automatic scrolls altogether?

b) Unwanted vertical jumps (automatic scrolling) after cut-and-paste (even of single items)

I do a lot of cut-and-paste from one tree position to the other, by control-x/v, within the tree. I do not use Item-Link/MoveTo since it is within a vicinity, and I already see the target item in the tree, whilst by the special command (which moves without causing the problems described here), I would have to look up the target (new parent) item.

In this use case, the automatic vertical scrolling is extreme, even if I only cut-and-paste a single item or a parent item with (originally) collapsed subtree.

c) Unwanted and unpredictable automatic expanding of subtrees after cut-and-paste

This is totally unpredictable, and unwanted since for further working, those expanded subtrees then have to be manually collapsed again. Sometimes, the subtrees stay collapsed, as expected, and then, just some subtrees automatically expand, often the very last one of several subtrees included in the subtree which has been shifted, and then again even several inner subtrees are expanded.

This does not even reflect the previous expansion state of the subtrees in question, since previously, they were all collapsed, and even for possible further cut-and-paste of the same subtree, often the same sub-subtrees are (after having been manually collapsed before the new move) expanded again after the new move, whilst others, which had remained collapsed previously, remain collapsed here again.

d) Unwanted horizontal scrolling in general

In Options-Trees-Behavior, there is a switch (toggle) "Scroll horizontally on selection change to keep text visible" which I put "on" (or which was "on" by default); I also tried "off" but this will not help but for rare use cases. With "on", and expected, there is a lot of automatic (and minor) horizontal scrolling, sometimes so minor that it is not even enough.

I would largely prefer no horizontal scrolling at all, thus I suggest a three-position switch instead with the default where there is some automatic (system) scroll, the current option by which UR tries to adjust the automatic system scroll as it does now, and a third option to simply deactivate the scrollbar, which would then mean that the control would stay fixed at the start of the line in all cases. This would probably need a restart of UR but would be worth it. On today's broad screens, most of the time, the user would then be able to read the necessary portion of the item titles even then, without facing an ever-scrolling screen, and in rare cases, they would just press F2 or read the full item title above the content field.

e) Partially incorrect moves when outdenting ("move-left") blocks

Speaking even of simple blocks here, i.e. one parent item with a list of direct child items (no further-down subtrees).

Let's have a subtree on level n (does not matter) A, B, C, D, E. Now A (may be B, C..., problems if it's not E, i.e. the very last one in the list) has 26 child items a, b, c... z. I want (all of them, or in this case, just first 10 items a to j) to become siblings in the range A...E.

This most of the time triggers problems. I select, in A, a...j, then do "move left" (shift-control-leftarrow). I expect the A...E range to become A, b...j, B, C, D, E, or perhaps, in an intermediate stage, A, B, C, D, E, a, b...j, and then UR putting the a, b...j all after A and before B.

In most cases though, some of the a...j, after their intermediate - on screen for some second visible - placing after E, get placed / stuck between B, C, D and E in those upgrade-move cases, and whilst as a general rule, the longer the list, the more items will get stuck in such unwanted positions, but sometimes it works a little bit better even for longer lists, then again very badly for rather short lists.

Similar if the list a...z is within B (etc.), and in the "B" example, the result list should be A, B, a, b...z, C, D, E, but the a...z are mostly stuck between B, C, D, E again, the rule being, it's always beneath the wanted target position, never above it, i.e. a "B" list a...z would be dispersed beneath B, but no "B" subitem a...z would be between A and B.

In order to avoid the described chaos, for long lists, I first have to move (in the "B" example) B beneath E, i.e. to the last position in its own range, then do the block move the the left, then select the new A...E items (formerly a...z) one-by-one or in tiny blocks, 3 or 4, then move them up by shift-control-uparrow.

Since if then I select them as a block, then cut them, then paste them "into" A (or some other), they become child items of that, not siblings, and I am in the same situation as I had been upon start, since a command "Paste as sibling(s)" is not available.

I thus suppose that for moves of several items, there is no function which gathers the commands to be triggered, but the necessary commands are just triggered one after all, and when the HDD cannot write fast enough then, the sequence "chokes"? (Doing very much of moves, etc., I fear wear with putting my UR databases onto my system SSD, but my HDD is a professional and fast one, as well as my pc.)