the damned GUI - was:[PD] Pd in white on black and OSC

Krzysztof Czaja czaja at chopin.edu.pl
Sun Nov 23 13:36:36 CET 2003


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





More information about the Pd-list mailing list