How to select all children?

[Spliff]

(with the keyboard, obviously)

My bad, could be deleted in case, but perhaps other UR users make the same mistake? A simple ^a does do that indeed (i.e. does not select the whole tree): perfect!

[Spliff]

My very first question above was much more detailed; I then discovered the ^a (which I had simply overlooked in all my elaborate tries), then replaced my question as above.

But I then discovered this was premature: In fact, control-a works fine for the siblings indeed, and that even when they are in a list which is broken up by further sub-items.

But then, HOW to "select all visible here" then? I simply don't get it, and I suppose that currently, there is NO such shortcut? Let's have:

A) (all expanded)
0 (parent-item)
_1 (1st level-1 sib)
_2 (2nd level-1 sib)
00 (another parent-item)
etc

B) (all expanded)
0 (parent-item)
_1 (1st level-1 sib)
__1a (first level-2 sib beneath _1)
__1b (second level-2 sib beneath _1)
_2 (2nd level-1 sib)
__2a (first level-2 sib beneath _2)
__2b (second level-2 sib beneath _2)
_3 (3rd level-1 sib)
00 (another parent-item)
etc

Both in A) and B), 0 is selected; then, {right} or {down} will select _1, then, in A), ^a will select both siblings, and similar in B), ^a will select all sibs, i.e. _1, _2, and _3, but I would like to find a way to either select the whole "0" subtree, as far as it is displayed.

Either a) including the "0" parent-item itself, or b) just everything beneath; I suppose that a) is both preferable from the user's point of view, and much simpler to implement?

So, instead of "select all siblings" (which is available by ^a), I'm looking out for a "select all", understood that this "all" just comprises the current item ("0" here) and all displayed = currently visible child and further-down descendance items (here down to _3, but not including a possible = not visible ____2aa).

In other words, it would be a combination of "the parent", and then, recursively, "all siblings", as far as they are currently displayed, or, from the "parent", "GO next sibling" (of the parent that is), but with "Shift"= "extend selection", and then again a single {up} (the selection being preserved, but without its very last line, the "00" here), since we don't want to select but "everything visible beneath" the first parent, not also the second parent, which will just have served as a line pole.

I hope that could be technically quite easy? Since I understand we can do this "by hand", just by an extensive {down}, with {shift} held down. But it would be immensely convenient that is!

[kinook]

Implemented Edit | Select All Children command in the latest download (v6.3).

[cnewtonne]

I'm on 6.3, but I do not see 'select all siblings' option.

[kinook]

The previous message was mislabeled, should be Select All Children. Select All selects all siblings.

[Spliff]

Yes, the "totally correct" wordings would possibly be
Select (incl. Descendants) [since, thankfully, the parent item is included], and
Select All Siblings [instead of Select All]

But you have done tremendous work these last months, all in more or less "little things", technically speaking, but which "make all the difference" indeed, for smooth and productive working with a program.

Thank you so very much, Kyle!

(And fellow users should try the new "Tree - Show n levels" commands, and adopt them systematically, also, and especially, in their way of organizing their elements: their degree of organization will rise spectacularly, by masking non-pertinent "details" info whenever not needed (yet).)

[cnewtonne]

I can hardly see a use-case for my workflow using the 'show n level'. Can you please share your functional use-case? How is this feature helpful to you?

Thanks

[Spliff]

No problem, cnewtonne: "their degree of organization will rise spectacularly, by masking non-pertinent "details" info whenever not needed (yet)." - this being said, "by n levels" is not that helpful anymore, once n >= 3 (since n is counted from the current level down): it's about avoiding clutter while thinking about what you've got, and what you should add, amend, change, think over...*

And for purely organizational / business means, it helps to identify / correctly maintain customer / goods / etc data, even and especially if you switch between entering data in UR, and retrieving data by SQL.

*=I recommend "show 1/2 level" in particular (beyond for drilling down of course) for drilling UP, i.e. when you will have been within SOME details (spread over possibly even more than one level further down, and possibly in more than just one sub-tree further down), and then "go" up again: In this situation, "show 1 (or, rarer, 2) level", triggered from your original starting point again, is wonderful (and neither to be mixed up with (collapse by) {left} (arrow) nor with "collapse tree") - especially since "going up again by {left} will remember the expansion state "further down", which is NOT wanted in these situations:

Use "Show 1 level" even more upward, than downward, and you'll get its tremendous interest even faster...

[Spliff]

Too late to edit my previous, spontaneous answer of yesterday (where I mentioned using those commands not only for expanding ("drilling down"), but also and especially for "better" collapsing ("drilling up"), and for "normalization" of more "database-like", not-so-much "freeform text" data).

I currently encounter an ever-recurring "problem" (which, thanks to Kyle, isn't a problem anymore!), and which I hadn't had on mind in the situation yesterday; let me explain:

I'm on level 1 of a biiiig sub-tree, i.e. 1 level down from level 0, which here is the "parent item" from which the sub-tree runs down if I may say so (so the levels count down here, as for the commands, from "somewhere within the whole tree" (which is about 10,000 items), my sub-tree alone has about 1,000 items.

I'm in that (!) level 1, as said; this level has some 30 entries (all of them being "parent items on their own).

Now - and this is my current real-life example from this very moment -, I remember I have used some terms in some of the (immediate) child items (if further down, I'd prefer to call them "descendants" instead), but I don't remember those terms - so I can NOT search for them -, I just know I they are there, and I want to change them (to some others); so I open the alleged (2, 3) parent-items, but I don't find them in there. Again, I'm in a level 1, and I want get to info 1 level down (and then only, after having identified those terms in there, I'll be able to search for them even within the levels deeper-down, i.e. in the whole sub-tree).

My "opening" of those 2, 3 items, by {right}, is unsuccessful, so my traditional "solution" would have been:

- either multiply the {right} on more or less all of the other about 28 items in my level 1 (and then "close" (collapse) them almost all again, 1 by 1, or do a "collapse tree", or collapse my level 0, above my level 1, "willing" to live with the chaos (=unwanted sub-tree expansion state for further processing) I have just created, whenever I reopen that level 0 again)

- expand my whole sub-tree level 0, with its 1,000 or so items in all, and then try to visually identify the "info" on level 2, with all the other levels further down creating some incredible visual clutter around my "core info" I'm interested in.

NOW, being on my level 1, and having unsuccessfully opened some 2, 3 level-2 lists, I simply go back to my level 0 {left}, then press the shortcut for "view 2 levels" - I have 2 shortcuts for "view 1/ level(s)" in total, since those are the "views" I need again and again (and as said, "view level 1" even more often; whilst I haven't had any use yet for specific views further down: in those cases, I continue to use "expand all (subs)" - on my then-level 3 that is, NOT on my levels 1 or 2).

This "view 2 levels" on "1 level up" = from my level 0) now opens me my level 1 (again; about 30 items) and my level 2 (anew; about 160, 180 items)... and albeit those 200 items might appear "a lot" for visually browsing, I can now browse those at ease, WITHOUT all that 4- or 5-fold CLUTTER which would have hampered my visual search if on my level 0, I had triggered "view all (subs)".


1) In short: I advise to use the new commands "show 1/2 level(s)" from any starting point "level 0" within the tree, for general navigation, replacing lots of previous {right} and "view all (subs)", and in BOTH directions (i.e. also replacing lots of {left}).

2) Understood that the tree form in general, while inciting some (or many, that is) users to "endlessly drill down" - and I even have read web posts complaining that some application limited the tree hierarchy to -- shocking! -- 10 or even 12 levels -, comes to much smarter application whenever the user sees the multi-level storage as a chance for special occasions, while organizing their material in some corpus which in general will "display in breadth" whenever that makes sense (and it makes sense almost everywhere), instead of "in maximum depth" - not even speaking of the (almost always very obvious!) fact that this urge to create more and even more descendancy causes forced classification, i.e. instead of creating one, larger group, they needlessly create subgroups, then don't know anymore in which of them the currently pertinent material is stuffed into - also see in this respect my not being successful with the "first" (i.e. first looked-into) level-2 groups above: obviously, I had committed attribution errors, but then I had opened that sub-tree in order to work on it, and obviously it needs some reorganization, since it's become a very pertinent sub-tree (i.e. some level 0 with its descendants) for me now... whilst the organizational "level" (i.e. quality here) is much less important for non-pertinent "stuff", obviously.

Thus, easily browsing some 180 level-2 items now, I already have discovered those terms, ready to change them, and I see what will have to be done to organize this sub-tree material better. (And remember, if I had done 30 {right} in my level 1 instead, these {right} would NOT just have opened level 2, but would have displayed more or less expanded sub-trees on their own.)

3) The core idea behind this being, and as said: You discard the "detail-details" (within levels 3 or 4 and then down to level n), while preserving the "decision-relevant details" (= level 2, categorized / ordered on level 3), so your "musings", with level 2 expanded, will be both profit from completeness of the relevant criteria (data), and from being undisturbed by non-relevant things.

4) And yes, getting to 3) implies better organization, with decisions what is "strategy-relevant" if I may so, and what is "purely executive managerial stuff" - in the end, just like the distribution of tasks, and information (sic!), in a well-organized business organization.


"Show 1/2(/3) level(s)" is pure gold.

Since at the end of the day, it incites you to better think, and that's what we hope to get from our information management software, right? ;-) (And yes, there's always the problem that some stuff, relevant, pertinent here, is less so in other contexts, and vice versa... but let's not overcomplicate things prematurely: lets take fullest advantage in-between of what we've already got, and Kyle obviously "got" the idea, and implemented the necessary functionality in a perfect way.


EDIT (while I can edit instead of multiplying posts):

You could it sum up this way:

"Show 1/2(/3) level(s)" allows you to work with lists, instead of sheer endless trees

-, and that people have identified the problem indeed and in general, is shown by the ubiquity of the saying, "can't see the forest for the trees" - which means the same thing indeed: To be overwhelmed by, in the then specific stage of "mental processing", non-pertinent detail.

Acknowledged (and said above) that this only works if you will have organized (those (relevant) parts of) your info accordingly, but I also argue (above) that the chance to work on them this way then will motivate you to organize along these (quite horizontal instead of too brutally vertical) lines, and then possibly even systematically, "naturally" (it having become a habit in-between? wouldn't that be nice?): It could become an effortless "second nature".

Remember that some people swear by information management, etc, by "TheBrain" (and that in spite of their whopping pricing); I did extensive tries, and thus I'm not convinced, but the developers claim their (more or less original) paradigm to be some "superior" instrument; well:

Introducing horizontal "throughlines" into the (systematically underlying, because of its capacity to contain and technically manage big corpora) tree-form paradigm, could be the real game-changer.

Be that as it may, but UR now gives you / us all the chance to try it out, and I claim that's a spectacular chance we got; subsequent {right} drill down, discarding too many relevant elements from your scope, possibly (partly) blinkering you; "Show 1/2(/3) level(s)" will broaden, widen, open up your vision instead. 'Nough said: I think you can see. ;-)