20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Adding new features
| Line 319: | Line 319: | ||
Switches are configured at the top of the navdisplay.mfd file, but will usually be overridden by each ND.nas, i.e. by the aircraft developer. For now, modes are hard-coded and people should refer to the code to see what's supported there. | Switches are configured at the top of the navdisplay.mfd file, but will usually be overridden by each ND.nas, i.e. by the aircraft developer. For now, modes are hard-coded and people should refer to the code to see what's supported there. | ||
{{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["B747-400"] or NavDisplay["777"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc. | 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["B747-400"] or NavDisplay["777"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc. | ||