Ok, so we have:
1) default widgetbehavior external: binary compatible

2) custom widgetbehavior external, compiled against Pd-l2ork and used in Vanilla: big problems when external tries to initialize extra member of struct

3) custom widgetbehavior external, compiled against Vanilla and used in Pd-l2ork: the last member of the widgetbehavior will initialize to 0 (or NULL, can't remember which).  Pd-l2ork checks for that and will fall back to the old displacefn callback, not only avoiding a crash but also successfully displacing the object.

So, technically, Pd-l2ork is binary incompatible with Pd Vanilla.  Yet this has no consequence for objects that inherit widgetbehavior from t_text, which is the vast majority of external objects.

Additionally, Pd Vanilla's API for defining custom widget behaviors is so woefully inadequate that externals like Toxy didn't even
survive the GUI refactoring.  And even simple GUI externals like pddplink must add their own custom interface because there's
no mouseover behavior defined in the core widgetbehaviors.  (Nor is there a standard way to define custom widgetbehaviors.)

Additionally-- all those custom ways of bypassing the widgetbehavior callbacks inside externals _must_ be rewritten when
changing gui toolkits anyway.  Some do crazy things like writing a tcl proc in the c string, and I don't see any sensible way to
write a compatibility layer to handle that.

Going forward there are only two options I see:
* Pd Vanilla gets rid of tcl strings in its C code and standardizes on my parameterized gui messaging interface
* Pd community standardizes on the HOA wrapper stuff for GUI externals (porting existing external GUI objects to use it), and Pd-l2ork writes a binding to make that wrapper work with the nw.js port.

The latter makes the most sense to me.  I'll port the HOA wrapper to Pd-l2ork on the off chance the Pd community decides on
that as a standard for writing GUI externals.

-Jonathan






On Tuesday, July 28, 2015 4:13 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:


On 07/27/2015 01:28 PM, Charles Z Henry wrote:

> On Mon, Jul 27, 2015 at 12:08 PM, Jonathan Wilkes via Pd-list
> <pd-list@lists.iem.at> wrote:
>
>> Background info: Pd-l2ork has an extra member at the _end_ of the
>> t_widgetbehavior struct.  This member is used to do accelerated displacing
>> of a selection of objects in Pd.
> This type of modification isn't meant to be binary compatible in both
> directions.  Your Pd-Vanilla externals with the Vanilla
> t_widgetbehavior struct will not work in Pd-l2ork, because the struct
> is smaller.
>
> When Pd-l2ork tries to access those elements off the end of the
> t_widgetbehavior struct, it should seg fault.


Since pd-l2ork is compiled with a different widgetbehavior and assigns
all new objects by default a null value to additional widgetbehaviors,
unless 3rd-party external explicitly somehow overrides widgetbehavior,
this will not crash. The only situation where I think it may crash is if
a 3rd party external tries to copy an object and tries to allocate
memory for a specific widgetbehavior size, which seems questionable
since externals should not have to worry about widgetbehavior size and
IIRC this part is instantiated inside core pd routines.

Best,

Ico

>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico@vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu