[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.
.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/
More information about the Pd-list
mailing list