When opening and then closing a tab, Terminal is resized but isn't done correctly. You end up with a smaller window then original, after opening/closing several tabs you need to resize the window because it gets too small. I didn't see the version I'm using listed, but its 0.2.9svn-28991.
I cannot reproduce it here (version 0.2.9svn-28782).
There is a race in the code. It's hard to reproduce but sometimes it happens.
I get this problem when I have a transparent background on my terminal windows. Currently, I have compositing and transparent backgrounds turned off, and the problem isn't occurring, or is rare enough that I'm not seeing it. With transparent backgrounds, windows resize incorrectly more times than not. Re-drawing/re-sizing windows is quite slow when I have transparent backgrounds on, so I guess it's this that's exacerbating the race condition. What it appears is happening (and I write this with no real understanding of what's going on) is that it's a race between the terminal to resize the window such that inner dimensions of the text area are the same, and the window manager to resize the window based on the new size constraints to be a similar 'outer' size to what it was before.
Created attachment 2349 manifestation Not only does the window get slightly resized, it gets completely confused about the COLSxROWS. I get this bug reliably, no compositing/transparency, Terminal 0.2.12, Xfce 4.6.1.
I seem to only be able to get it to happen by closing the first (left-most) tab.
This should not happen in trunk anymore (well I cannot reproduce it anymore). It was a weird race between size updates. Could someone test this in trunk too?
Still there in r30194 for me, it also doesn't seem to matter if its the first or second tab that I close. I don't see the race condition when my box is at 100% load, things open/close as expected. btw, great work on the Terminal updates lately!
Tried to fix this in the code but I can't. When I switch to the metacity window manager the problem disappeard, so maybe it's a race in xfwm4 with the geometry hints we use? Olivier? Any ideas?
Red title in search results please....
(In reply to comment #8) > Tried to fix this in the code but I can't. When I switch to the metacity window > manager the problem disappeard, so maybe it's a race in xfwm4 with the geometry > hints we use? Olivier? Any ideas? The WM does not set the size hints, it reads it. So if the hints are wrong (with xprop), it cannot be the WM fault.
This seems to be resolved for me with version 0.4.
The shrinking of the window's height (on my system) is definitely still there in 0.4.7. The confusion between rows and columns is a bug I've seen too but it isn't caused by closing tabs. It's caused by resizing the terminal after output has already been printed to it. If I want a bigger terminal it only works if I resize the window immediately after I open it.
methink it's a discrepancy in the size increments, xfwm4 will enforce the window size to match the size increments provided by the application, thus downsizing the window slightly to the closest multiple of the size increments. kwin does the same as xfwm4, but metacity is a lot less strict about it last time I checked.
The terminal resizes and goes off the bottom edge of the screen when not maximized. To reproduce, place a terminal at bottom of the screen and open a second tab. I would expect the window to not be resized as this would solve the problem. An alternative would be to have an option to display tabs when only one tab is open, although this would waste space on the monitor.
(In reply to comment #14) > The terminal resizes and goes off the bottom edge of the screen when not > maximized. > > To reproduce, place a terminal at bottom of the screen and open a second tab. > > I would expect the window to not be resized as this would solve the problem. An > alternative would be to have an option to display tabs when only one tab is > open, although this would waste space on the monitor. Please do not hijack this bug, this is a different issue fixed with git commit cee208fd and 798d9cd4
This particular bug has to do with size increments, I suspect it should be fixed with git commit bf911e27 The problem I suspect is a discrepancy with the size increments, that xfwm4 would try to fix by resizing the window so that the size actually match the size increment, thus inducing a race condition with Terminal. GNOME Terminal in gnome3 is broken the same, and the result is a loop of events which shrink the window automatically. git commit bf911e27 makes xfwm4 a lot more relax and ignore the size increment when receiving a configure request (ie honor what the apps asks for even if it goes against the size increment). Please try current git and report back.
I would even prefer not resizing at all when tabs come into play. Or at least allow a setting "Always show tabs". Maybe this is worth a separate request..
Pushed a new fix for this.
(In reply to comment #18) > Pushed a new fix for this. Just as comment #4 said, I've this problem, too. OS: Gentoo x86_64 Program: terminal 0.4.8 (Xfce 4.10) With: xfwm4 version 4.10.0 (revision cc70567) Compiled against GTK+-2.24.16, using GTK+-2.24.16.
(In reply to comment #19) > (In reply to comment #18) > > Pushed a new fix for this. > > Just as comment #4 said, I've this problem, too. > > OS: Gentoo x86_64 > Program: terminal 0.4.8 (Xfce 4.10) > > With: xfwm4 version 4.10.0 (revision cc70567) Compiled against GTK+-2.24.16, > using GTK+-2.24.16. Oh no, should refer to comment #3