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.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to