[PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released

Hans-Christoph Steiner hans at at.or.at
Mon Jan 21 17:02:16 CET 2013


Yes, I think that's a great idea.  Its definitely not too soon, these have
been discussed for years.  Its the time for action :)

.hc

On 01/21/2013 10:12 AM, Leandro da Mota Damasceno wrote:
> Shouldn't we try to organize this?
> 
> I mean, apparently we had people testing and working with the toolkits.. It
> would be great to know which ones have been tested so far, what are their
> pro and cons... Then we could pick one approach and go for it... or is it
> too soon?
> 
> 
> 
> 
> On Mon, Jan 21, 2013 at 10:24 AM, Bill Gribble <grib at billgribble.com> wrote:
> 
>> [sorry about partial message send, thumb slip]
>>
>> I am working on a pd-clone intended to explore a lot of the topics in this
>> thread.  It's not fully baked yet -- the biggest working patch is a biquad
>> filter designer with pole-zero and freq response plotting -- but I'm
>> particularly excited about the approach to namespacing and scope
>> management, which works a lot like hc describes.  Patches have a set of
>> scopes which can be mapped onto subpatches (represented as layers, not
>> separate windows).  Name resolution in send/receive elements works like you
>> would want it to.
>>
>> The GUI is implemented in Clutter, which is a pretty nice toolkit and
>> gives you things like zooming for free.  With the pd-style graphics the GUI
>> isn't that huge a load.
>>
>> I'm submitting a paper to LAC in a week or so, and the code (Linux only
>> ATM, and not for the faint of heart) is on github:
>> http://www.github.com/bgribble/mfp
>>
>> It's a bit premature to "announce" this code, but the discussion is
>> hitting really close to a lot of the topics of my interest so I couldn't
>> resist :)
>>
>> Thanks,
>> Bill Gribble
>>
>> On Jan 21, 2013, at 6:13, Lorenzo Sutton <lorenzofsutton at gmail.com> wrote:
>>
>>> On 19/01/13 20:20, Hans-Christoph Steiner wrote:
>>>> On 01/19/2013 01:56 PM, IOhannes m zmölnig wrote:
>>>>> On 01/18/2013 22:31, Hans-Christoph Steiner wrote:
>>>>>> I would love it if someone started this since it would greatly help
>> with the
>>>>>> goal of splitting the GUI from Pd itself.  And of course I'd help
>> where I can.
>>>>> i keep starting that project every now and then: moving all the
>> drawing code
>>>>> to pd-gui and only use FUDI (that is: not tcl code) to communicate
>> between
>>>>> pd->gui.
>>>>>
>>>>> unfortunately i always get distracted after a short time and i never
>> get to a
>>>>> really working prototype.
>>>>>
>>>>> gmsdr
>>>>> IOhannes
>>>> It can be done incrementally, which is likely the only way its going to
>> get
>>>> done.  It turns out that FUDI and tcl proc calls are very similar: space
>>>> separated list of elements where the first one is the functionality.
>>>>
>>>> If the basics were done first, like object drawing, then someone could
>> build a
>>>> rough GUI with another toolkit to test out.
>>> When you say 'FUDI' what exctly do you mean... what I mean is for me
>> FUDI is actually [netsend] and/or [netreceive] interacting with 'something
>> else'... would this be something more clever? Is it still relying on
>> sockets (have no strong feeling about that nor pro nor con just to have a
>> clearer picture)
>>>
>>> Would it make sense within this to think of some kind of 'patching'
>> conventions, for example the fact that parameters are always set/modified
>> by messages (and thus easily routable)? maybe some sort of 'namespacing'
>> lingo e.g. mypatch.freq mypatch.amplitude etc...
>>>
>>> Or even some sort of semantics related to the GUI...
>> mypatch.hslider.freq .. but this is probably going to far.
>>>
>>> As you can see this topic is very thought provoking over here :)
>>>
>>> Lorenzo.
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>> 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
>>
> 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list