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

[Leandro da Mota Damasceno]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130121/7b8a11bf/attachment-0001.htm>