GNOME Bugzilla – Bug 751064
toggling full screen shrinks terminal
Last modified: 2021-06-10 20:58:25 UTC
In GNOME Terminal 3.14.3 included in Fedora 21 switching to full screen mode and back shrinks the terminal window by 1 column and 1 line. Steps to reproduce: 1) Open a GNOME Terminal window and print its size: $ echo $COLUMNS X $LINES 80 X 50 2) Toggle Full Screen mode (and optionally print the terminal window size): $ echo $COLUMNS X $LINES 282 X 87 3) Disable Full Screen mode, print its size, and observe it has shrunk by 1 column and one line: $ echo $COLUMNS X $LINES 79 X 49 4) Repeating steps (2) and (3) continues to shrink the terminal window until it's 33 X 3 in size, after which point it eventually jumps up to fill the screen (281 X 82 on my monitor) and then starts shrinking again.
Not reproducible here with gnome-terminal git master (gtk+, glib from git master too).
@Martin Sebor I confirm the same issue with gnome-terminal. Can you tell me if the menubar is enabled or not ? For me, the issue only occurs when the menubar is disabled (means not visible). Looks like there is already a serious track at https://bugzilla.gnome.org/show_bug.cgi?id=757282, but since the owner closed it, the chance to see an answer is not high ... Last but not least, I tested the proposed patch, and it didn't fix the issue. For me, there is some missing information, probably dimensions not pushed / poped correctly, at least when not using the menubar (menubar disabled), but I didn't' seriously read the code, so I'll trust the one who know it better than me ;-) TIA
Apologies : not the same issue, but a similar one : got a little terminal, around 5 lines X 5 columns, and the issue occurs only when the menubar is disabled. Probably something else than what is described there. Sorry for the noise, but still wondering what happened to the most used application for me (I use a lot the gnome-terminal), who was the most stable as well ...
Just in case it's important, I'm using Gnome Ubuntu 15.10 on a macbook pro be@xxxxxx:~$ gnome-terminal --version Terminal GNOME 3.16.2 be@xxxxxx:~$ apt-cache show libgtk-3-0 Package: libgtk-3-0 Priority: optional Section: libs Installed-Size: 11573 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org> Architecture: amd64 Source: gtk+3.0 Version: 3.16.7-0ubuntu3.3
I see this with gnome-terminal 3.24.2 in Ubuntu 17.10. The terminal window shrinks by 1 row and 1 column every time I maximize and restore (or fullscreen and restore). I'm using a GNOME session on Wayland. I also have the terminal menu bar disabled.
Let's link back to https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1288655 where I just made a (probably not so important) comment :)
The following goes on for me: gnome-shell on Xorg: - gnome-t, vte test app (from git), xfce4-t and mate-t all behave like this: - In both maximized (Windows+Up) and half-maximized (Windows+Left/Right) states the window occupies the whole designated area, the "gap" belongs to the terminal (that is, geom hints are overridden). - There's a nice animation when (full/half/un)maximizing. - The window size never shrinks. - xmag works as expected. gnome-shell on Wayland: - mate-t in all aforementioned aspects behaves just like on X11. I _guess_ it means that some X11-compatibility layer is in use. - gnome-t, vte test app and xfce4-t: - In maximized mode the terminal occupies the entire space (the "gap" belongs to g-t, geom hints are overridden). The size shrinks when unmaximizing. - In half-maximized modes the geom hints are obeyed, the terminal is slightly smaller than half of the desktop, and the desktop background peeks through the gap. The size doesn't shrink. - There's no real animation (maybe a bit of fade-out). - xmag doesn't work over these windows. I _guess_ it means that these are native Wayland apps now without any bit of X11. Conclusion: The bug is probably somewhere in Wayland's native (not X11 emulated) code of maximizing, or wherever the geometry hints are overridden in this mode. Or probably in the relevant code of Gtk+ (or maybe VTE if we have any X/Wayland-specific code around geometry hints; do we?).
xfce4-terminal's size noticeably increases when its app menu is opened and then closed. Only on gnome-shell + wayland. https://bugzilla.xfce.org/show_bug.cgi?id=13938. No clue whatsoever whether it's related.
It's the maximized -> original size step that shrinks the terminal. If you go original -> halfmax(1) -> maximized -> halfmax(2) -> original or original -> maximized -> halfmax -> original then the original size is correctly restored. Note however, that (at least with my screen size and font size) steps (1) and (2) do not have the same window size, ouch. I believe we should reassign/forward this to gnome-shell/wayland (which?) folks for further investigation. I can hardly imagine gnome-terminal or vte being the culprit here.
(The observation of bug 782863 comment 16 doesn't apply here. It's not the title change that triggers the issue.)
*** Bug 789826 has been marked as a duplicate of this bug. ***
*** Bug 790647 has been marked as a duplicate of this bug. ***
The same occurs for me when unmaximizing a terminal window in Wayland, but not in Xorg. I've reported it against GTK: <https://gitlab.gnome.org/GNOME/gtk/issues/34>. I'm resurrecting roxterm, and ran into the same problem with that. If I remove the call to gtk_window_set_geometry_hints(), which roxterm uses in much the same way as gnome-terminal, the problem goes away. But I found a less drastic workaround. In the handler for "window-state-event" I check whether any of the maximized, fullscreen or tiled flags have changed. If any of them have become set, I clear the geometry hints; if they're all clear I restore the geometry hints, which I keep cached from the last time I set them.
> I'm resurrecting roxterm Wow! Welcome back! :) You might have seen bug 789356 and bug 789357 as well, the changes from them made it into gnome-terminal 3.27 series, as well as GTK+ 3.22.25 IIRC (or maybe .26?). I recommend that you target these new enough GTK+ versions only. Honestly there are many things I don't fully understand in this story and would need to dig pretty deep to fix the remainig issues, which won't happen for gnome-terminal 3.28.
> Wow! Welcome back! :) Thanks. > You might have seen bug 789356 and bug 789357 as well, the changes from them > made it into gnome-terminal 3.27 series, as well as GTK+ 3.22.25 IIRC (or > maybe .26?). I recommend that you target these new enough GTK+ versions only. I didn't see those bugs, but I noticed the new tile flags and did this: #if GTK_CHECK_VERSION(3,22,23) #define WIN_STATE_TILED \ (GDK_WINDOW_STATE_TOP_TILED | GDK_WINDOW_STATE_BOTTOM_TILED | \ GDK_WINDOW_STATE_LEFT_TILED | GDK_WINDOW_STATE_RIGHT_TILED) #else #define WIN_STATE_TILED GDK_WINDOW_STATE_TILED #endif #define WIN_STATE_SNAPPED (GDK_WINDOW_STATE_MAXIMIZED | \ GDK_WINDOW_STATE_FULLSCREEN | WIN_STATE_TILED) > Honestly there are many things I don't fully understand in this story and > would need to dig pretty deep to fix the remainig issues, which won't happen > for gnome-terminal 3.28. Yes, widget size negotiation is still a big problem for GTK. I think it's changing again in GTK4 (replacing the various get_preferred size functions with a single measure function that can handle each case), which is only marginally helpful. It would be nice if there was a less arcane way to reliably measure the size of a widget, especially for a container with a child/children of known size.
It occurred to me that the problem might not be Wayland-specific, but CSD-specific. I'd like to restyle roxterm with a header bar one day, which would give us an opportunity to find out, but I think that's still some time off. Probably the same for g-t (#756798)?
(In reply to Tony Houghton from comment #16) > It occurred to me that the problem might not be Wayland-specific, but > CSD-specific. I'd like to restyle roxterm with a header bar one day, which > would give us an opportunity to find out, but I think that's still some time > off. Probably the same for g-t (#756798)? I don't think a CSD header bar helps anything here – it's one more widget that our app has to count for when computing geometry hints. See {chrome,csd}_{width,height} in the test app src/app/app.cc in current VTE git, it's fresh code and much less bloated than g-t (and uses CSD).
What I meant was that if one of these apps used a header bar we could test it in X to work out whether the problem is in Wayland or CSD.
The shrinkage related to the header bar is continued in: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/129
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7576.