[PD] Apply missing

[Hans-Christoph Steiner]

On Fri, Jan 27, 2012, at 09:21, Jonathan Wilkes wrote:
> ----- Original Message -----
> > From: Hans-Christoph Steiner <hans at at.or.at>
> > To: Jonathan Wilkes <jancsika at yahoo.com>
> > Cc: Max <abonnements at revolwear.com>; PD list <pd-list at iem.at>
> > Sent: Friday, January 27, 2012 11:39 AM
> > Subject: Re: [PD] Apply missing
> > 
> > 
> > On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
> > 
> >>  ----- Original Message -----
> >> 
> >>>  From: Max <abonnements at revolwear.com>
> >>>  To: Hans-Christoph Steiner <hans at at.or.at>
> >>>  Cc: PD list <pd-list at iem.at>
> >>>  Sent: Friday, January 27, 2012 10:02 AM
> >>>  Subject: Re: [PD] Apply missing
> >>> 
> >>>  Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
> >>>>  On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
> >>>>> 
> >>>>>  i noticed that in the current autobuilds of Pd-extended the 
> > property 
> >>>  dialogs for the gui-objects are missing the Apply-Button. Is that a bug 
> > or a 
> >>>  feature?
> >>>>>  IMHO this is a bug - if you want to adjust for instance a 
> > canvas to be 
> >>>  the same size as another object of unknown size you can do that with a 
> > few 
> >>>  clicks and the help of the Apply button. If you have to click OK and 
> > then go to 
> >>>  context menu->Properties, set the size, OK repeately to do that 
> > it's 
> >>>  simply annoying.
> >>>>> 
> >>>>  That seems like a good enough reason, I brought back the Apply 
> > button to
> >>>>  the iemgui Properties panel on Mac OS X.  It was originally moved 
> > since
> >>>>  the whole "OK, Apply, Cancel" is very Windows-like, but 
> > there 
> >>>  isn't an
> >>>>  easy way to make to work better, so the Apply button is back.  
> > IMHO,
> >>>>  when you change the setting, it should take effect immediately.
> >>> 
> >>>  great. i agree that ideally i'd like to be able to see that change 
> > happen 
> >>>  immediately. even better: when grabbing the bottom-right corner i'd 
> > have an 
> >>>  anchor to scale the object (see Max/MSP for that)…
> >> 
> >>  Also see: pd-l2ork
> > 
> > I think you are referring to Ico trying to make the iemguis resizable live with 
> > a handle.
> 
> Yep.  All the iemguis are resizable with a little anchor that appears
> when the object 
> is selected.  Very handy.
> 
> > I should finally get to releasing something useful form the tkwidgets 
> > lib, since that also includes resizing with a handle.
> 
> Right, I remember that when I tried them.  To make them useful is
> difficult, though, 
> because iemguis have (rightly) set a precedent that gui objects can
> integrate 
> naturally into a normal object chain.  For example, it's not uncommon to
> find a [tgl] 
> deep inside a subpatch somewhere and my friend running pd -nogui can
> still 
> run my program.  Or the user having a little UI subpatch that pops up or
> gets 
> hidden as needed-- if you depend on the actual tk widget to exist in
> order for its 
> properties to get set, then the user will get an error if for example
> they try to 
> change its size or placement when it's not vis'd.  So I guess on the one
> hand it's 
> nice to separate gui from pd, but on the other you don't want to force
> the user 
> to care about implementation details like, "when a subpatch closes and no
> one 
> can see its contents, does it _really_ have a slider inside there?"  If
> the answer is 
> yes for pd-ish methods and no for tk/gui-related methods, things start to
> get 
> tricky.

That is definitely an important point, and I think its something that
the tkwidgets approach can also support.  I'm thinking that when a
tkwidgets object does not have a Tk representation, it could just store
the messages destined for that Tk object.  There are problems there too,
I suppose, but it would be nice to avoid reimplementing the whole Tk
object's data structure on the 'pd' side.

.hc