Canvas ND framework: Difference between revisions

Jump to navigation Jump to search
m
m (→‎Development Post 3.2: code review updates http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214252#p214252)
Line 293: Line 293:
If you are primarily interested in porting/adding new '''mapping''' layers (such as e.g. waypoints, route, weather etc), please see the [[MapStructure]] article for details.  
If you are primarily interested in porting/adding new '''mapping''' layers (such as e.g. waypoints, route, weather etc), please see the [[MapStructure]] article for details.  
Otherwise, this section is focused on dealing with non-mapping aspects, i.e. ND-specific SVG symbols and animating them via properties and calculations. Typically, a new symbol will require 10-20 lines of code added to navdisplay.mfd - it will typically take 5-10 minutes to add a new animated symbol to the ND.}}
Otherwise, this section is focused on dealing with non-mapping aspects, i.e. ND-specific SVG symbols and animating them via properties and calculations. Typically, a new symbol will require 10-20 lines of code added to navdisplay.mfd - it will typically take 5-10 minutes to add a new animated symbol to the ND.}}
If you want to add new features to the navdisplay.mfd code, you need to open that file and map an SVG element to a callback routine - that's how everything is working currently.
If you want to add new features to the navdisplay.styles code, you need to open that file and map an existing SVG element to a Nasal callback routine - that's how everything is working currently. A straightforward examples can be found in the implementation of the '''planArcs''' symbol animation:
 
<syntaxhighlight lang="nasal">
{
                                id:'planArcs',
                                impl: {
                                        init: func(nd,symbol),
                                        predicate: func(nd) nd.in_mode('toggle_display_mode', ['PLAN']),
                                        is_true: func(nd) nd.symbols.planArcs.show(),
                                        is_false: func(nd) nd.symbols.planArcs.hide(),
                                },
},
</syntaxhighlight>
 
This is hash entry, linked to the SVG element whose id is '''planArcs'''. The embedded hash named '''impl''' contains 4 fields:
* '''init()''': a Nasal function that will be invoked to initialize the symbol
* '''predicate()''': a Nasal function that will be invoked to check some condition (predicate)
* '''is_true()''': the Nasal function that will be executed if the condition is true
* '''is_false()''': the Nasal function that will be executed if the condition is false
 
Except for the init() callback, all others get passed a single argument called '''nd''' which is the instance of the current nd, i.e. the equivalent of '''me''', Nasal's '''this''' pointer. In the future, we're hoping to generalize this a little better and also use the init signature, which should make for shorter/more readable code.
 
In this case, the predicate will merely determine in which mode a certain switch is and hide/show the symbol (SVG element) accordingly. Here, it's checking that the '''display-mode''' switch is set to '''PLAN''' mode, and otherwise hide the symbol.
 
Switches are configured at the top of the navdisplay.mfd file, but will usually be overridden by each ND.nas, i.e. by the aircraft developer. For now, modes are hard-coded and people should refer to the code to see what's supported there.


There's a "configuration hash" called "NDStyles" at the top of the file. Each aircraft can have its own entry in NDStyles, such as NDStyles["B747-400"] or NavDisplay["777"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc.
There's a "configuration hash" called "NDStyles" at the top of the file. Each aircraft can have its own entry in NDStyles, such as NDStyles["B747-400"] or NavDisplay["777"]. Then, all the required canvas callbacks are listed there, i.e. the font mapper etc.

Navigation menu