Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Changes

Jump to: navigation, search

Canvas ND Framework

711 bytes added, 15:20, 4 January 2015
m
no edit summary
== Development ==
 
=== Backward Compatibility ===
Once we support a handful of different '''styles''', it would probably make sense to refactor the styles file so that we end up with dedicated files for each style, e.g. by having:
 
* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus
* $FG_ROOT/Nasal/canvas/map/ND/nd.boeing
 
However, it makes sense to wait a little with this so that multiple styles can evolve in parallel, to ensure that overlapping functionality can be generalized and refactored/reused. Equally, that would allow us to provide versioning support, so that aircraft developers can request a certain version of the "ND API", e.g.:
 
* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-3_4
* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-4_0
=== Getting rid of Aircraft Dependencies ===
* the constructor/newMFD() methods still contain a few hard-coded assumptions due to the origins of the code, but those can be also moved into some kind of construct() field in the hash, or you can simply use the method I suggested, i.e. hiding unneeded symbols. But you're right, that the most proper solution would be identifying non-generic code that contains hard-coded assumptions and moving that into some kind of construct() field that is simply invoked by the new/newMFD() methods. Doing that would not be difficult, it would be just copy & paste - i.e. copy from the navdisplay.mfd file into the style file, by adding a corresponding hash field entry there - and calling it instead. Takes under 3 minutes[http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214897#p214835]
18,205
edits

Navigation menu