20,741
edits
Canvas MapStructure layers: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Add new Slippy Map layers) |
No edit summary |
||
| Line 15: | Line 15: | ||
{{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.|width=70%}} | {{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.|width=70%}} | ||
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/> | <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/> | 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/> | ||
| Line 23: | Line 22: | ||
<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. | 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. | ||
{| class="wikitable" | {| class="wikitable" | ||