special-case behaviour for GDK_WINDOW_STATE_TILED is no longer applied
@smcv
Submitted by Simon McVittie Link to original bug (#789356)
Description
gnome-terminal has special cases for when it is maximized or tiled (half-maximized) to turn off the character-cell-based resizing logic (Bug #760944
).
Since GTK+ 3.22.23 and Mutter 3.26.1, these special cases are ineffective, because GTK+ now sets 0-4 hints like GDK_WINDOW_STATE_TOP_TILED instead of a single hint GDK_WINDOW_STATE_TILED. It no longer sets the plain TILED hint (which I think is a regression, and I'll open a separate bug for that).
I think this might be the root cause of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879566:
I don't know whether this bug lies with gnome-shell or with mutter, but either way, it's a serious usability problem when using terminal windows. I think this might correspond to the changes to support resizing a pair of half-maximized windows by grabbing the border between them.
Previously, when half-maximizing a terminal window (with Super-Left or Super-Right), the window would extend all the way to the edge of the screen on the bottom and side. Zooming the terminal with Ctrl-plus or Ctrl-minus would change the font size but leave the terminal half-maximized, and opening a second tab or closing the penultimate tab would show or hide the tab bar but leave the terminal half-maxmized. Showing or hiding the menu bar worked similarly.
Now, when half-maximizing a terminal window, it resizes to an integral number of character cells, leaving a distracting border on the bottom and the right side. And when zooming, or showing or hiding the tab bar or menu bar, the window size changes, often pushing part of it off-screen.
For that matter, opening two terminal windows, half-maximizing both, and dragging the border between them produces various buggy behavior with window borders jumping around and separating. I think the whole mechanism doesn't work well with windows that have resize increments other than one pixel.
I'm not sure whether this should be considered to be a bug in gnome-terminal, a bug in GTK+ or a bug in Mutter/Shell. It would probably be most robust to fix it in both gnome-terminal and GTK+.
Version: 3.26.x