On 3/10/23 11:06, Pierre Alexandre Tremblay wrote:
But is there a way to read programmatically the state of ‘installs’ ? If so then this new addition of a menu would tap into it and voilà, low/no maintenance and custom, situated content!
how does the search-plugin do it? the Pd-GUI knows which paths are searched by Pd, and can use this action.
what it does not know is, when a new library is actually *loaded*¹ and which new objects are now known (e.g. after Gem, you suddenly have a [square] object).
newly added objects cannot be deduced from the search-paths. so it would indeed require a way to query the list of objects known to Pd. E.g. the GUI could be given a list of all known objectclasses and their corresponding help-patches (and this list would need to be updated whenever a new objectclass is loaded). the help-patches can be parsed to get the categories for a given object.
you probably also need a bit of context, as some objects are not available in all canvases (think abstractions and [declare -path]; future versions of Pd might also extend this patch-locality to libraries and [declare -lib]) - so when designing such an API, one should keep this in mind.
of course it is much easier, if you only take built-in objects into account (as is currently the case).
gfmdsar IOhannes
¹ this is not a problem for the search-plugin, as this will only give you patches, that are hopefully useable on their own.