View Single Post
Old 07-08-2021, 09:05 AM
Spliff Spliff is online now
Registered User
Join Date: 04-07-2021
Posts: 72
ad s)

As said above, when I select several items, in order to move them up or down, in order to get right beneath their future common parent item, then wanting to do "move right", in order to make them child items of that (common) new parent item -

i.e. having siblings n, o, p, in direct order (i.e. no other items in-between), then moving them up e.g., right beneath sibling a, then wanting to do "move right, in order to items n, o, p become child items of item a, even for just TWO such siblings, n and o, o will "lag behind", between n and o there will appear some item x, y z which are in-between the original position of items n and o, and then item a.

But - I verified this with n and o and n, o and p, i.e. with 2 or 3 (originally) "compound" items at least, probably the same will apply to "bulks"/"sets" of more than even 3 such items -, when I then reach the position "a minus 1" for the first item in the group at least (here, item n), and when I then do the "move right" command, ALL 2 or 3 items of the "group" - which are now dispersed between other, not concerned items, but always selected indeed -, are correctly made child items of item a, not of the respective items beneath of which they are currently placed.

Thus, the problem described in s) is not a procedural one, but a visual one, the visual tree rendering just not being in synch anymore with what will technically be done with those items; and even when I then wait for many seconds, the tree is not "updated".

Thus, it's not a item processing problem, here at least, but clearly a problem of visual updating of the tree lacking.

I discovered this by accident, but then, even when such "group" items lack behind after moving, the user could trigger the "move right" command indeed, without triggering unwanted results by this, at least for 2 or 3 such items.

This being said, I hope that some kind of "group being held together in all situations" functionality could be implemented, see other points in this thread where this would be needed indeed.

(Users would avoid the specific problem described here by doing ^x, then going to the intended parent item, then pressing ^v, anyway.)

EDIT: Just tried this with 12 (!) items, of which 11 were trailing behind, i.e. with another 11 items, not included within the group, in-between. All 12 items (always selected, independently of their respective tree position now) were correctly made child items of their new current target item, by "move right", i.e. the very first one, immediately beneath the new parent item, and every one of the "left behind" items, too.

Last edited by Spliff; 07-08-2021 at 09:33 AM.
Reply With Quote