I’m using the member KnownPluginList::addToMenu( PopupMenu & menu, const SortMethod sortMethod )
to create a menu of all the plug-ins my host can load. Works fine, except, my host can load both VST & AU
and I wish that the menu would also display which plug-in is of which type. Sometimes plug-ins come in both
VST & AU versions and I wish to distinguish between them in the menu.
May I suggest changing the menu creation call to something like:
The code alteration would be minimal. Thanks for considering it!
I intended to inherit but the stuff was private. The class itself isn’t that complex so copying it isn’t that big a deal, although the day Jules starts to change the original class is when I gets annoyed with myself.
Deriving from KnownPluginList is bad form. You can still get at the private data members using the accessor functions, getNumTypes() and getType(). There is no reason for you to subclass or access the private data members.
Which is why subclassing and accessing private members is a mistake. I very much doubt that getNumTypes() and getType() are going to change. And these are the two functions you need for building the menu the way that you want.
The only realistic change that I could endorse would be to move class PluginFilesystemTree and class PluginSorter into a header so that they can be reused by people who want to build their own menu (Jules?)
TBH that code’s pretty old, and if I was writing it now, I wouldn’t do it like that. The class shouldn’t know anything about menus at all, it’d be better if it just provided an iterator that was suitable for using to build your own menus. Would probably be best to just have some methods to return arrays of the plugins, sorted with whatever sorting method is needed.