The pd/pd-gui divide is a little misleading-- there are lots of places in the c code where there are sys_gui and sys_vgui calls with tcl in them, plus c code that probably assumes tcl is being used on the gui side.
You'll either need to write a wrapper for those calls, or modify a lot of c code and basically make a fork (iemguis, canvas stuff, etc.)
But even if you write a wrapper, there are still issues that will need to be dealt with on the c side to minimize the number of messages passing back and forth between pd and gui. For example, there is one call per xlet to the gui when an object gets instantiated/vis'd, plus drawing the border and text, rather than one call per object (and letting the gui deal with where to draw xlets, box width, font,
etc.).
-Jonathan
From: yvan volochine <yvan.pd@gmail.com>
To: Hans-Christoph Steiner <hans@at.or.at>
Cc: Jonathan Wilkes <jancsika@yahoo.com>; pd-dev List <pd-dev@iem.at>
Sent: Thursday, August 25, 2011 6:18 PM
Subject: Re: [PD-dev] tkwidgets
On 08/17/2011 08:54 PM, Hans-Christoph Steiner wrote:
> I've started a private git branch of
> tkwidgets
that I intent to push once I get somewhere with it. The idea
> is to try out a new idea for how GUI objects can work. Basically, I
> think I can make it so that Tcl handles more of the interaction with the
> user, minimizing on pd-gui <--> pd communications, and making it easier
> to write GUI objects. Its not trivial to do, but should be doable.
hiho
sorry for bumping in but what about giving up tcl-tk and go on with something more "modern" (à la Qt), with a decent OO interface ?
I might miss the obvious as I'm new here but what about rewriting pd GUI in Qt ?
wouldn't it make more sense than spending time hacking on and on tcl-tk code ?
my 0.001$
_y