#1941 Linux: mouse click-zone offset low after return from full-screen

[Jim (JR)]

Issue:
If the window size is maximized by clicking the "+" in the upper right corner, is then toggled to full-screen, and then returned to maximized window mode, the mouse click-zone is offset low.

Steps to reproduce:
1. Install FG 2016.4.4 using the .deb package from the private PPA (this may not be necessary but is how I did it)
2. Launch and configure:
a. Starting airport: LSZH
b. Runway: 16
c. Aircraft: Cessna 172p
d. Time-of-day: Afternoon (it's easier to see if it's not dark!)
e. Season: Summer
f. Additional "official" hangar aircraft installed
g. Terrasync enabled
3. Select "Run" and allow sim to load. Sim should start in a non-maximized window
4. Maximize the window by clicking on the "+" in the upper right hand corner
5. Move the mouse to varous control features. (e.g. knobs, switches, etc.), and note where the mouse cursor becomes a two-headed control cursor.
6. Open a dialog with selectable choices, (e.g. View => Rendering Options, etc.) Attempt to click on a check-box and note where the effect takes place.

Expected Result:
The "active" control point for the mouse is directly at or upon the item being controlled.
Actual Result:
As expected.

1. Toggle into full-screen by selecting Shift=>F10 Verify that the active control point is directly at or upon the item being controlled as noted above.
2. Toggle back out of full screen back into the "maximized" screen by selecting Shift=>F10 again
3. As noted above in steps 5 and 6, attempt to move the mouse to various control points and/or open a dialog with check-boxes and attempt to control the check-boxes with the mouse.

Expected Result:
The "active" control point for the mouse is directy at or upon the item being controlled as noted above.
Actual Result:
After returning from full-screen mode to maximized window mode, the location where the active control point is located has been shifted down by about 1-2 cm physical distance on the screen.

Examples:
1. Attempting to activate a cocpit control knob on an instrument. Normally the mouse cursor is placed directly upon the knob. In this case the cursor has to be moved below the knob by one or two cm to activate the knob.
2. Attempting to select a check-box in a dialog: Normally the mouse cursor is pointed directly into the check-box to select it, In this case the mouse cursor has to be pointed to the check-box directly below it to select a check box. To close the window, the cursor has to be placed about 1-2 cm below the "close" button to select it.

This behavior can be reset by un-maximizing the window by selecting the "+" in the upper right-hand corner and then re-maximizing the window by selecting the "+" again.

Note that this effect does not occur when switching between a non-maximized window and full-screen mode, even if the windows size is adjusted to be larger or smaller than the default non-maximized size.

[James Turner]

This is quite likely a bug in our underlying graphics library (OpenSceneGraph), I'm not sure we have control over the maximize / fullscreen interactions. It would be interesting to know if the issue also occurs on Windows; if it does it's likely in our code and we can fix. If it doesn't, it's probably the Linux-specific pieces of OSG. These are not directly under our control, but we can make a patch. Hoewever, the expertise needs to fix such bugs is quite specific (for example, I wouldn't know where to start).

Oh, this would also be worth testing with different window-managers / desktops on Linux I guess, since maximise behaviour is something the window-manager has a lot of control over.

[Jim (JR)]

James, If anyone would know, you would!

To answer these questions, I'm going to build out a throw-away install on a small SSD that I can just plug into an eSATA port and boot.

It will contain three installs of Mint, Cinnamon, Mate and KDE. Since Cinnamon and Mate are both forks of Gnome, (afaik), I want to include KDE.
I want to test both with, and without, the proprietary NVIDIA graphics drivers.
I also want to test under Windows on both my laptop which has (afaik) imbedded Intel graphics and my test box with the NVIDIA graphics card.

This might take a second or two to build out (laughing!) before I can begin testing. Since I want to gain the maximum amount of traction prossible, and give you the maximum amount if quality information possible, if there are things you'd particularly like me to do/look-for, please let me know.

You can either e-mail me direct if you wish, PM me on the fora, or notify me somehow if you reply here since SourceForge does not auto-notify if someone adds something here.

Thanks for all your help!

Jim (JR)

[John F]

I also noticed this behavior a while ago here on Debian with Openbox.
As you mentioned the workaround for now is to de-maximize and then to maximize again.

Edit:
It is not only in the 3D-Cockpit but the buttons in the UI are affected too.

[xDraconian]

Unable to reproduce the reported issue with 2018.3.1 build.
Closing ticket.