i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
----- Original Message -----
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
-Jonathan
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
You can set paths in the preferences still. I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
.hc
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....
i agree hence the "in patch" gui-plugin loading....
hmmmm
m
On Fri, Jan 25, 2013 at 4:01 PM, Hans-Christoph Steiner hans@at.or.at wrote:
On 01/25/2013 04:21 PM, me.grimm wrote:
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].
.hc
On 01/25/2013 04:34 PM, Hans-Christoph Steiner wrote:
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
----- Original Message -----
Ok, I didn't see that.
By user-set, do you mean by setting the paths in Preferences from the "Edit" menu?
Also, is there a tcl variable that holds the paths that were set by a [declare], or one that holds the paths for the currently opened patches?
-Jonathan
----- Original Message -----
That was one thing that was neat about the the object-oriented GUI approach of DesireData-- you ended up with a mirror of the Pd side of things (at least it looked that way).
BTW-- I've done a little work on my "rename" hack, and it seems to work ok so far. The question is should the FUDI message that I generate look exactly like the FUDI message that triggered the event in Pd that generated the message to the gui in the first place, or does it just need to follow the FUDI syntax?
-Jonathan
.hc
On 01/25/2013 07:22 PM, Jonathan Wilkes wrote:
Since pd-gui --> pd is FUDI, pd --> pd-gui should be too. Then it also fits in to the 'Pure Data' idea of the same message format everywhere, including within Pd, between pd and pd-gui, in the file format, in network communication, etc.
.hc
----- Original Message -----
[...]
I thought the same thing. In the case of "tip" it suggests a redesign-- separating out the "autotips" from the manual tips (which is probably a good idea anyway). But in terms of this plugin, I could just make two separate methods available-- "tip" and "autotip" instead of using an arg, then the message content for "tip" would be the same between pd and the gui.
-Jonathan
.hc