Implement search box in the Mixer

[jessjwilliamson]

Your idea

To have a faster and more efficient way for users to search for sounds or audio FXs in the Mixer, a search box is a way to make quicker results.

Problem to be solved

This will solve slow, FX locating issues, especially for users who have lots and lots of plugins installed on their computers.

Prior art

No response

Additional context

This is a collaboration project with me, I have already made designs for this, only implementation needed.

Here are the designs with a UX flow in a Figma project: https://www.figma.com/file/f5JfTbhKggUjPfTMoqyynH/Search-box-in-Mixer?type=design&node-id=6-35

[22justinl]

Hello, I would like to try working on this but I'm having trouble with figuring out how, could I get some general pointers on what I would need to do (or what is required when working on something similar)? (How do I add to the existing dropdown, do I need to create a new UI component qml file, etc.). Any help would be appreciated!

[cbjeukendrup]

Some ideas:

• Some of the relevant existing classes are AbstractAudioResourceItem (and especially its two subclasses), AudioResourceControl.qml, StyledMenuLoader.qml/StyledMenu.qml etc.
• Currently, the model for a menu is either a QAbstractListModel, or a QVariantList (or JS list); i.e. a list, not a tree. That list contains MenuItems, as defined in menuitem.h, or a QVariantMap (or JS object) with the same entries; and such a menu item contains a property called subitems, which is again a list of menu items. So, there is a kind of tree structure, but only an "ad hoc" one, and not a real QAbstractItemModel (as opposed to QAbstractListModel).
  But to implement the tree-like UI in a somewhat comfortable way, it seems essential to use QML's TreeView component, together with a QAbstractItemModel. So, either you'd need to generate one based on the ad hoc tree structure, or completely replace the ad hoc structure.
• Another big question is whether you should implement this new functionality inside the existing StyledMenu components, or as a completely new component. With the first option, you risk that it adds a performance penalty to all instances of StyledMenu that don't make use of the feature; with the second one, you risk code duplication.
  My guess in this case would be that option 2 might still be better:
  • Create a new component that will contain the search box at the top and the menu items below it (use StyledMenu.qml as inspiration for how to do a menu-like popup)
  • When the user is not searching, just show the content of a StyledMenu; i.e. extract the StyledListView and any other relevant stuff from StyledMenu.qml into a new component called StyledMenuContent.qml, and reuse that new component in your new container component
  • When the user is searching, hide the StyledMenuContent and show a new TreeView-based component instead
  • Regarding menu models: with this solution, it would maybe even be possible to do it the other way around than what I mentioned above: specify a QAbstractItemModel (i.e. a real tree model) to the container component; for the StyledMenuContent component, generate an ad hoc tree structure based on the tree model, as the StyledMenuContent expects; for the TreeView-based component, specify the QAbstractItemModel directly. But I find it difficult to say what would be the best way; absolutely feel free to experiment with it.
• To implement the searching, SortFilterProxyModel (not Q…) might come in handy. It's used for example in AdvancedPreferencesModel and `ScoresListView.