Emesary MFD bridge: Difference between revisions

From FlightGear wiki
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