[Spliff]

Well...


1)

I know /assumed there currently is not enough column info, that's why in-between I had suggested adding a new column; this was visible for some time here, but was part of a part I later edited out, I see now; I've been (and am) aware the necessary code will be very compact AND very demanding, the respective SQL is highly complicated (as I have known by my efforts to write such code myself, I just got to 90 p.c. of the wanted result); but then, since you do it (almost, see below) right in the tree ("Data Explorer"), it obviously can be done, albeit not on-spot.

I made a mistake by saying to do it within the tree itself was "ideal"; even before trying, just after reading you, my mistake occurred to me: In fact, we need the filtered-tree ASIDE to the tree, not in place of it, why? Because from the filtered-tree, we see what we (might) want to do within our tree, thus, if we have the two in two concurrent panes, we can toggle between filtered-tree, for (further) analysis, and tree, for doing changes;

technically, the same is true if we switch forth and back within one (the tree) pane, but if filtered-view, we (regularly, not systematically) need the complete = expanded (but filtered) tree, and thus the toggle "View - Show flagged items" will then show that complete, expended tree > "lost in hyperspace" > lots of searching / navigating after every one such toggle-back;

also, an exclusive (sic!) tree solution, = a) above instead of b) above (instead of both solutions, eventually), represents the inconvenient that tree preservation would only remain possible for filtering by flags, but not also for filtering by other criteria, e.g. "tags", e.g. some tag codes within the titles or elsewhere, or any other search element; it's obvious such functionality - tree preservation for ANY search / filtering would be more than welcome (all the more so since even, see the two links above, it was asked for by other users already in 2017, and assumed by all of us as "being there" while in fact it was not; it's just that currently, me trying a combination of two flags, one for the "construction" and the other one for "content specifics", it's become clear as day that the solutions we all believed in, in 2017 and 2021, don't give the results we're after.

Also, see 3) below in this respect, since in tree-preserving filtering, we will have problems within the tree which are absent within the (flat) search result list.


2)

Thus, I suggest to create the necessary code for tree preservation in searching / filtering, perhaps even then as an click-box, overriding the current column sorts, working as a toggle then (even if for the toggled view, the search has to be started again).

Btw, the new column could be a (= another) virtual one, and just be filled (in work memory) in cases the toggle "preserve tree structure" is set to "on", so as to simplify (and fasten) the proceedings when it's not needed - since in that intermediate SQL "view" (behind the scene), some tree column 1.1.1.1, 1.1.1.2, etc. would be necessary to be built I suppose.


3)

"since you do it (almost, see below) right in the tree" - why did I say that? Because I had assumed that a flag-filtered tree would show ALL NON-filtered items (I called them "elements" above, I mean "items", of course), and that's currently not the case in your current solution a) (I have checked.).

As I have already mentioned above, in the FLAT tree-preserving search results list, we don't encounter any problem to display ALL NON-filtered items, we just leave out the filtered items.

Otherwise in a filtered tree (which preserves the tree structure visually): Here, we have 3 possibilities (as the designer / developer):

a) We can simply leave out non-filtered items, too, if the necessary parenting (sub-) structure is filtered out currently, and that's been your current, quick-n-dirty "solution", which unfortunately makes the filtered view unusable, since a filtered view is about prominence (sic!) of the non-filtered items, not about aleatorically hiding them with the rest I'm afraid.

b) We can leave any partial substructure (= the intermediate-level parenting items), needed for correct tree positioning of the non-filtered items, untouched, perhaps (just for the screen representation) "formatting" them in light grey, and of course, the caption would become ("Data Explorer - Filtered View"); this obviously is, code-wise, the most elaborate solution (and would also imply that all un-necessary siblings of those intermediate parent items would be filtered out, of course).

Of interest here: According to the situation, this very elegant solution would not necessarily be the user's wanted one since if the "intermediates" are too numerous, they would possibly make necessary a lot of scrolling, and then, the question arises, both on the developer's as on the the user's side: To what "degree" should the "intermediary skeleton parts" be preserved? At least somewhat, at the higher-up levels, they would probably say, but then, whenever most of the non-filtered items are within some sub-structure, it would become evident that the "in-betweens" especially within that sub-structure should be preserved...

In other words, this would become highly-complicated stuff, for at the end of the day, little effect; of course, the only realistic (sic!) solution b) would be to implement a toggle (sic!), between "complete b)" (= show ALL necessary "intermediates" (in light grey) for and together with the non-filtered items), and c):

c) Even in the "Data Explorer" = tree pane, show a filtered flat list: easy, and also sufficient in itself, albeit a (toggled) combination with b) would be "ideal"...


4) BUT we've got additional PROBLEMS here, for our "tree solution", both for the developer as for the user:

How much "editing" will be allowed in those "tree solutions" a, b and c (except for simple renames that is: moving items?)? A code nightmare, AND a perfect occasion for the user to definitely (even if just partly) scramble their tree, even if the code is totally correct.

And that brings us back to the tree-preserving search/filter solution, b) on top: Concurrently (sic!) available: the (tree-preserving) "flat list" search results (and here, as in the "tree solution c", just the non-filtered items, but all of them), for deciding WHAT to do, AND the tree (in its current, and malleable, collapse-expand state) for DOING what we've decided to do, and whenever we then decide the two panes have got too much out of sync, we simply trigger the same search again.

It's clear as day that THAT would be a smooth workflow, AND it would not just apply to flag filtering, but to ALL searches / filterings.

The current "tree solution a) a)" (which even hides non-filtered items) being unusable as such, and the alternative "tree solutions" a)b) and a)c) coming with their problems of their own:

Please, Kyle, implement the necessary code for optionally preserving, by sort-overriding toggle, the tree structure in search results lists!

Here again, some might say, "not needed!", but as I have said, again and again, UR might NOT only be a "data repository", as which it's perceived by most of the general public, but could be the very best "write app" out there (Macworld included), and that would apply to ALL sorts of writing.