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

[Ivica Bukvic]

Indeed. Let's hope pd/extended adopt these soon.

Best wishes,

Ico
On Jul 3, 2013 7:31 AM, "Roman Haefeli" <reduzent at gmail.com> 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. However, things haven't changed in pd-vanilla|pd-extended yet and
> I see myself forced to decide which route to go.
>
> Roman
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130703/a9c7093f/attachment-0001.htm>