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

[Bill Gribble]

[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