Honestly, Tcl/Tk does a much better job than GTK on Mac OS X and maybe Windows too. GTK apps look like, well, GTK apps. Tcl/Tk apps can be made to be quite native in feel.
I guess I am thinking more of functionality. I feel like I have hit a wall with pd's data structs, as the things I want to do are either impossible or too slow with tk (If anyone can think of a way to make a playhead auto scroll in a data-struct - score, I may stand corrected).
Personally, the thought of using cario or opengl widgets for controlling pd is appealing. So much that I am experimenting with a seperate app, coded in gtk/opengl, for controlling pd through OSC. I just don't see any reason why not to have it as the native pd GUI as well. Not that I can do it at present, or that cario/opengl will ever be in pd-vanilla, just dreaming.
Tcl/Tk's big lack right now is native GNOME (and maybe KDE?) panels. I've looked for a way to use native GNOME open/save panels, but I haven't found it yet. Anyone know of a way?
.hc
IIIIIII!
rich.
cheers M
On Thu, Mar 06, 2008 at 05:26:00PM -0500, Hans-Christoph Steiner wrote:
Now that I have discovered this bytecode caching feature, I am curious if the changes I made have made any performance differences. Also, matju mentioned that the bytecode caching probably works better if reusing procs, so it could make sense to have sys_vgui calls use Tcl procs, so that the bytecode gets reused.
I was also thinking that perhaps sys_vgui communications could use Tcl_Obj references instead of sending whole lines of Tcl, but that might get overly complicated.
.hc
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Access to computers should be unlimited and total. - the hacker ethic