4,400
edits
Canvas widgets: Difference between revisions
Jump to navigation
Jump to search
m
Link to special directory articles
(→Nasal) |
m (Link to special directory articles) |
||
| Line 40: | Line 40: | ||
== Status (08/2012) == | == Status (08/2012) == | ||
As of 08/2012, the event handling system is being worked on. Once that is completed, it should be possible to reimplement a dialog/xml parser which maps the various supported widgets ($FG_ROOT/Docs/README.gui) to new canvas widgets (button, checkbox, label, textbox etc), so that these can be implemented step by step in order to phase out PUI usage (which will also require re-implementing the current layout manager in Nasal). | As of 08/2012, the event handling system is being worked on. Once that is completed, it should be possible to reimplement a dialog/xml parser which maps the various supported widgets ([[$FG_ROOT]]/Docs/README.gui) to new canvas widgets (button, checkbox, label, textbox etc), so that these can be implemented step by step in order to phase out PUI usage (which will also require re-implementing the current layout manager in Nasal). | ||
* '''TheTom''': (30/07/2012) I have now pushed some updates to my branch. It is now possible to create windows (texture rectangles) with just using the property tree and place a canvas texture onto it. Mouse events are passed to the active window (=the window the cursor is hovering over, or for dragging the window where the drag gesture started) and can be handled from Nasal or anything else that has access to the property tree. | * '''TheTom''': (30/07/2012) I have now pushed some updates to my branch. It is now possible to create windows (texture rectangles) with just using the property tree and place a canvas texture onto it. Mouse events are passed to the active window (=the window the cursor is hovering over, or for dragging the window where the drag gesture started) and can be handled from Nasal or anything else that has access to the property tree. | ||
| Line 84: | Line 84: | ||
==== Nasal ==== | ==== Nasal ==== | ||
* '''[[Canvas_Widgets#Widget_Declaration_via_SVG|Extend gui.nas to support loading widgets from SVG files]]''': We want to be able to load widgets from SVG files and link them to Nasal code in $FG_ROOT/Nasal/widgets - for example: $FG_ROOT/Nasal/widgets/button.nas {{Not done}} | * '''[[Canvas_Widgets#Widget_Declaration_via_SVG|Extend gui.nas to support loading widgets from SVG files]]''': We want to be able to load widgets from SVG files and link them to Nasal code in [[$FG_ROOT]]/Nasal/widgets - for example: [[$FG_ROOT]]/Nasal/widgets/button.nas {{Not done}} | ||
* '''[[Canvas_Widgets#Nasal_requirements|Implement Widgets]]''': {{Not done}} | * '''[[Canvas_Widgets#Nasal_requirements|Implement Widgets]]''': {{Not done}} | ||
* '''[http://wiki.flightgear.org/Canvas_Widgets#Layout_Management_.28_.28Not_done.29.29 Layout Handling]''': {{Not done}} | * '''[http://wiki.flightgear.org/Canvas_Widgets#Layout_Management_.28_.28Not_done.29.29 Layout Handling]''': {{Not done}} | ||
| Line 271: | Line 271: | ||
Also, we are currently able to reload the GUI in FlightGear, we will want to retain this feature. But once we start implementing widgets in Nasal, we won't just want to reload the GUI XML files, but also the widget modules from $FG_ROOT/Nasal/widgets, so that widgets can be easily developed and tested, without having to restart FG. | Also, we are currently able to reload the GUI in FlightGear, we will want to retain this feature. But once we start implementing widgets in Nasal, we won't just want to reload the GUI XML files, but also the widget modules from [[$FG_ROOT]]/Nasal/widgets, so that widgets can be easily developed and tested, without having to restart FG. | ||
This can be implemented in Nasal space, there's no need to modify the Nasal sub modules code for this - however, we also need to ensure that there's a sane way to terminate all active widgets, i.e. by stopping all running instances. This will also be important to handle simulator reinit/reset. | This can be implemented in Nasal space, there's no need to modify the Nasal sub modules code for this - however, we also need to ensure that there's a sane way to terminate all active widgets, i.e. by stopping all running instances. This will also be important to handle simulator reinit/reset. | ||
| Line 280: | Line 280: | ||
{{Feedback}} | {{Feedback}} | ||
* [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.gui $FG_ROOT/Docs/README.gui] | * [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.gui [[$FG_ROOT]]/Docs/README.gui] | ||
* [http://gitorious.org/fg/flightgear/blobs/next/src/GUI/FGPUIDialog.cxx#line710 Supported Widget Types] | * [http://gitorious.org/fg/flightgear/blobs/next/src/GUI/FGPUIDialog.cxx#line710 Supported Widget Types] | ||
| Line 293: | Line 293: | ||
* 2D panels {{Pending}} | * 2D panels {{Pending}} | ||
All of these will require an XML parser that turns the existing structure into canvas nodes. The existing SVG parser is purely implemented in scripting space (see svg.nas) using the XML parser in $FG_ROOT/Nasal/io.nas | All of these will require an XML parser that turns the existing structure into canvas nodes. The existing SVG parser is purely implemented in scripting space (see svg.nas) using the XML parser in [[$FG_ROOT]]/Nasal/io.nas | ||
Given that all three file formats are PropertyList-encoded XML files, it should be possible to come up with a "Xml2Canvas" interface class which implements the XML parser and the Canvas interfaces. That will ensure a maximum degree of code reuse. | Given that all three file formats are PropertyList-encoded XML files, it should be possible to come up with a "Xml2Canvas" interface class which implements the XML parser and the Canvas interfaces. That will ensure a maximum degree of code reuse. | ||
| Line 318: | Line 318: | ||
Afterwards the getMinSize method is used to calculated the available space and stretch widgets if required. | Afterwards the getMinSize method is used to calculated the available space and stretch widgets if required. | ||
To ensure that the core widgets in $FG_ROOT/Nasal/widgets cannot be accidently invalidated by users, the widget namespace/hash will be made immutable using globals.nas magic. | To ensure that the core widgets in [[$FG_ROOT]]/Nasal/widgets cannot be accidently invalidated by users, the widget namespace/hash will be made immutable using globals.nas magic. | ||
=== Building Widgets at the C++ Level === | === Building Widgets at the C++ Level === | ||
| Line 371: | Line 371: | ||
<syntaxhighlight lang="php"> | <syntaxhighlight lang="php"> | ||
m.root = m.canvas.createGroup(); | m.root = m.canvas.createGroup(); | ||
canvas.parsesvg(m.root, "$FG_ROOT/gui/svg/button.svg"); | canvas.parsesvg(m.root, "[[$FG_ROOT]]/gui/svg/button.svg"); | ||
var label = m.root.getElementById("label"); | var label = m.root.getElementById("label"); | ||
label.setText("Widget loaded from SVG"); | label.setText("Widget loaded from SVG"); | ||
| Line 416: | Line 416: | ||
=== Layout Management ({{Not done}}) === | === Layout Management ({{Not done}}) === | ||
* [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.layout $FG_ROOT/Docs/README.layout] | * [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.layout [[$FG_ROOT]]/Docs/README.layout] | ||
Have you thought where the layout logic will work in this scheme? Right now it's all in C++, and a layout manager might make sense for the canvas in general (think about laying out text or elements on an MFD or EICAS), possibly even in C++, but again you maybe already have a solution. | Have you thought where the layout logic will work in this scheme? Right now it's all in C++, and a layout manager might make sense for the canvas in general (think about laying out text or elements on an MFD or EICAS), possibly even in C++, but again you maybe already have a solution. | ||