can anyone get dropfile.pd to corectly open with .38test4?
on windows? on my pd it opens blank (if i have -lib toxy in my .bat).
i'm not sure that's specific to 0.38. however i would always recommend building toxy to your pd version, rather than use binaries( the makefile in externals/miXed/ will build in GCC on windows, or linux..or osx...) since a minor tweak in any of the g_ files could break everything...(mathieu has seemed interested in pure-Tk GUI objects so i would hope or suspect the process is integrated one day..)
so i noticed if you open drop*.pd first, pd freezes, on this:
image create bitmap ::toxy::img::empty -data {} proc ::toxy::doreply {target vname vndx op} { pd [concat $target _rp $::toxy::reply ;] unset ::toxy::reply } pdtk_canvas_new .x9f5850 505 131 +471+279 0 wm title .x9f5850 {dropfile.pd - C:/samples/_p/pd} set menu_windowlist {{dropfile.pd .x9f5850} } pdtk_fixwindowmenu
however, if you open another toxy-using patch first, or, if you add -lib "widget;zexy" it should work on launch....
hi cdr, Josh,
cdr wrote:
can anyone get dropfile.pd to corectly open with .38test4?
on windows? on my pd it opens blank (if i have -lib toxy in my .bat).i'm not sure that's specific to 0.38. however i would always recommend building toxy to your pd version, rather than use binaries( the makefile in externals/miXed/ will build in GCC on windows, or linux..or osx...) since a minor tweak in any of the g_ files could break everything...(mathieu has seemed interested in pure-Tk GUI objects so i would hope or suspect the process is integrated one day..)
it is unlikely toxy would work with 0.38, I am afraid, without updating the way of addressing Tk objects (or waiting for Miller to release a version which restores the original way).
so i noticed if you open drop*.pd first, pd freezes, on this:
image create bitmap ::toxy::img::empty -data {} proc ::toxy::doreply {target vname vndx op} { pd [concat $target _rp $::toxy::reply ;] unset ::toxy::reply } pdtk_canvas_new .x9f5850 505 131 +471+279 0 wm title .x9f5850 {dropfile.pd - C:/samples/_p/pd} set menu_windowlist {{dropfile.pd .x9f5850} } pdtk_fixwindowmenu
weird the trace ends here... The fragile part of potential widget-to-text transformation (which is fired on a Tk failure) comes just next, after [widget]s start sending Tk-widget drawing requests.
Have you tried building toxy with uncommented WIDGET_DEBUG, WIDGETTYPE_DEBUG, and SCRIPTLET_DEBUG #defines?
Krzysztof
On Tue, 14 Sep 2004, Krzysztof Czaja wrote:
since a minor tweak in any of the g_ files could break everything...(mathieu has seemed interested in pure-Tk GUI objects so i would hope or suspect the process is integrated one day..)
I had started working on Model-View object relationships in Pd. The way I implement it in IMPD is that the Model is a C object and the View is a Tcl object that is as much as possible a clone of the first one and updated by recopying its fields from the Model.
The problem with doing such work is that it completely obsoletes any old kind of GUI object API in such a way that it becomes very boring and/or silly to make the effort to keep compatibility with the old system. So, I thought, I should take that occasion to make the most useful possible changes all at once.
That new system wouldn't be pure-Tk but would be rather close to it; and possibly that in such a context a kind of stub class could be created, that does the minimum possible handling in C in a generic way so that subclasses of it may be created by only adding Tcl code.
Actually I have a prototype of that but it's been on hold for ~4 months because I have more GridFlow-related inspiration these days. I stopped working on it just before working out the Observer/Observable relationship and the new pd_changed() function that decouple C and Tcl one step further.
Mathieu Bouchard http://artengine.ca/matju
-
cdr -
Krzysztof Czaja -
Mathieu Bouchard