Yes, we do have that (binding to individual elements) - keep in mind, any element you see on the screen is also just that: a Canvas element, so any event handling can be made to work that, too.
The most common way this is done is looking up the ID of the SVG element and then you'll get a Canvas.Element from it, and you can use all the APIs there.
Obviously, that means that all elements that you want to look up, need a valid/unique ID.
The baseclass API being this:
http://wiki.flightgear.org/Canvas_ElementAnd the Canvas-specific mapping from SVG element to Canvas space is the Canvas.Path child class:
http://wiki.flightgear.org/Canvas_PathBasic example to look up an SVG element by its SVG/XML id and treating it as a Canvas element/path, is shown here:
http://wiki.flightgear.org/Canvas_SVG_P ... ic_exampleRegarding your other comments of treating it as svg/xml vs. raster image - that's a valid concern, and even if the SVG/XML file can be simplified to make it work (or the parser extended accordingly), it may still be a worthwhile optimization - especially assuming that multiple instances of the dialog may be instantiating multiple "nodes" for the whole shell.
I believe it would be a good simplification for now to create a set of raster images for our needs, and only commit the SVG file as "source code".
If however, the SVG/XML can be fed to svg.nas/parsesvg() "as is", I would simply do just that, and look at the previously mentioned pointers regarding the "SymbolCache" - it is the equivalent of a caching scheme for creating raster images from SVG/XML images - if the latter need to be instanced many times (or are sufficiently complex, which I believe to be the case here)
Note that you can also create/use conventional texture maps using the Canvas system:
http://wiki.flightgear.org/Canvas_Image#srchttp://wiki.flightgear.org/Howto:Using_ ... xture_MapsYes, I do agree that you've been making enormous progress here - and I believe this is an excellent project, because it shows what can be accomplished if people actually team up temporarily to help eachother out - which is remarkably exemplified by Michat's most recent contribution to this effort, as well as the great MFD/Emesary groundwork created by Richard obviously, not to mention TheTom and his Canvas system to begin with.
PS: If the SVG/XML is too complex for the parsesvg implementation right now and cannot be easily reduced in complexity, another possibility might be revisiting the patch that adds raster image support to svg.nas, to move some of the complexity of the "shell" into a separate texture map, to only use a safe subset of SVG/XML, which should also be a good optimization from the Canvas standpoint.