Any way to create a compound (flag) search preserving the tree structure? Or in tree?

[kinook]

I must confess that I don't fully comprehend what you are requesting or the specifics on how it would be implemented. I get the idea of a filtered tree that only contains flagged items, and any intervening non-flagged items (which are included in order for all flagged items to be visible [although this would be a departure from the current functionality to *hide* flagged items, and it would entail having to traverse the entire tree to determine what to populate, and UR works hard to minimize how much of the DB it has to read in order to populate the tree, so performance would suffer]), but I'm not clear on how the search results would show a tree structure in like fashion, or if that's even what you're asking (maybe your idea is a new mode for the related items pane that displays [fill in the blank]). If you could elaborate with some examples and pictures or diagrams, it might help. Thanks.

[Spliff]

Well, I did do something for me, from csv export, and could do it even better since "individual", but it's perfect to be standardized as well:

My proposition had been, be a "project" sub-tree somewhere in your full-tree, the project title then being regarded as "level 0". Below, you have level 1, with some 20, 30 bold titles (bold flag, I use yellow for that since yellow isn't readable anyway), for the project's main titles. On level 2, you have possibly 100 or 200 level 2 project titles, but spread over the 20, 30 level-1, main, titles, e.g. level 1 title #1 has 15 level-2 titles, level 1 title #2 has 20 level-2 titles, and so on.

Then, I said, filtering is about de-cluttering, so your filter will show your project's level 1 titles, but NOT also the many level 2 titles; it will show the level 1 titles in order to (not very precisely, but sufficiently precisely) "SITUATE" the CORE info of your filter: special flags, of one, two or several kinds.

As a user, you will want to see those, with just the "necessary" "situational" info provided by the level 1 titles, and since I did it for me, it occurred to me that I could do it even MUCH better: from the level 2 titles, I just show the "needed" ones; I automate this of course.

I other words, my filter shows the level 1 titles, the special flags, and any level 2 title which is followed by 1 or several special flagged items, so in other words, any level 2 title which does NOT serve to precisely "situate" any special flag, is automatically hidden., and that thus goes for 90 p.c. of them; also, any other flag, and any no-flag, is hidden of course.

It's obvious that you as UR's developer could also do this as fine-grained.

I have a little list of targets, let's say targets := "A,U,T"
(B = bold does not appear here, since it's not a target, see below)
(All my flags have 1-char names; the ORDER here: A then U then T specifies the additional tabs = indentation levels for the flag in question, see below)

I then run a loop for every one of my csv output lines (put from file into clipboard, I then run the loop within the clipboard), in case for retrieving the current line for my target file (i.e. I write the lines to be retrieved to a target file (in fact, first into some var, which then will be normalized (double and more double quotes, etc) and written to file).

line without flag (i.e. with no flag): next (skip)

line with flag b (bold) AND indentlevel 1: write (no indentation)

line with flag b (bold) AND indentlevel 2: store in var b2 (replace in case)

(You might have other or no flags on level 1 and/or 2, as "siblings" of these flag-b items: they are skipped by the rule above (noflag) of below (other-flag))

line with flag in targets-lists: fetch curr content from var b2 > write b2 line (indent 1 tab) IF there was content > empty var b2, write target-flag-line (indentation min. 3 tabs, see below)

line with other flag: next (skip: this is even the more or less DEFAULT behavior in filtering)

I thus get:

no indent: bold level 1 titles (outer skeleton)

with 1 indent: bold level 2 titles IF they are title to one or several target lines:
A with 3 indents, U with 4 indents, T with 5 indents, etc (see above)

Thus, I have the skeleton at the left, with its second level just where "applicable" (i.e. where the level-2 line is "needed" as a title for 1 or more targets), and multiple targets but of the SAME flag, SHARE the same indentation level, AND I can determine their "indent order" by changing their position within the "targets" list.

You, as the developer, can provide the same, perfect schema: We just would need have to accept a "convention" that any project's (= any sub tree to then to be filtered this way, or even the source item) first two titling levels (-1 under 0, and -2 under 0) will have to be flagged "B" or "Bold"; obviously, users could use full-written out flag names if they insist, they will just have to make lots more of my typing, since a targets list "A,U,T" is typed in a breeze, whilst perhaps 60, 70 characters are not.

Btw, it took me 3 minutes of hard thinking, how to put in the level-2 lines whenever needed, and only then, but as you can see, then the implementation of it was blunt easy. And you'll get all the level-2 titles you would want, and none of the unwanted ones, according to your specific target-flags view(s).


On the developer's side, this filtering would not be entirely by flags-only, since for the "B" flag (or the flag of which the name starts with "B"), the indentation level also would come into play, but that's easy; for me it was the reason why my csv export not only retrieved the flag, but also the indentation level; note that the NEW indentation levels, in the filtered view, do NOT correspond to the original ones, except for B-level 1 (which becomes no tab) and B-level 2 (which becomes indented by 1 tab).


And MI (now "App": https://forums.myinfoapp.com/viewtopic.php?t=8262 ) is a joke, not even formatted import does seem possible, and the developer gives a crack (it seems he adopted TypeDown or what it's called, hence "App"), and anyway, he's too busy counting the money (since in his country, the dollar is worth tenfold: American developers can only dream of such returns' value. On the other hand though, I would be interested in knowing how the developers of MI(A), RN, MB (all SQLite-backed) do the necessary code and / or tables, in order to get their search results as UR just gets, correctly, its exports.