[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