Thomas Grill wrote:
 
any how , i would like to hear more about what you and every one else thinks about tcl/tk and why its the way to go for pd's gui editor .    
 
Well, as stated some time ago, i'm not a friend of tcl/tk and i would personally trade the client/server approach for a fast and more feature-rich GUI. To my mind, a fast, OS native, but portable graphics library such as wxWindows would be a good choice. That should not have an impact on real-time behavior or latency if it is well implemented (on a separated, lower-priority thread).
I'd like to underline that the client/server possibility should of course remain, but i think it's not helpful to sacrifice the speed of a native GUI for that.
I would be very interested how many projects are actually run with the GUI on a separate machine and what the needs are for those applications, though.
 
greetings, Thomas
 
well, some confusions have occurred here :


a/ i was speaking of loosing client/server feature
if one's intended to write externs in Java
which would handle their graphics by themselves :
this approach is not feasible because of the overhead
introduced by the graphics that you would embed in PD itself.

you NEED to have a protocol between PD's real time engine
( e. g. process named PD ) and the graphical server.
this protocol for now consists of Tcl/Tk scripting commands
( which says : draw an image, draw a rectangle ),
Java CAN'T do that AFAIK.

if it can, good, but it still would be very slow ( try jmax on a large scale ).

b/ you can use another graphic library which understands such commands
like WxWindows which is scriptable with add-ons like WxPython.
then you NEED to write a new graphic engine for PD.
if you think objects can directly use drawing functions
of WxPython ( or anything else ), you're going the wrong way
because these operations cost CPU and the engine would suffer
from such calls.

Anyway, i'll stick to PD as it is, it's so beautiful that
i want a PD screeensaver ..... will do it one day ...

yvotchka