[PD] gui development (was puredata evolution)

Hans-Christoph Steiner hans at eds.org
Wed May 30 03:49:49 CEST 2007

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.


> -- 
> damian stewart | +44 7854 493 796 | damian at frey.co.nz
> frey | live art with machines | http://www.frey.co.nz
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



More information about the Pd-list mailing list