[PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Leandro da Mota Damasceno
lemota at gmail.com
Tue Jan 22 00:08:39 CET 2013
how would that work, martin?
On Mon, Jan 21, 2013 at 8:35 PM, Martin Peach <martin.peach at sympatico.ca>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 <hans at at.or.at
>> <mailto:hans at at.or.at>> 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
>> <hans at at.or.at <mailto:hans at at.or.at>>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
>> <hans at at.or.at <mailto:hans at at.or.at>
>>
>> >>> wrote:
>> >>>
>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote:
>> >>>>> ----- Original Message -----
>> >>>>>
>> >>>>>> From: Billy Stiltner <billy.stiltner at gmail.com
>> <mailto:billy.stiltner at gmail.**com <billy.stiltner at gmail.com>>>
>> >>>>>> To: IOhannes zmölnig <zmoelnig at iem.at <mailto:zmoelnig at iem.at
>> >>
>> >>>>>> Cc: pd-list at iem.at <mailto:pd-list at iem.at>
>>
>> >>>>>> 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
>> >>>>
>> >>>> ______________________________**_________________
>> >>>> Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
>>
>> >>>> UNSUBSCRIBE and account-management ->
>> >>>> http://lists.puredata.info/**listinfo/pd-list<http://lists.puredata.info/listinfo/pd-list>
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>>
>>
>> ______________________________**_________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130121/72a6305d/attachment.htm>
More information about the Pd-list
mailing list