20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Encapsulating Properties: pm2wiki
m (→Encapsulating Properties: pm2wiki) |
|||
| Line 404: | Line 404: | ||
=== Encapsulating Properties === | === Encapsulating Properties === | ||
[[File:NDSourceDriverHash-concept.png|thumb|Screenshot demonstrating how the Canvas-based ND was designed to use an encapsulated "data souce" abstraction to hide implementation details, so that the same ND code can be used for creating independent ND instances that support AI/MP (or [[Dual Control]]) aircraft for driving the MFD<ref>http://forum.flightgear.org/viewtopic.php?f=4&t=28965&p=280612#p280612</ref>. Note that this was prototyped in late 2013 originally<ref>http://forum.flightgear.org/viewtopic.php?p=193660#p193660</ref>, and may not have received much testing/attention lately.]] | [[File:NDSourceDriverHash-concept.png|thumb|Screenshot demonstrating how the Canvas-based ND was designed to use an encapsulated "data souce" abstraction to hide implementation details, so that the same ND code can be used for creating independent ND instances that support AI/MP (or [[Dual Control]]) aircraft for driving the MFD<ref>http://forum.flightgear.org/viewtopic.php?f=4&t=28965&p=280612#p280612</ref>. Note that this was prototyped in late 2013 originally<ref>http://forum.flightgear.org/viewtopic.php?p=193660#p193660</ref>, and may not have received much testing/attention lately.]] | ||
Over time, the ND code has become kind of a mess - and we helped create/add to it,at a time when the ND code was not supporting multiple aircraft or multiple instances, so it evolved from then - my suggestion would be not to touch/refactor it anytime soon, it's really mostly procedural code that is including files with "configuration hashes" - e.g. navdisplay.styles and navdisplay.mfd if I remember correctly. | |||
The "mfd" file is a conventional Nasal file that sets up the whole thing, while the styles file is/was intended to keep aircraft specific stuff (think 777 vs 747 vs 737 vs. Airbus A320, 310 etc). | |||
So we wanted to have some separation scheme in place, while providing a foundation for code reuse. | |||
From a functionality standpoint, the meat of it are two for/each loops that either set up listeners for certain events (e.g. cockpit-specific switches), or just a generic timer that calls a bunch of callbacks in a vector - each callback there is treated as a predicate with a function that is evaluated, and the corresponding true/false callbacks being invoked accordingly. | |||
It really is a rather simple/inelegant design, but it proved to be rather accessible for people without much of a programming background, i.e. the "styles" stuff can be touched/maintained and refactored by people without having to touch the other files. And that also applies to the *.mfd file | |||
At some point, artix added a bunch of functionality to it - but originally we were hoping to even have manufacturer-specific style files with hashes - I just requested not to implement that back then, because I felt that the degree of code reuse taking place was still not satisfactory (think animation/event handling) - looking at Richard's MFD framework, the *.mfd file would be the right place to integrate it - and we would not need to touch the *.styles stuff at all to make that work. | |||
The one thing were things may fall apart is that the ND code is intended to support independent instances, that may be driven by AI/MP properties, i.e. that may not even have a proper "aircraft/FDM/autopilot/route manager" associated, which means that the standalone UI use-case is/was intended to be supported. | |||
Overall, it's a rather verbose, explicit and inelegant design, but there's a sane way to refactor things by just looking at navidsplay.mfd - the only feature implemented differently is mapping/charting, because that is using the MapStructure framework, which using fairly sophisticated metaprogramming, on top of a simple MVC framework, so that charting layers can be easily implemented/customized and maintained (think VOR, NDB, DME, AI/MP traffic, weather etc) - without any of those layers containing aircraft/use-case specific code, which makes the whole thing reusable elsewhere (e.g. see $FG_ROOT/gui/dialogs/map-canvas.xml). | |||
In coding terms, there's a bunch of delegates used everywhere that are contained in various configuration hashes, so that the system can be easily re-configured, without having to use much/any copy & paste, apart from the configuration itself. | |||
{{Note|The quotes below are mainly intended for people wanting to use the ND framework with other aircraft (e.g. those not driven by an actual FDM), and/or for visualizing situations for arbitrary AI/MP nodes in the tree (think bombable), but also dual control aircraft (multi-instance synchronization)}} | {{Note|The quotes below are mainly intended for people wanting to use the ND framework with other aircraft (e.g. those not driven by an actual FDM), and/or for visualizing situations for arbitrary AI/MP nodes in the tree (think bombable), but also dual control aircraft (multi-instance synchronization)}} | ||