After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751368 - wayland: gnome-terminal does not fill entire area when fullscreen or maximized due to size increments
wayland: gnome-terminal does not fill entire area when fullscreen or maximize...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 745376 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-06-23 09:53 UTC by Olivier Fourdan
Modified: 2015-12-03 15:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed fix (4.14 KB, patch)
2015-06-23 10:02 UTC, Olivier Fourdan
none Details | Review
Proposed patch (Updated) (3.23 KB, patch)
2015-06-23 11:51 UTC, Olivier Fourdan
accepted-commit_now Details | Review
Additional fix for configure requests (1.09 KB, patch)
2015-10-01 13:59 UTC, Olivier Fourdan
accepted-commit_now Details | Review

Description Olivier Fourdan 2015-06-23 09:53: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.
Comment 1 Olivier Fourdan 2015-06-23 10:02:39 UTC
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.
Comment 2 Daniel Stone 2015-06-23 11:16:44 UTC
I don't know GTK+ well, but that seems okay to me. Duplicate of #745376 tho.
Comment 3 Matthias Clasen 2015-06-23 11:24:19 UTC
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 ?
Comment 4 Olivier Fourdan 2015-06-23 11:51:58 UTC
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 :-)
Comment 5 Matthias Clasen 2015-06-24 00:39:04 UTC
Review of attachment 305914 [details] [review]:

looks good
Comment 6 Olivier Fourdan 2015-07-03 14:28:16 UTC
attachment 305914 [details] [review] pushed as c806f9b - ignore size inc when maximized/fullscreen
Comment 7 Daniel Stone 2015-09-04 11:45:40 UTC
*** Bug 745376 has been marked as a duplicate of this bug. ***
Comment 8 Olivier Fourdan 2015-10-01 13:54:57 UTC
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.
Comment 9 Olivier Fourdan 2015-10-01 13:59:03 UTC
Created attachment 312484 [details] [review]
Additional fix for configure requests
Comment 10 Olivier Fourdan 2015-10-01 14:01:10 UTC
Not necessarily happy with this patch, but I am not sure how to fix it differently...
Comment 11 Matthias Clasen 2015-10-01 14:03:13 UTC
Review of attachment 312484 [details] [review]:

ok
Comment 12 Olivier Fourdan 2015-10-01 14:37:48 UTC
attachment 312484 [details] [review] pushed as commit 42b02d9 window: ignore resize increments for maximized/fullscreen
Comment 13 Nathaniel McCallum 2015-12-03 14:42:15 UTC
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
Comment 14 Olivier Fourdan 2015-12-03 14:45:01 UTC
(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
Comment 15 Daniel Stone 2015-12-03 15:03:19 UTC
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.
Comment 16 Olivier Fourdan 2015-12-03 15:11:49 UTC
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.
Comment 17 Olivier Fourdan 2015-12-03 15:27:55 UTC
Actually, here, with the fix 3ed71cf4 the g-t window doesn't actually grow anymore.