[PD] Apply missing
Hans-Christoph Steiner
hans at at.or.at
Fri Jan 27 19:28:23 CET 2012
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
More information about the Pd-list
mailing list