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