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 120301 - zooming with multiple tabs
zooming with multiple tabs
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
[geometry]
Depends on:
Blocks:
 
 
Reported: 2003-08-20 09:15 UTC by Andras.Belokosztolszki
Modified: 2021-06-10 15:26 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Andras.Belokosztolszki 2003-08-20 09:15:40 UTC
My problem is that zooming (with Ctrl++/-) changes the fontsize of only the
current tab. Changing tabs in zoomed in state tries to resize the terminal
window to match the original fontsizes, but this is inconsistent.
After zooming in/changing tabs/zooming out I usually end up with many
different fontsizes in different tabs, while at the same time the window
size does not match what one would expect for the tab's fontsize. 

gnome terminal version: 2.3.2
Comment 1 Mariano Suárez-Alvarez 2003-09-02 20:42:55 UTC
Right now, the behaviour is consistent: changing the zoom factor of a
tab affects that tab. Because of that, changing to an unzoomed (or
differently-zoomed) tab changes the window size. 

This can easily be fixed: zooming could be made to affect all tabs in
a window. This can even be done with a negative line count net change,
and IMO, would be more reasonable behaviour. I'll post a patch later.

But window resizing on tab changes also happens when switching from a
tab to another which is using a profile with a different font and/or
different font size. (See bug 120123 and bug 110103) 

Should be tackle both issues at the same time (maybe making the window
as large as the biggest tab; I don't think this is good except for
zooming...)?

Comment 2 Mike Duigou 2006-10-03 21:03:55 UTC
I would like to argue that changing the font and/or font size should not cause the window size to change. 

If the window size doesn't change in response to font changes then the tab behaviour becomes consisent--switching between tabs doesn't change the window size.

IMHO, the zoom level and/or font choice reflects how much or how little text I wish to see in the window. It is not a preference for how big I want the window to be. If I want a bigger or smaller window, occupying more or less of my screen I will adjust the window size. If I want more or less text shown in the window I will adjust the font or font size. The two sizing issues should not be coupled.

I assume most users normal mode of operation is similar to mine. Create a window, place and size the window in relation to other windows I have open so that it is as large as is comfortable, adjust the size of the text in the window to a comfortable level.
Comment 3 Mario Gonzalez 2010-08-13 15:36:22 UTC
I know this is old bug report but we cannot close it because it's a enhancement request. So, according what Andras.Belokosztolszki reported, I think it's a good idea to change the behaviour but if now Ctrl+ will change every open tab... mhh What would you say if rather we add a new key-pair like:

 "Ctrl +" or "Ctrl -" => Increase/decrease font size in one tab
 "Ctrl Alt +"  or "Ctrl Alt -" => Increase/decrease font size in ALL tabs

What do you think?
Comment 4 Mike Duigou 2010-09-03 23:18:30 UTC
Your suggestions for enhanced key combinations make sense. However, still unaddressed is the problem I identified with the window size changing.
Comment 5 GNOME Infrastructure Team 2021-06-10 15:26:50 UTC
-- 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/2423.