Regardless of what I said, if you find the problem itself interesting, you may want to look up some of the advice I have previously given whenever someone announced that they were working on an aircraft specific Canvas display/instrument, i.e. covering some of the lessons we learnt during the refactoring of the ND code and the creation of the MapStructure framework. Even if you aren't planning on coming up with a new framework from scratch, it may help to look at other code and ideas, especially those that actually worked out well enough (think Richard's MFD framework).
The thing to keep in mind here is that both, Nasal as a language embedded in FlightGear, but also the Canvas system are rather flexible, and maybe even "too flexible", in that they encourage a "free form" approach of coming up with new instruments rather easily - however, somewhere down the road people may realize that the time they spent on working on such code may have better been spent detailing their mid-term requirements to come up with a design that may help accomplish all their goals in the long-term.
I don't know if you have ever looked the navdisplay.mfd or navdisplay.styles files, or even the EFB stuff created by I-NEMO (IIRC). The Nasal code there is frankly a freakin mess, and that's usually because people started writing code before knowing anything about their requirements - but at some point, things worked "well enough", so that they began sharing it, maybe even documenting it, and making it available for others to use/extend.
In the case of the ND, that meant that it would not support more than instance (instrument) per aircraft, i.e. would show the same display on all ND screens. Equally, it didn't support other aircraft, also it contained many assumptions about the properties in use (again, aircraft specifics), but also the cockpit bindings and other systems.
And then, there's other issues - such as people wanting to do multiplayer/dual-control or multi-instance setups like those shown at FSWeekend/LinuxTag.
All of this is to say that it isn't impossible or even difficult to design for these requirements, but it is a ton of work to add a correspondign architecture to such code once it is almost complete.
That is one of the reasons why most of the canvas early-adopters have been encouraging a modular, framework-centric, approach to creating avionics, usually advocating standalone prototyping of Canvas avionics using just a Canvas GUI dialog. That way, it will be much easier to ensure that multiple instances can be made to work, and that different aircraft/autopilots or route manager configurations will also work.
In the long-term this usually means that other contributors will get involved to help with the maintenance of the system - for instance, imagine you were to come up with a useful PFD framework that isn't specific to your aircraft only, others needing a PFD may reuse your work and even join the effort. Probably for pretty much the same reasons that you may be using the NavDisplay/MapStructure frameworks, or even Nasal/Canvas in general - we're literally standing on the shoulders of giants here, but every once in a while we can also be/become the giants for others to be standing on us (a few years from now, which is what happened when it comes to the MapStructure framework and to the Canvas system in general).
If you can relate to this kind of thinking, you may want to reconsider your approach and maybe look at what is needed to write code that isn't specific to just a single aircraft/instrument or instance - it's not that difficult, things may even fall into place automatically once you stop developing/testing using a single aircraft only.
http://wiki.flightgear.org/Howto:Coding ... _Frameworkhttp://wiki.flightgear.org/Howto:Bootst ... Canvas_MFDhttp://wiki.flightgear.org/Howto:Using_ ... s_in_Nasal http://wiki.flightgear.org/Canvas_PFD_Framework
FlightGear Forum
