|
|
| Line 76: |
Line 76: |
| * '''Own ideas''': Come up with a new idea or something that I have already mentioned somewhere else {{Feedback}} | | * '''Own ideas''': Come up with a new idea or something that I have already mentioned somewhere else {{Feedback}} |
| * Find more work I've currently forgotten about :) {{Feedback}} | | * Find more work I've currently forgotten about :) {{Feedback}} |
|
| |
| == The current PUI/CanvasWidget Implementation (finished) ==
| |
| {{Progressbar|100}}
| |
| * implement a new "WidgetCanvas" class to create a puObject which renders a canvas texture as a PUI widget and which invokes Nasal callbacks for GUI events (update,redraw,keyboard/mouse events) {{Done}}
| |
| * modify the [https://gitorious.org/fg/flightgear/blobs/next/src/GUI/FGPUIDialog.cxx#line708 FGPUIDialog::makeObject] helper such that a custom "canvas" widget is supported {{Done}}
| |
| * next, custom GUI widgets could be instantiated by using widget type "canvas" and some widget-specific identifier such as "button", "checkbox" etc {{Done}}
| |
| * whenever a new canvas widget is instantiated, a new canvas rendering context (RTT) could be created and a Nasal callback would be called to set up a GUI handler implemented in Nasal space for the corresponding canvas texture {{Done}}
| |
| * in the beginning, new Nasal widgets could be added to $FG_ROOT/Nasal/canvas_widgets to keep things simple {{Done}}
| |
| * during instantiation, the Nasal callback would then just need to invoke a constructor like canvas_widgets.checkbox.new() to control the canvas widget {{Done}}
| |
|
| |
| Basically, this would allow us to move more and more GUI code out of C++ space into Canvas/Nasal space, so that parts of the GUI could be slowly re-implemented by non-C++ coders, i.e. to implement custom styles or custom widgets using Canvas-textures - the rendering backend would be increasingly unified.
| |
|
| |
| We could probably come up with a list of things missing by taking a look at existing custom PUI widgets (such as James' Map dialog or the route manager's waypoint list dialog, or the property browser) - basically, we only need to expose the PUI callbacks, such that that are forwarded to Nasal callbacks - and then, the whole GUI could be scripted using your Canvas system and Nasal.
| |
|
| |
|
| == Fully Canvas based implementation (in progress as of 08/2012) == | | == Fully Canvas based implementation (in progress as of 08/2012) == |