Emesary MFD bridge: Difference between revisions
Line 5: | Line 5: | ||
== Background == | == 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. | [[File:Canvas-mfd-framework-prototyping.png|400px|thumb|This is an adapted version of the [[Garmin GPSMap 196]] originally developed by F-JJTH. Here, the whole instrument is entirely set up in XML space without using any [[Nasal]], including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]] | ||
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, mainly because it is generic and can be easily reused, which is due to it having been designed using just a standalone GUI dialog. | |||
So there are some lessons to be learnt from the whole experience. | |||
== Nasal modules == | == Nasal modules == |
Revision as of 14:31, 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, mainly because it is generic and can be easily reused, which is due to it having been designed using just a standalone GUI dialog.
So there are some lessons to be learnt from the whole experience.
Nasal modules
Use Cases
Design Goals
The NavDisplay code is structured to support:
- GUI-based prototyping and design/testing of layers
- 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
Implementation
We will be hooking up the Canvas MFD framework to a conventional Canvas GUI dialog, so that a MFD instrument can be shown in a standalone GUI dialog. The next step will involve using the Emesary framework to create custom events and actions.
Instantiating a MFD Dialog
See Howto:Creating a Canvas GUI dialog file for the main article about this subject. |
Related
References
|