I think there is quite a bit of existing code that could be copied and adapted. Thorsten's work is certainly a good starting point.
My suggestion would be to prototype the whole thing using a single Canvas GUI dialog for testing purposes, that will speed up things considerably. As a matter of fact, even developing the library as an "addon" might be a good idea to ensure that people can easily get involved in testing. Besides, this would ensure that there is no breakage introduced, because it would be developed as a new module.
I do think it's a good idea to incrementally hook up parts of this to svg.nas, i.e. to support more primitives there. This, too, would be a good way to grow the library, while also ensuring that people using SVG/Inkscape can benefit from this work.
Obviously, there is going to be a more abstract layer for drawing avionics elements ("widgets"), but that would ideally be using the lower level 2D API as its back-end.
As a matter of fact, James recently mentioned that he was hoping for people to come up with a parser to re-implement the existing HUD functionality (README.HUD) on top of the Canvas system. Given the overlap here, it would actually seem like a good idea to bootstrap such a parser by coming up with the 2D primitives to make this happen, this could be prototyped using Thorsten's groundwork, maybe in conjunction with some of rleibner's work - and possibly with ideas taken from the extra500 ?
Given the different modules involved here, I do think making this an addon for the duration of the protoype phase would actually be a good idea, because it would be lightweight not very invasive at all. In other words, we could get really fancy and try all sorts of new stuff, without stepping on anyone's toes.
For example, we could simply copy useful GPL'ed stuff into the new addon, and begin using it to prototype a 2D drawing API, and hook that up to svg.nas and/or a dedicated Nasal module to parse existing HUD XML.
This would ensure that we have a good stress test for the API (benchmarking, profiling, debugging), while also making sure that the API becomes sufficiently powerful and flexible.
I think James and Stuart have come up with their own 2D drawing primitives, so looking at some of their code might also be interesting. Stuart stated specifically, that he'd like to see the FG1000 evolve to a point where people can simply replace "pages" and "page elements" with custom MFD specs to "style" the FG1000.
FWIW, I actually once began writing a parser to even parse/interpret 2D instruments and panels:
http://wiki.flightgear.org/Howto:Parsin ... the_CanvasNote that these (writing Nasal parsers for legacy HUDs/2D panels to process them via Canvas) are actually ideas that James came up with originally:
http://www.mail-archive.com/flightgear- ... 38629.htmlJames Turner wrote:Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)