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

[Jonathan Wilkes]

On 07/03/2013 07:31 AM, Roman Haefeli wrote:
> On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote:
>> On 07/03/2013 04:31 AM, Roman Haefeli wrote:
>>> On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
>>>> 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.
>>>
>> The solution is the one you stated above--stick to one particular flavor
>> of pd and run with it. I for one believe the sooner I switch my patches
>> to a more consistent drawing mechanism the less I will have to deal with
>> down the road. pd has two choices:
>>
>> 1) keep the same inconsistent behaviour for as long as it exists causing
>> problems in other places for the patch developers such as yourself (e.g.
>> autopatching), in the end causing the same amount of work (whether you
>> fix whatever is currently misaligned or do that while patching because
>> your autopatch feature did not align your objects properly is as far as
>> I can tell the same amount of work, of course, assuming that you do use
>> autopatch--I do, so this is very important to me)
>>
>> 2) fix this at some later date at which point you will have a larger
>> library of patches you've built between now and that later date that
>> will require fixing because they relied on the current inconsistent way
>>
>> Consider also how pd does not properly account for labels on iemguis or
>> comments and does not mind having them stick outside GOP. Or how
>> dynamically changed iemgui objects inside GOP do not get their
>> visibility rechecked to see if they still fit within GOP and then spill
>> outside it only to disappear when you copy and paste the said GOP. These
>> are all fixed within pd-l2ork. I believe these are very pressing issues
>> for me as L2Ork's entire GUI scoring system is built around iemguis and
>> scalars and I want to make sure that others developing similar scores
>> (or expanding upon the existing) for the ensemble do not encounter such
>> inconsistencies that can be abused for temporary solutions that later
>> break because such bugs have been fixed, rendering their scoring engine
>> unusable.
>>
>> tl;dr version: I find issues of GUI inconsistency critical and prefer to
>> fix them sooner rather than later and do not want to worry about legacy
>> behaviour that is incorrect to begin with, because the longer one waits,
>> the more they'll have to fix later when the similar/identical fix is
>> implemented in their flavor of pd.
> Thanks for your considerations. I actually agree with you in every
> respect. I also wouldn't mind having GUI glitches fixed in pd-extended|
> pd-vanilla, even if it means having to go through all my patches to fix
> them.

Well, maybe if we can get the bug fixed in all distributions then
we could automate updating all the gop abstractions in svn.

But if standardization doesn't happen it's going to cause minor but
_unfixable_ annoyances for all distributions.

-Jonathan

> However, things haven't changed in pd-vanilla|pd-extended yet and
> I see myself forced to decide which route to go.
>
> Roman
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list