---------- 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
On Mon, 8 Aug 2005, Tim Blechmann wrote:
Mathieu Bouchard wrote:
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 ...
Ok, what do you want in the nice API ?
I mean what would be in the libpd API that isn't already in m_pd.h ?
And then there might be nice stuff required for a better API that isn't specific to libpd, ... such as publishing stuff from g_canvas.h... (but incidentally g_canvas.h corresponds to the part of Pd i am currently nuking)
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 ...
Ok, you're right.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hey Mathieu +
How would a graphical external be written in such a system with multiple interchangable patchers/guis? Would there be any effort to abstract the gui code to allow for one graphical external to be realized in all the possible GUIs? I think we would loose a lot if graphic external "A" only works on PD gui 2.3 and not on any others...
For me a nice API would include a nice way to build gui externals. Ever nicer would be a cross-toolkit method of doing so. A heftly task I imagine.
Also I'm about to start on that help-patch searching system in tcl. (for a start anyhow)
B.
Mathieu Bouchard wrote:
On Mon, 8 Aug 2005, Tim Blechmann wrote:
Mathieu Bouchard wrote:
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 ...
Ok, what do you want in the nice API ?
I mean what would be in the libpd API that isn't already in m_pd.h ?
And then there might be nice stuff required for a better API that isn't specific to libpd, ... such as publishing stuff from g_canvas.h... (but incidentally g_canvas.h corresponds to the part of Pd i am currently nuking)
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 ...
Ok, you're right.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 9 Aug 2005, B. Bogart wrote:
How would a graphical external be written in such a system with multiple interchangable patchers/guis?
A few possibilities:
1. it would be rewritten for every target GUI. This makes it possible to adapt to every GUI's strengths and weaknesses.
2. there would be a common GUI-drawing API that can be used from C. This is what Gunther (?) has suggested some time ago, ... I think it was in a discussion about g_canvas.h.
3. there would be a common GUI-drawing API that can be used from PD. This is more interesting than (2) because it allows abstractions to be GUI objects without having to be GOP.
4. Miller's "data structures" thingy.
Several of the above would be implemented concurrently, each focusing on different niches. The problem with (2,3,4) is that they are geared towards the current thin-client approach whereas (1) follows my fat-client approach. That's unless we get into the business of putting a mini-pd-server in the client which cares only about the gui stuff... (wheee!!!)
I think we would loose a lot if graphic external "A" only works on PD gui 2.3 and not on any others...
Therefore it's important to balance this loss with the gain of how easier it will become to write graphic externals, so that the net result is a gain.
For me a nice API would include a nice way to build gui externals. Ever nicer would be a cross-toolkit method of doing so. A heftly task I imagine.
Well, IMHO, what could go a long way is just mapping the Tk Canvas to Pd messages and make emulators of that for other toolkits. This would recycle the knowledge that Pd GUI developers already have right now, so that portable GUI objects may be written without having to learn a whole new API.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada