To Pd dev -
I just pushed a 'gtk' branch to github for everyone's joy and delectation :) I think this idea was very much annoying to Christof and perhaps others. My strategy is to simplify the tcl commands coming out of Pd to the point that they're easy to parse and carry out in other environments. To start with I'm just using the tcl interpreter but calling gtk drawing commands.
In the future this could be replaced by a more formal API on the Pd side that would conditionally generate either tcl or any other kind of stream to a GUI.
Note that this is only possible because the GUI itself is extremely 'thin', not knowing how to do mouse-hit detection for example. I think this could be viewed as positive (it's fairly easy to just replace it as this branch shows) or as negative ("why can't the GUI take some of the non-real-time work off Pd?)
I'm doing this now because it looks like X windows is being phased out of linux distros and apparently TCL/TK has lots of problems under wayland. It's possible that the TCL/TK folks will somehow patch TCL/TK up to work with Wayland's X emulation in which case this all might be unnecessary - but OTOH I don't mind having an escape route in case not.
AND... the dependence on GTK itself is pretty lightweight so far so this would probably also be adaptable to QT or whatnot if the world so desires. Most of the work is in interpreting the TCL commands (net.c and tclparser.c) which could move right over to some other GUI setup.
cheers Miller
I can chime in and say Miller's original test of this was relatively easy for me to build on macOS after installing gtk with homebrew. I build an executable and not an app bundle but we would want the latter for distribution at some point.
On Dec 8, 2025, at 6:37 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
To Pd dev -
I just pushed a 'gtk' branch to github for everyone's joy and delectation :) I think this idea was very much annoying to Christof and perhaps others. My strategy is to simplify the tcl commands coming out of Pd to the point that they're easy to parse and carry out in other environments. To start with I'm just using the tcl interpreter but calling gtk drawing commands.
In the future this could be replaced by a more formal API on the Pd side that would conditionally generate either tcl or any other kind of stream to a GUI.
Note that this is only possible because the GUI itself is extremely 'thin', not knowing how to do mouse-hit detection for example. I think this could be viewed as positive (it's fairly easy to just replace it as this branch shows) or as negative ("why can't the GUI take some of the non-real-time work off Pd?)
I'm doing this now because it looks like X windows is being phased out of linux distros and apparently TCL/TK has lots of problems under wayland. It's possible that the TCL/TK folks will somehow patch TCL/TK up to work with Wayland's X emulation in which case this all might be unnecessary - but OTOH I don't mind having an escape route in case not.
AND... the dependence on GTK itself is pretty lightweight so far so this would probably also be adaptable to QT or whatnot if the world so desires. Most of the work is in interpreting the TCL commands (net.c and tclparser.c) which could move right over to some other GUI setup.
cheers Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JZXNOQBOCFZ...
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 12/8/25 20:22, Dan Wilcox wrote:
I can chime in and say Miller's original test of this was relatively easy for me to build on macOS after installing gtk with homebrew.
on Debian it did not work out of the box, even with tcl headers installed.
i've created a PR for the build-system to fix my pains: https://github.com/pure-data/pure-data/pull/2808
On 12/8/25 21:09, Christof Ressi wrote:
PS: Should we maybe have another dev meeting?
that would probably be a good idea.
gfamsdr IOhannes
Hi Miller,
I'm happy about any initiatives that help us move away from Tcl/Tk!
One general question: why is the GUI still a separate executable? IMO this doesn't buy as anything and only adds overhead. Yes, there should be an *option* to run the GUI as a separate application (e.g. for running the GUI on a separate machine), but for the common case where both the core and the GUI live on the same machine, they should run in the same process.
All of the actual GUI code can be shared, the only difference is in the initialization/teardown and the implementation of the GUI queue. (The in-process GUI would simply use two thread-safe queues instead of a TCP socket.)
Generally, an in-process GUI would be more efficient and real-time safe. First, it would remove two or three layers of buffering. Second, sending messages to the GUI can be made non-blocking. (pdgui_vmess() could push messages directly to a lockfree FIFO. Then we could either post a single message to the UI thread at the end of the scheduler tick to tell the GUI that there are pending messages, or the GUI could poll the queue in regular intervals.)
Another big advantage is that it can integrate windows created by externals. For example, the VST editor windows created by [vstplugin~] would appear as part of the main GUI, and not as a separate application.
Also, this would finally force Pd to get off the main thread :)
Christof
PS: Should we maybe have another dev meeting?
On 08.12.2025 18:37, Miller Puckette via Pd-dev wrote:
To Pd dev -
I just pushed a 'gtk' branch to github for everyone's joy and delectation :) I think this idea was very much annoying to Christof and perhaps others. My strategy is to simplify the tcl commands coming out of Pd to the point that they're easy to parse and carry out in other environments. To start with I'm just using the tcl interpreter but calling gtk drawing commands.
In the future this could be replaced by a more formal API on the Pd side that would conditionally generate either tcl or any other kind of stream to a GUI.
Note that this is only possible because the GUI itself is extremely 'thin', not knowing how to do mouse-hit detection for example. I think this could be viewed as positive (it's fairly easy to just replace it as this branch shows) or as negative ("why can't the GUI take some of the non-real-time work off Pd?)
I'm doing this now because it looks like X windows is being phased out of linux distros and apparently TCL/TK has lots of problems under wayland. It's possible that the TCL/TK folks will somehow patch TCL/TK up to work with Wayland's X emulation in which case this all might be unnecessary - but OTOH I don't mind having an escape route in case not.
AND... the dependence on GTK itself is pretty lightweight so far so this would probably also be adaptable to QT or whatnot if the world so desires. Most of the work is in interpreting the TCL commands (net.c and tclparser.c) which could move right over to some other GUI setup.
cheers Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JZXNOQBOCFZ...
On 12/8/25 18:37, Miller Puckette via Pd-dev wrote:
To Pd dev -
I just pushed a 'gtk' branch to github for everyone's joy and delectation :) I think this idea was very much annoying to Christof and perhaps others. My strategy is to simplify the tcl commands coming out of Pd to the point that they're easy to parse and carry out in other environments.
that's cool and into the ™right™ direction :-) it would also allow us to do more nifty things for pure Tcl/Tk based GUI, like using "virtual colors" (e.g. "foreground" rather than "#000")
Note that this is only possible because the GUI itself is extremely 'thin'
true for the actual patch drawing. obviously more complex features of the GUI (think "deken") still need re-implementing.
gdasrm IOhannes