Tree problems and suggestions

[Spliff]

ad u) again (my "Mark" suggestion): I have discovered that such a "semi-persistent selection" would also be of great use in the search results pane:

Many users will have many items in "wrong" sub-trees, or in not-specific-enough sub-trees, or in "Inboxes", etc (sub-trees C (current) and T (target) may be independent of each other, or T would be another child of C, i.e. a current sibling of the item(s) to be moved, etc.).

Instead of trying to select those manually in the tree, in many use cases they will take advantage of the search (for specific terms), and then the search results pane, just for the "Item Title", or in combination with "Item Parent" (!). Here, just as you would in the tree, you would like to check / verify if the item in question really belongs into the alleged target sub-folder, by verifying the text/content.

This, as in the tree, currently arises a memory problem: You will have to memorize the items you have already checked, and which are "good" for the intended move, and which thus you will have select again, by control-clicks, vs. those where your check resulted in deciding they should either not be moved, or at least not moved to the common target sub-tree to which you want to move your intended selection; since, as in the tree, any selection will delete previous selections, and multiple selections (which are possible) will prevent from checking the content.

Thus, for the search results pane (which is used as a "filter" pane in these common use cases), too, a "pre-selection" (toggle, e.g. by the space bar) would be of tremendous usefulness!

(Ditto for using the search and search results pane for intended copies / duplication or - in theory - links; in numbers / bulk.)

[Spliff]

ad u) again

Please allow a demonstration WHY such a "mark" functionality would be of even much greater interest within the search results pane, than within the tree; it goes without saying that once such functionality were coded, its implementation also in the tree (where it's not that much needed after all) would not be a real, additional problem.

When I gather several dispersed items in the tree, in order for group / "bulk" processing of them afterwards, I can manually move them together, then just remember (or try, if needed), the very first and the very last item of this "block".

On the other hand, search results are listed in alphabetical order, and thus I cannot "move them together", as I would do in the tree. Thus, here, I really have to remember every single item to be "block-processed" then, and beyond just some, my memory fails me, and I risk including items into this "block-processing" which don't belong there, or then, I just can remember and then select just a few, 3 or 4 at a time, then must do the block-processing, and again and again, for exactly the same processing (e.g. moving them into a specific subfolder in the tree).

[Spliff]

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.

[Spliff]

ad u) again: With so many imported items, I absolutely need some "pre-selection", i.e. a way of selecting multiple, non-consecutive items for further processing, while being able to check the respective item contents, except another way than just regularly selecting those.

So I gave this another thought, and found a quite obvious, intermediate solution to the problem: Instead of selecting those items, I assign them a special flag (red, by shortcut). Then, before processing the group, I manually select them (by control-clicks), then reassign the flag "no flag" to them, then only process them as a group.

This does not work upon originally flagged items, since it would take away that "real" flag, but considering most items are not flagged originally, it's the best way I could find for the majority of items at least, and this intermediate solution works both in the Data Explorer, and the Search Results pane.

If you have a file manager which does not have pre-selection (as Total Commander has) but which has different display formats for different attributes, AND (as does UR for flagging, etc.) allows for changing the attributes of multiple selected files at the same time (and also with a shortcut), you can apply a similar way to files (e.g. first applying "hidden" or "system", then de-applying those attributes again), there again with the limitation that you can't do that for files which already have these attributes, or even, there, with the additional risk that you could inadvertently include such files in your final selection - in UR, you'll obviously use some specific flag exclusively for this pre-selection.

[Spliff]

y) And another one: When I try to "indent" a block (i.e. given sibling items A...Z, of which L is to become the parent of siblings M...T), this works fine, with selecting M...T, then "Tree - Move right", if M...T are either single items, or if all of the items M...T which may be parent items of some other child items "further down", are "collapsed", i.e. if no (and not even a single one) "further-down" child item is currently visible; if it is, the "Move right" command will have no effect, even though it's obvious the command should only work onto the "outer block" of the selection, and thus leave alone any possible "further-down" children in the block (as it correctly does if those immediate children are "collapsed").

[Spliff]

z) Just a minor glitch in a special situation:

While my "secondary" databases work as expected, in my "main" database, AFTER having (explained in the thread "Reasonable database sizes") added more than 50,000 items to more than 70,000 items, then having deleted those additions again (and having them deleted from the Recycle Bin, too), then having done a "Compact and repair":

When I select (single or several) items, then "cut" them (^x), the repective tree icons (all the native ones, e.g. for the "Text" items which in my case make 99.9 p.c. of the lot) are NOT greyed out anymore (and this applies to "regular" tree entries as well as to "formatted" (i.e. by flags) entries; this behavior has been persistent for the last few days now), but then the move (both the cut and the insert (^v)) work as expected.

[Spliff]

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.