Fix floating window width increase when moving to workspace

[daviwil]

Hi @ch11ng!

I noticed this issue when writing some custom window pinning logic for floating windows so that I can have a pinned mpv player. When you move a floating window to another workspace, its new frame has a width 1 pixel larger than on the previous workspace. If you keep moving the window between workspaces (for instance, when it's pinned), it gradually starts to get larger.

The fix I'm proposing is to subtract 1 from (frame-pixel-width old-frame) when doing the move operation so that this pixel increase is cancelled out. I've tested this when moving both tiled and floating windows and it seems to work fine in both cases. However, you might have a better idea for how to fix this so I'm definitely open to suggestions.

Side question: would you be interested in a PR to add pinned floating windows as a core feature to EXWM? Moving the pinned window after the workspace switch isn't the greatest user experience, it could be a lot smoother if was built in to the workspace switching logic.

Thanks!

[ch11ng]

The size of some programs may not be consistent after they are moved to another workspace.
But as I tried it appears MPV (version 0.29.1) doesn't have this problem.

The 1-pixel offset in width is likely program-specific; some might have more, and it might also be an offset in height. The problem lies in the fact that we can't resize Emacs frames precisely according to which the size of floating X windows is calculated.

Side question: would you be interested in a PR to add pinned floating windows as a core feature to EXWM? Moving the pinned window after the workspace switch isn't the greatest user experience, it could be a lot smoother if was built in to the workspace switching logic.

We already have a similar feature for displaying an X window on all workspaces. There are some limitations though:

• _NET_WM_DESKTOP (the X11 property indicating on which workspace an X window should be placed) must be set to 0xffffffff on creation (you can still modify the buffer-local variable exwm--desktop to #xffffffff to make EXWM consider it 'pinned' though).
• Interacting with such X window would automatically switch to the workspace it was actually placed.

Depending on how well we can resize a floating X window after moving it to another workspace, this may be the best we can get for now.

[daviwil]

The size of some programs may not be consistent after they are moved to another workspace.
But as I tried it appears MPV (version 0.29.1) doesn't have this problem.

I'm experiencing it with mpv 0.30.0, but now I'm starting to wonder if DPI differences between machines would determine whether the problem actually appears. Since the size increase is something that may not be experienced by everyone, I now don't feel comfortable making the exact change in this PR.

I will experiment with setting exwm--desktop to see if I get better results for a pinned window experience despite the possible drawback you mentioned!

[daviwil]

OK, I just quickly tried exwm--desktop and it works much better than the hacky solution I came up with. I do notice that, like you said, focusing the mpv window causes EXWM to snap back to the original workspace where the window was opened. Do you think there's some work I could do to remove that limitation, or is it something that can't be done?

[daviwil]

Quick idea that I haven't fully thought through: if we added an exwm-workspace-before-switch-hook which was called just before the workspace changes, it it possible a hook could use exwm-workspace--set-desktop to switch the exwm--desktop of the "pinned" window to the destination workspace? Probably would have to add an optional desktop parameter to exwm-workspace--set-desktop in that case.

I guess what I don't know is why it's currently necessary to create a new frame to host the window on a new workspace when it's clear that setting exwm--desktop to #xffffffff allows the existing frame to be maintained.

[ch11ng]

Do you think there's some work I could do to remove that limitation, or is it something that can't be done?

This is by design. In EXWM a floating X window always remembers which workspace it belongs to, or things like making it tiling would be impossible. This is more true when exwm-workspace-minibuffer-position is unset (the default) since a floating frame does not have a minibuffer and relies on the one of some workspace frame for input.

if we added an exwm-workspace-before-switch-hook which was called just before the workspace changes, it it possible a hook could use exwm-workspace--set-desktop to switch the exwm--desktop of the "pinned" window to the destination workspace?

This is not how things work. The property exwm-workspace--set-desktop sets does not have any affect on how X windows would be displayed. It's just a convention that window managers should set it. It's up to the window manager whether to show an X window.

I guess what I don't know is why it's currently necessary to create a new frame to host the window on a new workspace when it's clear that setting exwm--desktop to #xffffffff allows the existing frame to be maintained.

This is only partly true. With exwm-workspace-minibuffer-position set floating frames would never be recreated. Otherwise a floating frame has to specify which minibuffer to use which cannot be changed after frame creation, and this is when floating frames get recreated.