> On Oct 6, 2016, at 3:49 AM, pd-list-requ...@lists.iem.at wrote: > > 1) External developers who want to support purr-data (pd-l2ork) can #ifdef > their guis. > 2) For those who don't want to learn a new toolkit, and for unmaintained > libraries, it'll be up to purr-data developers. > > Until we have good documentation for integrating pd+nwjs, the first option > may only work well for people who have a toe in both pools. I think that's me > for cyclone, and I'll be glad to support purr-data directly in the new > cyclone library as soon as I have a good chunk of time to do it, and some > time to work out the kinks with Jonathan.
I know I’ve mentioned it before, but I wish there was a middle ground where the GUI calls were abstracted enough to make these kinds of version/fork specific approaches unnecessary. A possibly solution would be to standardize around the tcl messages that vanilla already uses and provide a way to help parse and translate them into whatever is being used by the GUI implementation. “Draw a box here” and “draw some text”, “draw a line from this point to another point”, and “open this window” are all actions possible in tons of languages and environments, just done in a different syntax. Yeah, it’s probably not super efficient but this mechanism seems to have worked pretty well over the years on older, slower hardware to I’m in favor of proposing sticking to what works as a start. My thought is if we could standardize some of the api interfaces and allow others to be overridable (say the undo/redo mechanisms in a separate .c file) or via default dummy implementations, vanilla/libpd could be uses as the lingua franca core and each variant of Pd adds on it’s extras without diverging. I *really* hope we can talk about this idea in person at the pd con as I still feel that, overall, we should find a way to pool resources more effectively. For instance, Miller keeps the pd core solid & provides a Pd vanilla GUI while pd-l2ork & purr data have their extensions, expanded internals by overriding/extending aspects of the core, and custom GUI implementations. All of this, hopefully, wrapped upon the same core. I think it’s possible, we just have to figure out what kind of architecture would make this possible. Some of this would probably be possible by simply splitting some functions into separate .c files. Forgive me if this has already been talked to death, but I have a feeling it hasn’t so far... Relatedly, I’d like to be able to add an editing GUI to PdParty and have thoughts on making a console-based ncurses GUI for pd. That would be alot easier with the knowledge and help of those of you to wrap the GUI comm via a libpd api instead of me basically reverse engineering things myself. I’d rather be lazy and use the shared knowledge that is one of the best parts about open source. -------- 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 -> https://lists.puredata.info/listinfo/pd-list
