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 555668 - terminal size switching in maximised / fullscreen mode
terminal size switching in maximised / fullscreen mode
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
[geometry]
: 563513 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-09 12:40 UTC by Christian Persch
Modified: 2021-06-10 19:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2008-10-09 12:40:35 UTC
Both in bug 207 and bug 548322 which deal with resizing the terminal to a specific grid size, the problem came up about what to do when the terminal is maximised or fullscreened.

The options would be:
- ignore the resize request
- unmaximise / unfullscreen and apply the resize
- stay maximised / fullscreended but change the zoom factor so that the display has the requested grid size
Comment 1 Christian Persch 2008-12-15 18:38:58 UTC
*** Bug 563513 has been marked as a duplicate of this bug. ***
Comment 2 Mateus César Gröess 2009-04-04 01:34:03 UTC
Christian, I guess terminal size is also incorrectly calculated when a new tab is created on a maximised/fullscreen window previously without tabs. See this example, using gnome-terminal 2.26.0:

1) open 1st gnome-terminal window:

maximize the window
su -  (then type password to switch to superuser)
keep Enter key pressed until last line is at end of window
tail -f /var/log/messages  (last lines of the log file are displayed)
cursor is at end, at begining of a blank line

2) open 2nd gnome-terminal window

logger test1
logger test2
logger test3

3) on 1st gnome-terminal window:

open a new tab
switch back to the first tab
last line is test2
cursor is at begining of that line

4) on 2nd gnome-terminal window:

logger test4
logger test5
logger test6

5) on 1st gnome-terminal window:

last lines with text are test1, test4, test5 and test6
cursor is at end, at begining of a blank line



The problem may even be a security issue if what someone in that example wanted is watch logged login attemps, by example.
Comment 3 Christian Persch 2009-04-04 09:20:28 UTC
That's an entirely unrelated problem, vte bug 563374.
Comment 4 Toni Ruottu 2009-07-07 18:45:32 UTC
We are voting regarding a more general question at http://brainstorm.ubuntu.com/idea/20553/
Comment 5 Toni Ruottu 2009-08-26 14:47:20 UTC
Per Ubuntu Brainstorm the correct solution seems to be, to "Give up each terminal within one window having the same amount of rows, and the same amount of characters on a row. Print out as many characters and rows as can be fitted to current window size, with the font chosen for the current tab. Fill the small amount of extra screen space (windowsize mod charactersize) with some padding."

Simply remove the requirement for all tabs having a character grid of equal size.
Comment 6 Behdad Esfahbod 2009-08-26 16:51:34 UTC
Last thing I want to see is to base this decision on an Ubuntu survey...
Comment 7 Toni Ruottu 2009-08-26 18:50:03 UTC
It is open for anyone to participate. Also feel free to do additional polling where ever you want. All I wanted to know was, if there is a trend at all. It seems there is.
Comment 8 Behdad Esfahbod 2009-08-26 18:54:33 UTC
Nothing against Ubuntu per se.  Most of the time people don't know what they want.  Not until they try it.  If you give them an implementation and they try for two weeks, they can tell you if they want that or not.  That's why I'm more interested in hearing the problems users are facing, not solutions they come up with.

Anyway, I'm not the one to fix this anyway, ChPe is.
Comment 9 Toni Ruottu 2009-08-26 19:10:59 UTC
Just for the record. Do we agree that window size should not change when one switches between tabs?
Comment 10 Behdad Esfahbod 2009-08-26 19:17:29 UTC
Sounds right, yes.  I personally think all tabs in a window should have the same font size and terminal size.
Comment 11 Toni Ruottu 2009-08-26 20:04:52 UTC
You assume that people use zoom based on the size that they can read, and not based on the content visible in the current tab?
Comment 12 Behdad Esfahbod 2009-08-26 20:11:58 UTC
Yes, and I think that gives them the least surprise.  However, I'm not pushing my own preference on anyone.  As I said, it's very very very tricky to figure out what people want.  And one can't make 100% of users happy anyway.  So while I understand that there are some people that want different sizes in different tabs, my guess is that most people will find that behavior surprising.
Comment 13 Toni Ruottu 2009-08-26 23:52:30 UTC
Ok. I just feel that any change stopping the window size from changing would be an improvement. Although I came to think that Firefox has different zoom levels by tab.
Comment 14 Toni Ruottu 2009-09-09 20:10:52 UTC
Do you think changing font size should cause the window size to change, rather than causing the amount of rows and characters to change? I think that would be be odd. I'm not aware of any other application that would change the window size when you use some sort of zoom.

I think it is the support for a fixed size character grid that is causing all of these silly problems. I think there are many problems that can never be fixed while we support that.

I suggest support for a fixed size character grid is removed. Instead support some easy way for the user to see CHAR x CHAR size of the current grid. Thus the user can adjust the size of the window to fit his grid requirement, if he has one. Then, if the use messes the grid size by changing window size or font size it becomes his responsibility to resize the window to get the preferred grid size back.
Comment 15 Jochen Seliger 2015-07-03 15:31:02 UTC
I'm running SEES12 on ASUS ZenBook UX301.
After the first installation I tryed to instsll LibreOffize.
There was requirden a patch.
After instaling this patch (on the RED HAT-Site I've seen that it was due to NATILUS FS Implementation) the aplication is disfunctional.
The system is unusable.
Through the GRU-menu 'additional options + recovery' I can start the system with the functioning add-menue.
But in this case, it happenes quite often, that the screen becomes grey.
There is ni maous cursor. Sometimes I can close ( the incorrect window-sized aplication, alpplication, while the icon will stay at the botton line.
There it is posible to open the right mause menue on that icon ans select 'unmaximisde'. After selecting this option ans stering the app againg, it will be started with as size, smaler that the whole scree proper.
It seems to me that the screen size of the ZenBook is not correctly caculated/determined.
The rest seems to be the result of this failure.
Comment 16 GNOME Infrastructure Team 2021-06-10 19:46:13 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/6687.