On Sun, 17 Jul 2005, Thomas Grill wrote:
i'm asking myself how this should be handled then... In my understanding there should be no relevant difference between internals and externals, meaning that both should use the same API. What is the solution for external developers? Not implement graphical stuff at all? Or do it with data structures, wasting development time and system resources?
I think it should be handled by not implementing graphical stuff at all or by doing it with data structures, but wasting development time and system resources should be avoided.
No, honestly, I am for a stable graphics API. I even think all the drawing stuff should be wrapped into an API instead of sending it as tcl/tk commands to the canvas directly. If this is done throughout pd, you can reimplement the canvas as an OpenGL window and do scaling, zooming rotating and other fancy stuff with your patch, and the drawing is fast.
It seems the common problem is that things in PD development got and get messed up by the time because people want to work with the API and implement useful things but it's totally unclear what future directions will be, what can be used safely etc. It's a problem of documentation and communication.
Yes, this was one of the goals that I had in mind when creating the CVS. Unfortunately we haven't been able to define a clear direction, and then this is terribly difficult because everyone will have another opinion in which direction Pd should go. (remember the endless single external versus library discussions ?) That is also why I (hope at least) try to enforce the direction of Miller, Pd is his program and he is the authority. It is obvious that one of the main interests currently are the data structures, and honestly, I find this a lot more interesting than coding yet another graphical external. I have a terribly bad memory and my main concern is to have a possibly small basic set of objects that I can use to build my patches. Currently the external business is going in the other direction and this scares me because I can't follow all the new and fancy developments that are happening.
Concerning flext, it uses g_canvas.h quite conservatively and i think it would be even possible to avoid it with the loss of some comfort (attribute editor).
I think this is a very wise decision.
Guenter
best greetings, Thomas