Tree problems and suggestions

[kinook]

We'll look into these, but it will take some time.

I was unable to reproduce g) or w).

Regarding v), uncheck Tools | Options | Fonts | Bold selected item.

[Spliff]

Thank you very much, Kyle, and I'm perfectly aware that this is a very long list!

ad v) As said already in the thread "Flag problems with custom font, I had created the (unnecessary) bolding myself, with my settings, so this was my mistake, sorry!

ad w) This does not appear systematically, just sometimes: I (inadvertently) create a new item but do not "finish" it, i.e. leave it in the state of it being named "New Text", and then cannot delete it before having created some other item. This does not seem to be a memory problem in my system, having 16 GB of which then just about 8 GB is used. I cannot identify any "external" condition for this to occur, but as said, this appears just sometimes, and in every such case, creating another item will then make possible to delete the item in question.

ad g) I said "often" above, which is not true, sorry. In fact, I encountered this problem yesterday, for 2 different moves from one database into another: Just the title was put into the target database tree, and then replicated as first and only line within the content, while the real content was lost. But as said, in these - admittedly just 2 - cases, the original item had not been transferred, in the source database, from its original position to the "Recycle Bin" of that database (as would have been expected for item moves from one database to another), but had stayed in its original position, so NO data was lost. I'm currently not aware of any other occurrences of this phenomenon - my "often" wasn't a lie, but very sloppy writing, sorry for this! I'll mention it, hopefully together with more details re the "general situation" whenever it will occur again.

ad u) My "mark" suggestion: It goes without saying that the technical realization I had in mind, is totally mistaken. In fact, no additional table column would be needed, since there is no need for persistence beyond the very next ^c, ^x or similar command, let alone beyond the current session. Such "markings" by the space bar or similar just should be held in a simple array which would then be processed together with the selection of the next ^c, ^x... command, then be emptied, or perhaps even the same array could be used as is used anyway for multiple mouse selections. And, not only the defunct "Norton Commander" used such a system (for file system files/folders), but it's also present in the current "Total Commander". As said, the interest of this functionality is that the user is then able to freely navigate to other items, possible candidates to be included in this selection, without destructing the previous selection, as would any navigation within a multiple mouse selection would do. And since currently there is no (other) use for the space bar within the tree...

Thank you very much again, in the meanwhile, Kyle! Having made such a very long list for "tree problems" does in no way mean that there would be any other Windows program like UR coming near to it in its usefulness!

[Spliff]

Some add-ons (details; I can't edit the above anymore):

ad p) (sudden selection of the whole tree after moving subtree; also when "indenting" subtree)

This also and often (here, "often" is correct) occurs by "indenting" a subtree, i.e. given (again) a sibling to become the new parent of a subtree, but instead of cutting the subtree, then paste it into the new parent (^x, ^v), I move the subtree (by multiples "move up") right beneath its new parent-to-be, then do a "move right" (which will expand the parent item, as expected here, but will also, and often, then select the whole tree).


ad e) (items from an "outdented" block "left behind")

One example here that may be helpful in HOW this occurs (and it occurs almost every time, for blocks of beyond just 3, 4, 5 items):

Inbox (= first level) with about 120 items; item on position around-20 had 11 direct children, which are to be "outdented" / "upgraded" = to be made siblings of the siblings of their parent item = are to be on second instead of third level. Thus, below that indented block, there are some 80 other items on the target level of the block in question. I select the block (as said, 11 items) and do "move left". Result beneath the former parent item (all 11 items are its siblings now, but not, as would have been expected, directly beneath it):

4 others, sib1, 4 others, sib2, 4 others, sib3, 2 others, sib4, 2 others, sib5, 1 other, sib6, 1 other, sib7, 1 other, sib8, 1 other, sib9, 1 other, sib10, 1 other, sib11, and then the rest of the others.

(As said, with about 8GB of free work memory, an i7 processor and with a good (and the data traditionally storing, not the newer, lesser kind) WD "Red" HDD.)

See also below for allegedly the same "leaving behind" problem for which something like a "packet manager" would be needed even if that meant that the command, henceforward, would take more time to complete (correctly, then).


ad n) ("move first/last")

When I said there, "This way, this command does not help with this problem, and also, I would not expect these two commands [i.e. "Move first" and "Move last"] [to be] in the Tree menu, but in the Item menu, since as said, they don't work but on single items.", I didn't want to make the suggestion to move them into the "item menu", but it would be great if they could be enhanced in the way that they, too (as "move left/right and up/down) could process blocks / selections of more than one sibling, and, as said before, the same "packet manager" as in e) would obviously be needed then in order to prevent siblings from being "left behind".


All this being said, I'm very thankful for your kind and hyper-fast resolving the "formatting flags" problem, and adding these further details to the tree problems and suggestions should in no way being considered as my trying to rush things; I would have used the "Edit" function instead if such edits were possible even after some days.


x) EDIT: One more: On the other hand, when I expand the very last item visible on screen (or then some item very near that very last "visible" position), the tree systematically stays there, even after expanding, i.e. in order to see any "freshly expanded" item, I have to scroll (PGDN; this PGDN then will put the very first one of the expanded child item as first visible-on-screen item though, which for very long lists of expanded children is what you'd expect; this PGDN should just not be necessary in this situation).

[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.