Not likely. For example, look at the coordinate system for iemgui objects and you will find out that they are offset arbitrarily by a few pixels (in other words, their xy coordinates do not reflect their top left corner but some other arbitrary location). This is particularly apparent when trying to autopatch things. In pd-l2ork I first started working with ugly workarounds and soon found that I had to keep adding exceptions (e.g. in undo/redo actions that pertained to autopatching and similar situations) all over the place until I decided the best thing is to simply redo the iemgui implementation the right way by positioning them accurately according to their xy position.
Now, fast-forward x years where we have a shiny new gui and are facing the question that pd-l2ork is already trying to address, which is do we keep backwards compatible yet dubious behavior of the original gui or do we correct this and then expect everyone to correct their endless library of GOP abstractions that put iemgui objects on the edge of the gop rectangle and as a result many of which become invisible because now they technically do not fit the GOP rectangle any more?
On Sun, Feb 23, 2014 at 8:26 PM, Rich E reakinator@gmail.com wrote:
Hey lets keep on topic here. :) I'd say separating the gui and core is much less work than trying to revamp pd's threading model. Just *enabling* thirdparty GUI's that can talk to pd core as an audio and computation engine, should be possible without breaking backwards compatibility.