[PD] GOP text field / symbol which is resizeable?

[Jonathan Wilkes]

On 07/03/2013 04:31 AM, Roman Haefeli wrote:
> 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.

I agree with Roman.  Patch authors were being very reasonable when
they created their GOPs that just so happened to be based on faulty
logic under the hood.  Those discrepancies were extremely small,
small enough that most patch author's probably didn't even notice the
bug until you pointed it out and fixed it.

So through no fault of their own, their patches are broken on the
distribution of Pd that has a superior UX.  That's a bad situation.

If you have a solution not too far off that will allow such GOP objects
to be functional again, then the temporary breakage is probably ok.
If not, then we need to keep the bug for all eternity and work around it.

To do otherwise is to scare off potential users who have no idea how many
other changes will break their patches because of idiosyncracies
that lurk deep in code that Pd was designed to abstract away from them.

-Jonathan

> 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
>
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list