GNOME Bugzilla – Bug 762956
Don't resize window on font size change
Last modified: 2016-03-06 07:00:15 UTC
Suppose I've got some "carefully arranged" layout of windows on my screen. (I use "shellshape", a gnome shell extension, to make that easy, but that's besides the point) I do any of the following: (1) Resize the font in Gnome Terminal (2) Switch to a different tab in Gnome Terminal that happens to use a different font size The above-mentioned carefully-created layout is now messed up, as G-T has resized its window. #412056 seems related.
Bug 731137 is probably more related. As long as we have window geometry hints (the window size is preferred to be a multiple of cell size plus the necessary chrome (tab bar etc.)) it's practically undoable since upon a font change the old window size wouldn't be properly aligned according to the new font size. Now the question is what happens with gtk+ 3.20 which breaks some of this geometry hinting. I don't know. I'm not sure g-t is the right place to address your feature request; I'd guess it rather belongs to the WM to override the hints and force a certain window size. It would be cool if you could ask the shellshape folks for their opinion.
Done: https://github.com/timbertson/shellshape/issues/168
As one data point, Konsole (KDE's terminal) behaves according to my expectation above, i.e. it doesn't resize its window.
Konsole doesn't set geometry hints. You resize the window continuously, resulting in a random amount of (up to 1 cell's width/height) unused space at the right/bottom all the time. There are no words to express how much I loathe this! All my contributions of the last 2.5 years to vte wouldn't have happened if g-t was such a terminal emulator, I would've chosen to use (and perhaps develop) another one. When chosing a terminal emulator, it's pretty much a showstopper for me. Your requested feature requires that we switch to this behavior, which I'm stroingly against. Unfortunately Gtk+ might be heading in a direction where we won't have any other option (apart from trying to convince Gtk+ folks to revert their recent change). We'll see.
Well, I see what you're saying, and this may just be a shortcoming of shellshape in this case. Perhaps the next best thing I might ask for to make my life better is a check box that provides the behavior I want. But then, I can't blame you for not wanting to spend time implementing behavior you loathe...
*** This bug has been marked as a duplicate of bug 412056 ***
Hi, developer of Shellshape here. I think it's _probably_ a limitation of shellshape, in that we don't get access to window manager hints - shellshape just performs a dumb move/resize during its layout process whenever the current size doesn't match the layout. If we could tie in closer to mutter this might not be an issue, but last time I looked it either wasn't exposed or wasn't flexible enough for shellshape. As for the behaviour in general, I must agree with the reporter - in no other application that I know of does "zooming" change the window size, and I'm always surprised + annoyed when gnome-terminal does this. I understand the point about exact snapping to character bounds, but I personally don't mind if resizing creates unused space beyond the last row / column. But clearly some people feel strongly the other way as well.
As far as I can tell, there is no way to specify in geometry hints a pattern plus one additional allowed value. Let's take an example, only looking at the window width. Let's begin with 80 columns, 6 pixels each. Given the 1px padding on both edges, the geometry hints is set to be "6k + 2 pixels width for some integer k". Currently with k=80 this happens to be 482px. Now let's increase the font size to 7px wide. The hints change to "7k + 2 pixels for some integer k", which can have values such as 471, 478 (for k=68), 485 etc. You might argue that the result should be a window that is still 482px wide, that is, 68 columns, plus an additional 4px unused area (as well as the standard 2px padding). However, according to my best knowledge, it's not possible to specify "7k + 2 or 482" in geometry hints (and that "or 482" would be bad to have on subsequent resize events). Also, window managers will not leave the window at its the current unaligned size of 482px, they will snap it to 478px perhaps. I might be mistaken with the latter, please let me know if you do an intensive testing on that and find out that pretty much all WMs leave the window size unchanged (disobeying the new hints) when the geometry hints change. If so, then this might be the key to a new behavior. I understand that the current behavior is unusual. This is because having geometry hints is unusual. I believe that resizing the window is a way more typical event than changing the font, and hence, the user experience should be optimized for the former. And there's one more thing. If you argue that the window shouldn't change size on font change, I guess you should also be arguing that the window shouldn't change size when the tab bar (dis)appears. That is, upon opening the second tab, the 80x24 terminals would shrink to perhaps 80x22 plus some additional vertical gap. I wouldn't be happy with this either.
First, let's see if Gtk+ 3.20 will break geometry hints or not, it's not clear to me (see link from bug 760944). I'm wondering if we could introduce a global pref (perhaps no UI, only dconf) to never set hints and never resize the window, and behave as you prefer (plus as outlined in the previous comment's last paragraph). If so, maybe it could have three states: on, off and auto – the latter one useful if we can detect tiling WMs including Shellshape running (can we?).