[PD] GUI and DSP
Ivica Ico Bukvic
ico at vt.edu
Mon Feb 13 01:34:14 CET 2012
On 02/12/2012 06:10 PM, Hans-Christoph Steiner wrote:
> I think a lot of this would be alleviated for the most part if not entirely if:
>
> 1) pd completely removed redrawing logic from the c code and migrated it into tcl (which is what you may have done in great part already inside desire-data)
>
> 2) pd used a different toolkit that allowed for more intelligent addressing of individual gui components (again, JUCE IMO comes at the very top here)
>
> I agree. I think a lot of this can be done incrementally. Basically, take a chunk of logic and refactor it so that Tcl/Tk handles the GUI stuff and pd sends pd messages rather than lines of Tcl. One example of where that could be done is the key press/release handling code. Right now, there is a lot of code for this in g_canvas.c. It is possible that the tag/move code could also be done this way.
>
> .hc
Moving by tag requires a major rewrite on c side of things or
reimplementation of widgetbehavior as is the case with pd-l2ork. This is
mainly because there are some actions that simply require absolute
positioning while others can work through relative positioning (e.g.
creating vs. moving). This is why pd-l2ork uses expanded version of
widgetbehavior and now is capable (through an iterative improvement) of
moving by tag pretty much everything (albeit at the expense of binary
compatibility, which IMO is not a problem when pd-l2ork pretty much
packages most of additional externals with it and others can be simply
recompiled with no changes to the source, with the exception of gridflow
that uses unusual approaches to deal with GUI matters).
More information about the Pd-list
mailing list