how would that work, martin?
On Mon, Jan 21, 2013 at 8:35 PM, Martin Peach <[email protected]>wrote: > Wouldn't it be a good idea to settle on a graphics metalanguage rather > than translating tcl code to qt or whatever? > > Martin > > > > On 2013-01-21 15:11, Leandro da Mota Damasceno wrote: > >> so let's see...Who´s working with what so far? >> >> I´d love to join a team and start learning how to code with one of the >> toolkits. >> >> >> >> On Mon, Jan 21, 2013 at 6:03 PM, Hans-Christoph Steiner <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> So all those interested in a new GUI should start working on it, >> there is lots >> of interest. Then we can incrementally change pd itself as there is >> a need. >> >> .hc >> >> On 01/21/2013 02:48 PM, Leandro da Mota Damasceno wrote: >> > You're right. Damn, you're always right :) >> > >> > So, just to know where we are right now... What have been >> tested/done >> > regarding the GUIs toolkits so far? I think we should at least >> have this >> > set and go on from there... >> > >> > >> > On Mon, Jan 21, 2013 at 5:31 PM, Hans-Christoph Steiner >> <[email protected] <mailto:[email protected]>>wrote: >> >> > >> >> >> >> I think this is the general idea of what everyone wants to >> support. But >> >> the >> >> way is actually takes shape is going to depend on whoever >> actually does the >> >> work. A great example of this is the PDDP (Pure Data Documentation >> >> Project). >> >> We had lots of design meetings and then no one implemented the >> ideas. Then >> >> Jonathan picked up from that what was interesting to him and >> made the whole >> >> meta help system, the search plugin, etc. >> >> >> >> The lesson there for me is that big design discussions only work >> if the >> >> people >> >> involved them are willing to do the work to implement them. >> Instead, I >> >> think >> >> for a more decentralized community like this one, we only should >> nail down >> >> the >> >> key parts that everyone must use, then leave other decisions to >> those who >> >> are >> >> implementing those parts. >> >> >> >> So that means I'm happy to help people write there own GUI, and >> I'll >> >> definitely be involved in the work of making it possible with Pd. >> >> >> >> .hc >> >> >> >> On 01/21/2013 01:05 PM, Leandro da Mota Damasceno wrote: >> >>> That sounded like a Lego approach. :) >> >>> >> >>> So the way I see it the GUI development should be in the most >> seemless >> >> way >> >>> for the user, right? >> >>> >> >>> And we also have the problem between people who prefer a >> simple, leaner >> >> GUI >> >>> approach (the classic PD, for instance) against people who >> prefer a more >> >>> sofisticated, and sexy GUI. And I believe both groups would >> also like >> >> some >> >>> more knobs and stuff... >> >>> >> >>> so basically, we should at least have two options of gui: simple >> >> (classic) >> >>> or sophisticated (sexy). But it would be cool to make it open >> enough to >> >>> anyone develop their own or come up with new and customized >> ones. that >> >>> would make PD way cooler than Max/MSP or anything else. So for >> that to >> >> work >> >>> (and now I must admit I really don't know the architecture >> behind this >> >> part >> >>> of PD, so maybe it is already this way), the comunication >> between the GUI >> >>> and the rest of PD should be kept simple, fast and modulated, >> working >> >> with >> >>> the leanest possible API. I also think this is a good approach >> >> considering >> >>> that most of these toolkits will stop getting support way before >> PD >> >> ceases >> >>> to exist. I have also thought about the possibility of skins, >> but then >> >>> loading a bunch of bitmaps would not help in terms of >> performance... >> >>> >> >>> >> >>> At the same time we pick a toolkit and focus on that one first. >> So we >> >>> should think of at least two teems, right? One at the GUI end >> and the >> >> other >> >>> at the core PD end... >> >>> >> >>> What do you guys think? >> >>> >> >>> >> >>> On Mon, Jan 21, 2013 at 2:02 PM, Hans-Christoph Steiner >> <[email protected] <mailto:[email protected]> >> >> >>> wrote: >> >>> >> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >> >>>>> ----- Original Message ----- >> >>>>> >> >>>>>> From: Billy Stiltner <[email protected] >> <mailto:billy.stiltner@gmail.**com <[email protected]>>> >> >>>>>> To: IOhannes zmölnig <[email protected] <mailto:[email protected] >> >> >> >>>>>> Cc: [email protected] <mailto:[email protected]> >> >> >>>>>> Sent: Sunday, January 20, 2013 10:04 PM >> >>>>>> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra >> Live 1.5 >> >>>> released >> >>>>>> >> >>>>>> haha , last month i tried to install juce to see about making >> an >> >>>>>> alternate graphics front end to my patches. there was some >> weirdness >> >>>>>> in the way you compile it then run the introjucer or somethin >> to >> >>>>>> update it then after the update something didn't quite work >> right. >> >>>>>> then there are all the old projects that use the old >> steinberg vst sdk >> >>>>>> which you cant get from steinberg anymore so all that is >> just awful. i >> >>>>>> think that there should be a really nice updated version of >> juce >> >>>>>> either available now or in the near future. its a tossup >> between >> >>>>>> fltk, qt , opengl ,juce, and processing. i just want to be >> able to >> >>>>>> add my waveform data filenames to the presets with a >> fileopen dialog >> >>>>>> without using an external, string parsing like .scl files >> that have >> >>>>>> 100.00 or 3/2, and polyphonic patchcords would be nice. >> >>>>> >> >>>>> What about the -guicmd "cmd..." flag? Could one write a >> pd-gui.html >> >>>>> that lives at localhost:1234, and have it talk to pd at its >> port on >> >>>> localhost? >> >>>>> >> >>>>> Then you could just write the interface with html5 canvas, svg, >> >>>>> javascript, or whatever. >> >>>>> >> >>>>> -Jonathan >> >>>> >> >>>> >> >>>> That sounds feasible to me. >> >>>> >> >>>> .hc >> >>>> >> >>>> ______________________________**_________________ >> >>>> [email protected] <mailto:[email protected]> mailing list >> >> >>>> UNSUBSCRIBE and account-management -> >> >>>> >> http://lists.puredata.info/**listinfo/pd-list<http://lists.puredata.info/listinfo/pd-list> >> >>>> >> >>> >> >> >> > >> >> >> >> >> ______________________________**_________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/** >> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list> >> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
