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