20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 364: | Line 364: | ||
== Development == | == 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 === | === 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] | * 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] | ||