I've noticed in the TK 8.6 release notes http://tcl.tk/software/tcltk/8.6.html, there are a few new commands for moving existing canvas objects:
Moving Things on a Canvas: New commands $canvas moveto, $canvas imove and $canvas rchars for moving and manipulating canvas items.
Perhaps this is something that can be used by the pd core instead of deleting then redrawing? I think there would need to be some sort of compile time or runtime check for the TK version though.
In any case, I'm still interested in ways to abstract the raw guilt tcl from the core usage in order to provide a generic interface for guis communication in libpd, so looking into this could be part of that...
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 03-11-17 18:42, Dan Wilcox wrote:
In any case, I'm still interested in ways to abstract the raw guilt tcl from the core usage in order to provide a generic interface for guis communication in libpd, so looking into this could be part of that...
Is this the problem that Purr-data and CICM tried to solve?
There were some ideas discussed atd Pd-CON-2016, and it would be nice to try to implement it as a proof of concept for 'standard' objects and maybe some IEM-GUI ones. Having something implemented makes it easier to talk about the problem (the 'code,talk' adagium).
Fred Jan
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Is this the problem that Purr-data and CICM tried to solve?
Purr Data uses a generic interface for speaking to the GUI.
The spec for Purr Data's communication from Pd to the GUI is here:
https://git.purrdata.net/jwilkes/purr-data/tree/master#gui-messaging-specifi...
-Jonathan
On 04-11-17 23:42, Jonathan Wilkes wrote:
Is this the problem that Purr-data and CICM tried to solve?
Purr Data uses a generic interface for speaking to the GUI.
The spec for Purr Data's communication from Pd to the GUI is here:
https://git.purrdata.net/jwilkes/purr-data/tree/master#gui-messaging-specifi...
Both the current Pure Data and Purr Data interface use drawing primitives. The PDCon2016 discussion was about replacing it with somewhat more high-level, like 'draw me a standard object box with X name, Y inlets and Z outlets'.
The Purr Data approach would still be used for custom GUI objects.
Fred Jan
-Jonathan
On 04-11-17 23:42, Jonathan Wilkes wrote:
Is this the problem that Purr-data and CICM tried to solve?
Purr Data uses a generic interface for speaking to the GUI.
The spec for Purr Data's communication from Pd to the GUI is here:
https://git.purrdata.net/jwilkes/purr-data/tree/master#gui-messaging-specifi...
Both the current Pure Data and Purr Data interface use drawing
primitives.
Not for everything. For example, text/message/object box edition
currently happens with the kind of interface you're describing.
The PDCon2016 discussion was about replacing it with
somewhat more high-level, like 'draw me a standard object box with X
name, Y inlets and Z outlets'.
Because Pd has no specification for GUI behavior, I chose to do a
"primitive for primitive" port from tcl/tk to nw.js and only incrementally
change some of the primitives to what you're calling somewhat more
high-level, and only in those cases where performance dictated it to
be necessary.
-Jonathan
The Purr Data approach would still be used for custom GUI objects.
Fred Jan
-Jonathan
On 11/04/2017 11:42 PM, Jonathan Wilkes via Pd-dev wrote:
Is this the problem that Purr-data and CICM tried to solve?
Purr Data uses a generic interface for speaking to the GUI.
The spec for Purr Data's communication from Pd to the GUI is here:
https://git.purrdata.net/jwilkes/purr-data/tree/master#gui-messaging-specifi...
hmm, well. i don't see how this specification abstracts the communication (apart from the array stuff). instead, it defines a C interface. afaics, this C interface could be used out of the box with the current Pd, without changing a jota of the problem, that the GUI needs to run a Tcl/Tk interpreter in order to make sense of what is coming over the wire.
am i missing the actual message specification. or am i looking at the wrong problem?
gfasdr IOhannes
-
Dan Wilcox -
Fred Jan Kraan -
IOhannes m zmölnig -
Jonathan Wilkes