Canvas ND framework: Difference between revisions

The '''navigation display''' ('''ND''') is a display in a glass cockpit, providing information about an aircraft's lateral situation. As of late 2013, a new fully-scripted ND ([[Navigation display]] being the old) is in development for [[FlightGear]] using the new [[MapStructure]] back-end for charting purposes, and SVG symbols animated via Nasal functions for any non-mapping aspects (typically using listeners and timers).  

Extending the framework should normally require very little in terms of coding - typically, people can simply take an existing feature/symbol, copy & paste the code section and customize it according to their needs (e.g. different SVG element id, different animations, different properties) - symbols can be easily changed by providing a separate SVG file, or by creating a new one via Inkscape.

* 01/2014: Hyde (777-200) {{Progressbar|100}}

* 02/2014: mueko (A320) {{Progressbar|90}} [http://forum.flightgear.org/viewtopic.php?f=71&t=22045&p=200427#p200422]

<!--

* 02/2014: D-MKF1 (707) {{Progressbar|10}}

}}

== Custom ND Styles ==

Note that setup instructions above will initially just give you a Boeing-centric ND, because it is currently being developed by the 747/777 maintainers primarily - please use the issue tracker to file feature requests for missing features.  

Over time, the framework will grow and become more flexible,so that also specifics of non-Boeing aircraft can be properly emulated. But obviously this will take a while. We invite aircraft developers to help extend and refine the framework accordingly.

We can obviously not stop anybody from working with that code, but we would very much prefer to scratch off a handful of items from our todo list first - otherwise, this is going to be a maintenance problem in the mid-term.

Currently, we are simply not there yet - and some of the recent additions aren't exactly making this much easier unfortunately.

''The thing is, even if someone were to come up with a 100% correct/working A320 implementation now, the framework itself would not yet be sufficiently generalized - some of the recent additions are making things more complicated here, such as the inflated update() method, the Boeing-specific constructor and hard-coded assumptions in the newMFD() method.''

This is hash entry, linked to the SVG element whose id is '''planArcs'''. The embedded hash named '''impl''' contains 4 fields:

* '''init()''': a Nasal function that will be invoked to initialize the symbol

* '''is_true()''': the Nasal function that will be executed if the condition is true

* '''is_false()''': the Nasal function that will be executed if the condition is false

In this case, the predicate will merely determine in which mode a certain switch is and hide/show the symbol (SVG element) accordingly. Here, it's checking that the '''display-mode''' switch is set to '''PLAN''' mode, and otherwise hide the symbol.

   

{{Note|The whole layout/approach of the navdisplay.style file isn't set in stone at all - it just ended up being a simple workaround to accomplish some goals, while also allowing newcomers to easily maintain/extend the system by just having to go through a handful of lines of code. At some point this may further evolve. It would now even be straightforward to move the whole thing to XML space using a simple script that turns our hash into XML. But ultimately we hope to wait a little with that until a generic '''MFD''' framework has evolved that can also be used for other displays like a PFD, CDU or EFB.}}

There's a "configuration hash" called "NDStyles" at the top of the file. Each aircraft can have its own entry in NDStyles, such as NDStyles["Boeing"] or NavDisplay["Airbus"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc.

Lines 52-131 set up existing layers, which are now shared with the GUI code - so that is where new layers are added.