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 | [EMAIL PROTECTED] > frey | live art with machines | http://www.frey.co.nz > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- http://at.or.at/hans/ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
