|
|
| Line 48: |
Line 48: |
| * Support implementing GUI widgets using Canvas/Nasa (currently being discussed) | | * Support implementing GUI widgets using Canvas/Nasa (currently being discussed) |
| * Static image files should be handled like any other element on the canvas. Only instead of specifying a path you'll have to set the file system path to an image which will be loaded with osg. | | * Static image files should be handled like any other element on the canvas. Only instead of specifying a path you'll have to set the file system path to an image which will be loaded with osg. |
|
| |
| === Todo:GUI (06/2012) ===
| |
|
| |
| This section lists a bunch of ideas related to supporting Canvas textures for GUI drawing needs, i.e. to render Canvases as textures, but also to increasingly implement parts of the GUI (such as custom widgets) using interactive Canvases with scripted callbacks, the idea is to work around existing GUI/PUI shortcomings by using Canvases to implement custom styles and widgets.
| |
|
| |
|
| |
| '''TheTom''': "I haven't done anything with PUI yet, but I think it shouldn't be too hard to place a texture onto a widget."
| |
|
| |
| : '''Hooray''': Agreed, you definitely already completed the hard part (i.e. the canvas subsystem). PLIB's PUI widgets are all derived from "puObject": http://plib.sourceforge.net/pui/index.html#puObject And James' Map dialog demonstrates how to create a new PUI widget and keeping everything OSG compatible: https://gitorious.org/fg/flightgear/blobs/next/src/GUI/MapWidget.cxx His code is an excellent example of code that could be significantly simplified if we could use your canvas instead - because then most of the stuff could be done in Nasal space instead.
| |
|
| |
| :: '''Hooray''': This just occurred to me in another discussion: Once your canvas textures can be used by PUI, we could not just display dynamically created textures using Nasal, but we could even create our own custom GUI/PUI-widgets using your canvas system. I shortly mentioned this here: http://flightgear.org/forums/viewtopic.php?f=49&p=160415#p160410 This is because James mentioned a while ago that he was going to redo the GUI in FlightGear, but he wanted to start out by absorbing PLIB/PUI into SimGear, so that it can be ported to OSG, so that multiscreen/multi-window setups are supported, and so that custom widgets could be added (tabs, treeviews etc). Basically, this could be dealt with like a traditional/static texture, so that new widgets could be created from Nasal using your Canvas properties. But obviously some GUI-specific update/notification callbacks would need to be registered for the canvas texture, so that PUI may handle certain GUI events (key presses, mouse actions). Looking at the docs, this would require a puObject-wrapper for "active" textures that may respond to GUI events: http://plib.sourceforge.net/pui/index.html
| |
|
| |
| Ideas so far:
| |
|
| |
| * implement a new "puCanvas" 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)
| |
| * 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
| |
| * next, custom GUI widgets could be instantiated by using widget type "canvas" and some widget-specific identifier such as "button", "checkbox" etc
| |
| * 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
| |
| * in the beginning, new Nasal widgets could be added to $FG_ROOT/Nasal/canvas_widgets to keep things simple
| |
| * during instantiation, the Nasal callback would then just need to invoke a constructor like canvas_widgets.checkbox.new() to control the canvas widget[/list]
| |
|
| |
| 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.
| |
|
| |
|
| |
| For MFD-type displays with touchscreen support, but also for fully interactive canvas-based PUI widgets, the following issues exist currently (06/2012):
| |
| * '''TheTom''': "I already tried to build some GUI for touchscreen based MFDs but whats currently missing is the possibility to register picking callbacks from Nasal and also to get the location of the click (pick animation). If we would be able to get the click coordinates in the canvas coordinate system and also a global key callback (with the possibility to grab all the keyboard inputs for text input) it should be possible to completely build a GUI with Nasal."
| |
| * '''TheTom''': "So what currently seems to be missing is the possibility to register callbacks for mouse and keyboard input from Nasal and to place the canvas somehow in screenspace (for a first implementation inside a puObject). Everything else (apart from displaying raster images) should be already possible."
| |
| * '''TheTom''': "Maybe it would be good not to create a canvas for each widget but instead for each window. I don't know what the performance impact is with using many cameras and lots of separate textures, but probably the GPU won't like it very much."
| |
|
| |
|
| === Todo: fgCanvas (standalone canvas rendering analogous to fgpanel) === | | === Todo: fgCanvas (standalone canvas rendering analogous to fgpanel) === |