<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1461247656715_11938">For a1) I've also thought about abusing the invisible template-canvas, for a different purpose. But that's a <br></div><div id="yui_3_16_0_ym19_1_1461247656715_12048" dir="ltr">short term gain for the risk of bigger problems and unnecessary side-effects later.</div><div id="yui_3_16_0_ym19_1_1461247656715_12269" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12270" dir="ltr">If you still want to go the route of invisible canvas, there should probably be a simple interface to create and <br></div><div id="yui_3_16_0_ym19_1_1461247656715_12271" dir="ltr">manage a new invisible canvas for that purpose. That way if you need to debug your invisible canvas, you <br></div><div id="yui_3_16_0_ym19_1_1461247656715_12272" dir="ltr">don't end up nuking garray's drawing instruction when you accidentally close it (for a simple example).</div><div id="yui_3_16_0_ym19_1_1461247656715_12300" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12301" dir="ltr">I know Hans was thinking in that direction for libdir loading. I'm still not sure if that's a good idea, though.</div><div id="yui_3_16_0_ym19_1_1461247656715_12491" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12492" dir="ltr">But backing up a bit...</div><div id="yui_3_16_0_ym19_1_1461247656715_12493" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12556" dir="ltr">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:<br></div><div id="yui_3_16_0_ym19_1_1461247656715_12577" dir="ltr"><a id="yui_3_16_0_ym19_1_1461247656715_12576" class="" href="https://github.com/CICM/CicmWrapper">https://github.com/CICM/CicmWrapper</a><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12621"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_12705"><br></div><div id="yui_3_16_0_ym19_1_1461247656715_11608"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Thursday, April 21, 2016 10:08 AM, IOhannes m zmölnig <zmoelnig@iem.at> wrote:<br></font></div> <br><br> <div class="y_msg_container">i'm developing a little something that consists of a gui-plugin and some<br>library running on the pd-core side.<br><br>the gui plugin does not make any sense without the library loaded and<br>vice-versa.<br><br>so i'm looking for the best way to<br>a1) load an external from a gui-plugin<br>OR<br>a2) load a gui-plugin from an external<br>AND/OR<br>b) check from one side that the other side is initialized properly.<br><br>all of the above should not make any assumptions about the OS.<br>all of the above should work without any nasty trace-back errors.<br>instead, i would like to do the error-reporting myself (a traceback is<br>cool for a dev; less so for a user)<br><br>ad a1) i was thinking about abusing one of the invisible<br>template-canvases to instantiate a dummy object that triggers the<br>library load (e.g. "_float_template"). are there any pitfalls that i<br>should be aware of?<br><br>ad a2) the main reason or writing a GUI-plugin is to get rid of any<br>tcl/tk hard-coded into the C-plugin. i guess sending a command like<br>"load_plugin_script mycoolthing" is platform agnostic enough for my<br>needs. however, it seems that the only way to load a plugin is currently<br>by specifying the full filename: "load_plugin_script mycoolthing.tcl"; hmpf<br>it also throws a nasty error if Pd cannot find the GUI-plugin:<br>> Tcl) UNHANDLED ERROR: couldn't open "mycoolthing.tcl": no such file or<br>directory<br><br>ad b) the basic idea is to have a ping-function on the *other* side,<br>that replies with a "hi, i'm here" when called.<br>so far i've found two options:<br>b1) create a proc in the plugin, and call that directly from the core;<br>or b2) have the GUI register a plugin-receiver that does the dispatching.<br>unfortunately both solutions give me a backtrace when the GUI-plugin has<br>not been instantiated (and the point of the exercise is to avoid a<br>backtrace)<br><br>ideas?<br><br>_______________________________________________<br>Pd-dev mailing list<br><a ymailto="mailto:Pd-dev@lists.iem.at" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a><br><a href="https://lists.puredata.info/listinfo/pd-dev" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br><br><br></div> </div> </div> </div></div></body></html>