FR: Allow using more flexible models with the PluginListComponent

PluginListComponent shows context menu wrong plugin if setTableModel is used that provides filtering.

In our app, we provide a custom model so users can have a search box to filter the plugins. If users search and then right click, the context menu applies to the wrong plugin.

Please also make the following change to the revealed plugin is selected:

diff --git a/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp b/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp
index 28e06a093..88c3f8183 100644
--- a/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp
+++ b/modules/juce_audio_processors/scanning/juce_PluginListComponent.cpp
@@ -262,7 +262,7 @@ static bool canShowFolderForPlugin (KnownPluginList& list, int index)
 static void showFolderForPlugin (KnownPluginList& list, int index)
 {
     if (canShowFolderForPlugin (list, index))
-        File (list.getTypes()[index].fileOrIdentifier).getParentDirectory().startAsProcess();
+        File (list.getTypes()[index].fileOrIdentifier).revealToUser();^M
 }

We can definitely make the revealToUser change you’ve suggested here.

Regarding the initial report, I’m not sure that I’d call this a ‘bug’, but rather a limitation of the current API. Given that the list model is a plain TableListBoxModel, it’s only possible for this model to communicate with the PluginListComponent in terms of indices into the list. There’s no way for an instance of TableListBoxModel to communicate that it is only displaying a subset of the plugin list. Essentially, the limitations of the model API require that the PluginListComponent and the TableListBoxModel both adhere to the same contract: that table indices in the TableListBoxModel/PluginListComponent exactly correspond to the same plugin indices in the KnownPluginList.

To get the behaviour you’ve requested, I think we’d need to significantly change the interface of the ‘model’ class, so that the PluginListComponent can query it to find the actual PluginDescriptions that are currently selected, rather than just plain list indices. This would mean moving away from the current use of TableListBoxModel, and would be a breaking change in the API.

Due the scope of the required changes, I’m going to recategorise this topic as a feature request.