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