GNOME Bugzilla – Bug 751368
wayland: gnome-terminal does not fill entire area when fullscreen or maximized due to size increments
Last modified: 2015-12-03 15:27:55 UTC
Description of problem: Maximized or fullscreen window of gnome-terminal in Wayland does not stretch over the whole available area, but the size is constrained by its size increments (basically the size of the characters) The same does not occur in X11 because most window managers including mutter/gnome-shell and metacity will ignore size increments for maximized/fullscreen windows. How reproducible: always Steps to Reproduce: 1. run gnome-terminal 2. maximize or fullscreen the window Actual results: There is a right and bottom transparent border. Expected results: Maximized/fullscreen window should not leave any transparent borders around the window.
Created attachment 305903 [details] [review] Proposed fix This is admittedly a violation of the size increments, but something done for years by most window managers under X11 so users expect the same in Wayland as well. Another solution could be to patch the applications (e.g. gnome-terminal) to not set size increments, either all the time or just when maximized/fullscreen.
I don't know GTK+ well, but that seems okay to me. Duplicate of #745376 tho.
Review of attachment 305903 [details] [review]: I think I'd prefer if we could take the same approach in both gtkwindow.c and gdkwindow-wayland.c: Ignore GDK_HINT_RESIZE_INC when calling constrain_size if the window state is maximized or fullscreen. Is there any reason why you took a different approach in the wayland backend ?
Created attachment 305914 [details] [review] Proposed patch (Updated) (In reply to Matthias Clasen from comment #3) > I think I'd prefer if we could take the same approach in both gtkwindow.c > and gdkwindow-wayland.c: Ignore GDK_HINT_RESIZE_INC when calling > constrain_size if the window state is maximized or fullscreen. Is there any > reason why you took a different approach in the wayland backend ? No good reason actually, patch updated :-)
Review of attachment 305914 [details] [review]: looks good
attachment 305914 [details] [review] pushed as c806f9b - ignore size inc when maximized/fullscreen
*** Bug 745376 has been marked as a duplicate of this bug. ***
Reopening, as soon a command is entered in gnome-terminal, a configure request is issued by the application that will shrink the window back to its resize increment multiple, leaving some portion of the screen uncovered.
Created attachment 312484 [details] [review] Additional fix for configure requests
Not necessarily happy with this patch, but I am not sure how to fix it differently...
Review of attachment 312484 [details] [review]: ok
attachment 312484 [details] [review] pushed as commit 42b02d9 window: ignore resize increments for maximized/fullscreen
I am still seeing the problem. Further, every time gnome-terminal gains/loses focus, it shrinks. This makes it completely unusable. Fedora Rawhide $ rpm -qa gtk3 gnome-terminal gnome-terminal-3.18.2-1.fc24.x86_64 gtk3-3.19.3-2.fc24.x86_64
(In reply to Nathaniel McCallum from comment #13) > I am still seeing the problem. Further, every time gnome-terminal > gains/loses focus, it shrinks. This makes it completely unusable. Different issue with gtk+-3.19.x fixed this morning with https://git.gnome.org/browse/gtk+/commit/?id=3ed71cf4
Mind you, it's still not a perfect fix, as it seems to grow outside the available area if you: - start gnome-terminal with only one window - set it to maximised (or half-maximised) - open tabs such that the tab bar is newly created At this point, AFAICT, the terminal window extends beyond the bounds by the size of the tab bar, minus the cell-size increment required to reach the border.
But I reckon that's actually yet another issue different from size increment rounding, once a window is either maximized or fulslcreen, the client should not attempt to resize the surface. On X11 this is managed by the window manager, but on Wayland, it's up to the client and its toolkit to take care of that.
Actually, here, with the fix 3ed71cf4 the g-t window doesn't actually grow anymore.