Canvas widgets: Difference between revisions

Jump to navigation Jump to search

Canvas widgets (view source)

Revision as of 18:31, 9 May 2013

3,862 bytes removed ,  9 May 2013
→‎Reimplementing CanvasWindow without PUI dependency using osgGA (in progress) {{Pending}}: done
Line 152: Line 152:


We probably want to support Java-style Key listeners and Key bindings, so that widget-behavior can be easily implemented in Nasal space
We probably want to support Java-style Key listeners and Key bindings, so that widget-behavior can be easily implemented in Nasal space
=== Reimplementing CanvasWindow without PUI dependency using osgGA (in progress) {{Pending}} ===
Note: This is currently in progress, see [[Canvas Widgets#Status (08/2012)]].
{{Progressbar|50}}
* <del>The major thing is we need to switch away from the CanvasWidget approach we are using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class</del> {{Done}}
* That will get rid of the legacy (GLUT based) mouse event API that PUI uses, and mean we can support any mouse event supported by osgGA and osgViewer - mouse wheel, buttons and mouse-over. {{Pending}}
* Basically we only need to pass mouse/keyboard events and handle dragging/resizing and input focus/stacking order of multiple dialogs. {{Pending}}
* This is certainly where things need to start, then. I'd hope dragging and resizing can be mostly handled by the Nasal layer, the C++ only needs to keep the window and canvas texture in sync when a resize happens. {{Done}}
* <del>We should consider the way osgWidget gets events from osgGA as the 'correct' way. We want to be passing osgGA events around, not raw x,y values, and pretty much all of fg_os.hxx dates from support GLUT and OSG in a single codebase - which forces us to use a very crude API. If we use the real OSG events we get  lots of information about button index, event type and modifier state all encapsulated in a clean way.</del> {{Done}}
* On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb "visible thing that renders a texture". That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. {{Done}}
* Agreed - I was planning to dive into adapting the window on Tom's branch, with a C++ host for a canvas. Note that the canvas  currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable. (Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not) {{Pending}}
* I'd suggest starting with the current GUICamera code, and especially the osgWidget base class. In particular my goal is to be able to kill off fg_os.hxx in the near future, i.e to have all events being passed into the canvas as osgGA types, not the old GLUT interface of raw x/y floats.
* It should probably even be enough to use just one single camera for all windows. The big advantage we gain with render-to-texture is that by using a larger texture we can get better anti-aliasing. For rendering paths the stencil buffer is used so we only have pixel resolution which can be seen at non horizontal or vertical lines or curves.
* We could also use lazy rendering to only update the GUI texture if something changes. Normally dialogs should be pretty much static... {{Pending}}
* <del>The current window manager registers itself to the main viewer and subscribes on osgGA events, so the canvas has no dependencies on the old system.</del> {{Done}}
* What do you think about the current way of handling mouse events? It's also just passing x/y and some more values to the property tree, but we need to forward the values somehow.
* <del>Also I had to create a new event class (which uses most of the osgGA types) because the coordinates of the mouse where passed in the range [-1,1] which would make handling a bit more complicated...</del>


=== Nasal requirements  ===
=== Nasal requirements  ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/60058"

Navigation menu