Alright, good to know! I might just go ahead and do it anyway because I have some spare time ATM :-)
Christof > Gesendet: Mittwoch, 07. August 2019 um 18:20 Uhr > Von: "Miller Puckette" <[email protected]> > An: "Christof Ressi" <[email protected]> > Cc: pd-dev <[email protected]> > Betreff: Re: Re: [PD-dev] [pdcontrol] reliance on Tcl > > All good, but I need to freeze 0.50 if it's going to come out in August - > I think I need to stick to bug fixes now. > > (One of which is "portaudio: handle closing of audio device because of > sys_pollgui()" from PR 710 - but I think the rest of that PR can wait til > afterward as things are at least in a better state than they were before ATM). > > cheers > M > > On Wed, Aug 07, 2019 at 06:15:03PM +0200, Christof Ressi wrote: > > Cool, I'll try to setup a working prototype in the next few days. > > > > Christof > > > > > Gesendet: Mittwoch, 07. August 2019 um 17:57 Uhr > > > Von: "Miller Puckette" <[email protected]> > > > An: "Dan Wilcox" <[email protected]> > > > Cc: pd-dev <[email protected]> > > > Betreff: Re: [PD-dev] [pdcontrol] reliance on Tcl > > > > > > I think you're right about this - "gui" will also fail if running Pd > > > -nogui :) The only functionality I can see as really important is the > > > "system" one. That itself is going to be necessarily system-dependent and > > > thus non-portable. > > > > > > And yes, Christof's suggestion to make a real API is excellent - if that > > > comes about, and if I've replaced "gui" with something like "system" in > > > the pdcontrol object, it will be easy to reimplement it on top of the new > > > API later. > > > > > > cheers > > > M > > > > > > On Wed, Aug 07, 2019 at 03:34:46PM +0200, Dan Wilcox wrote: > > > > I'm just now looking into the new [pdcontrol] object and I like what I > > > > see. I am concerned about the gui sending feature as it seems to rely > > > > directly on Tcl. > > > > > > > > With my libpd hat on, I'm interested in moving the pd core towards > > > > less/no direct reliance on raw sending Tcl/Tk strings, basically making > > > > Pd more GUI agnostic. For the gui running Tcl/Tk, the plugin concept > > > > makes sense as it's focused on that domain and not with the pd core. > > > > However for a future libpd-based app that renders patches with a > > > > different framework on a specific platform (ie. PdParty) and focused on > > > > as much feature parity as possible, I may need to suddenly support > > > > people's edge-case usage of raw Tcl without a Tcl interpreter. > > > > > > > > If the idea is that gui sending provides a quick way to emulate a > > > > system() call, I can understand that however I think a more universal > > > > design would be based around system() itself and an overridable > > > > function or interface as some platforms, namely iOS, do not allow the > > > > use of system(). > > > > > > > > I bring this up now as once this precedent is set, it's obviously > > > > *very* difficult to change it once people start using this feature. > > > > > > > > -------- > > > > Dan Wilcox > > > > @danomatika <http://twitter.com/danomatika> > > > > danomatika.com <http://danomatika.com/> > > > > robotcowboy.com <http://robotcowboy.com/> > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pd-dev mailing list > > > > [email protected] > > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > [email protected] > > > https://lists.puredata.info/listinfo/pd-dev > > > > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
