GNOME Bugzilla – Bug 412056
*Don't* Resize when the font preference is set
Last modified: 2016-04-15 16:19:10 UTC
+++ This bug was initially created as a clone of Bug #71750 +++ I notice that Havoc filed and fixed bug #71750: When the font changes, we need to resize in pixels in order to maintain the same size in characters. GTK makes this a bit challenging. It strikes me that this is not the preferred behavior. I have a limited amount of screen real estate in pixels, and the reason I resize the terminal font is to get more characters into one terminal (or, inversely, to make it easier to see). By trying to maintain the same size in characters, I end up with the window size getting smaller or larger (potentially larger than my screen, even). Every time I change font size, I end up having to resize the window afterwards. The preferred behavior in my view would be to remain constantly sized in pixels, and simply resize the terminal size in characters. Other opinions / thoughts?
If you want to fix more characters in your terminal, you can use a smaller font size. You can even create a separate profile for that so you do not have to change it by hand each time. Zooming is for a different purpose: making what's currently seen bigger/smaller.
I understand your point, but I'm not sure I agree on UI grounds. I agree that zooming is for making things bigger or smaller, but I don't agree that means you should resize the window. I'm asking whether the way things currently are laid out are laid out that way for UI reasons, or just because somebody thought it was best that way once. When I change font sizes in Firefox (same keyboard shortcuts), the window doesn't resize. When I zoom into an image in gThumb, the window doesn't resize. When I zoom in on my inkscape document (+/-), the window doesn't resize. In fact, I'm hard pressed to find another example of a window resizing when you 'zoom in' or 'zoom out'. Whereas users may have long lines in a terminal (eg, cat'ting logs), I've never seen a use case where somebody needed to "zoom in" to make their terminal bigger - people know how to resize windows, and do that independently. Having the program move / resize the window is disturbing to the user. I'm reopening because I'm not sure if it should be marked as resolved, and I'm not the biggest bugzilla user. If that's not the correct etiquette, my apologies.
Chris, In 2.18.x, Terminal seems to behave exactly as you prefer it to: the graphical window size doesn't change while the terminal size in characters does change.
There is some voting going on about this at http://brainstorm.ubuntu.com/idea/20553/
*** Bug 620980 has been marked as a duplicate of this bug. ***
*** Bug 762956 has been marked as a duplicate of this bug. ***
(In reply to Chris Murphy from comment #0) > It strikes me that this is not the preferred behavior. I have a limited > amount of screen real estate in pixels, and the reason I resize the terminal > font is to get more characters into one terminal (or, inversely, to make it > easier to see). By trying to maintain the same size in characters, I end up > with the window size getting smaller or larger (potentially larger than my > screen, even). Every time I change font size, I end up having to resize the > window afterwards. > > The preferred behavior in my view would be to remain constantly sized in > pixels, and simply resize the terminal size in characters. This seems to be a matter of opinion. My opinion is the opposite of yours: I like what gnome-terminal does now (trying to maintain a fixed character-cell grid, and allocating more/fewer pixels to do that with the newly selected font). GNOME Terminal 3.20.0 accidentally had your desired behaviour due to Bug #760944 and I found it annoying enough to work on fixing it. Reasoning for that: * If the terminal currently contains an imperfect app that doesn't catch SIGWINCH and reflow its content, changing the character-cell grid results in messed-up layout. * In particular, if the terminal contains microcom or something (for a serial console in embedded development), SIGWINCH *can't* propagate to the other end, and the other end will carry on believing that it is a vt220 or whatever, at precisely 80x24. * Some (many?) uses of a terminal strongly prefer an 80 x whatever grid; for instance, git commit messages are meant to be of a length that fits neatly in 80 columns. > Whereas users may have long lines in a terminal (eg, cat'ting logs), I've > never seen a use case where somebody needed to "zoom in" to make their > terminal bigger - people know how to resize windows, and do that > independently. Having the program move / resize the window is > disturbing to the user. Counterpoint: having the text move around within the terminal when I change the font size disturbs this user :-) I zoom with Ctrl-plus/Ctrl-minus because I want to see the same content that's already there, but see it more easily (because I'm reading it more carefully or showing it to someone who is not at the optimum distance, usually), or occasionally because I want to make it unobtrusive (shrinking the window while it scrolls logged stuff during a long compile, bringing it back up to normal for analysis when finished). I resize the window (much more rarely) if I want to see longer lines in their entirety. If altering the effective text size didn't cause a resize, then "show exactly this, but bigger" would take two operations (zoom, then drag-resize back to desired size), assuming that the TUI redraw wasn't destructive.
I concur -> WONTFIX.