Namespace globals canvas
Sub-namespaces
MFD_Generic
Generic Page switching cockpit display device. --------------------------- Richard Harrison: 2015-10-17 : rjh@zaretto.com --------------------------- I'm calling this a PFD as in Programmable Function Display. --------------------------- documentation: see http://wiki.flightgear.org/Canvas_MFD_Framework See FGAddon/Aircraft/F-15/Nasal/MPCD/MPCD_main.nas for an example usage --------------------------- This is but a straightforwards wrapper to provide the core logic that page switching displays require. Examples of Page switching displays * MFD * PFD * FMCS * F-15 MPCD
MapStructure
MapStructure mapping/charting framework for Nasal/Canvas, by Philosopher See: http://wiki.flightgear.org/MapStructure
PropertyElement
PropertyElement ============================================================================== Baseclass for all property controlled elements/objects
api
FlightGear canvas API Namespace: canvas Classes included: Transform Element Group Map Text Path Image Canvas see also gui.nas
draw
canvas_draw loader 03/2020 by jsb if you add files to the draw subdirectory, add corresponding lines below in the main() function
gui
FlightGear canvas gui Namespace: canvas Classes: WindowButton Window see also api.nas
map
map.nas - provide a high level method to create typical maps in FlightGear (airports, navaids, fixes and waypoints) for both, the GUI and instruments implements the notion of a "layer" by using canvas groups and adding geo-referenced elements to a layer layered maps are linked to boolean properties so that visibility can be easily toggled (via GUI checkboxes or cockpit hotspots) without having to redraw other layers GOALS: have a single Nasal/Canvas wrapper for all sort of maps in FlightGear, that can be easily shared and reused for different purposes DESIGN: ... is slowly evolving, but still very much beta for the time being API: not yet documented, but see eventually design.txt (will need to add doxygen-strings then) PERFORMANCE: will be improved, probabaly by moving some features to C++ space and optimizing things there ISSUES: just look for the FIXME and TODO strings - currently, the priority is to create an OOP/MVC design with less specialized code in XML files REGRESSIONS: 744 ND: toggle layer on/off, support different dialogs ROADMAP: Generalize this further, so that: - it can be easily reused - it uses a MVC approach, where layer-specific data is provided by a Model object - other dialogs can use this without tons of custom code (airports.xml, route-manager.xml, map-canvas.xml) - generalize this further so that it can be used by MFDs/instruments - implement additional layers (tcas, wxradar, agradar) - especially expose the required data to Nasal - implement better GUI support (events) so that zooming/panning via mouse can be supported - make the whole thing styleable - keep track of things getting added here and decide if they should better move to the core canvas module or the C++ code C++ RFEs: - overload findNavaidsWithinRange() to support an optional position argument, so that arbitrary navaids can be looked up - add Nasal extension function to get scenery vector data (landclass) - -
svg
Parse an xml file into a canvas group element @param group The canvas.Group instance to append the parsed elements to @param path The path of the svg file (absolute or relative to FG_ROOT) @param options Optional hash of options font-mapper func parse_images bool