Ok, so we have:
default widgetbehavior external: binary compatible
custom widgetbehavior external, compiled against Pd-l2ork and used in
Vanilla: big problems when external tries to initialize extra member of struct
- 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 mailto: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 mailto: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 mailto:ico@vt.edu www.performingarts.vt.edu disis.music.vt.edu l2ork.music.vt.edu