i just wondered: probably a better approach than PR1766 would be to just expose an API (aka: message to Pd) to call the load_plugin_script on the GUI side.
If this is supposed to be used by externals, we should probably also add an API function.
(for an abstraction it is easy enough to get its own path, e.g. with [file patchpath]; for externals it might be slightly more complicated)
Yes, for externals it's not trivial at all. Actually, it would be cool to have an API function for obtaining the current external path in the setup() function.
Christof
On 13.11.2024 17:47, IOhannes m zmölnig wrote:
moved this to pd-dev, as it is now more about implementing...
On 13/11/2024 12:46, Christof Ressi wrote:
Hi,
I think this PR would be a first step in this direction: https:// github.com/pure-data/pure-data/pull/1766
So far it only allows to load GUI plugins together with compiled externals, but I guess the mechanism can be extended to specifically load GUI plugins.
i just wondered: probably a better approach than PR1766 would be to just expose an API (aka: message to Pd) to call the load_plugin_script on the GUI side. e.g. [; pd load-gui-plugin /path/to/my/plugin( which would then tell the GUI to load /path/to/my/plugin.tcl
notes:
- this takes the full path, so the GUI doesn't need to know anything
about the filesystem organization (for an abstraction it is easy enough to get its own path, e.g. with [file patchpath]; for externals it might be slightly more complicated)
- i deliberately left out the file-extension (so it also works when we
just motif is the GUI backend)
as opposed to PR1766, this moves the responsibility to loading a GUI-plugin from Pd itself to the object/library that wants to use the GUI-plugin. given that an object/library will typically know whether it wants to load a GUI-plugin this is not exactly a bad thing.
gmdsar IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5NBI7555BI7...