On 01/25/2013 04:34 PM, Hans-Christoph Steiner wrote:
On 01/25/2013 04:21 PM, me.grimm wrote:
plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
that would be so one might have a different gui look for each of their patchs. or could distribute a gui-plug specific to their patch with their patches, etc.
in my case im using the gui-plugs to make my patch look like some absrtacted, glitch, unusable mess... but then if i leave it in the standerd path every patch i would open would be like that there for if i could [declare] the path to the gui-plug then i wouldn't have to worry about it. only that one patch would have those properties....
Hmm, that would be tricky for Pd to make a GUI-plugin only apply to a single patch, but you could program that in GUI plugin itself. Use [wm stackorder .] to get the list of open windows, then go thru the list and check [wm title ], then compare that to the patchname you want to affect. Then use that to make a canvas id, and only use that canvasid to change things. ROughtly like:
foreach mytoplevel [wm stackorder .] { if {[regsub {mypatchname} [wm title $mytoplevel]]} { set tkcanvas [tkcanvas_name $mytoplevel] break } }
Now $tkcanvas is the canvas that you want. I didn't try the above code, it might have errors, but that's the idea. You can also do that in a patch itself with [hcs/window_name] and [hcs/canvas_name].
Hmm, now that i think about it, there is a better way, which would be using the <<Loaded>> event.
If you receive it:
bind all <<Loaded>> {receive_loaded %W}
proc receive_loaded {mytoplevel} { if {[regsub {mypatchname} [wm title $mytoplevel]]} { set tkcanvas [tkcanvas_name $mytoplevel] # apply your tricks here } }
.hc