Skip to content

Conversation

@mathesoncalum
Copy link
Contributor

@mathesoncalum mathesoncalum commented Jan 5, 2026

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:



  1. We pass a flyout tree to setModel in MenuView (pretty much the same as master)

  2. If our MenuView is searchable, we immediately cache a “flattened” version of the tree
  3. When our search text changes - we create a filtered list using our flattened tree



Doing 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 isFilterCategory property (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 the setFilterText method) however this is just the MVP and we will have opportunities to refine things going forward.

@mathesoncalum mathesoncalum force-pushed the search_in_mixer branch 2 times, most recently from 1dcb9c9 to 8d72f83 Compare January 6, 2026 22:21
@mathesoncalum mathesoncalum force-pushed the search_in_mixer branch 2 times, most recently from 57bd29e to 6340526 Compare January 7, 2026 16:00
@mathesoncalum mathesoncalum marked this pull request as ready for review January 7, 2026 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement search field component in context menus Implement search box in the Mixer

1 participant