Canvas popout windows
| This article is a stub. You can help the wiki by expanding it. |
|
Good thing to have!!! Just still support graphics context on different screens/displays too ...[1] — Mathias Fröhlich
|
|
|
|
What we just need is the ability to still redirect some windows to an other display/screen.
What would be good to have is the specify a completely different scenegraph in some subcameras. I think of having panel like instruments on an additional screen/display for example.[2] — Mathias Fröhlich
|
|
| Started in | - |
|---|---|
| Description | Support for multiple independent windows |
| Status | RFC |
 |
The FlightGear forum has a subforum related to: Canvas |
Motivation
Last updated: 04/2021
For the time being, GUI windows/dialogs are not "docked"... they live completely inside the current interface... in the future, though, having multiple windows will most likely be a thing... then you can, for instance, have multiple views of your craft...[3]
Some users have been wondering if it is possible for Canvas displays to be dragged to another monitor and/or be resized if they are not modeled in a particular plane. [4]
In other words, allow dialogs outside of the main window preventing the outside view from being partly obfuscated (which would be very welcome for the Property Browser dialog which can take a great chunk from the outside view)[5]
People have asked if there a way to undock windows so that they can -for example- keep the control panel view open outside the main FlightGear window [...] without using multiple physical monitors. [6] Being able to undock windows/dialogs would be nice addition. [7]
For example, devices like the FG1000 cannot be dragged to another monitor which is a shame.[8]
The idea of the FG 1000 is to basically use it to fly the plane using it rather than steam gauges. But we must be able to see outside the plane at the same time. It's the size of it that makes doing both impossible.[9]
The device has to stay within the FG window because it is part of FG... it is not an autonomous window that you can drag anywhere on your screen realestate... if you want to put it on another monitor, you have to make the FG window split across more than one monitor but even then, the FG1000 will still be in the FG window...[10]
one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. [11]
It would be useful if the UI can be trivially hosted as an OpenGL overlay *or* a pop-out window, to give people the flexibility to move the UI to a second screen.[12]
Would it be possible to make the Canvas Windows leave the FlightGear borderspace? Like in P3D, I can right click a window and click “Undock Window”, which then gives it its own system title bar and then I can put it on other monitors.
If added, this could make 2D panels via Canvas a lot of useful! I can have the sim on one screen, and a radio stack on another, for example, to easily switch radios. Or a lighting panel.[13]
What I guess you want here, is to start creating the kind of GPS Ui that would be found in GA aircraft - for example a Garmin GNS 480 series or the more modern equivalent. This could be done as as a Nasal add-on so it could added as a variant into many GA aircraft including the C172, and would give you all the route-manager features and display.
(It could also be a pop-out Canvas window)[14]
Background
|
|
The issue is how to get fgfs to open a separate window with its own view/camera setup?
For example, [...] to have Tower View AGL active in a separate window (perhaps on a multiplayer aircraft), while the main window shows the view from the user aircraft's cockpit.
Such a window will need its own CameraGroup; would it also need its own FGRenderer or would it share the one used by the main window?
It would be enough to just being able to have a separate window with an empty OSG state that can then be filled in by writing new Camera/view code.[15]
The scene root is a member of the Viewer. A slave camera -- whose own pose in the scene is either relative to the main camera or completely independent -- can be configured to render the main scene or a completely different scene graph. For example, the camera that does Canvas rendering is set up like that.[16]
Currently, the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views.[17]
Problem
currently not possible in FG, although OSG has the perfect tool for the job: CompositeViewer. Some info and past discussions on the topic can be found here CompositeViewer Support.
As mentioned, each view would require another CameraGroup, the problem is that currently the entire FG codebase assumes that the CameraGroup is a singleton. If you manage to solve that, it would just be a matter of defining some kind of configuration scheme for the new CameraGroups and instantiate them on startup (preferably on FGRenderer). You wouldn't have to deal with the internals of CameraGroup as the rendering pipeline of each view is managed by a Compositor.[18]
It's possible to do, but it's definitely not trivial. There are two showstoppers:[19]
- Canvas uses nested cameras, not viewer-level slave cameras. You can only assign another GraphicsContext (another window) to slave cameras as nested cameras inherit their GraphicsContext from the main viewer camera. I think Tim Moore mentioned somewhere that he had a patch to move Canvas to slave cameras [20]
- CameraGroup hasn't been thought out from the beginning to support dynamic creation of windows. At startup the property tree in /sim/rendering/camera-group is read and the specified windows/cameras are created. I guess supporting this would require some architectural changes to CameraGroup.
Another idea previously mentioned is to fix up WindowBuilder which can already do multiple windows? (with an XMl driven UI, though : that’s the part that is missing to make it useful at runtime), i.e. extending WindowBuidler to allow changes at runtime might be a better solution [...] because this will keep existing multi-window / multi-view setups working. [21]
Implementation
While cameras can be attached to the scene root (e.g., the cameras that render Canvas objects), the viewer's cameras are outside of the main scene graph.[22]
This can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.[23] 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.[24]
The default OSG model is that slave cameras are different views offset from a common viewpoint. [...] Because FG has its own view system we mostly treat the slaves as independent. I think that most other uses of cameras during rendering -- for example, render to texture cameras for effects -- are best handled by slave cameras with independent views as well. [25]
See also
- Howto:CameraGroup talks
- http://www.openscenegraph.org/index.php/documentation/guides/programming-guides/93-viewer-vs-compositeviewer
- http://www.openscenegraph.org/index.php/documentation/knowledge-base/92-views-and-viewers
- https://sudonull.com/post/1525-OpenSceneGraph-Manage-Windows-and-Display-Modes