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 760944 - resizing and geometry (snap to character cells) regressed with Gtk 3.19+
resizing and geometry (snap to character cells) regressed with Gtk 3.19+
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
3.19.x
Other Linux
: Normal enhancement
: gnome-3-20
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 765244 765902 (view as bug list)
Depends on:
Blocks: WaylandRelated
 
 
Reported: 2016-01-21 15:44 UTC by Andre Robatino
Modified: 2016-12-20 09:36 UTC
See Also:
GNOME target: 3.20
GNOME version: 3.19/3.20


Attachments
Fix --geometry and also chunky resize (2.94 KB, patch)
2016-03-21 17:20 UTC, Sorokin Alexei
none Details | Review
Fix chunked resize and --geometry option (3.02 KB, patch)
2016-03-29 18:07 UTC, Sorokin Alexei
none Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (1.50 KB, patch)
2016-04-01 07:26 UTC, Simon McVittie
none Details | Review
[v2] Replace no-op gtk_window_resize_to_geometry by calculating new size (10.26 KB, patch)
2016-04-04 08:36 UTC, Simon McVittie
none Details | Review
[v3] Replace no-op gtk_window_resize_to_geometry by calculating new size (10.70 KB, patch)
2016-04-04 10:13 UTC, Simon McVittie
none Details | Review
screen-container: Implement the resize popup for Wayland (8.80 KB, patch)
2016-04-15 17:33 UTC, Debarshi Ray
none Details | Review
screen-container: Implement the resize popup for Wayland (9.02 KB, patch)
2016-04-18 09:57 UTC, Debarshi Ray
needs-work Details | Review
Fix chunked resize and --geometry option (3.00 KB, patch)
2016-05-13 05:48 UTC, Debarshi Ray
none Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (13.07 KB, patch)
2016-05-13 06:30 UTC, Debarshi Ray
none Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (12.71 KB, patch)
2016-05-23 07:16 UTC, Simon McVittie
none Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (12.57 KB, patch)
2016-05-23 07:28 UTC, Simon McVittie
none Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (12.57 KB, patch)
2016-05-23 09:56 UTC, Simon McVittie
none Details | Review
[vte] widget_get_preferred_height: use vertical padding, not horizontal (1.02 KB, patch)
2016-05-23 09:57 UTC, Simon McVittie
committed Details | Review
Fix chunked resize and --geometry option (3.02 KB, patch)
2016-06-08 08:52 UTC, Simon McVittie
committed Details | Review
Replace no-op gtk_window_resize_to_geometry by calculating new size (11.81 KB, patch)
2016-06-08 08:57 UTC, Simon McVittie
committed Details | Review

Description Andre Robatino 2016-01-21 15:44:15 UTC
Since gtk3-3.19.5, the --geometry option in gnome-terminal doesn't work (for example, "gnome-terminal --geometry=80x24" brings up a very small window) in Fedora Rawhide. Also filed https://bugzilla.redhat.com/show_bug.cgi?id=1293671 . This happens using either Wayland or Xorg. It seems more likely to be gtk3-related, since downgrading to gtk3-3.19.4 fixes it, but Kamil Paral suggested it would be a good idea to file here as well.

OS: Fedora Rawhide
gnome-terminal-3.18.2-1.fc24.x86_64
gtk3-3.19.7-1.fc24.x86_64 currently, but broken since 3.19.5. Works properly with 3.19.4
Comment 1 Christian Persch 2016-01-21 16:55:58 UTC
Most likely due to gtk+ commit 08974a1e9a6099a5a94b9d56970dbf96e473ba87 / bug 757282.
Comment 2 Matthias Clasen 2016-01-21 20:09:38 UTC
It is unlikely that the functionality will come back in gtk. It would probably be good to either remove the --geometry argument, or compute the geometry itself.
Comment 3 Christian Persch 2016-01-26 17:20:23 UTC
I've neutralised the --geometry option if gtk+ version is >= 3.19.5, but leaving this open as a reminder to try and fix geometry support with new gtk.
Comment 4 Sorokin Alexei 2016-03-09 23:21:16 UTC
I didn't test it in gnome-terminal, but… https://github.com/mate-desktop/mate-terminal/commit/c0efce1
Seems like it would do the trick for you guys too.
Comment 5 Debarshi Ray 2016-03-11 17:02:26 UTC
(In reply to Sorokin Alexei from comment #4)
> I didn't test it in gnome-terminal, but…
> https://github.com/mate-desktop/mate-terminal/commit/c0efce1
> Seems like it would do the trick for you guys too.

Thanks for the link. Sadly, that is unrelated to geometry hints.
Comment 6 Sorokin Alexei 2016-03-21 17:20:47 UTC
Created attachment 324487 [details] [review]
Fix --geometry and also chunky resize

> Sadly, that is unrelated to geometry hints.
Actually, it is. I finally applied it to gnome-terminal, and it worked from the first try.
Comment 7 Felipe Morales 2016-03-27 23:07:39 UTC
Is this also why commands like

$ printf '\e[8;40;100t'

Don't work as expected in gnome-terminal 3.20? Or is this a different issue coming from vte3?
Comment 8 Debarshi Ray 2016-03-29 17:24:52 UTC
(In reply to Sorokin Alexei from comment #6)
> Created attachment 324487 [details] [review] [review]
> Fix --geometry and also chunky resize
> 
> > Sadly, that is unrelated to geometry hints.
> Actually, it is. I finally applied it to gnome-terminal, and it worked from
> the first try.

Ok, you are right.

I confused myself while reading through the recent gtk/gtkwindow.c commits regarding this. This patch addresses the consequences of these two commits. One of them completely ignores the geometry_widget argument in gtk_window_set_geometry_hints, while the other removes GDK_HINT_BASE_SIZE and GDK_HINT_RESIZE_INC from the mask.

commit f7cc4abbad76f354cdc740e7fb9192719f72a89a
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Mon Dec 7 10:11:06 2015 -0500

    Avoid ugly seams on half-tiled terminals
    
    Since we're no longer doing geometry widgets, don't send
    base size and increments to the window manager anymore either.
    This avoids an ugly 2 pixel gap to the right and bottom of half-tiled
    terminals under gnome-shell.

commit 08974a1e9a6099a5a94b9d56970dbf96e473ba87
Author: Benjamin Otte <otte@redhat.com>
Date:   Tue Mar 24 04:33:45 2015 +0100

    window: Ignore geometry widget
    
    Ignore the geometry widget passed to gtk_window_set_geometry_hints().
    Usind the widget itself was a hack that complicates the size request
    machinery.
    
    It is also incorrect in that it doesn't respect height-for-width.
    
    Last but not least, it was only used by gnome-terminal and that
    application can easily work without it.

This means that passing a non-NULL geometry_widget to gtk_window_set_geometry_hints would neuter the hints. This patch shows that we can avoid that by not passing a geometry_hint and adjusting the arithmetic to work with the top-level GtkWindow.
Comment 9 Debarshi Ray 2016-03-29 17:26:52 UTC
Review of attachment 324487 [details] [review]:

Could you please use git format-patch with a valid name and email address to generate the patch? That way we can attribute it properly.

::: src/terminal-options.c
@@ -3580,3 @@
-  gtk_style_context_get_padding(gtk_widget_get_style_context(widget),
-                                gtk_widget_get_state_flags(widget),
-                                &padding);

We should not move this into the branch. If we do that then the if condition would be accessing garbage values inside the 'padding'.
Comment 10 Sorokin Alexei 2016-03-29 18:07:18 UTC
Created attachment 324960 [details] [review]
Fix chunked resize and --geometry option

> We should not move this into the branch
Oh, yes, indeed.
Comment 11 Debarshi Ray 2016-03-29 18:48:43 UTC
Review of attachment 324960 [details] [review]:

Thanks for the new patch. I am not the maintainer, so I can't ack/nack this.

Note that we still need to take care of doing what gtk_window_resize_to_geometry did inside gnome-terminal itself. That method simply doesn't do anything nowadays.
Comment 12 Simon McVittie 2016-04-01 07:26:47 UTC
Created attachment 325130 [details] [review]
Replace no-op gtk_window_resize_to_geometry by calculating  new size

Together with the previous commit, this fixes a regression in
GNOME 3.20: anything that would alter the Terminal size, for example
a font size change or the 80x24, 80x43 etc. menu items, did nothing.

---

Requires Attachment #324960 [details]. The commit message assumes that Attachment #324960 [details] will be the previous commit.
Comment 13 Simon McVittie 2016-04-01 07:46:58 UTC
Unfortunately something is still not quite right with those two patches: I get a 79x23 window (with the default 80x24 requested), or 1x1 cell smaller than whatever I asked for with --geometry.
Comment 14 Simon McVittie 2016-04-01 08:08:09 UTC
(In reply to Simon McVittie from comment #13)
> Unfortunately something is still not quite right with those two patches: I
> get a 79x23 window (with the default 80x24 requested), or 1x1 cell smaller
> than whatever I asked for with --geometry.

False alarm, that was caused by my vte not having been recompiled against Gtk 3.20 (Bug #763538). I can't help thinking that's an ABI break somewhere, but it isn't really part of this bug.
Comment 15 Simon McVittie 2016-04-01 15:04:49 UTC
(In reply to Simon McVittie from comment #12)
> Replace no-op gtk_window_resize_to_geometry by calculating  new size
> 
> Together with the previous commit, this fixes a regression in
> GNOME 3.20: anything that would alter the Terminal size, for example
> a font size change or the 80x24, 80x43 etc. menu items, did nothing.

This works fine under X11, but breaks under Wayland: the terminal window is at the requested size (80x24 for me) for a split second, but then resizes to something like 90x30. Each time I press Enter, resize the window with Ctrl+plus/Ctrl+minus, or move input focus away/back, the terminal window gets around 10% larger in each dimension.

I suspect there's some feedback loop going on where resizing the window affects the size available for the actual terminal widget, which causes a resize, which affects the size available and so on.
Comment 16 Simon McVittie 2016-04-01 17:40:45 UTC
(In reply to Simon McVittie from comment #15)
> This works fine under X11, but breaks under Wayland: the terminal window is
> at the requested size (80x24 for me) for a split second, but then resizes to
> something like 90x30.

Perhaps related, when I have either just Attachment #324960 [details], or neither patch, my gnome-terminal is larger than configured (again, approximately 90x30) under Wayland, but is the correct size under X11 (including if I run both gnome-terminal-server and gnome-terminal with GDK_BACKEND=x11).
Comment 17 Simon McVittie 2016-04-01 21:36:02 UTC
(In reply to Simon McVittie from comment #15)
> This works fine under X11, but breaks under Wayland

Running the terminal server and client with GDK_BACKEND=x11 GTK_CSD=1 causes the same symptoms as for Wayland, so it seems CSDs may be causing this. My guess is that the window is initially sized as if there were no CSDs, then the CSDs are added, resulting in a larger overall window; the logic that sizes the actual terminal widget adds a few more rows and columns to use up that extra space; the CSDs are added again, providing a larger overall window; and so on, growing each time size is recalculated.
Comment 18 Simon McVittie 2016-04-02 17:40:13 UTC
(In reply to Felipe Morales from comment #7)
> Is this also why commands like
> 
> $ printf '\e[8;40;100t'
> 
> Don't work as expected in gnome-terminal 3.20?

If that's the terminal escape code for "resize to 100x40", then yes, the missing window-resizing support would cause that symptom too. The patches on this bug restore the functionality of that escape (but currently also break Wayland and GTK_CSD=1, as described).
Comment 19 Felipe Morales 2016-04-02 17:59:04 UTC
(In reply to Simon McVittie from comment #18)
Thanks for the info. Indeed, that code would normally resize the window. I had that problem when trying neovim[0] on the 3.20 release of g-t (using a wrapper[1]). It isn't a big deal, but I'm looking forward for these patches to land. 

[0]: http://neovim.io/
[1]: https://github.com/fmoralesc/neovim-gnome-terminal-wrapper
Comment 20 Simon McVittie 2016-04-03 12:21:26 UTC
Review of attachment 324960 [details] [review]:

::: src/terminal-window.c
@@ +3593,3 @@
+
+      base_width = toplevel_request.width - widget_request.width;
+      base_height = toplevel_request.height - widget_request.height;

This logic isn't correct when client-side decorations are used, because the GtkWindow's preferred size (toplevel_request) includes the CSDs (title bar and shadows), whereas gtk_window_resize() expects a size that does not include the CSDs.
Comment 21 Simon McVittie 2016-04-04 08:25:56 UTC
(In reply to Simon McVittie from comment #20)
> Review of attachment 324960 [details] [review]:
> 
> ::: src/terminal-window.c
> @@ +3593,3 @@
> +
> +      base_width = toplevel_request.width - widget_request.width;
> +      base_height = toplevel_request.height - widget_request.height;
> 
> This logic isn't correct when client-side decorations are used, because the
> GtkWindow's preferred size (toplevel_request) includes the CSDs (title bar
> and shadows), whereas gtk_window_resize() expects a size that does not
> include the CSDs.

Actually, this logic was correct for the hints - when we're using CSDs, it seems the base size should include the CSDs' size. It was just not the right input for gtk_window_resize() in my follow-up patch.
Comment 22 Simon McVittie 2016-04-04 08:36:52 UTC
Created attachment 325309 [details] [review]
[v2] Replace no-op gtk_window_resize_to_geometry by  calculating new size

Together with the previous commit, this fixes a regression in
GNOME 3.20: anything that would alter the Terminal size, for example
a font size change or the 80x24, 80x43 etc. menu items, did nothing.

---

This revised patch reworks the size calculation to split the base width/height into the CSD width/height (which should be included in the geometry hints but not passed to gtk_window_resize()), and the "chrome" width/height (which should be included in both - I borrowed the naming from web browsers, better suggestions welcome). This fixes the constant-resizing behaviour that I reported.

It also defers the calculation of the CSDs' sizes and window hints until the window gets realized, because until that point they're just a guess. For example, on my GNOME 3.20 system, the CSDs are initially claimed to be 52x52 px, which is revised to 52x89 px after the layout of the title bar has been done. The practical effect of this was that the geometry hints were off by a fraction of a character cell - on my system, that 37px difference is 2px less than 3 rows of 13px text. This led to the window initially being sized 2px smaller than it should have been, which deducted 1 row from the vte widget's height, which was then rounded down to the next whole row after the CSDs' correct size was applied, giving me an 80x23 window instead of the intended 80x24.

Tested on X11 with menubar, scrollbar and no CSDs; X11 with menubar, scrollbar and CSDs; Wayland with menubar and scrollbar; and Wayland without menubar or scrollbar.
Comment 23 Simon McVittie 2016-04-04 08:41:05 UTC
An optional refinement which is not implemented here, but would be nice, would be to draw a client-side bubble on Wayland with "80x24" (or whatever) while the window is being resized, similar to the one that Mutter would draw for us on X11.
Comment 24 Simon McVittie 2016-04-04 09:12:31 UTC
One remaining glitch with my v2 patch: if the window is snapped to the left or right side of the screen (half-maximized), we should disable the size reduction and let it occupy the entire half-screen, but at the moment it will continue to reduce its height and width down to the next whole character cell.

I'm not sure how you're meant to detect "I am half-maximized" from the client side. Fully-maximized works fine.
Comment 25 Felipe Morales 2016-04-04 09:28:23 UTC
(In reply to Simon McVittie from comment #24)

> I'm not sure how you're meant to detect "I am half-maximized" from the
> client side. Fully-maximized works fine.

In X11, fully maximized windows have the X property

_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT

but "half maximized" only

_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT

(I just checked using xprop).

No clue about Wayland, though.
Comment 26 Simon McVittie 2016-04-04 10:12:29 UTC
(In reply to Simon McVittie from comment #24)
> I'm not sure how you're meant to detect "I am half-maximized" from the
> client side.

It looks as though testing GDK_WINDOW_STATE_TILED should be able to solve this for CSD windows under X11, but that flag is never set for Wayland. There's an XDG_SURFACE_STATE_MAXIMIZED but no equivalent for _TILED.

Jasper, is this something that you intend xdg-shell to gain in future?
Comment 27 Simon McVittie 2016-04-04 10:13:57 UTC
Created attachment 325317 [details] [review]
[v3] Replace no-op gtk_window_resize_to_geometry by calculating new size

Together with the previous commit, this fixes a regression in
GNOME 3.20: anything that would alter the Terminal size, for example
a font size change or the 80x24, 80x43 etc. menu items, did nothing.

---

v3: respect GDK_WINDOW_STATE_MAXIMIZED, GDK_WINDOW_STATE_TILED (but please note that the latter only works in X11 at the moment)
Comment 28 Simon McVittie 2016-04-13 18:47:25 UTC
Made this a blocker for #757579 due to:

(In reply to Simon McVittie from comment #16)
> Perhaps related, when I have either just Attachment #324960 [details], or
> neither patch, my gnome-terminal is larger than configured (again,
> approximately 90x30) under Wayland, but is the correct size under X11
> (including if I run both gnome-terminal-server and gnome-terminal with
> GDK_BACKEND=x11)

which my proposed patch also fixes.

(The issue was actually failure to compensate for CSDs, but that obviously hits Wayland all the time, while not normally affecting X11.)
Comment 29 Debarshi Ray 2016-04-15 17:33:46 UTC
Created attachment 326121 [details] [review]
screen-container: Implement the resize popup for Wayland
Comment 30 Debarshi Ray 2016-04-15 17:37:29 UTC
Review of attachment 325317 [details] [review]:

Works for me, under both X and Wayland.
Comment 31 Debarshi Ray 2016-04-15 17:39:29 UTC
(In reply to Debarshi Ray from comment #29)
> Created attachment 326121 [details] [review] [review]
> screen-container: Implement the resize popup for Wayland

The actual label should ideally be themed like the server-side popup shown by gnome-shell under X.
Comment 32 Christian Persch 2016-04-17 12:55:43 UTC
With these patches, geomtry is broken on gtk+ < 3.19 (window grows on each return in bash), so this new code needs to be ifdef'd to GTK_CHECK_VERSION (3, 19, something).
Comment 33 Egmont Koblinger 2016-04-17 14:18:56 UTC
(Just wondering: what happens on a return in bash that can potentially have such a side effect, that is, not entirely vte's private business?)
Comment 34 Christian Persch 2016-04-17 18:08:39 UTC
Actually the same happens with gtk+ 3.20. In both cases, for testingpurposes, I have a big padding around VteTerminal (via ~/.config/gtk-3.0/gtk.css). If the padding is zero, this doesn't happen. So the patch is not taking the padding into account completely, somehow.

(The cause of the size change on 'return' is probably the title change via PROMPT_COMMAND, which is set as text in the tab label (even though it's hidden with only 1 tab present), causing a size request/alloc cycle.)
Comment 35 Debarshi Ray 2016-04-18 09:57:27 UTC
Created attachment 326233 [details] [review]
screen-container: Implement the resize popup for Wayland

Conditionally #include <gdk/gdkwayland.h>
Comment 36 Simon McVittie 2016-04-18 11:04:20 UTC
(In reply to Christian Persch from comment #34)
> Actually the same happens with gtk+ 3.20. In both cases, for
> testingpurposes, I have a big padding around VteTerminal (via
> ~/.config/gtk-3.0/gtk.css). If the padding is zero, this doesn't happen. So
> the patch is not taking the padding into account completely, somehow.

Huh. I didn't have a hacked theme while testing this, but I did enable the menu bar and scrollbar to make sure I'd have something in the window other than vte.

Could you attach your CSS here, please? The calculations added in my patch probably need to compensate for that padding or something.
Comment 37 Egmont Koblinger 2016-04-18 11:10:19 UTC
To get custom padding (rather than the default 1px), place something along these lines in ~/.config/gtk-3.0/gtk.css:

    VteTerminal, vte-terminal {
        padding: 20px 30p 40px 50px;
    }
Comment 38 Egmont Koblinger 2016-04-18 11:13:57 UTC
(Fix the "p" typo to be "px".)
Comment 39 Egmont Koblinger 2016-04-19 07:23:43 UTC
*** Bug 765244 has been marked as a duplicate of this bug. ***
Comment 40 Simon McVittie 2016-04-19 11:17:21 UTC
(adjusting description to try to catch more duplicates)
Comment 41 Egmont Koblinger 2016-05-02 13:46:55 UTC
*** Bug 765902 has been marked as a duplicate of this bug. ***
Comment 42 Christian Persch 2016-05-09 20:00:28 UTC
I was unsuccessful at trying to get the patches here for correctly for me, so this missed 3.20.2. There'll be a 3.20.3 specifically for this, once I can get it working.
Comment 43 Debarshi Ray 2016-05-13 05:48:07 UTC
Created attachment 327752 [details] [review]
Fix chunked resize and --geometry option

The code meant for newer gtk+ versions is now optional. I tested it against gtk-3-18 and gtk-3-20.
Comment 44 Debarshi Ray 2016-05-13 06:30:29 UTC
Created attachment 327753 [details] [review]
Replace no-op gtk_window_resize_to_geometry by calculating new size

Same as before. Made the code meant for newer gtk+ conditional and tested against gtk-3-20 and gtk-3-18.
Comment 45 Debarshi Ray 2016-05-13 06:31:57 UTC
(In reply to Christian Persch from comment #42)
> I was unsuccessful at trying to get the patches here for correctly for me,
> so this missed 3.20.2. There'll be a 3.20.3 specifically for this, once I
> can get it working.

Is there anything broken other than the padding problem?
Comment 46 Christian Persch 2016-05-15 18:29:38 UTC
There are 2 things broken:

* Changing the padding makes the window spontaneously resize e.g. when starting 'mc', or while in mc, closing the window which pops up the confirm-close dialogue. Curiously this *also* happens e.g. when I do 

vte-terminal { padding: 1px 20px 1px 1px; }

ie put the extra padding on the left or right size, the window shrinks/grows by *lines*. 

* Tab label height changes can shrink or grow the window by 1 line (bug 732588 is back). I can definitely repro this by enlarging the font for the tab labels

notebook > header tab { font-size: 32pt; }

and cycling through all unicode characters as window-title for the tab.
Comment 47 Christian Persch 2016-05-15 18:32:53 UTC
Comment on attachment 326233 [details] [review]
screen-container: Implement the resize popup for Wayland

Before I review this more in depth, was there a specific reason to put this code into terminal-screen-container.c instead of terminal-window.c ?


I don't really like this approach. Wouldn't it be simpler to get window manager cooperation for this? I.e. like 'tiled'/'maximised' state is signaled from the WM to gtk, here the WM would signal that the window has entered 'resizing' state, and we could simply show the size popup while that state is on.
Comment 48 Debarshi Ray 2016-05-16 17:17:32 UTC
(In reply to Christian Persch from comment #47)
> Comment on attachment 326233 [details] [review] [review]
> screen-container: Implement the resize popup for Wayland
> 
> Before I review this more in depth, was there a specific reason to put this
> code into terminal-screen-container.c instead of terminal-window.c ?

I just happened to notice that TerminalScreenContainer is a GtkOverlay, so I decided to leverage that and limit the interaction with TerminalScreen inside it. There is no reason we can't put this in TerminalWindow and poke the current container and screen.

> I don't really like this approach. Wouldn't it be simpler to get window
> manager cooperation for this? I.e. like 'tiled'/'maximised' state is
> signaled from the WM to gtk, here the WM would signal that the window has
> entered 'resizing' state, and we could simply show the size popup while that
> state is on.

We could add a GDK_WINDOW_STATE_RESIZING, but that would be new API and probably not fit for gnome-3-20. Admittedly, this is not as important as the other two patches, so it wouldn't be the end of the world to do it only in master.
Comment 49 Simon McVittie 2016-05-23 06:49:51 UTC
(In reply to Christian Persch from comment #34)
> So the patch is not taking the padding into account completely, somehow.

OK, this is quite annoying. My patch delays some resizing until after the window has been realized, at which point we know how large the CSDs are. However, we don't actually apply the non-default padding until the redraw *after* realizing:

[window 0x119e5f0] size is 80x24 cells of 9x18 px
[window 0x119e5f0] 720x432 + 14x30 = 734x462
80x24 cells of 9x18 px = 720x432 px
padding = 80x60 px
content area requests 734x462 px
window requests 786x514 px
chrome: 14x30 px
CSDs: 52x52 px (just a guess)

[window 0x119e5f0] size is 80x24 cells of 9x18 px
[window 0x119e5f0] 720x432 + 14x30 = 734x462
[window 0x119e5f0] realize, size 1 : 1 at (-1, -1)
[screen 0x142f640] size-alloc   722 : 434 at (26, 88)
[window 0x119e5f0] size-alloc result 786 : 551 at (0, 0)
80x24 cells of 9x18 px = 720x432 px
padding = 80x60 px
content area requests 734x462 px
window requests 786x551 px
chrome: 14x30 px
CSDs: 52x89 px
[window 0x119e5f0] hints: base 66x119 min 102x137 inc 9 18

[window 0x119e5f0] size is 80x24 cells of 9x18 px
[window 0x119e5f0] 720x432 + 14x30 = 734x462
[screen 0x142f640] size-alloc   722 : 434 at (26, 88)
[window 0x119e5f0] size-alloc result 786 : 551 at (0, 0)
71x20 cells of 9x18 px = 639x360 px
padding = 80x60 px
content area requests 731x468 px
window requests 783x557 px
chrome: 92x108 px
CSDs: 52x89 px
[window 0x119e5f0] hints: base 144x197 min 180x215 inc 9 18

[window 0x119e5f0] size is 71x20 cells of 9x18 px
[window 0x119e5f0] 639x360 + 92x108 = 731x468
[screen 0x142f640] size-alloc   719 : 440 at (26, 88)
[window 0x119e5f0] size-alloc result 783 : 557 at (0, 0)
71x21 cells of 9x18 px = 639x378 px
padding = 80x60 px
content area requests 731x486 px
window requests 783x575 px
chrome: 92x108 px
CSDs: 52x89 px
[window 0x119e5f0] hints: increment unchanged, not setting

How would I determine that the style has actually been applied and therefore we are ready to start setting geometry hints?
Comment 50 Simon McVittie 2016-05-23 07:13:38 UTC
I think the underlying issue here might be that terminals reverse the GTK layout algorithm's expectations.

Normally, an app starts up with some sort of content, the initial window size is relatively arbitrary, and the height-for-width or width-for-height algorithm arranges widgets to fill that arbitrary size.

In a terminal, we want the terminal widget's size to be fixed at all times except for when the user is resizing the window; if padding or client-side decorations appear, we want to resize the window to fit them around the fixed size of the terminal. (But user-initiated resizing, including maximize/unmaximize, should still resize the terminal...)
Comment 51 Simon McVittie 2016-05-23 07:16:17 UTC
Created attachment 328365 [details] [review]
Replace no-op gtk_window_resize_to_geometry by calculating  new size

---

Version of Attachment #327753 [details] which re-merges the code paths for old and new GTK, to get the same debug info in both code paths and make it clearer what is different. Not tested with old GTK, but hopefully equivalent to Attachment #327753 [details].
Comment 52 Simon McVittie 2016-05-23 07:28:32 UTC
Created attachment 328366 [details] [review]
Replace no-op gtk_window_resize_to_geometry by calculating  new size

---

better-merged version restoring old size calculation logic; slightly more debug
Comment 53 Simon McVittie 2016-05-23 09:56:22 UTC
Created attachment 328373 [details] [review]
Replace no-op gtk_window_resize_to_geometry by calculating  new size

---

Recalculate window size after the TerminalScreen's style changes, so that we take into account custom padding.

Tested under GTK 3.20 with X11 and Wayland. Not tested under 3.18 yet.
Comment 54 Simon McVittie 2016-05-23 09:57:45 UTC
Created attachment 328374 [details] [review]
[vte] widget_get_preferred_height: use vertical padding, not horizontal

---

This is necessary for Attachment #328373 [details]'s logic to work right when custom padding has a different width and height.
Comment 55 Simon McVittie 2016-05-26 10:19:30 UTC
(In reply to Simon McVittie from comment #26)
> It looks as though testing GDK_WINDOW_STATE_TILED should be able to solve
> this for CSD windows under X11, but that flag is never set for Wayland.
> There's an XDG_SURFACE_STATE_MAXIMIZED but no equivalent for _TILED.

Bug #766860.

The patches on that bug work fine for other GTK3 apps, but something is still not quite right for the Terminal: it's still not occupying the whole space. So I probably need another iteration of these patches.

(In reply to Christian Persch from comment #32)
> With these patches, geomtry is broken on gtk+ < 3.19 (window grows on each
> return in bash), so this new code needs to be ifdef'd to GTK_CHECK_VERSION
> (3, 19, something).

Since you later reported that 3.20 suffered the same issue with non-default padding, and my latest attempt fixes it, this might not actually be necessary. At some point I'll try a non-#ifdef'd version on Debian 8 (GNOME 3.14) - hopefully it will turn out that we can use the "new" code path unconditionally.
Comment 56 Simon McVittie 2016-06-06 08:54:13 UTC
(In reply to Simon McVittie from comment #55)
> The patches on that bug work fine for other GTK3 apps, but something is
> still not quite right for the Terminal: it's still not occupying the whole
> space. So I probably need another iteration of these patches.

Actually, this seems to be a GDK/GTK bug, which I've reopened (Bug #755947): both GDK's Wayland backend and GTK apply the incremental resize hint to TILED windows for the purposes of calling gdk_window_constrain_size(). I think the correct solution is to treat TILED the same as MAXIMIZED and FULLSCREEN in both those places, as in the patch I've attached to Bug #755947.
Comment 57 Simon McVittie 2016-06-08 08:52:32 UTC
Created attachment 329366 [details] [review]
Fix chunked resize and --geometry option

From: Sorokin Alexei <sor.alexei@meowr.ru>

Was caused by https://git.gnome.org/browse/gtk+/commit/?id=08974a1

---

Back to the version that does not have a #ifdef for GTK 3.19.5. If we do the recalculations right, as in the follow-up patch that I'm about to attach, then we don't need to have different code paths for 3.20 and for older versions.
Comment 58 Simon McVittie 2016-06-08 08:57:59 UTC
Created attachment 329367 [details] [review]
Replace no-op gtk_window_resize_to_geometry by  calculating new size

Together with the previous commit, this fixes a regression in
GNOME 3.20: anything that would alter the Terminal size, for example
a font size change or the 80x24, 80x43 etc. menu items, did nothing.

---

Un-#ifdef'd again. With the recalculation on style changes, as seen in Attachment #328373 [details], we do not need the different code paths for old and new GTK that were introduced in Attachment #327753 [details].

Tested with GTK 3.20.6 (from source, on Debian 9) under X11 and Wayland, and with GTK 3.14 (Debian 8) under X11. Both used VTE 0.44.2-6-gf08229f from source, including Attachment #328374 [details].
Comment 59 Brian J. Murrell 2016-07-02 22:50:37 UTC
What needs to happen here next?  I notice this ticket has not had any update in almost 4 weeks.

Having this --geometry broken is quite disruptive to work environments that open many windows with specific geometries.
Comment 60 Simon McVittie 2016-07-04 09:52:39 UTC
(In reply to Brian J. Murrell from comment #59)
> What needs to happen here next?  I notice this ticket has not had any update
> in almost 4 weeks.

The next step is code review by a gnome-terminal maintainer.

My current attempt at a solution to this is Attachment #329366 [details] (my modified version of a change initially proposed by Alexei Sorokin) and Attachment #329367 [details] (a follow-up change to fix resizing). I believe these fix the bugs in my previous attempt that Christian reported when using non-default padding, and they also avoid requiring a separate code path for Gtk < 3.20 (I tested in Gtk 3.14 and it seemed fine).

I would appreciate review and testing for those changes. They won't be merged until a gnome-terminal maintainer approves them, but non-maintainers doing review/testing would probably also be useful: if there is anything wrong in those changes that you can point out without taking up any of Christian's time, that's good information.

I applied a slightly older version of those changes to Debian's gnome-terminal a while ago and we haven't had any bug reports so far. I'm going to update that to these latest patches, hopefully later today.
Comment 61 Brian J. Murrell 2016-07-16 13:53:55 UTC
Could any gnome-terminal maintainers please review @Simon McVittie's patch so that we can try to resolve this ugly regression in GNOME?  Please?
Comment 62 Øyvind 2016-07-21 07:10:56 UTC
Is there a "for-more-or-less-dummies" description on how I apply this patch on my own system before I go nuts?
Comment 63 Brian J. Murrell 2016-07-21 10:53:29 UTC
A suggestion for everyone here suffering from this regression... mate-terminal does all of the things that have been removed from gnome-terminal lately, such as:

- setting of geometry with --geometry
- showing the terminal geometry when being resized
- a functional --title cmdline argument

I dropped mate-terminal in, in place of gnome terminal and it has been wonderful.

I tried waiting a while for this to be fixed; for the patch to even be reviewed; I even requested a review for a second time, but  since nothing seems to be happening with this defect, I just moved on.
Comment 64 Øyvind 2016-07-22 06:49:34 UTC
I thought this bug would cover the changed behaviour when zooming as well, but that doesn't work like I was used to in mate-terminal either. Previously, before gnome 3.20, I could zoom (with for instance Ctrl-+), and the size of the terminal window changed to allow for the same geometry in terms of character cells. Now, just the font size changes.
Comment 65 Simon McVittie 2016-07-22 16:42:22 UTC
(In reply to Øyvind from comment #64)
> I thought this bug would cover the changed behaviour when zooming as well,
> but that doesn't work like I was used to in mate-terminal either.
> Previously, before gnome 3.20, I could zoom (with for instance Ctrl-+), and
> the size of the terminal window changed to allow for the same geometry in
> terms of character cells. Now, just the font size changes.

Yes, that was a related regression in the 3.19/3.20 cycle. My patches attached to this bug address that.

The patched gnome-terminal 3.20 in Debian 9 "stretch" has those patches, and works the way you described.
Comment 66 Christian Persch 2016-08-01 18:16:56 UTC
Comment on attachment 326233 [details] [review]
screen-container: Implement the resize popup for Wayland

I don't like this part.

IMHO gtk+ should add a GDK_WINDOW_STATE_IN_RESIZE (or so), and then we show/hide the size popup accordingly. That gets rid of the motion tracking, and also allows to show the size popup right on click before any motion (so you can use this to check the size, without resizing at all).

As for the overlay on the screen container, that might be easy since it's already a GtkOverlay, but placing the popup there makes it not centred on the window. Maybe just paint the size popup on terminal_window_draw directly on top?
Comment 67 Simon McVittie 2016-08-02 11:20:28 UTC
(In reply to Christian Persch from comment #66)
> IMHO gtk+ should add a GDK_WINDOW_STATE_IN_RESIZE (or so)

That sounds good to me too, but can't target GNOME 3.20 like the rest of this bug. Possibly worth cloning that off into a follow-up, and closing this one?
Comment 68 Christian Persch 2016-09-04 12:54:01 UTC
Fine with me.
Comment 69 Simon McVittie 2016-09-04 14:44:47 UTC
(In reply to Simon McVittie from comment #67)
> Possibly worth cloning that off into a follow-up

Bug #770850

> and closing this one?

Fixed in the GNOME 3.22 cycle. I don't seem to have bug-closing powers (at least not on my non-work Bugzilla account) so please close this.
Comment 70 Andre Robatino 2016-09-04 14:49:33 UTC
Please check that specifying location works with the --geometry option before closing this - last I checked, the latest version in Fedora 25 and Rawhide would give the correct size but the wrong location.
Comment 71 Michael Catanzaro 2016-09-04 14:58:54 UTC
(In reply to Simon McVittie from comment #69)
> I don't seem to have bug-closing powers (at
> least not on my non-work Bugzilla account) so please close this.

Fixed and fixed.

(In reply to Andre Robatino from comment #70)
> Please check that specifying location works with the --geometry option
> before closing this - last I checked, the latest version in Fedora 25 and
> Rawhide would give the correct size but the wrong location.

Please file a new bug if it's broken, thanks; I think this one is sufficiently long and confused already.