[PD-dev] Re: pure devil (fwd)

[Mathieu Bouchard]

---------- Forwarded message (ANNOTATED) ----------
Date: Mon, 8 Aug 2005 20:17:07 +0200
From: Tim Blechmann <TimBlechmann at gmx.de>
To: Mathieu Bouchard <matju at 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