[PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)

Ivica Bukvic ico at vt.edu
Wed Jul 3 09:56:48 CEST 2013


On Jul 3, 2013 1:38 AM, "Roman Haefeli" <reduzent at 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

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130703/d2049a9f/attachment.htm>


More information about the Pd-list mailing list