Quirks affecting windows enforcing discrete resize increments (eg. gnome-terminal, emacs, ...)

[olejorgenb]

This is a "super" issue tracking the suboptimal handling of windows that don't resize freely. I'll close the other issues and try to gather info and workarounds here.

Issues where this is the underlying problem: #187, #106, #277

Symptoms

• Windows not fully maximized vertically (bottom gap)
• Non-uniform window gap when windows are tilied vertically
• cycle-width and increase-size sometimes have no effect

Key points

We do not know the increments. (ie. set of valid window sizes)* Gnome-shell/mutter makes it hard to handle these windows correctly. Well-behaved X11 windows do advertise the increments[1], but mutter/g-s does not expose this information to extensions. The XID of windows is not easily available either, making hacks involving executing eg. xprop even more hacky.

No reliable way of detecting when a resize-request has been fully handled The size-changed signal is only triggered if the window size actually changed. Resizing is synchronous for X11 windows (also through XWayland), but not for wayland. Ie. for X11 windows we can check directly after a resize if it worked, and issue a new resize with slightly a higher delta, but this doesn't work for wayland. (usage of discrete increments is more common for X11 windows but we have not found the motivation to make X11 only hacks yet)

Application specific workarounds

The use of discrete increments is common among terminal emulators. One good freely resizable terminal is Tilix.

Emacs

(setq frame-resize-pixelwise t)

makes emacs windows (aka. frames) resize freely.

gnome-terminal

https://github.com/paperwm/PaperWM/issues/320#issuecomment-652056612 suggests using css to add padding to remove the bottom gap.

urxvt

A patch disabling the increments is available here: https://github.com/paperwm/PaperWM/issues/106#issuecomment-487405272

[1] Through the WM_SIZE_HINTS xprop