Possible extension of PluginDescription

The combination of PluginDescription and KnowPluginList is really convenient for a host to manage a user’s plugin catalog. The only drawback in the way it is designed is that it does not allow to add extra, host specific fields. For example, we could think of adding a favorite boolean that the user could set, etc.

Subclassing PluginDescription is out of the table since it would involve entirely rewriting KnowPluginList to support it.

The only way to achieve this I can think of at the moment is to “hack” the extra fields in PluginDescription directly.

Does anyone has any idea / experience with this? Would adding support for extra fields be a reasonable feature request?

How about going the other way round and have a list of your favourites?

std::vector<juce::PluginDescription> favourites;

And you can serialise that using the uid.

It has a few redundancies if you want to add more information, but all in all I think it’s a viable option.

Sure that’s an option for this specific example, although it means maintaining two data structures instead of one (all changes to the KnownPluginList will need to be reflecting in favourites). Also for persistence, it would mean storing this list in a different file, or hacking into the XML created by KnownPluginList.

And it would become even more complex the more fields you add, like user tags per plugin, some usage statistics, etc.

If PluginDescription allowed for adding extra fields, enforcing the fields type to String, the catalog handle by KnownPluginList could fit any application.

You could create a data structure that contains all your custom settings (favourite, tags, etc.) and stores a reference of the plug-in by identifier/name.
My first guess is to create an XML like

<Plugin pluginID="some-plugin-id" isFavourite=true tags="tags-here" />
<Plugin pluginID="some-plugin-id" isFavourite=true tags="tags-here" />
<Plugin pluginID="some-plugin-id" isFavourite=true tags="tags-here" />

Good suggestion indeed, although I don’t like to have to maintain a synchronization between 2 data structures & 2 files. But I guess that is what I’ll end up doing if I end up hacking more than a few fields to PluginDescription!