Emesary MFD bridge: Difference between revisions
Jump to navigation
Jump to search
(Created page with "{{Stub}} == Objective == Document ongoing talks and ideas about using the Emesary framework to provide a sane interfacing mechanism for Canvas based avionics (and lo...") |
|||
Line 14: | Line 14: | ||
* styling of ND layers/components according to aircraft specifics (think Boeing vs. Airbus ND) | * styling of ND layers/components according to aircraft specifics (think Boeing vs. Airbus ND) | ||
* encapsulate aircraft/system specifics (think differences between fdm, autopilot and route manager) | * encapsulate aircraft/system specifics (think differences between fdm, autopilot and route manager) | ||
* encourage a modular and reusable design of additions, so that all aircraft developers using the framework can benefit automatically | |||
== Related == | == Related == | ||
{{Appendix}} | {{Appendix}} |
Revision as of 11:06, 14 October 2017
This article is a stub. You can help the wiki by expanding it. |
Objective
Document ongoing talks and ideas about using the Emesary framework to provide a sane interfacing mechanism for Canvas based avionics (and lower-level MapStructure building blocks]] using Richard's Canvas MFD Framework.
Background
Over time, the NavDisplay code has become a huge mess - it is far from being easily maintainable, yet it is the most widely used Canvas-based MFD in use today. So there are some lessons to be learnt from the whole experience.
Design Goals
The NavDisplay code is structured to support:
- truly indenpendent instances (an arbitrary number of them)
- styling of ND layers/components according to aircraft specifics (think Boeing vs. Airbus ND)
- encapsulate aircraft/system specifics (think differences between fdm, autopilot and route manager)
- encourage a modular and reusable design of additions, so that all aircraft developers using the framework can benefit automatically
Related
References
|