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

[Ivica Bukvic]

On Jul 3, 2013 7:09 PM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:
>
> 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.

For me having a new user face inconsistency with autopatching is a lot more
critical than an existing user encounter an inconsistency due to the fact
that an old bug has been fixed.

One could approach this problem by having a hack that adjusts the spacing
during autopatching and that's exactly what I used to have. At some point I
simply realized that I was adding more and more hacks to keep the hack
propagating through the undo and other functions, and came to the
conclusion it's time to start cleaning up hacks like these and make the
code cleaner and easier to maintain.

Otherwise, by your suggested approach one could conclude that PD is perfect
as-is and that no other development/changes are necessary. Case in point if
a comment or labels for iemgui objects do in part fall out of GOP area,
pd/extended still render them visible. Since this bug has been there for
some time there are possibly patches out there that exploit this bug as a
feature and by using your logic we should never change that either as doing
so would break old patches. Again, if we take the suggested approach then
there's nothing to change about pd. OTOH, one could ostensibly look into
creating a simple shell script that when run could easily adapt all of the
old patches to the new spacing. Perhaps someone else may want to contribute
this?

In summary let us hope that other versions of the pd adopt the same/similar
fixes and do so soon.

Best wishes,

Ico

>
> 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
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130704/2efa9f90/attachment-0001.htm>