Linux build: Mouse trap.

[OoMrFlibble]

Testing with the appimage on LinuxMint 22.3 xfce4, and AnduinOS:

If one loads the game as windowed (default), then hits F12 to go full-screen, and again to go back to windowed, the mouse sometimes gets 'trapped'.

If one has existent other windows, and Alt-tab 'might' save the day. YMMV depending on desktop environment.

This is worse under XFCE4 than it is on AnduinOS. With the latter, the mouse is not often initially trapped, but gets 'snagged' if one tries to resize the window. With the former, the mouse is often irreversibly stuck in the game window, making it impossible to operate debug console if it's in the same workspace.

On AnduinOS, even if leaving the game windowed, resizing it is 'hectic'.

Workspace switcher still functions on XFCE. So it's still possible to use ctrl-alt-(left right) to achieve stuff.

This is with the most recent appimage in a fresh folder. Same happens when testing with my usual OXP heap.

[OoMrFlibble]

Further tests:

Debian 13.3.0 Gnome, KDE & LXDE. LinuxMint 22.3 Cinnamon.
Mouse ineffective outside game window. Partially Alt-tab escapable.

Debian 13.3.0 LXQT
Mouse ineffective outside game window. Not Alt-tab escapable.

LinuxMint 22.3 Mate
Mouse ineffective outside game window. Fully Alt-tab escapable except for operations on game window.

TrixiePup64 260103 (wayland)
Mouse ineffective outside game window. Fully Alt-tab escapable.

[brianread108]

I can confim this on Linux Mint 22.3, although cannot confirm exactly on which of the recent builds this changed.

[mcarans]

This also occurs on a standard build. Is the behaviour the same in Windows @AnotherCommander?

It seems to be standard SDL 1.2 behaviour. A fix that worked for me is to add the line below here:
SDL_WM_GrabInput(SDL_GRAB_OFF);

[AnotherCommander]

This also occurs on a standard build. Is the behaviour the same in Windows @AnotherCommander?

No. In Windows almost all of the application's window management happens via native Windows API and not SDL.

In case it can be of help, seeing that you have a potential fix available already, check out the method - (void) grabMouseInsideGameWindow:(BOOL) value. This controls when the game window will grab the mouse and when it will not. There is a Windows and a Linux variant of this method, with the Linux variant currently being this:

- (void) grabMouseInsideGameWindow:(BOOL) value
{
	// do nothing
}

You could try adjusting it with your fix so that no further changes would be needed in the core code. Check the Windows equivalent for more info on how the logic of this method is expected to work.

[mcarans]

@OoMrFlibble @brianread108 Please try the version with fix here and let me know how it goes:
https://github.com/mcarans/oolite/actions/runs/22598233891

[OoMrFlibble]

@OoMrFlibble @brianread108 Please try the version with fix here and let me know how it goes: https://github.com/mcarans/oolite/actions/runs/22598233891

That seems to have sorted the Mouse trap.

[AnotherCommander]

For anyone with a multi monitor setup on Linux, you may also want to check that when full screen is enabled and mouse control is on, the mouse does get grabbed. Otherwise it just exits the window while trying to control the ship and stops providing inputs to it, which we probably don't want. This is the reason the setting "grab-mouse-on-mouse-control" exists.

[OoMrFlibble]

Forgot we had mouse control! I never did get the hang of that.

Maybe only trap the mouse when mouse control is enabled, which at least with this test version is only possible whilst in full-screen, it disengages when switching to windowed, potentially limiting the scope of any 'trap'.

I'll dig out another monitor in a bit.

[AnotherCommander]

Maybe only trap the mouse when mouse control is enabled, which at least with this test version is only possible whilst in full-screen, it disengages when switching to windowed, potentially limiting the scope of any 'trap'.

Right now there is this in PlayerEntityControls.m, line 1061,pollApplicationControls method:

[... if mouse control conditions are satisfied ...]
 #if OOLITE_GNUSTEP
	[gameView resetMouse];
	if ([[NSUserDefaults standardUserDefaults] boolForKey:@"grab-mouse-on-mouse-control"])
	{
		[gameView grabMouseInsideGameWindow:YES];
	}
#endif
[...]

It enables mouse grab only if the user explicitly requests it by means of the "grab-mouse-on-mouse-control" key in OoliteDefaults.plist. This is done because it is considered bad form for applications to take exclusive control of the mouse at any time, but if it is decided that in full screen it is ok to do so, then just removing the if statement and leaving the grabMouseInsideGameWindow call in will do what you describe.

Not sure if this has been implemented in Mike's code yet, at the time of writing this I expect it to be Windows-only.

[AnotherCommander]

Oh and one more thing. I just remembered that we also have the user defaults key mouse-control-in-windowed-mode, which was mainly used for debugging purposes. This is a reason why we may want to keep grab-mouse-on-mouse-control around: debugging when in windowed mode.

[Zireael07]

Maybe only trap the mouse when mouse control is enabled, which at least with this test version is only possible whilst in full-screen, it disengages when switching to windowed, potentially limiting the scope of any 'trap'.

IMO this is a good idea

[mcarans]

I tried adding this to the Linux function, but it didn't seem to make any difference:

- (void) grabMouseInsideGameWindow:(BOOL) value
{
	if(value)
	{
		SDL_WM_GrabInput(SDL_GRAB_ON);
	}
	else {
		SDL_WM_GrabInput(SDL_GRAB_OFF);
	}
}

I tried the above with setting SDL_WM_GrabInput(SDL_GRAB_OFF); wherever stuff is done with the screen, but still no difference.

The behaviour seems to be that in full screen, regardless of whether I set SDL_WM_GrabInput(SDL_GRAB_OFF);, the mouse is grabbed and the normal mouse pointer disappears. It doesn't seem possible to do Shift M to do mouse control in window mode - it looks like that is intentional in the code.

What is the behaviour that is desired?

[AnotherCommander]

What is the behaviour that is desired?

This is how it works on Windows: The mouse is never trapped unless specifically requested via the grab-mouse-on-mouse-control defaults key. This is so because as I mentioned in a reply earlier it is considered bad form for apps to steal the mouse cursor from the rest of the OS. Even when in full screen, grabbing the mouse cursor can be problematic if running on a multi-monitor setup.

If the above key is set to true/YES/etc., then the mouse is trapped inside the window whenever mouse control is on.

Shift-M works in fullscreen only by default. To make it work also for in windowed mode, you set the defaults key mouse-control-in-windowed-mode to true/YES/etc.

I think that's about it.

[mcarans]

I have tested and I think on Linux or maybe specifically Wayland, the window manager can override whatever the application does, so fullscreen seems to grab the mouse even if I set SDL_WM_GrabInput(SDL_GRAB_OFF); after every SDL_SetVideoMode call. The only time SDL_WM_GrabInput(SDL_GRAB_OFF); does anything is in window mode - specifically when going from fullscreen to window where grab stays on unless explicitly disabled. Hence, I don't think it's possible to replicate the Windows behaviour in Linux.

[OoMrFlibble]

I think on Linux or maybe specifically Wayland, the window manager can override whatever the application does, so fullscreen seems to grab the mouse even if I set SDL_WM_GrabInput(SDL_GRAB_OFF); after every SDL_SetVideoMode call.#

Certainly with your last couple of versions, I was able to trivially alt-tab (given another open window) to get mouse control back outside Oolite, so that would at least be document-able, if unavoidable.