On Fri, Jan 27, 2012, at 09:21, Jonathan Wilkes wrote: > ----- Original Message ----- > > From: Hans-Christoph Steiner <h...@at.or.at> > > To: Jonathan Wilkes <jancs...@yahoo.com> > > Cc: Max <abonneme...@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 <abonneme...@revolwear.com> > >>> To: Hans-Christoph Steiner <h...@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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list