---------- Forwarded message (ANNOTATED) ---------- Date: Mon, 8 Aug 2005 20:17:07 +0200 From: Tim Blechmann TimBlechmann@gmx.de To: Mathieu Bouchard matju@artengine.ca Subject: Re: pure devil
Mathieu Bouchard wrote:
Tim Blechmann wrote:
oh ... btw, what do you think of _completely_ separating dsp core and gui? basically kicking out all of pd's gui ...
You mean the dsp+message core on one side and the rest on another side? That's already my intent.
great ... this makes it not even possible to reimplement the gui, but also to reimplement the kernel...
[I suppose Tim wanted to say "not just" instead of "not even"]
i'm suggesting this, since georg holzmann from graz wants to start with a qt gui, you're going to work on a tcl gui, thomas grill is working on an opengl gui ... so i'm thinking of a libpd, that can work with all different guis ...
I want to allow multiple GUI engine, and even, several GUIs at the same time... as long as no-one wants to use the old GUI, that we keep for compatibility with anything that happens to not work with the desire.tk GUI. My idea of it is like this:
In devel_0_39, you can pick between (1) old Pd GUI (2) new Pd GUI, in which the server gets started first, and then zero-or-more clients get started, in: (2.1) DesireData (2.2) Georg's Qt GUI (2.3) Mamalala's Qt GUI (2.4) Thomas Grill's OpenGL GUI (2.5) Carmen's Tcl/TkZinc/OpenGL GUI
Those are separate processes, so they don't need to be linked to Pd, and anyway in all of situation (2), the GUI code of the server side gets replaced by just a stub that can accept anything.
sounds great ...
Therefore we do not need libpd for that purpose... but it would still be cool to have a libpd one day, as an option for those who want it. (Someone came in _today_ on the channel asking whether there was a libpd)
well, no idea, that his purpose would be, but it's possible to compile a libpd ... no nice api, though ...
you'd basically have to rewrite the whole pd gui from scratch,
Most of the pd GUI is _already_ rewritten anyway -- I mean that's what I did in the first half of 2004. The IEMGUIs were all rewritten, and some patching functions also had been rewritten. Chun is working on the patching.
For disabling the old Pd GUI, I see these options: (A) disabling the code using #ifdef (B) disabling the code by not calling the startup code (C) disabling the code by ignoring what we can and else calling more startup code that overwrites the objectmaker entries that we don't want
(C) is the least "destructive", but sometimes destruction is better... I don't know which I'd pick, but I'm confident that I/we will figure it out at the right time.
B ... makes it possible to stay compatible with miller as long as possible ...
ttyl ... tim