i'm developing a little something that consists of a gui-plugin and some library running on the pd-core side.
the gui plugin does not make any sense without the library loaded and vice-versa.
so i'm looking for the best way to a1) load an external from a gui-plugin OR a2) load a gui-plugin from an external AND/OR b) check from one side that the other side is initialized properly.
all of the above should not make any assumptions about the OS. all of the above should work without any nasty trace-back errors. instead, i would like to do the error-reporting myself (a traceback is cool for a dev; less so for a user)
ad a1) i was thinking about abusing one of the invisible template-canvases to instantiate a dummy object that triggers the library load (e.g. "_float_template"). are there any pitfalls that i should be aware of?
ad a2) the main reason or writing a GUI-plugin is to get rid of any tcl/tk hard-coded into the C-plugin. i guess sending a command like "load_plugin_script mycoolthing" is platform agnostic enough for my needs. however, it seems that the only way to load a plugin is currently by specifying the full filename: "load_plugin_script mycoolthing.tcl"; hmpf it also throws a nasty error if Pd cannot find the GUI-plugin:
Tcl) UNHANDLED ERROR: couldn't open "mycoolthing.tcl": no such file or
directory
ad b) the basic idea is to have a ping-function on the *other* side, that replies with a "hi, i'm here" when called. so far i've found two options: b1) create a proc in the plugin, and call that directly from the core; or b2) have the GUI register a plugin-receiver that does the dispatching. unfortunately both solutions give me a backtrace when the GUI-plugin has not been instantiated (and the point of the exercise is to avoid a backtrace)
ideas?
For a1) I've also thought about abusing the invisible template-canvas, for a different purpose. But that's a short term gain for the risk of bigger problems and unnecessary side-effects later. If you still want to go the route of invisible canvas, there should probably be a simple interface to create and manage a new invisible canvas for that purpose. That way if you need to debug your invisible canvas, you don't end up nuking garray's drawing instruction when you accidentally close it (for a simple example). I know Hans was thinking in that direction for libdir loading. I'm still not sure if that's a good idea, though. But backing up a bit... If you're goal is to get rid of tcl in the C code in an external written for Pd Vanilla, why not use this: https://github.com/CICM/CicmWrapper
On Thursday, April 21, 2016 10:08 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
i'm developing a little something that consists of a gui-plugin and some library running on the pd-core side.
the gui plugin does not make any sense without the library loaded and vice-versa.
so i'm looking for the best way to a1) load an external from a gui-plugin OR a2) load a gui-plugin from an external AND/OR b) check from one side that the other side is initialized properly.
all of the above should not make any assumptions about the OS. all of the above should work without any nasty trace-back errors. instead, i would like to do the error-reporting myself (a traceback is cool for a dev; less so for a user)
ad a1) i was thinking about abusing one of the invisible template-canvases to instantiate a dummy object that triggers the library load (e.g. "_float_template"). are there any pitfalls that i should be aware of?
ad a2) the main reason or writing a GUI-plugin is to get rid of any tcl/tk hard-coded into the C-plugin. i guess sending a command like "load_plugin_script mycoolthing" is platform agnostic enough for my needs. however, it seems that the only way to load a plugin is currently by specifying the full filename: "load_plugin_script mycoolthing.tcl"; hmpf it also throws a nasty error if Pd cannot find the GUI-plugin:
Tcl) UNHANDLED ERROR: couldn't open "mycoolthing.tcl": no such file or
directory
ad b) the basic idea is to have a ping-function on the *other* side, that replies with a "hi, i'm here" when called. so far i've found two options: b1) create a proc in the plugin, and call that directly from the core; or b2) have the GUI register a plugin-receiver that does the dispatching. unfortunately both solutions give me a backtrace when the GUI-plugin has not been instantiated (and the point of the exercise is to avoid a backtrace)
ideas?
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
One thing to add-- I believe Hans' proposal was to actually load the *-meta.pd so that it's just sitting there in the background like the garray template canvases. So I guess the idea is:1) see if LIB-meta.pd exists when trying to load LIB.2) if it exists, load it as an invisible background canvas.3) done So for your case I guess you would need a public interface to try to load a library at runtime from the GUI. And sitting in your LIB-meta.pd patch is the external object that you want to exist. -Jonathan
On Thursday, April 21, 2016 11:10 AM, Jonathan Wilkes via Pd-dev pd-dev@lists.iem.at wrote:
For a1) I've also thought about abusing the invisible template-canvas, for a different purpose. But that's a short term gain for the risk of bigger problems and unnecessary side-effects later. If you still want to go the route of invisible canvas, there should probably be a simple interface to create and manage a new invisible canvas for that purpose. That way if you need to debug your invisible canvas, you don't end up nuking garray's drawing instruction when you accidentally close it (for a simple example). I know Hans was thinking in that direction for libdir loading. I'm still not sure if that's a good idea, though. But backing up a bit... If you're goal is to get rid of tcl in the C code in an external written for Pd Vanilla, why not use this: https://github.com/CICM/CicmWrapper
On Thursday, April 21, 2016 10:08 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
i'm developing a little something that consists of a gui-plugin and some library running on the pd-core side.
the gui plugin does not make any sense without the library loaded and vice-versa.
so i'm looking for the best way to a1) load an external from a gui-plugin OR a2) load a gui-plugin from an external AND/OR b) check from one side that the other side is initialized properly.
all of the above should not make any assumptions about the OS. all of the above should work without any nasty trace-back errors. instead, i would like to do the error-reporting myself (a traceback is cool for a dev; less so for a user)
ad a1) i was thinking about abusing one of the invisible template-canvases to instantiate a dummy object that triggers the library load (e.g. "_float_template"). are there any pitfalls that i should be aware of?
ad a2) the main reason or writing a GUI-plugin is to get rid of any tcl/tk hard-coded into the C-plugin. i guess sending a command like "load_plugin_script mycoolthing" is platform agnostic enough for my needs. however, it seems that the only way to load a plugin is currently by specifying the full filename: "load_plugin_script mycoolthing.tcl"; hmpf it also throws a nasty error if Pd cannot find the GUI-plugin:
Tcl) UNHANDLED ERROR: couldn't open "mycoolthing.tcl": no such file or
directory
ad b) the basic idea is to have a ping-function on the *other* side, that replies with a "hi, i'm here" when called. so far i've found two options: b1) create a proc in the plugin, and call that directly from the core; or b2) have the GUI register a plugin-receiver that does the dispatching. unfortunately both solutions give me a backtrace when the GUI-plugin has not been instantiated (and the point of the exercise is to avoid a backtrace)
ideas?
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmölnig -
Jonathan Wilkes