[headerbar] Maximize or fullscreen back-n-forth shrinks the terminal
Let's continue from #44 (closed) and 751064 in a new bug to get rid of the previous noise.
Maximize or fullscreen gnome-terminal, then leave this mode. Only with headerbar, the size shrinks. Both on X11 and Wayland.
It may actually be a gnome-terminal bug, let's see.
My setup:
- Physical screen: 1920x1080
- Font size: 9x18
- Initial terminal size: 80x24 cells
- Padding: 1px on each side
- (Initial VTE size derived from these: 722x434)
- Scrollbar width: 12px
- Headerbar height: 42px
- (Initial user-perceived real window size derived from these: 734x476)
- Shadow width: 74 px along both axes (around 37px on each side)
- (Initial overall size including shadows: 808x550)
Debug messages with GNOME_TERMINAL_DEBUG=geometry
around a fullscreen+unfullscreen cycle:
80x24 cells of 9x18 px = 720x432 px
padding = 2x2 px
content area requests 734x434 px
chrome: 14x2 px
terminal widget allocation 734x434 px
window allocation 808x550 px
CSDs: 74x116 px
terminal widget requests 722x434 px
[window 0x558d25ce23b0] hints: increment unchanged, not setting
[window 0x558d25ce23b0] size is 80x24 cells of 9x18 px
[window 0x558d25ce23b0] 720x432 + 14x2 = 734x434
[screen 0x558d25cf15f0] size-alloc 722 : 434 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 808 : 550 at (0, 0)
*** F11: enter fullscreen ***
[screen 0x558d25cf15f0] size-alloc 1982 : 1154 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1994 : 1154 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1994 : 1154 at (0, 0)
[screen 0x558d25cf15f0] size-alloc 1908 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 1920 : 1080 at (0, 0)
*** F11: leave fullscreen ***
[screen 0x558d25cf15f0] size-alloc 641 : 344 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 727 : 460 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 727 : 460 at (0, 0)
[screen 0x558d25cf15f0] size-alloc 713 : 416 at (36, 74)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
[window 0x558d25ce23b0] size-alloc result 799 : 532 at (0, 0)
Interpretation:
When entering fullscreen, the window is first enlarged to (1920+74)x(1080+74) pixels, that is, my physical screen size plus the shadow. (The screen is narrower by 12px due to the scrollbar.) Then the shadow is dropped.
When leaving fullscreen, the screen is shrunk to 641 pixels wide (71*9+2) instead of 722 (80*9+2). This value is suspiciously 722 (expected) - 74 (shadows) = 648 rounded downwards to respect the grid and padding. Correspondingly, the window becomes 727 pixels wide which is 641 + 12 (scrollbar) + 74 (shadows).
Ditto for the height: the screen becomes 434 (expected) - 74 (shadows) = 360 rounded downwards to match the grid to 344 = 19*18+2 (19 lines + padding). The window height is correspondingly 344 + 42 (headerbar) + 74 (shadows) = 460.
Then the shadow's size gets re-added, and again, the sizes are rounded downwards to match the grid.
To double check that I'm on the right track, let's try to see what a trap 'stty size' WINCH
says:
*** F11: enter fullscreen ***
64 220
59 211
*** F11: leave fullscreen ***
19 71
23 79
The intermediate 71x19 size is clearly visible, and there's a similar dance when going oversized.
So, during (un)maximize/fullscreen, the amount of CSD changes. The value printed in the debug messages CSDs: 74x116 px
is no longer relevant. According to the lack of further similar debug messages, the value is not recomputed.
Maybe all we need to do is recompute the CSD dimensions at the right place, in an atomic step along with the resize? (Is it possible? Or do we derive the CSD values from other properties that we're just about to figure out during a resize, so there's a chicken-and-egg problem?)
[The at (36, 74)
values (allocation->x/y) might indicate that the shadow is probably not evenly distributed. 36px on the left and the remaining 38px on the right. 74 - 42 (headerbar) = 32 pixels at the top and the remaining 42 pixels at the bottom. And then if I'm not mistaken it's just a coincidence that allocation->y's 74 is the same number as the overall shadow width per axis.]