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

[kinook]

In the latest download (6.2.0.1), I made some changes to always honor the tree scroll options, so if you uncheck

Tools | Options | Tree | Scroll horizontally on selected change to keep text visible

and

Tools | Options | Tree | Scroll item to top when going to item

there should be no more automatic scrolling in the tree.

Still trying to digest the last two items. A screen recording and other info from

https://www.kinook.com/Forum/showthread.php?t=3038

could be helpful.

Thanks.

[Spliff]

Thank you, Kyle. Any remark of mine is for version 6.1.0.7.

I had and have "Scroll horizontally on selection change to keep text visible" on since if it's off (I tried both), when there is some long title, I don't see the start of other titles anymore without manual scrolling, thus my suggestion to have an option to just do away with any scroll, so that the title begins are always visible, without automatic or manual scrolling.

I had and have "Scroll item to top of tree when going to item" off, but even my newer tries (always with the above-mentioned version, which I will replace by the newest one now) show a non-predictable behavior, for item moves, and for new items: many a time, that item (after the move or when creating it) stays at the expected position, and sometimes, it becomes first visible item on screen.

As said, all remarks apply to the above-mentioned version, I try to describe every phenomenon as precisely as possible; many phenomena are aleatoric, so there is no precise anterior situation which would then trigger the phenomenon afterwards.
__________

f) Often or even most of the time, after ^x (for cut = move), the file symbols (=tree symbols, I do not mean the flags since I do not display flags) are not greyed out but stay as they are, this occurs with single items and with subtrees. The cut is done though, and pressing ^x a second or third time does not change this.

g) Often, when I try to move a (single) item (with content) to another database, the cut and paste is not done correctly: The original, "cut" item stays at its original position as it is (also with its content), and the "moved" item is inserted in the other, the target database (by ^v) in the following form: Just the title in the tree, and then again the title, and just the title, instead of the original content, in the content-pane. This risks even to delete contents, in case the original item will be deleted (which is the idea in moving an item), especially since I do not check, after moving an item, if also its content has been moved, a check which would need to open the target tree/subtree for every move.

h) Often (but not systematically), inserting a new item will shift the tree upwards, to that the new item is then, even before entering its title, within the first line which of the tree is visible on screen. The tree should not shift this way, except perhaps, perhaps for just some lines, when the currently active line, before the new-item command, is within the very last 3 or so visible lines / items on screen; then perhaps an upwards scroll of perhaps 5 lines or so could come handy. I would prefer the tree to stay as it is, except for the very last line as current line which would need an upwards scroll of 1. Currently, the current position does not seem to be a factor in this, scroll to very first visible line is even possible, in some aleatoric way, when the current position is within the upper third of the screen display.

i) I had said that when I shift/move subtrees or items, often the target subtree for the move will expand, which is not wanted, and that this is aleatoric, and that some target subtrees seem to be systematically expanded by a move (^v at the parent item of that subtree), while other target subtrees remain collapsed (which is wanted). This is true indeed, but it seems that if I move a single item or a "simple block" (some siblings) to a target subtree, most of the time, the target subtree remains collapsed (but not always), and when I move a subtree instead, even a "subtree" which just consists of a single parent item with a single child item, the target tree is almost systematically expanded (in over 90 p.c. of the cases it seems, but here again, not in every case). This means that often, even a block of 5 siblings does not expand the target subtree, whilst just 2 items, parent and child, do expand the target subtree. As said, it would be highly preferable that the target subtree is not expanded, or perhaps systematically expanded by some option only, which may be helpful for some special use cases.

j) The PGDN does not move as expected / as standard. Standard is (i.e. most programs work, in fact almost every program works, that way) that the very first press of the key will just activate / set to "current item", the currently lowest visible item on screen, further pressings of the key will then move the visible part of the tree by a full screen height, or, for some, by a full screen height minus 1, 2 or 3 lines, in order for the user being able to read, as "new" first line which was the "old" last line before pressing the key (similar with PGUP). The UR tree, on the other hand, works in a way that even the very first PGDN will do a real pagedown, from the current position, and since that current position from which then the pagedown is triggered, is highly unpredictible (see my descriptions above), pressing PGDN will set the "current item" into an unpredictable area. (See below.)

k) When I move subtrees around in some part of the tree, it occurs that some subtree below those I'm working on, is systematically expanded, almost every time, in spite of the fact that that subtree is totally independent of those I'm working in and working on. For example, be the subtrees A, B,... Z, and I am shuffling around subtrees b, c... within their parent ranges C, D, L, subtree Z (on the high indentation level of A... Z) is expanded systematically. To be as precise as possible here, I observe this specific behavior with my INBOX, which is the renamed "Imported Items" subtree, and which is quite at the end of the tree, just before the Templates and the Recycle Bin. So this may be specific to the "Imported Items", but as said, shuffling around above that Inbox, will systematically expand the Inbox.

l) The aforementioned "Imported Items" expansion problem is quite disturbing my work, since as an intermediate solution to the various tree shifts, and the lack of previsibility of the PGDN command after a move (^v), explained above, I have found the intermediate sort of solution to do moves (^x, ^v) in such a way that after every ^v, I press END, in order to have a fixed position after a move, and from which then I do other moves. In other words, I put any sort of "Inbox", from which I have to do many moves to other tree positions, near the end of the tree, then go to the target = new parent, press ^v, then press END again, and so on. Whenever the place of origin of an item / subtree to be moved, is in the "INBOX" ("Imported Items"), I hold the "INBOX" expanded anyway, but in every other case, an expanded "INBOX" or "Imported Items" subtree near the end of my tree seriously hampers my way of working, in this shifting of long lists of items which must be distributed to their final tree situation, one by one; working in "bulk" not being possible, since the target situations will vary.

m) As I already said above, the problem with the "Tree - Link/Move To" command is that this is some extra pane, with a different tree, so the orientation there needs too much time; moving within the original tree takes less time after all. One of the main problems with the extra tree is that especially also all the siblings of the item to be moved, are listed, which may be 50, 100, 150..., so finding the target, in some other subtree above or below, is not easy at all. I have some suggestions to make this better, at this point in time: An option could be implemented which systematically hides the siblings of the item to be moved. Then, the 10 or 12 last move, or link, or copy targets should be available "immediately", perhaps as the very first entries in the list, the active entry, when opening the extra-pane, being the very first entry (or perhaps the other way round, the active position being at the very end, but then with the last 10 or 12 targets being listed at the end. Those 10 or 12 targets should be held in different arrays for link, move, copy, and should be displayed according to the current radio-buttons setting. I am aware that there are other problems with the extra-pane; I would prefer that at the moment the pane is displayed, and except for the last 10 or 12 targets, only the very first level is displayed, in order for expanded subtrees not blurring the way to the possible targets, but I don't think this will arrange the majority of users, so there is always the problem that expanded subtrees will prevent fast target identification; this could also be prevented by some option, which ideally, and as well as the "hide current siblings" option, would be accessible from within the "Tree - Link/Move To" pane. I know that the pane, in its current state, tries to be "smart", but unfortunately, the way it does that will not comply with my way of working / my way of moving items in big numbers, all one by one, necessarily.

n) Back to the main tree: The problem that it is almost impossible to upgrade "blocks" (longer lists of siblings) to the higher-up indentation level, is the main problem, and even original lists of 10 or so will spread all over the place, by trying to "outdent" them when in the target list, there are already "siblings". (Details above.) So I also tried "Tree - Move First", but this will only work on one single item, not onto a list, so these commands (there is also "Tree - Move Last") are quite different from the commands "Tree - Move up/dn/left/right" which all also work on blocks. This way, this command does not help with this problem, and also, I would not expect these two commands in the Tree menu, but in the Item menu, since as said, they don't work but on single items.

o) In the Go menu, there is "Go Previous item" (and "Next item"). I tried them both, but I as far as I have found out - probably I missed some use cases? -, they are not helpful. Especially, whenever I move an item (^x), the item immediately beneath the item which has been "cut" is NOT selected as "previous item", but this would obviously be the next navigation target, as soon as the cut item will have been moved to its new location. After, at its new location, I then press ^v, the "previous item" (i.e. the location then selected by command "go previous item") is the new parent of the moved item, which obviously does not make sense, all the more so since, ideally, the move of the item to its new parent should NOT expand the new parent item, and thus, the "previous item" is the current item, the new parent of the moved item, whilst getting back to the original location, before the move of the item, and from where you would want to then move other items, to other target locations, requests manual navigation, every time. I suppose there is a timer for this function, so that some item had focus for more than 2 or 3 seconds, it becomes "previous item", but as said, in the case of a move, or a copy, this function becomes useless, the "go previous item" function should go back to the tree location from which the item had been moved or copies. Thus, for every move or copy, I suggest that immediately after any ^c in the tree (only), the system should put the copied item into the "previous item" variable, and BLOCK that variable (i.e. prevent further updates), and for every ^v in the tree, the system should put the item immediately beneath that item into the "previous item" variable, and again block, the blocking being by the very next ^v, and then the user's triggering of the "go previous item" command would get the user back to their original location in the tree: to the original instance of the copied item, or to the "next" item in the case of a move.

p) Another recurring tree problem: Let's have a list of siblings A, B, C...Z, on any indentation level and in part with subtrees. Then I cut subtree L (which may eben be a very "light" subtree, just the item L, with some 3 or 5 children), navigate to E, press ^v, which makes L a child of E; my next action would then be to expand E, in order to fetch L and outdent L ("move left"), in order to have it again a sibling of its original siblings, just at another position. Now, often (but again not systematically), the ^v already selects the whole tree, just everything. I than have to navigate (UP or DN), in order to "break" the selection", then go to E again, then expand E, etc. This unwanted selection of the whole tree doesn't seem to do any real harm, but is a visual shock, since it does appear unmotivatedly and unpredictably.

q) Another unwanted scroll of the tree: Let's have siblings A, B... Z, at any indentation level, and be them single items or parents for subtrees. Let's have the single child e (i.e. it's not a subtree), of parent E. When then I "upgrade" e, in order for it to become another sibling, between E and F, very often the tree doesn't stay as it is, just "growing" below the E by 1, but in many cases, the tree is heavily shifted vertically, for just the insertion of a single item (e here).

r) For some hours today I had the problem, with multiple tree items of which only a tiny minority was bolded: While renaming (mostly shortening) those titles (F2), within the rename dialogue, the strings to be renamed were/remained bolded, and the text cursor within the string was not visible and/or not correctly placeable, it helped to press END, wait for some seconds, and then I had a correctly placeable cursor even within the bolded text. The expected behavior for F2 being: Since the "current" item is bolded, as long as it is the current item, then F2 will present the same string in a dialogue where the string is NOT bolded anymore, and even if the original string (item) is bolded (by a "formatting" flag), the string in the F2 dialogue is NOT bolded. Here, as said, during hours, the string within the dialogue WAS bolded, even though most of the original items were NOT bolded, except while being "current". This phenomenon vanished after several hours, without closing and reopening the file or UR. I had observed this phenomenon at different times in the weeks before, too.

s) As already stated above, some of the problems listed above obviously can be explained by an observation when I upgrade ("move left") or downgrade ("move right") single items, one by one but too fast in a row: Then, the second and further shifts are NOT being done anymore, since the shift command had come "into" the processing of the previous command, and had not been stored by the system. Thus, especially, when a block of items is "outdented" ("move left"), the system obviously stores the full list of the items to be "moved left", but then does not leave waits sufficiently long between the "move left" and the "move up in the siblings-range up to the correct position", so these get stuck at every which position below their correct target position, similar to my manual work when I trigger the "new" command when the processing of the previous command has not ended yet: There should be some "worktable" instead which just registers the internal database commands to be triggered, but then "listens" to the actual database processing, and sends any ulterior command just when the previous commands have been fully processed; "sending it all together" obviously makes the SQLite choke, SQLite does not seem to have an internal memory from which it then gets the further commands to be processed just at due time.

t) Most of the phenomenons here are much more than just visual nuisances, since they demand additional navigation or other user interaction, before the user is able to continue their regular tree work. (As for "moving left" blocks, I new move the items one-by-one, which after all is less work then to try to move the block, and the to gather all the items from their individual, wrong "left there"-positions down the tree.

u) A suggestion: Both the "Norton Commander" (defunct, for files) and the (not robust) outliner "Jot+ Notes" present a "mark" functionality, where (in the "Norton Commander") the user pressed the space bar (in "Jot+ Notes" it's some key combination), to "mark" a file / an item, in order to group non-adjacent items without using the mouse; then, the next command (^c, ^x, DEL) is applied to that group (just like as it had been gathered by multiple control-clicks). The obvious interest in doing such gathering by space bar is that, while selecting-and-marking items this way, the user can regularly select (by navigation with UP/DN or single mouse clics) other items, in order to decide if they want them to include in the mark-selection or not, which is not possible with control-clicks with the mouse where any non-pertinent item navigation regularly will destruct the multiple selection. In the above-mentioned outliner, this "mark" function is also for other means and has to be de-marked when not needed anymore, but in "Norton Commander", it's implemented in a very intuitive way, since, as said, ^c, ^x or DEL (perhaps also print?) will automatically de-mark those "marked" items, in fact it's just a persistent selection, persistant beyond navigation but automatically not needed anymore after copy, cut or deletion (or possible print/export). The implementation of such a functionality would just need an additional column in the "items" table, and any such ^c, ^x, DEL (or even print/export, perhaps) would automatically set all the "1" values in that "marked" column back to NULL; as for the tree coloring of the items while "marked", perhaps a "greyed out" would be good.

v) Since the "current" tree item automatically gets a blue background, the automatic bolding of the "current" tree item is redundant = not really needed.
__________

EDIT:

w) Speaking of previous, and of current versions (I had omitted to mention this problem, and it prevails): Sometimes I create a new sibling inadvertently, and often I cannot delete it then, even after some (or many seconds), i.e. the item "New item" just stays there then. I will have to create another item, and then only, I can delete (DEL) the unwanted "New item" I had created before.

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

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

[Spliff]

za)

(please also see "ad s)" from today)

When I move single items, or groups, or items with child items, down or up the tree, the noise of my HDD clearly indicates that for every new but INTERMEDIATE position, UR writes the new, "correct" sql data. This both wears the HDD and causes many of the problems described above.

Thus my suggestion: Would it be possible that for the "move up/down" commands (i.e. not also the "move left/right" commands, which are "final"), UR would "wait" some, let's say, 200 or 250 milliseconds, before "writing the sql data", and would NOT write that sql data yet if immediately afterwards, another "move" command is triggered by the user?

This way, the "final" move command would be retarded by 200 ms or such, but all the intermediary, unwanted "new position" sql data would NOT be written to the file (and in case, even for multiple items, so this would obviously avoid lots of overhead).