On May 28, 2007, at 1:52 PM, Damian Stewart wrote:
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?
In a nutshell, the tricky bit is that there are two processes: pd (C)
and pd-gui (Tcl). They actually communicate largely using pd
messages, so that's not too hard. But there are also a number of
situations where the C code is sending Tcl to pd-gui, and other
oddnesses. I think the best thing to do is to start checking the
mailing list archives and reading the code. This topic has been
discussed a lot, and there is some good discussions on the structure
there. Then come back to the pd-dev list with specific questions.
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.
That's one of the main drives of the desiredata project. I believe
they aim to make a fork that is a compatible language, with
substantial differences in the program itself.
.hc
-- damian stewart | +44 7854 493 796 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/