On Jul 3, 2013 1:38 AM, "Roman Haefeli" <reduzent@gmail.com> wrote:
>
> On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
> > > [symbol\
> > > |
> > > [label $1(
> > > |
> > > [cnv]
> > >
> > > > - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
> > > > in l2ork so it doesn't GOP when it's less than 2-3px from the border
> > > > of the parent canvas. Checked in Vanilla, it works as expected ([hsl]
> > > > can be placed to the very border and it will GOP).
> > >
> > > According to Ivica this is on purpose. The reason is that iemguis used
> > > to have miscalculated positions and pd-l2ork fixed that while
> > > pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility
> > > between pd-l2ork and pd-vanilla/pd-extended.
> >
> > This is true. Although, I wouldn't call translating an object by 3
> > pixels exactly breaking compatibility.
>
> If a patch just isn't usable at all on a different flavor, then I don't
> see how this doesn't qualify for breaking compatibility.
>
> Roman

I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily. If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.

HTH

>
>