[Feature Request] Filter/Search project tree

[tarnos12]

Describe the problem In larger projects, finding an item/gui or even a script is hard. Using folders might help, but there is a limit to that.(You still can't easily find GUIControl)

Suggested change This is related to another feature request here which has an easier solution to the problem.

To sum it up, a good solution might be to have a search bar for the project tree that let us filter the content. This may or may not search properties of the node.(e.x. GUI Control or an item Description) Extra feature would include filtering options such as using || to filter multiple nodes.(e.x. iCup || cPlayer || myScript)

[ericoporto]

Here's an example of project search, with autocomplete, but without the filter part...

I found and rebased my old project search here, it's not good, use as a thinking experiment. Caveats:

• it's not possible to search for a folder.
• in case of ambiguous results, it jumps to the first, since it's using selection as means of highlighting.

does your example work if you collapse the tree? Will it open up the tree to show what you are looking for?

yes and yes, it will expand as needed to reveal if it's hidden. and also scroll.

What if the thing you are looking for is inside a folder or multiple nested folders?

no problem there, it will expand.

it doesn't work with GUI controls?

no because the GUI controls are not nodes in the project tree, this is what I meant with being specific on the content it should search on, but inside content will probably not be highlightable.

---

Here are details when implementing filter search

• q: functions that results in jumping on the project tree, should they still work, if the leaf it's intended has been culled?
  • possible a: I believe the search as filter is better implemented as an additional tab where it filters out a copy of the project explorer tree
• q: should the search as filter cull the categories root if it doesn't have any children? (audio, speech, rooms, ...)
• q: should the search include the content of each node? (The script content, the custom properties, label text, ...)
• q: should ordering right click commands be disabled when a search is active?

Additional context https://www.adventuregamestudio.co.uk/forums/editor-development/editor-feature-requests/msg624000/#msg624000

[ericoporto]

For the filter search, the only idea I have so far is to have the filter happen in a different tab by copying the filtered elements from the tree in this copy of the tree. Then clicking any element will instead go-to it in the actual project tree - and dispose of the filtered copy.

I think I can also play with smoke and mirrors and just swap one control with the other and swapping it back - I think it will look seamless, but need to test. This means in the filtered version there won't be right click context menus, and any sort of click will swap back to the previous, where there is no filter and with selection there, and filter text cleared. I can't tell exactly how it would look without doing an implementation of it. But I think it would be serviceable enough.

[ivan-mogilko]

I did not pay much attention to this before, but from a quick glance:

1. The first variant with quick search shown here : could work nicely imo if it worked repeatedly finding next item each time on pressing button / enter key, as that would cover multiple result cases. Also, what was the problem with searching for folder names?

2. The second variant suggested in a comment above, with the special control displaying on top of the tree, actually sounds like not a bad idea. Alternatively, it could be on a second explicit tab, but also switch to the "filter" tab automatically as a person begins to type. And switch back when a person clicks (or double clicks) on a filtered item. If there's a key that quickly switches tabs while project content control has a focus (like... TAB or Ctrl+TAB, etc), then user would be able to switch back to the filter and choose another item to jump to.

The third alternative is to somehow combine both solutions, but then there have to be some smart idea how to distinguish their controls. Perhaps, in such case, the input field should also belong to each tab:

• project tree tab's input field acts as a quick search;
• filter tab's input field acts, well, as a filter input.