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
---
[email protected] - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/JZXNOQBOCFZK2T6XXTSUKRERY3QB7IIR/
---
[email protected] - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/E3WGNEWBS7DVYC76RI5OI4TS4MJWJPWL/
