Regarding your constructive feedback (what you call criticism), the thing is the SVG/XML parser we're using is extremely basic, it's only using/supporting a very tiny little fraction of what SVG provides, and that is accomplished by using a FlightGear-specific parser written in the FlightGear scripting language (Nasal) that looks for this SVG subset and translates that into Canvas properties (path, text/image) to tell the underlying C++ engine to dynamically create a matching OpenSceneGraph scene using primarily OpenVG paths.
I've previously extended that parser and shared instructions to demonstrate how this is done, more recently jsb has made some useful enhancements - but other than that, you cannot expect any SVG feature to just magically work:
http://wiki.flightgear.org/Howto:Extend ... SVG_moduleSpeaking in general, you would have to give it a try first, and then post your findings here. We could then discuss if it makes sense to extend the parser accordingly or not. A few weeks ago, I posted a link to a wiki article (tutorial) demonstrating the required steps, the example walks you through adding support for the <image> tag - which basically required 20 lines of code (ECMAScript-oriented)
While many SVG features might potentially come in handy, it isn't necessarily a good idea to extend the current parser "as is", there is a break-even point where adopting a different SVG-handling mechanism would be more lightweight or simply "better". Also, keep in mind, anything using svg.nas inevitably goes through props.nas (which is slow) and ultimately goes through the FlightGear property tree - in other words, there is quite a bit of bandwidth caused, depending on the complexity of the SVG DOM.
Regarding Inkscape scripting, I have previously written a simple Inkscape "plugin" to generate/customize FG/Canvas resources (SVG + Nasal code), and Stuart also used a few custom Perl scripts for the same purpose when he created the FG1000:
viewtopic.php?f=71&t=33594http://wiki.flightgear.org/Howto:Hackin ... as_supportIs there a wiki somewhere on how to use and setup Inkscape to design Instruments?
Yeah, you could say there is such an article - but there are also different philosophies involved here, i.e. many of our MFD developers do indeed seem to prefer a procedural approach where they end up using code to customize/draw template-based vector art:
http://wiki.flightgear.org/Canvas_Drawhttp://wiki.flightgear.org/Canvas_draw_libraryhttp://chateau-logic.com/content/flight ... instrumentThere also a few wiki articles, I believe abassign wrote a particularly comprehensive one recently
I still have to learn how animated SVG works to see if that transfers to OpenVG.
It certainly doesn't in FlightGear, where the 3D OpenGL scene graph is built via OpenSceneGraph (OSG).
All dynamic/animated stuff is currently implemented on top of scripted code (callbacks) invoked via timers and listeners:
http://wiki.flightgear.org/CallbacksI have no idea how Flightgear works apart from a few diagrams.
Is there a way to get the flight data going out a serial port?
Basic data like attitude, heading, airspeed, altitude etc
Yes, there is. Please see $FG_ROOT/Docs/README.serial and README.IO, README.properties
For starters, it would be best to work through the navbar shown here:
http://wiki.flightgear.org/Property_treeFinally, those are many questions, and unrelated ones, too - it would be better to split up such postings and post individual questions, rather than a collection of questions that nobody feels comfortable responding to entirely
With your current background, I would definitely suggest to start with the property tree, the property browser, the nasal console and then take it from there to tinker with a few SVG examples, so that you can make some first experiments before making concrete feature requests or suggestions for improvement.
You can learn how to make FlightGear create/load and render SVG/XML markup using just copy/paste "coding" and 10 minutes of your time:
http://wiki.flightgear.org/Canvas_Snippets