hi Chris,
chris clepper wrote: ...
certain cases). I'm thinking that the GUI elements like sliders and buttons would be perfect for having bitmaps (gee you ever notice how
in my thinking, would be better just having widgets controlled on a higher level, instead of by drawing lines or painting bitmaps. The protocol should be generic enough for making Pd independent from the widget implementation details, whatever they are: lines or bitmaps, Tk or GL, etc.
But the bottom line, I think, is that the current stage of development, a prototyping stage in fact, is better to be finished before starting any radical reorganization of the Pd gui. I guess, the right sequence is first to clean up the way Pd engine is dealing with the current gui, only then it will be possible to make right decisions about the protocol, and finally an api should be designed. After having an implementation-independent api working with Tk, Pd will be ready to have Tk replaced with anything people are going to find at that time as a better choice.
Besides, the fundamental question about the role of a patching gui (of which Pd has only a prototype), and its relation to a performance gui (of which Pd has not even a viable prototype), is yet to be answered.
I think there is no need to hurry. People do complain, but lets face it -- there is no shortcut path, anyway, for Pd gui to woo reactor fans, or even to appeal to an average max/msp addict.
The problem with bad design is that the poor thing would unlikely be ever redesigned, without full-time coders, and an army of bug-hungry beta-testers (none in Pd community!).
Krzysztof