[PD] binary compatibility

[Jonathan Wilkes]

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 at 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 at lists.iem.at <mailto:pd-list at 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 at lists.iem.at <mailto:Pd-list at 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 at vt.edu <mailto:ico at vt.edu>
> www.performingarts.vt.edu
> disis.music.vt.edu
> l2ork.music.vt.edu
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150728/eda4b2bf/attachment.html>