On 01/29/2013 02:13 PM, Jonathan Wilkes wrote: > > > > > ----- Original Message ----- >> From: Hans-Christoph Steiner <[email protected]> >> To: Jonathan Wilkes <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Sent: Tuesday, January 29, 2013 12:37 PM >> Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard >> Path >> >> On 01/25/2013 07:22 PM, Jonathan Wilkes wrote: >>> ----- Original Message ----- >>> >>>> From: Hans-Christoph Steiner <[email protected]> >>>> To: Jonathan Wilkes <[email protected]> >>>> Cc: "[email protected]" <[email protected]> >>>> Sent: Friday, January 25, 2013 6:26 PM >>>> Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in >> Standard Path >>>> >>>> On 01/25/2013 06:24 PM, Jonathan Wilkes wrote: >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: Hans-Christoph Steiner <[email protected]> >>>>>> To: Jonathan Wilkes <[email protected]> >>>>>> Cc: "[email protected]" <[email protected]> >>>>>> Sent: Friday, January 25, 2013 6:17 PM >>>>>> Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than >> in >>>> Standard Path >>>>> >>>>> [...] >>>>> >>>>>>> Also, is there a tcl variable that holds the paths that >> were set >>>> by a >>>>>>> [declare], or one that holds the paths for the currently >> opened >>>> patches? >>>>>>> >>>>>>> -Jonathan >>>>>> >>>>>> Hmm, off the top of my head, I don't think you can get the >> >>>> canvas-local path >>>>>> (ie. [path] or [declare -path]) in the GUI. >>>>> >>>>> Someone wanted to search whatever libs they had loaded, or in the >> path of >>>> the >>>>> patch that was loaded, so I think it is already desired. >>>> >>>> Yeah, it could be useful. Its a matter of someone implementing it. I >> can't >>>> think of any objections. It seems to me that it would basically end up >> having >>>> a mirror of the t_class struct in the GUI. >>> >>> That was one thing that was neat about the the object-oriented GUI approach >>> of DesireData-- you ended up with a mirror of the Pd side of things (at >> least it >>> looked that way). >>> >>> BTW-- I've done a little work on my "rename" hack, and it >> seems to work ok >>> so far. The question is should the FUDI message that I generate look >> exactly >>> like the FUDI message that triggered the event in Pd that generated the >> message >>> to the gui in the first place, or does it just need to follow the FUDI >> syntax? >> >> Since pd-gui --> pd is FUDI, pd --> pd-gui should be too. Then it also >> fits >> in to the 'Pure Data' idea of the same message format everywhere, >> including >> within Pd, between pd and pd-gui, in the file format, in network >> communication, etc. > > Of course both messages will have the same syntax, but what about content: > > pd -> pd: %x tip 1 Hello World > pd -> gui: %x.c tip 1 1 Hello World
I think that when messages have the same content, they should be exactly the same in either direction. .hc _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
