20,741
edits
Canvas MapStructure layers: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (this specifies if the layer is specific to the main aircraft, or if it can also be used by other aircraft - e.g. AI traffic - for instance, the route manager is only available for the main aircraft, so we cannot display routes for AI traffic currently) |
No edit summary |
||
| Line 14: | Line 14: | ||
{{Note|These MapStructure layers are currently to be found in $FG_ROOT/Nasal/canvas/map - these are conventional Nasal files, but they are bound to existing data structures at run-time and become ''classes'' that can be procedurally instantiated and customized. Depending on the phase of the current release cycle, the links shown below may be outdated and more recent additions are to be found in the [[Canvas-hackers]] team clone only. There are several incomplete/missing layers, if you'd like to work on any of those, please get in touch via the forum first.}} | {{Note|These MapStructure layers are currently to be found in $FG_ROOT/Nasal/canvas/map - these are conventional Nasal files, but they are bound to existing data structures at run-time and become ''classes'' that can be procedurally instantiated and customized. Depending on the phase of the current release cycle, the links shown below may be outdated and more recent additions are to be found in the [[Canvas-hackers]] team clone only. There are several incomplete/missing layers, if you'd like to work on any of those, please get in touch via the forum first.}} | ||
{{FGCquote | |||
|The main feat of the [[NavDisplay]] framework, and even [[MapStructure]], is not so much its design (sorry, P. ) - which isn't particularly "standard" or even elegant - the main accomplishment is its loose coupling, i.e. the decoupled nature of these modules makes it possible for people -who are interested in very different aircraft, avionics and use-cases, to still collaborate effectively, simply because things are so flexible. So these two "frameworks" are primarily collaboration enablers, because people that would normally not collaborate can all of a sudden easily work on a common code-base pretty easily.<br/> | |||
<br/> | |||
People doing modern MFD-style avionics or any kind of mapping/charting displays should really have no reason NOT to use these frameworks - if something is missing, extending the framework is simple enough, and it means that your work is going to be used -and even maintained- by a number of contributors who have a track record doing similar stuff.<br/> | |||
<br/> | |||
Obviously, there are quite a few other examples of great avionics developed in Nasal/Canvas, particularly the Avidyne Entegra R9 - but as long as those are non-generic and use-case specific (e.g. single aircraft), it is unlikely that fellow contributors will step up to help maintain such modules over time unfortunately. And re-implementing existing instruments on top of NavDisplay/MapStructure is a win/win for all parties involved, because there's less aircraft-specific code involved at some point.<br/> | |||
<br/> | |||
The whole MVC separation established by the ND/MS frameworks allows people to collaborate despite possibly working with very different aircraft and instruments/avionics, which even includes people who don't do any aircraft/instrument development at all, but "merely" GUI dialogs like an instructor console for example. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216427#p216427 | |||
|title=<nowiki>Re: A330-200 with Canvas and other features</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Mon Aug 11</nowiki> | |||
}} | |||
}} | |||
{| class="wikitable" | {| class="wikitable" | ||