Implement searchable context menus - use them in the mixer #31657
+352
−72
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: #17467
Resolves: #31544
My first thought was to keep the changes extremely minimal from a UI/MenuView perspective and let the models decide what to do when search text is received. In this case, the audio resource items would receive the search text and construct a “filtered list” of items. Part of my reasoning for this was that the prefixes (the pack, the vendor, the SoundFont name etc) for each item are quite arbitrary - i.e. it’s not like they all come from the same level in the “flyout tree” hierarchy so I figured it would be more intuitive to do this explicitly when building the filtered list.
However, in practice this approach ended up being extremely cumbersome and quite inefficient. It seemed inevitable that we’d end up with a lot of duplicated logic between the flyout tree structure construction and filtered list construction.
So instead I had the idea to continue using the flyout tree structure universally and just interpret it as a filtered list when some search text is present. It works like this:
setModelinMenuView(pretty much the same as master)MenuViewis searchable, we immediately cache a “flattened” version of the treeDoing it this way should be nice and efficient because we don’t need to traverse the entire tree every time our filter text changes, just the flattened version. And in the end it wasn’t too difficult to resolve the aforementioned problem with prefixes - I added an
isFilterCategoryproperty (for lack of a better name) for menu items; if this property is true for a given item then all “leaf” ancestors of that item will prepend the category title to their title.This task is definitely a bit of a balancing act between repetitive code, future flexibility, and readability. There are parts of it I’m not particularly happy with (e.g.
isFilterCategory,noResultsFoundItem, some aspects of thesetFilterTextmethod) however this is just the MVP and we will have opportunities to refine things going forward.