----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Martin Peach martin.peach@sympatico.ca Cc: PD List pd-list@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.or.at
mailto:hans@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.or.at mailto:hans@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.or.at mailto:hans@at.or.at >>> wrote: >>> >>>> On 01/21/2013 12:54 AM, Jonathan Wilkes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Billy Stiltner
<billy.stiltner@gmail.com
mailto:billy.stiltner@gmail.com> >>>>>> To: IOhannes zmölnig <zmoelnig@iem.at
>>>>>> Cc: pd-list@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@iem.at mailto:Pd-list@iem.at
mailing list
>>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list