Jon,
I can not agree any more. Hope Kinook agrees.

I was thinking that there might be a way to accomplish the task requested w a practical workaround. If more details were available, someone might come up w a useful idea.

xja,
would it help if only the search pane shows some kind of tree structure?

Depending on the level in the tree, in the first column of the search pane (which is fixed to be an item name) would be indented (simple empty chars) and preceded with └ sign, sth like this

Column1 Column2
Root
_└ A
_└ B
__└ B2
_└ C
__└ C3

Note that there is an item C3 on level 3 straight under item from level 1, ie. item on level 2 doesn't pass the search query.
This should be very easily implemented based on the lineage attribute (ie. simply replace number of slash signs in the lineage attribute by number of empty chars), the only other thing that needs to be implemented is sorting of the search results to recover tree structure (again simple algorithm based on lineage attribute). There needs to be a little tweaking with the indentation based on whether parent/grand-parent/ ... are also in the search result (if not exist, decrease indentation).

The result would be a FILTERED tree structure based on your search. Sure, not aesthetically perfect (and only static with all nodes expanded), but would do the trick :)

But thinking about it, if this could be implemented, then surely the search pane could just use the "tree module" that Data explorer pane uses ... no overhead here, cause this is only the search result pane that "dies" once you click Enter on an item or navigate somewhere else in the Data explorer pane.

GREP
 

Would grep type search filter be hard to implement?

Thanks for the explanation. I understand that that could be prohibitively slow, although only when in filtered mode and with a large tree. If you could apply the filter to a particular branch, then a filter could be created that was quick and useful.

That said, even if the filter was applied from the top down, that would be useful. eg, when expanding a branch, hide any items that don't meet the filter criteria and hide those items' children. ie, hide the whole branch. Then the filter would only be applied when expanding a branch and would only be applied to those immediate children. Wouldn't that have much less of an impact on performance? I know that is different than what has been discussed before but still useful with more careful filter definitions.

btw, quant, thanks for the idea about a tree-like view in search results. what you describe would be similar to what I just described above... ie, every item in the tree would have to pass the filter criteria. I think it would need to work like I described though otherwise you could have some items that match the filter whose parents don't. How would they be depicted in a hierarchy if their parents are not? Would be a little confusing I think.

if the parent doesn't match the filter, I'd think that it shouldn't be in the results (case of C3 in the example), that's the main point of filtering.
It could be in the setting, that the tree structure itself should take priority, (ie. say keeping parent present even if it doesn't pass the result).
Probably only those that used it in another application could say which one is better for their needs :)

We discussed way back in the original threads whether parents and children that didn't match the filter should be shown. Rather than hijack this thread any further than I have, I'll defer to that discussion regarding my, and others', views on the "ideal" solution for that.

My comment above is my attempt to suggest an alternative that is more feasible to implement and that could still be useful, if not "ideal."

Consolidate Filtered Tree Ideas
 

Giday xja,

As promised, have started new forum thread on topic of filtered tree. Hopefully I've made an entry that contributes positively to getting this feature request resolved in the near future.

http://www.kinook.com/Forum/showthre...&threadid=2777