Canvas popout windows: Difference between revisions
m (→Background: https://sourceforge.net/p/flightgear/mailman/message/36294049/) |
|||
Line 39: | Line 39: | ||
This can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/B681C32E-DFE4-4C59-BE44-61DB591BA334%40mac.com/#msg29592603</ref> | This can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/B681C32E-DFE4-4C59-BE44-61DB591BA334%40mac.com/#msg29592603</ref> | ||
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.<ref>https://sourceforge.net/p/flightgear/mailman/message/29609330/</ref> | 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.<ref>https://sourceforge.net/p/flightgear/mailman/message/29609330/</ref> | ||
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. <ref>https://sourceforge.net/p/flightgear/mailman/message/36295606/</ref> | |||
== See also == | == See also == |
Revision as of 17:42, 5 July 2020
The FlightGear forum has a subforum related to: Canvas |
This article is a stub. You can help the wiki by expanding it. |
Motivation
Some users have been wondering if it is possible that Canvas panels can be dragged to another monitor and or be resized if they are not modelled in a particular plane. [1]
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. [2]
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.[3]
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.[4]
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)[5]
Background
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.[6]
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.[7]
Problem
It's possible to do, but it's definitely not trivial. There are two showstoppers:[8]
- 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 [9]
- 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.
Implementation
This can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.[10] 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.[11]
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. [12]
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