GNOME Bugzilla – Bug 760944
resizing and geometry (snap to character cells) regressed with Gtk 3.19+
Last modified: 2016-12-20 09:36:55 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
Most likely due to gtk+ commit 08974a1e9a6099a5a94b9d56970dbf96e473ba87 / bug 757282.
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.
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.
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.
(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.
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.
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?
(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.
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'.
Created attachment 324960 [details] [review] Fix chunked resize and --geometry option > We should not move this into the branch Oh, yes, indeed.
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.
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.
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.
(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.
(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.
(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).
(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.
(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).
(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
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.
(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.
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.
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.
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.
(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.
(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?
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)
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.)
Created attachment 326121 [details] [review] screen-container: Implement the resize popup for Wayland
Review of attachment 325317 [details] [review]: Works for me, under both X and Wayland.
(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.
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).
(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?)
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.)
Created attachment 326233 [details] [review] screen-container: Implement the resize popup for Wayland Conditionally #include <gdk/gdkwayland.h>
(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.
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; }
(Fix the "p" typo to be "px".)
*** Bug 765244 has been marked as a duplicate of this bug. ***
(adjusting description to try to catch more duplicates)
*** Bug 765902 has been marked as a duplicate of this bug. ***
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.
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.
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.
(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?
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 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.
(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.
(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?
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...)
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].
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
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.
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.
(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.
(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.
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.
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].
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.
(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.
Could any gnome-terminal maintainers please review @Simon McVittie's patch so that we can try to resolve this ugly regression in GNOME? Please?
Is there a "for-more-or-less-dummies" description on how I apply this patch on my own system before I go nuts?
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.
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.
(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 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?
(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?
Fine with me.
(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.
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.
(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.