GNOME Bugzilla – Bug 144066
terminal size shrinks on dynamic title change
Last modified: 2008-10-09 14:38:46 UTC
I think this is very similar to bug 83698, so you may want to read it as background. Also, I my patch may be of some use there. This happens because Pango can alter the height of the notebook tab labels depending on the glyphs present. In particular, this happens when a font doesn't have the required glyph, and another is substituted in its stead. Here's my specific set-up: My default GNOME/GTK font is BitStream Vera (aliased as Sans). It doesn't have Cyrillic characters (not the version I have anyway). So, Pango substitutes Verdana from the MS-fonts collection. My DPI is set to 100x100, and the labels use font size 10. Pango requires 17 pixels for Vera, and 19 pixels for Verdana under these conditions. User scenario: 0) open gnome-terminal 1) Edit Current Profile->Title and Command 2) make sure that dynamic title is set to something like "Replaces Initial Title" (is displayed at least) 3) set PROMPT_COMMAND='echo -ne "\033]0;[${USER}] ${PWD}\007"' so that the terminal is named in a useful way. 4) Make sure you're in some directore that has a fully latin path. 5) mkdir "some cyrillic characters". For the cyrillic-impaired: bash$ mkdir $(echo $'\346\331' | iconv -f KOI8-R -t `locale -k charmap | cut -d\" -f 2`) This should create a directory with a two-character name. The first looks like a capital Phi, the next like an upside down p plus a bar. It's irrelevant whether your terminal font can display them. What's more important is that pango be able to find the glyphs. To check: 6) cd "some cyrillic characters", or, again: bash$ cd $(echo $'\346\331' | iconv -f KOI8-R -t `locale -k charmap | cut -d\" -f 2`) The title should now update to reflect this. If your system font settings are as mine (where different fonts are used for Latin and Cyrillic), you will have noticed that your terminal shrunk by one line. For a bit of fun: 7) cd .. 8) cd "some cyrillic characters" 9) go to step 7 until bored (or minimum terminal size is reached) CONCLUSION: This is an annoyingbug, since it can lead you to lose terminal area, and stuff that was written in it. Moreover, it makes you have to resize the terminal back. If you have trouble reproducing it, please tell me/ask. I'm attaching a patch. It includes some comments on how this happens.
Created attachment 28531 [details] [review] Patch to avoid terminal shrinkage when tab labels resize.
Er, forgot to mention. I snuck a clean-up in there in getting rid of current_widget in another part of the code. That's optional, but nice, I think :) Another clean-up: line 917, terminal-window.c says: /* the default label for GTK_STOCK_ZOOM_100 does not follow the HIG... */ set_menuitem_text (mi, _("_Normal Size"), FALSE); This no longer holds -- as of 2.4.1, GTK has a perfectly good label there.
Please do maintain the one-issue-per-bug invariant!
You patch sets the window size inside of a size-request signal handler; I am quite sure that is not correct. Here comes a rather simpler patch, which just keeps track of the tallest label we've had so far, and makes the notebook requisition larger so that it fits. This does not make the window smaller once the labels in the tabs all go back to "normal" size. I think this is not that bad, as having the window move all the time is pretty annoying. Can you test it?
Created attachment 29148 [details] [review] Keep track of the heightest label so far
Good call on the window resizing. Replacing that line with req->height += max.change; fixes that, and my patch continues to be effective. On the subject of window movement, it's a call between looking right, or avoiding window movement. I chose the former, but that's open to debate. I didn't find the window movement particularly distracting, whereas off-center labels are noticeably ugly. The patch you suggested is a bit broken. While it prevents window movement or shrinkage, it messes up the terminal sizing. Try: 1. Start terminal. 2. Resize to 80x2. 3. Add a tab. 4. Notice how the terminal is now 3.5 lines tall, while reporting to the window manager as 80x2. The 0.5 line is just extra padding on the bottom. I think that the reason for this bug is that the selected label is some pixels taller than the rest. So, you automatically add this compensation when none is due. This is why I chose to write the more complicated mechanism -- I didn't see a good way of distinguishing selected labels from non-selected ones. Also, I'm not sure why you change the label requisition -- I think that's extraneous. (commenting it doesn't help the other problems though) Finally, the patch should probably disconnect the notebook requisition handler. If you have ideas for making your patch work, I'll be glad to test. However, I'm also attaching my patch with the window sizing fix, since it works quite well already.
Created attachment 29300 [details] [review] Don't use window_set_size to avoid terminal shrinkage
Created attachment 29334 [details] [review] The fix, without the sneaky cleanup. As requested, I moved out the clean-ups to bug 145596.
Created attachment 29391 [details] [review] Don't shrink terminal, with window_resize again. I messed up -- I must have had some stale files lying round when I tested substituting the window_resize with req->height += max.change; This substitution does not work at all. Thus, for the time being I uploaded the original patch that works, without the cleanup.
This patch should be reviewed.
There may be a case in which the patch doesn't prevent terminal shrinkage. Please hold off review/merging until I finish investigating.
I haven't encountered this problem since. I think it might have been a miscompilation (without the patch). Please review when you get the time.
Comment on attachment 29391 [details] [review] Don't shrink terminal, with window_resize again. I've found a way to reproduce the issue with my patch. So, it's broken, and ugly. Another solution is needed.
Removing the patch keyword then...
I think this might have been fixed by setting single-line-mode on the tab label's label. Is this reproducible on svn trunk?