Just to clarify, while it is a combination of all those code files, they don't all need to be understood at all - in fact, Gijs added quite a few new layers recently, without ever looking at the other code - and that was the original plan: 1) copy a set of existing files, 2) customize those, 3) use them - these are typically 2-3 different Nasal files with about ~20-40 lines of code, where usually only a handful of lines need changes, so it's kinda straightforward - and MapStructure itself will even improve things further.
Currently, my priority is helping with the ND code to generalize it further - MapStructure is basically almost there, we already have a demo dialog that uses Philosopher's MapStructure framework to render charts for use in GUI dialogs (PUI) and canvas windows:
The next thing missing here are a handful of additional helpers for mapping/GUI needs, so that property-driven GUI widgets (e.g. PUI stuff) can be easily "linked" to MapControllers (the whole thing still using the MVC separation originally discussed and prototyped).
At that point we can yank a ton of legacy/prototyping code from $FG_ROOT/Nasal/canvas - especially all the map.nas related stuff, because things like the airport selection dialog and the map dialog can be fully re-implemented using roughly 20-50 lines of Nasal code, which is kinda neat obviously.
However, first of all MapStructure needs to be adopted by the ND framework, the map and airport-selection dialogs come next - but once that's done, there's no reason why we cannot get rid of all of the old code, and look into things again to help come up with a framework that also supports PFDs.
The navdisplay.mfd file will need some additional refactoring because recent changes were mostly workarounds, i.e. a ton of custom code was added to things like the update loop - so this will be a good opportunity to re-investigate things and extend the design as needed - ideally, based on feedback from Gijs and Hyde (preferably via the wiki or issue tracker, not via PMs or forum threads - so that things don't get lost over time).
From am design point of view, I would probably introduce a handful of helpers to help with all these tasks:
- SGSubsystem wrapper for Nasal-based subystems
- MFDScreen (wrapper for canvases referenced as raster images)
- MFDImageGenerator (wrapper for a canvas rendering context)
- MFDSourceSelector (wrapper for assigning different image generators to a single canvas screen)
- NavDisplay (wip)
- PrimaryFlightDisplay