View Single Post
Old 04-25-2021, 12:20 PM
Spliff Spliff is online now
Registered User
Join Date: 04-07-2021
Posts: 72
Thank you, Kyle. Any remark of mine is for version

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.


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.

Last edited by Spliff; 04-25-2021 at 02:47 PM.
Reply With Quote