2,733
edits
Red Leader (talk | contribs) m (Reverted edits by Hooray (talk) to last revision by Red Leader) |
Red Leader (talk | contribs) (Sorry, accidental) |
||
Line 12: | Line 12: | ||
}}</ref> | }}</ref> | ||
For the time being, this approach has a number of major advantages, i.e. it has proven to be able to deal with existing resources, without the original legacy UI dialogs having to be touched/modified, so that the primary thing missing to parse/process these dialogs are a handful of missing Canvas widgets. | For the time being, this approach has a number of major advantages, i.e. it has proven to be able to deal with existing UI resources (dialogs, and [[Menubar]]), without the original legacy UI dialogs (or any C++ code) having to be touched/modified, so that the primary thing missing to parse/process these dialogs are a handful of missing Canvas widgets, which can also be implemented in scripting space usually. | ||
For the time being, this approach also is the only effort that can easily support procedurally created and updated dialogs like [[Aircraft Checklists]] and [[Tutorials]]. | |||
Also, the '''pui2canvas''' approach can help address a number of long-standing PUI related issues, such as rendering arttfacts on some ATI/AMD GPUs, but also PUI/Canvas inter-operability issues related to [[Canvas Event Handling]]. | |||
As the integrated, and fully script-able, [[Canvas GUI]] develops, new {{wikipedia|Widget (GUI)|widgets}} need to be added <ref>{{cite web | As the integrated, and fully script-able, [[Canvas GUI]] develops, new {{wikipedia|Widget (GUI)|widgets}} need to be added <ref>{{cite web | ||
Line 33: | Line 36: | ||
For a complete list (including custom/undocumented widgets), refer to <code>FGPUIDialog::makeObject()</code> in {{flightgear file|src/GUI/FGPUIDialog.cxx|l=850}} | For a complete list (including custom/undocumented widgets), refer to <code>FGPUIDialog::makeObject()</code> in {{flightgear file|src/GUI/FGPUIDialog.cxx|l=850}} | ||
In addition, FlightGear introduces a number of custom PUI widgets implemented in C++ space, that not even PUI itself supports directly. | In addition, FlightGear introduces a number of custom PUI widgets implemented in C++ space, that not even PUI itself supports directly: | ||
However, many PUI widgets can be emulated/approximated by using a combination of existing widgets, and/or functionality found in existing | * {{PUI widget|airport-list}} | ||
* {{PUI widget|waypoint-list}} (only used by the [[Route Manager]] i.e. {{Dialog file|dialog=route-manager}} | |||
* {{PUI widget|property-list}} (only used by the [[Property browser]] i.e. {{Dialog file|dialog=property-browser}} | |||
However, many PUI widgets can be emulated/approximated by using a combination of existing widgets, and/or functionality found in existing widgets, i.e. by referring to their source code. | |||
As of late June 2016, the following widgets are primarily needed to help getting rid of PUI (listed in ascending complexity): | As of late June 2016, the following widgets are primarily needed to help getting rid of PUI (listed in ascending complexity): | ||
* {{PUI widget|vrule}} (not critical, could be implemented OpenVG or simply by using a transparent image) | * {{PUI widget|vrule}} (not critical, could be implemented OpenVG or simply by using a transparent image) | ||
* {{PUI widget|hrule}} (not critical, could be implemented OpenVG or simply by using a transparent image) | * {{PUI widget|hrule}} (not critical, could be implemented OpenVG or simply by using a transparent image) | ||
* {{PUI widget|radio}} (Canvas images using event handling) | * {{PUI widget|radio}} (Canvas images using event handling to dynamically change the image based on mouse events) | ||
* {{PUI widget|slider}} (basically 3 buttons with the middle button supporting dragging, see also [https://forum.flightgear.org/viewtopic.php?f=71&t=19975]) | * {{PUI widget|slider}} (basically 3 buttons with the middle button supporting dragging, see also [https://forum.flightgear.org/viewtopic.php?f=71&t=19975]) | ||
* {{PUI widget|dial}} (see also [https://forum.flightgear.org/viewtopic.php?f=71&t=19975]) | * {{PUI widget|dial}} (see also [https://forum.flightgear.org/viewtopic.php?f=71&t=19975]) | ||
Line 46: | Line 53: | ||
The key ones really being the last 4 in that list (radio, slider, dial and combo/dropdown) | The key ones really being the last 4 in that list (radio, slider, dial and combo/dropdown) | ||
Most other widgets currently missing can be implemented by using a combination of these widgets, e.g. a ScrollArea with buttons can be used to implement any type of list (airportlist, waypointlist, property-browser etc) | Most other widgets currently missing can be implemented by using a combination of these widgets, e.g. a ScrollArea with buttons can be used to implement any type of list (airportlist, waypointlist, property-browser etc), just by adding event handling callbacks to each entry/button that invoke the corresponding bindings: | ||
<gallery> | |||
Pui-airport-list-widget-in-canvas.png|airport-list widget re-implemented using Canvas ScrollArea and Buttons arranged in a VBox layout | |||
Crude-canvas-property-parser.png|crude property-browser approximation using the pui2canvas parser (unmodified dialog), no layouts or sorting applied | |||
</gallery> | |||
This ScrollArea-based approach has the added benefit that improvements to the ScrollArea widget will automatically benefit widgets using it internally. | |||
However, once these basic widgets are supported, additional FlightGear/flight simulation specific widgets may be implemented sooner or later, e.g. for picking a frequency, heading/course etc (see [[UI_Unification#Widget_tags]]). | |||
== Widget.nas == | == Widget.nas == | ||
Line 74: | Line 84: | ||
== Part one == | == Part one == | ||
A new Canvas widget will have two parts to it. | |||
The first provides the background code and the APIs for that widget. The second defines the appearance of the widget, i.e. its style. | |||
The first part is a Nasal file in {{fg root file|path=Nasal/canvas/gui/widgets}}, e.g., . They must follow the basic structure of the example below, replacing | The first part is a Nasal file in {{fg root file|path=Nasal/canvas/gui/widgets}}, e.g., . They must follow the basic structure of the example below, replacing | ||
{{Canvas Widget Template|name=myWidget}} | {{Canvas Widget Template|name=myWidget}} | ||
Line 114: | Line 128: | ||
== Examples == | == Examples == | ||
{{Stub}} | |||
=== Implementing a hrule widget === | === Implementing a hrule widget === | ||
Line 164: | Line 180: | ||
* <code>scrollTo()</code> | * <code>scrollTo()</code> | ||
* ... | * ... | ||
=== Implementing a graph widget === | |||
{{See also|Canvas_Snippets#Adding_OpenVG_Paths}} | |||
[[File:Openvg-via-canvas.png|thumb]] | |||
{{Canvas Widget Template|parent=Widget|name=graph}} | |||
=== Map === | |||
{{Main article|MapStructure}} | |||
{{WIP}} | |||
[[File:MapStructure-map-widget.png|thumb|MapStructure Canvas widget prototyping]] | |||
Assuming, we have access to a root group, the most minimal snippet of code to display a layered MapStructure map is the following: | |||
<syntaxhighlight lang="nasal"> | |||
var TestMap = root.createChild("map"); | |||
TestMap.setController("Aircraft position"); | |||
TestMap.setRange(25); | |||
TestMap.setTranslation(width, height); | |||
var r = func(name,vis=1,zindex=nil) return caller(0)[0]; | |||
foreach(var type; [r('VOR'),r('APT'), r('APS') ] ) | |||
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,); | |||
</syntaxhighlight> | |||
Next, we need to wrap this in a Widget.nas child class: | |||
Everything that we'd like to be able to customize at the widget level, needs to be exposed via a corresponding method added to the subclass inheriting from Widget.nas, for example: | |||
* setController() | |||
* setRange() | |||
* setLayers() | |||
* ... | |||
To approximate the appearance of the legacy [[Map]] dialog, we will be using a hbox layout with two columns, with the left column containing a vbox layout with checkboxes added for each layer to control visibility of the layer, and the right hbox cell containing the actual MapStructure map: | |||
Once we are finished, we can check if the widget is working properly by adding a handful of identical widgets to the same dialog, all of which should work independently, i.e. having their own checkbox/range widgets to control the corresponding map widget. | |||
== References == | |||
{{Appendix}} | |||
[[Category:Canvas GUI]] | [[Category:Canvas GUI]] |