Ah ok. I just quickly looked at the link you sent. I can change Gui so it only loads the vanilla UIs by default and move the scene-specific stuff into the Scene class, for instance.
-------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Jan 8, 2016, at 10:18 AM, Daniel Iglesia <daniel.igle...@gmail.com> wrote: > > I am using submodules for the PDParty objects for all GUI classes. The only > copy-paste was Gui.h/m, which I changed significantly... > > On Fri, Jan 8, 2016 at 8:52 AM, Dan Wilcox <danomat...@gmail.com > <mailto:danomat...@gmail.com>> wrote: > >> On Jan 8, 2016, at 9:29 AM, Daniel Iglesia <daniel.igle...@gmail.com >> <mailto:daniel.igle...@gmail.com>> wrote: >> >> I'm glad you asked! It's done in a slightly convoluted, potentially fragile, >> possibly un-scalable way. >> >> When a user loads a .pd file, pre-proccessing is done on the .pd text to >> generate _two_ new .pd files, one for execution, and one for display The two >> communicate with each other. > > I thought it might be done that way. Does sound knife-edge :) I think it’s > not too conceptually difficult to work with send-receives, plus it makes it > easier to stream data from the device int Pd on your laptop while developing. > > We could work out a way to make the PdParty objects more extensible so you > could use the iem implementations as well. This can be included with > separating the PdParty UI from the Core and pd gui implementations. SO > Submodule instead of copy/paste classes (I could use any bug finding help as > well!) > >> Separate questions for everyone: >> 1) you may notice that the current version does not render connection lines. >> While the patch text lists all the connections (and inlet/outlet indices for >> them), the app doesn't know how many inlets/outlets each object has. I >> haven't delved too deeply for it yet, but is there an interface somewhere >> that will return that information? e.g. here's an atom line for an object >> and its parameters, tell me how many inlets/outlets. If so, then connection >> lines could be rendered correctly. (Without it, I could still render >> conneciton lines, but if there are empty inlets/outlets after a connection >> then they would not be shown.) > > I stayed away from connection lines mainly because trying to implement > “editing” is perhaps an unreasonable task for a single, unpaid developer. > Drawing the lines brings that expectation, no? ALso, since I’m using > sends/receievs there are no lines to render anyway ... > >> 2) Is showing the full set of patch objects (and, eventually, connection >> lines) even desirable? (Rather than just rendering the gui objects). I'm >> thinking of an option that would switch their display on/off. (But leave GUI >> objects, including message boxes) > > Mmm that implies, as I’ve written above, that people can “edit” in MobMuPlat. > >> Thanks for input, Dan I. >> >> On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox <danomat...@gmail.com >> <mailto:danomat...@gmail.com>> wrote: >> How are you doing this? >> >> -------- >> Dan Wilcox >> @danomatika <https://twitter.com/danomatika> >> danomatika.com <http://danomatika.com/> >> robotcowboy.com <http://robotcowboy.com/> >>> On Jan 7, 2016, at 9:19 AM, pd-list-requ...@lists.iem.at >>> <mailto:pd-list-requ...@lists.iem.at> wrote: >>> >>> - Unlike PdParty/PdDroidParty, you don't need to define send/receive values >>> for every GUI object. Just drop in your PureData patch, with normal object >>> connections, and it should work. (send/receive communication should also >>> still work as well). > > -------- > Dan Wilcox > @danomatika <https://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
