Canvas wrappers: Difference between revisions

Jump to navigation Jump to search
No edit summary
Line 17: Line 17:


The Canvas/GUI integration is implemented such that none of the existing code is touched, i.e. the old behavior remains fully supported. In addition, new widgets can be shared and reused by adding them to the $FG_ROOT/Nasal directory.
The Canvas/GUI integration is implemented such that none of the existing code is touched, i.e. the old behavior remains fully supported. In addition, new widgets can be shared and reused by adding them to the $FG_ROOT/Nasal directory.
Also, we also don't need to duplicate the existing C++ code and the dialog XML parsing.
Everything keeps as working as it is, adding new widgets (and USING them) can be purely done by modifying stuff in the base package, without touching the C++ code again.


In order to start using any custom Canvas-widgets, you only need to change the widget type to "canvas" and specify the name of the widget to be instantiated. For example:
In order to start using any custom Canvas-widgets, you only need to change the widget type to "canvas" and specify the name of the widget to be instantiated. For example:
Line 26: Line 31:


This is fully supported by Nasal code, as well as XML files.
This is fully supported by Nasal code, as well as XML files.
For example, if someone creates a new Canvas-based widget, say a "button" - all that is needed to start using it in FG, would be modifying the corresponding GUI XML files, and replacing the
<type>button</type>
with this instead:
<type>canvas</type>
<widget>button</widget>
(i.e. rename type and add a new "widget" node)
This can be done automatically within seconds using XSLT for XML files in $FG_ROOT - and all of a sudden, the PUI button class would no longer be used - no need to touch any C++.


== MFD ==
== MFD ==

Navigation menu