Fix app shortcuts in fullscreen

[mgi]

Hi,

Here is a patch that I have for some times now into my init.el. It is based on a patch I found here: ch11ng/exwm#786.

What does it fix?

When using an application that you can toggle to fullscreen (for instance mpv with f shortcut), you are not able to use any of the application shortcuts after that (even untoggling fullscreen). This patch fixes this.

Thanks.

[Stebalien]

Sorry for the long delay, I'm unfamiliar with this code so I had to do some research.

From what I can tell, the current behavior is intentional. That is:

1. Entering full-screen mode forwards all key presses to the application.
2. Exiting full-screen mode re-grabs the keyboard if we're in line-mode.

See:

exwm/exwm-layout.el

Lines 244 to 245 in 770520c

	(when (eq 'line-mode exwm--selected-input-mode)
	(exwm-input--grab-keyboard exwm--id))))

There's actually no need to release the keyboard in char-mode as it shouldn't be grabbed anyways.

---

On the other hand, I can also see the use in keeping the keyboard grabbed when in full-screen mode. I'd be open to adding an option for this (ideally a buffer-local one so it can be set per-window via the exwm-manage-finish-hook).

[medranocalvo]

I think we should reconsider whether EXWM should respect user bindings in fullscreen mode. For example, I remember using Firefox full-screen when I had that tiny laptop (it would hide its menubar). In that situation I would like, say, my substitution keys to continue working. On the other hand, if I launch a game, I would probably like it to have full control of input. We have char-mode for that!

I would argue that we should change the default behaviour of fullscreen to respect the input mode of the EXWM-mode buffer, and let users use the usual keys, or as well as exwm-configuration & hooks, to switch to char-mode.

I don't usually use fullscreen, so I'm not sure whether I'm missing anything.

[Stebalien]

I would argue that we should change the default behaviour of fullscreen to respect the input mode of the EXWM-mode buffer, and let users use the usual keys, or as well as exwm-configuration & hooks, to switch to char-mode.

Hm. Yeah, that seems reasonable. I wonder if there's some way to detect "game mode". Maybe when an application tries to grab the keyboard? Maybe we don't need to do anything because the application will grab the keyboard?

[medranocalvo]

I would argue that we should change the default behaviour of fullscreen to respect the input mode of the EXWM-mode buffer, and let users use the usual keys, or as well as exwm-configuration & hooks, to switch to char-mode.

Hm. Yeah, that seems reasonable. I wonder if there's some way to detect "game mode". Maybe when an application tries to grab the keyboard? Maybe we don't need to do anything because the application will grab the keyboard?

Could be, I don't know. I looked briefly at SDL; I didn't see anything that could differentiate their fullscreen windows from other's (looked at src/video & src/video/x11/). They do select a lot of events in SetupWindowInput https://github.com/libsdl-org/SDL/blob/main/src/video/x11/SDL_x11window.c#L452, but I believe they do so independently of whether the window is fullscreen or not.

The change here should be reduced to simply not force char-mode. I also think that @lucasgruss got it right: we should delete-other-windows when switching to fullscreen and restore the previows window configuration when quitting.

We might be opening a can of worms here.

[Stebalien]

I also think that @lucasgruss got it right: we should delete-other-windows when switching to fullscreen and restore the previows window configuration when quitting.

Hm. Any reason to delete other windows?

[medranocalvo]

I think that the point is to adapt the window configuration to the visual appearance: one fullscreen X window ~ one Emacs window. This way commands like other-window error or do the right thing, but never select an occluded window in the workspace of the fullscreen window. I thought it was nifty, but haven't thought really hard about it.

In case there's a misunderstanding: no X windows are destroyed; the Emacs window configuration is changed to contain a single window (that of the exwm-mode buffer we are fullscreening), then this window configuration is restored.

[medranocalvo]

Pushed a commit implementing the proposal, please have a look.

@mgi, please test the change and report back. (I had to push to your master branch to update this pull request. I hope it's OK.)

[Stebalien]

Hm. I think a better approach would be to exit full-screen mode if the window configuration changes.

[medranocalvo]

Hm. I think a better approach would be to exit full-screen mode if the window configuration changes.

Sounds reasonable, but it might lead to false positives. For example, a multi-line message printed to the echo area will cause a window configuration change; I don't think we'd want that to cause fullscreen exit. On the other hand if I cause the resize through a command I'd want it. Maybe we can find a way to ignore resizes caused by the echo area growing but, are there other such cases? window-configuration-change-hook triggers when "...at least one window has been added, deleted or changed its buffer or its total or body size...".

[Stebalien]

Maybe we should (temporarily) redirect/suppress echo area messages (e.g., with set-message-functions)? Ideally they'd display above the full-screen window, but that's getting quite complex.

[mgi]

medranocalvo ***@***.***> writes:

Pushed a commit implementing the proposal, please have a look. @mgi, please test the change and report back. (I had to push to your master branch to update this pull request. I hope it's OK.)

Sorry for this late reply. I have just tested your patch lightly and it works as expected. I think it is a good idea to remove any "cleverness" from fullscreen switching and let the user decide. Tell me if you need me to test anything else. Thanks. -- Manuel Giraud

[mgi]

Hi, Don't you think that this patch (the one from medranocalvo) could go in now? I'm using it for months without any issues. -- Manuel Giraud