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

[Ivica Ico Bukvic]

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.

-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net