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

Ivica Ico Bukvic ico at vt.edu
Wed Jul 3 01:15:01 CEST 2013


> [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.
> 
> Roman

This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility. I do agree it is a nuisance nonetheless, yet I feel it is a necessary part of pd(-l2ork) growing and becoming more consistent. The reason why I did what I did in pd-l2ork is best portrayed if you use autopatching option which positions everything in line vertically. If you autopatch objects like atom, then hsl, then another atom (or symbol or simply an object), you'll see how things align (or don't).

Now, if an object does not render properly in pd-l2ork because of this translation, then what is needed is simply nudging it in the opposite direction. However, if the object appears within the GOP boundaries but is still not visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.

Best wishes,

Ico




More information about the Pd-list mailing list