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

[Roman Haefeli]

On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
> 
> 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. 

Many of my patches are not usable at all without GOP GUIs visible. And I
cannot fix it myself as either it breaks pd-vanilla|pd-extended or
pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a
serious way. And I also do not see the temporary aspect of it. I as a
patch developer can't provide a solution to this.

This is _the_ reason I don't even try to bother to make my patches work
in pd-l2ork. And I even need to tell people that they shouldn't use
pd-l2ork when they want to use my patches.

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

Actually, one can decide to use or not to use new features. Obviously,
added features do not work in flavors that do not implement that
feature. From a user point of view, this can be dealt with  in an clean
way. If you want your patch to work on other flavors, don't use stuff
like preset_node. I don't see a problem at all with that.

Roman