20,741
edits
Unifying the 2D rendering backend via canvas: Difference between revisions
Jump to navigation
Jump to search
m
Unifying the 2D rendering backend via canvas (view source)
Revision as of 16:33, 6 July 2012
, 6 July 2012→Background
m (→Background) |
m (→Background) |
||
| Line 8: | Line 8: | ||
The Canvas subsystem is flexible enough to re-implement existing 2D rendering related features, such as the HUD system or the 2D panel system, in scripting space, so that legacy C++ code can be incrementally replaced with a more accessible and more maintainable version in scripting space, i.e. as part of the base package - while ensuring that the 2D rendering backend is increasingly unified, as part of the Canvas subsystem. | The Canvas subsystem is flexible enough to re-implement existing 2D rendering related features, such as the HUD system or the 2D panel system, in scripting space, so that legacy C++ code can be incrementally replaced with a more accessible and more maintainable version in scripting space, i.e. as part of the base package - while ensuring that the 2D rendering backend is increasingly unified, as part of the Canvas subsystem. | ||
The idea is to provide Nasal wrappers for these systems, which implement the existing behavior using the canvas system, so that the old C++ code can be phased out. In particular, this means that wrappers for the following systems will be added: | The idea is to provide Nasal wrappers for these systems, which implement the existing behavior using the canvas system, so that the old C++ code can be eventually phased out. In particular, this means that wrappers for the following systems will be added: | ||
* HUD | * HUD: https://gitorious.org/fg/flightgear/trees/next/src/Instrumentation/HUD | ||
* 2D PANEL | * 2D PANEL: https://gitorious.org/fg/flightgear/blobs/next/src/Cockpit/ | ||
* GUI | * GUI: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/FGPUIDialog.cxx#line709 | ||
Initially, the main focus will be on providing the infrastructure to enable people to develop widgets entirely in Nasal space. Once that is working, it will be possible to increasingly re-implement native PUI widgets in Canvas/Nasal space, so that PUI usage is increasingly reduced. | |||
To ensure that the Canvas/GUI wrapper is flexible enough, we need to take a look at existing hard coded PUI dialogs/widgets, and make sure that these can be theoretically reimplemented using Canvas/Nasal, and add any missing hooks as required: | |||
* property list widget: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/property_list.cxx | |||
* waypoint list widget: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/WaypointList.cxx | |||
* map widget: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/MapWidget.cxx | |||
* wxRadar | This automatically means that PUI callbacks must be forwarded to Nasal, so that they can be implemented as Nasal callbacks. | ||
* agradar | |||
* NavDisplay | Also, the Canvas subsystem should be powerful enough to allow re-implementing existing hard-coded [https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/od_gauge.cxx od_gauge instruments], such as: | ||
* dclgps: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/dclgps.cxx | |||
* kln89: https://gitorious.org/fg/flightgear/trees/next/src/Instrumentation/KLN89 | |||
* groundradar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/groundradar.cxx | |||
* wxRadar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/wxradar.cxx | |||
* agradar: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/agradar.cxx | |||
* NavDisplay: https://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/NavDisplay.cxx | |||
As of 07/2012 the navdb is fully exposed as part of the NasalPositioned module $FG_SRC/Scripting. | As of 07/2012 the navdb is fully exposed as part of the NasalPositioned module $FG_SRC/Scripting. | ||