[PD] gui development (was puredata evolution)

[*~]

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 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
> 
> 
> 
> ------------------------------------------------------------------------ 
> ----
> 
>                                                http://at.or.at/hans/
> 
> 
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>