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

Jonathan Wilkes jancsika at yahoo.com
Tue Jan 22 03:46:01 CET 2013


----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Martin Peach <martin.peach at sympatico.ca>
> Cc: PD List <pd-list at iem.at>
> Sent: Monday, January 21, 2013 5:48 PM
> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
> 
> 
> Sounds like a good idea, but I don't think that should block anyone from
> starting.  And having a real example to work with will make it much easier to
> figure out how to convert the Tcl into something more generic.  The graphic
> ideas in Pd are almost all really simple: draw an object box, draw a message
> box, draw an array, draw connections.  And indeed I think the communications
> between pd and pd-gui should be logical rather than graphical, i.e. 
> "connect 0
> 1 2 5" instead of a line draw command.


(Here's a modest proposal, additions, revisions, critiques welcome)


To that end I think the best way to move is by leveraging the tcl "rename"
command, which is what the DesireData devs were using to try out the
tkzinc canvas (a gui canvas library which I don't recommend).

Basically, someone just needs to write a gui-plugin that renames the
procs that are called from sys_gui and sys_vgui.  This can be done
incrementally.  Basically the process would be to write new
versions of those procs which a) call the old procs and b) send a
FUDI-style message to a proc named something like "forward_mess".

Then, inside proc "forward_mess", write the tcl bindings for the gui toolkit of
your choice to send that FUDI message to your alternate gui.

Example: Tooltips

For this example, we'll just consider "manual" tips, which get triggered from
within Pd and are thus simple to describe:

[namecanvas foo]

[loadbang]
|
[tip 1 Hello World(
|
[s foo]

This will print "Hello World" in a little label in the bottom right-hand corner
of a canvas.  (Let's assume we've already got canvases working in the alternate
gui.)

In the function canvas_tip from g_editor.c, sys_vgui is used to call the proc
"pdtk_tip", where the first arg is the .x%lx.c canvas name, the second arg
is the number "1" to signify a "manual" tip generated from pd (instead of
an autotip from hovering over an object with the mouse).  The rest of the
args are the user's message, which is "1 Hello World" above (the initial
float controls the message display-- nonzero for "on", zero for "off").

Armed with this information, how do we send a tip to our alternate gui?  We
use the "rename" command from tcl to hijack message from Pd to the
pdtk_tip proc:

rename pdtk_tip pdtk_tip_old

Now pdtk_tip has been aliased to pdtk_tip_old, which frees us up to
build our own pdtk_tip that will perform a "friendly" MITM attack on Pd:

proc pdtk_tip {w fromc show args} {
     pdtk_tip_old $w $fromc $show $args
     forward_mess [list $w "tip" $fromc $show [join $args]]
}

And finally, inside forward_mess, put your code to forward the FUDI
message to your alternate_gui:

proc forward_mess {args} {
     # actual command names may vary...
     ::alternate_gui_bindings::send $args
}

Now, if I wrote all my tcl correctly, your alternate_gui will receive the
message:
.x%lx.c tip 1 1 Hello World


(Note-- this is not the same message that was sent within Pd that ultimately

calls the canvas_tip function.  Is the aim to use the _exact_ same FUDI message
in the GUI that gets passed within the "c" part of Pd?  Or is it just to
have _a_ message in FUDI form?)


Then in your alternate_gui you parse that message in the same way you
would parse everything your alternate gui receives-- take the selector to refer
to the object, the 1st arg as a method of that object, and the remaining args
as the args to that method.

I still don't understand the details, but the last release of DesireData it looks
like poe.tcl was matju's object-oriented tcl system for handling the gui side
of things in a way something like what I describe above.  His classes seem
to mimic the way things look in Pd, though I could be wrong because I still
don't understand exactly how it works.

Anyway, the benefits to this approach:
* incremental-- you can build the new gui one piece at a time
* runs alongside tcl gui, so you can compare your incremental results to
the original gui which is still in tact
* your alternate_gui could be an object-oriented tcl/tk gui which processes
FUDI messages instead of raw tcl procs (and can be developed next to
the old, fully-functional tcl gui)
* you can have one gui-plugin to rename all the procs and send FUDI
messages to forward_mess, and another set of gui-plugins for each GUI toolkit
people want to test out that just loads the tcl binding package for that
toolkit and defines forward_mess to send the FUDI messages to it
* once we get some fully functioning guis in other toolkits (or one in
tcl that processes FUDI messages), the sys_vgui stuff in Pd can be
changed to send FUDI messages-- then you just remove the plugins
and forward the messages straight to the alternate_gui with (or
without) tcl as the middleman.

In fact, even before considering other toolkits, we can make the gui-plugin
to rename procs to lay the groundwork for this, or someone smarter than
me can make a proc that automates the process of renaming procs if
that's even possible.


-Jonathan


> 
> .hc
> 
> On 01/21/2013 05:35 PM, Martin Peach 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>>
>>>       >>>>>> 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
>>>       >>>>
>>>       >>>
>>>       >>
>>>       >
>>> 
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  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