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:
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)
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).