On 14.11.2024 09:40, IOhannes m zmoelnig wrote:
On 11/13/24 22:02, Christof Ressi wrote:
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.
i don't really see why we cannot consider sending a message to a
global receiver to be part of the API, at least for procedures that do
not return anything.
Because this is not idiomatic. I really don't want to assemble a Pd
message just to make an API call. Do you know of any other API that is
*only* accessible through a Pd message?
in the worst case (of an older Pd version that does not yet have the
given message), Pd just spits out an error ("unknown message").
You just hit another downside of Pd messages: no opportunity for error
handling
if instead we bake it into a proper C function call, then an older Pd
version will simply refuse to load the external that "naively" uses
the function (without checking whether the function actually exists).
That's why we now have sys_getfunbyname() :)
the bonus of a C API function, is that it is easier discoverable by
the casual developer (by just skimming through the public headers).
(but API documentation in Pd is an entirely different problem)
(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.
actually, i just found out¹ that we do have a function that can query
the load path of an object class: class_gethelpdir()
this is used to find the help-patch for an object (hence the name).
the function was introduced in 2002, so I think you can use it without
thinking of backward compatibility.
since you create your classes in the setup() callback, you can query
your just created classes to get the load path of the library.
in some circumstances, the load path will be relative to the current
working directory (e.g. when you load a library with a relative path
from the cmdline, like "pd -lib libs/zexy"), but i think in this case
it is safe to assume that the pd-gui is started from the same working
directory (so relative paths resolve the same). if this is *not* the
case, then I assume you have a rather complicated setup and are able
to cater for this problem by yourself (e.g. by loading the library
with its absolute name).
i'm a bit unhappy about the name though. should we create an alias
"class_getexterndir()"? or just not worry (adding an alias seems a bit
like busywork)
gmadsr
IOhannes
¹ jeez; some of my more complicated externals (like Gem) have a lot of
code to get the external directory; i'll have to cleanup
---
[email protected] - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/4RIKAADGG2LL33VI76N73FRYDB4W2L5L/
---
[email protected] - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/RE6NBX3AXC4YH6M43KHIMWPGFH542OKO/
