GNOME Bugzilla – Bug 755947
wayland: gnome-terminal does not fill entire area when tiled
Last modified: 2016-07-25 13:13:46 UTC
+++ This bug was initially created as a clone of Bug #751368 +++
Description of problem:
Windows partially maximized (vertically, mostly on mutter) or tiled with size increments does not stretch over the whole available area, as the size is constrained by its size increments.
This is mostly visible with gnome-terminal.
The same does not occur in X11 because most window managers including mutter/gnome-shell and metacity will ignore size increments for tiled windows.
Steps to Reproduce:
1. run gnome-terminal
2. tile the window on the right or the left of the screen
There is transparent border at the bottom.
Tiled windows should not leave any transparent borders around the window.
I think to fix this issue with tiling, we'd need to have partial maximization and/or tiling added Xdg-Shell client protocol to match those concepts in GDK.
this has been fixed (sortof)
Reopening, because the "sort of" fix seems to have been to make geometry-based resizing in gnome-terminal and other GTK terminals regress.
I have a patch for GDK and GTK which I think is a better long-term solution, and works well in conjunction with the patches from Bug #760944 and Bug #766860.
Created attachment 329172 [details] [review]
Don't apply GDK_HINT_RESIZE_INC to GDK_WINDOW_STATE_TILED windows
(In reply to Simon McVittie from comment #3)
> Created attachment 329172 [details] [review]
> Don't apply GDK_HINT_RESIZE_INC to GDK_WINDOW_STATE_TILED windows
Sorry, forgot to paste the long commit message:
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Yes, I had the same patch around but did not really cre to submit it as we don;t have tiled stated in wayland.
So, FWIW, I agree with this patch but it depends on bug 766860 on Wayland.
I agree that this patch will improve things under gnome-shell. But I'd caution that 'tiled' does not necessarily imply 'fixed size' - Jasper had a prototype for a tiling system that lets you resize tiled windows - it could e.g. be tiled on the left and top edges, but you could still drag the bottom right corner to change the window size.
(In reply to Olivier Fourdan from comment #5)
> So, FWIW, I agree with this patch but it depends on bug 766860 on Wayland.
Olivier's patches to signal a simple boolean tiling state through Wayland have now been applied.
(In reply to Matthias Clasen from comment #6)
> I agree that this patch will improve things under gnome-shell. But I'd
> caution that 'tiled' does not necessarily imply 'fixed size' - Jasper had a
> prototype for a tiling system that lets you resize tiled windows
Can we apply this one for now, and cross that bridge when we come to it? The protocol by which GTK on Wayland learns about tiled windows is currently GTK/Mutter-specific, so this isn't going to hurt anything on non-Mutter compositors; and it's a rather annoying "papercut" when using half-screen terminals under Wayland.
If someone adds per-edge "snapped" flags to the Wayland protocol later, we'd want to change the logic to something like this pseudocode:
if (maximized || fullscreen)
flags |= (EXACT_WIDTH | EXACT_HEIGHT);
if (snapped_left && snapped_right)
flags |= EXACT_WIDTH;
if (snapped_top && snapped_bottom)
flags |= EXACT_HEIGHT;
if (flags & EXACT_WIDTH)
use the actual width requested
round width down to the next character-cell step
if (flags & EXACT_HEIGHT)
use the actual height requested
round height down to the next character-cell step
(That would also require splitting up GDK_HINT_RESIZE_INC into horizontal and vertical parts, so that gdk_window_constrain_size() can do the right thing.)
(In reply to Simon McVittie from comment #7)
> Can we apply this one for now, and cross that bridge when we come to it?