View Single Post
Old 05-25-2021, 11:52 AM
Spliff Spliff is online now
Registered User
Join Date: 04-07-2021
Posts: 72
ad u) again: Another important use case for a "pre-selection" of multiple items, even in the tree ("Data Explorer"), occurs whenever the users wants to LINK multiple items to some other, "secondary" parent ("Tree - Link/Move to".

Here again, as in the Search results pane (where the user cannot manually move those items together, for "grouping" them), the user will not WANT to move those items together, for "grouping" them, since they want the "original" tree to be left unchanged, albeit they want to select multiple items from within it, which then all will be LINKED to some other, "secondary" parent item, i.e. be linked into some other sub-tree within the ontology the "full" tree represents.

ad p) I may have partly mistaken here: The - unwanted - selection of the whole tree regularly occurs whenever I put a sub-tree (i.e. parent item with child item) just beneath another, "target" parent item, then do "Tree - Move right" (by shortcut, but I always give the menu commands for precise identification of the command), and also, but depending on the number of the items, when I put a "block" of siblings just beneath another (then: sibling), select them, then do "Tree - Move right", in order to make them child items of their new parent item. (Only sometimes, this even occurs when I "make a child" just one or 2, 3 (former) siblings new "children". In other situations though, I haven't observed this behavior lately, so perhaps my alleged "observation" was worded to broadly - sorry for that! And it's understood that creating "children" this way (i.e. not by ^x, then ^v upon the new "parent", where the sub-tree should remain collapsed indeed, which is not always the case currently), the sub-tree will be expanded (I personally would prefer otherwise though), but the "full selection" of the whole tree in this situation seriously hampers the user's knowing "where in the tree" they currently "are", e.g. pressing "ArrowLeft" then, in order to get rid of the "all selected" state, will navigate to some higher-up parent; in other words, even the "navigational", more precisely, the navigational position, is lost by this. Current way-around, as said: avoid "block" moving by arrow-keys, but go by ^x, ^v.
Reply With Quote