Kevin McCoy wrote:
The gui needs work - do you mean we need more/better looking gui objects? When I was working on OS X, I couldn't really use very many gui objects at once because of Apple's crappy closed implementation of tcl/tk; the lag was terrible. Pd devs can't really do anything about that (though it is a huge problem). A significant portion of pd users are on OS X.
I have used pd on Windows, OSX, and Linux, and in all cases the tcl/tk performance was about equivalent: good enough (I certainly don't notice any lag issues with OSX), but it started to break down once there were too many objects on screen.
I understand this is a problem with tcl/tk. As I understand it, tcl/tk is basically a semi-scripted programming language in itself, with a gazillion features that pd neither uses nor needs to use. It would be dead-easy to re-implement the current GUI in C or C++ using a cross-platform low-level graphics library, which would not only give us enormous visualisation capability, but I think is necessary to support any more advanced GUI development, since tcl/tk already slows down too much if there are a lot of lines or objects on-screen. This would also give us real-time data-structure visualisation as well, which would be *great*.
Indeed this is a project I'd like to take on, but I can't penetrate the GUI code, can't figure out where anything hooks in to anything. Anyone care to give me some pointers?
Pd's gui definitely does need work, but without a clear roadmap it will be hard to say what priority that is, right? Watching that google talk has me thinking about all kinds of things.
The GUI doesn't need to have a particular priority relative to any other parts, surely; GUI development and core development can occur in parallel; this would also have the nice side-effect of enforcing looser coupling between the GUI and the engine.