Robertfm wrote in Thu Jul 09, 2020 8:23 pm:wkitty42 wrote in Thu Jul 09, 2020 8:02 pm:robert, it 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...
So if it can't go to another monitor and can't be reduced in size then as an addon to a non glass cockpit it can't be used because you take up almost the entire view.
Currently, this isn't supported - but it's a long-standing idea, even the implementer of the Canvas system originally mentioned this on the devel list:
https://www.mail-archive.com/flightgear ... 37907.html
Thomas Geymayer wrote:Support multiple views/windows:
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.
Mathias Fröhlich has been wanting to support multiple windows for a single graphics context for a long time, and he foresaw the concrete use-case long before the Canvas system took shape:
https://sourceforge.net/p/flightgear/ma ... /19718354/
Mathias Fröhlich wrote: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.
I would like to be able to still use displays and screens for some parts
of the viewer. So while this would be very good to have and probably better
for the end performance where you are heading to, we should have that as an
addition to the way we can now redirect views to different displays and
screens.
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.
I have an animation that I call rendertexture, where you can replace a
texture on a subobject with such a rtt camera. Then specify a usual
scenegraph to render to that texture and voila. I believe that I could finish
that in a few days - depending on the weather here
The idea is to make mfd instruments with usual scenegraphs and pin that on an
object ...
More recently some contributors have begun toying with CompositeViewer support again: http://wiki.flightgear.org/CompositeViewer_Support
And James specifically said the following a couple of weeks ago about the existing XML-driven WindowBuilder (which is currently not yet available/accessible at runtime):
https://sourceforge.net/p/flightgear/ma ... /37058207/
James Turner wrote: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.
From a Canvas standpoint, it would make sense to implement this as a dedicated Canvas placement (see below for details).
In other words, if you care about such features, please do file a feature request so that related comments/patches can be tracked properly.
http://wiki.flightgear.org/Canvas_Popout_Windows
http://wiki.flightgear.org/Canvas_Devel ... ve_Windows
PS: A Canvas placement is roughly 100 lines of boilerplate code: http://wiki.flightgear.org/Canvas_Devel ... Placements And the WindowBuilder method to be invoked is already building windows using the property tree structure: https://sourceforge.net/p/flightgear/fl ... r.cxx#l291 The existing way of using the windowBuilder can be seen here: https://sourceforge.net/p/flightgear/fl ... y.cxx#l796 - however, a non-scene window (GUI) can be dealt with more easily: https://sourceforge.net/p/flightgear/fl ... .cxx#l1048