Thorsten wrote:By now I have a library of procedural commands which allows you to e.g.
draw a HUD with a minimal set of commands and re-draw it with a different
design if you find it doesn't match reality runtime - something which SVG
can just not do.
All it needs is to streamline it and document it, and then the situation
your describe may (or not) change, but in my opinion it beats SVG in
designer-friendliness by a large margin - simply because you can change
spacings etc. runtime in FG. Whereas re-drawing a pitch ladder with
different spacing in SVG is a piece of work and there's no guarantee you
get it right runtime.James wrote:Indeed, it sounds as if, within the Shuttle code, you have developed a considerably superior version of the Canvas API, would it not make sense to move that into the FGData Canvas files, and standardise it? It sounds as if Dirk and probably many other people want exactly that kind of functionality. What I don’t understand is why, given such a rich API, it would make sense to use manually crafted SVG as the starting point.
Thorsten, were you referring to the canvas_draw.nas file in the shuttle repository ?
If so, would that be something that you'd consider adding to $FG_ROOT/Nasal/canvas ?
I am thinking primarily in terms of efforts like the G1000 and other MFDs where it may indeed be handy to have a library for procedurally creating elements - like you mentioned elsewhere, I am also more likely to create SVG/XML using a text editor than using Inkscape, but if we had a library for doing this sort of stuff procedurally, that could indeed be a game changer - and I suppose, that would also apply to Stuart ?
I am thinking in terms of low-level helpers for "shapes", and higher level helpers for common elements (altitude ladder, speed tapes, artificial horizon).
The reasoning being that we are seeing more and more aircraft/cockpit duplicating stuff unnecessarily, and the whole reason for creating the Canvas system was indeed to come up with a 2D drawing API ...
Ideas, thoughts ?