Hans-Christoph Steiner said :
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.
when i run pd with -d 1 option, all the traffic seem to be Tcl code. i think its more than a number of situations..
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.
yes, issues with GUI is one of the main area which desiredata tries to address. and yes, one of its goal is also to stay compatiable with the main Pd.
cheers
chun
.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/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list