On Fri, Jan 27, 2012, at 09:21, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; PD list pd-list@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@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD list pd-list@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