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 649680 - geometry not work well with non-metacity/mutter
geometry not work well with non-metacity/mutter
Product: gtk+
Classification: Platform
Component: .General
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
: 680710 (view as bug list)
Depends on:
Reported: 2011-05-07 18:30 UTC by Yichao Yu
Modified: 2016-01-23 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---

Demonstrates the bug with vte (1.97 KB, text/x-python)
2011-08-04 23:37 UTC, Tony Houghton
Demonstrates the bug with a GtktextView (1.03 KB, text/plain)
2011-08-04 23:39 UTC, Tony Houghton

Description Yichao Yu 2011-05-07 18:30:31 UTC
When I run gnome-terminal. The window become smaller and smaller after it start. The same thing continues to happen if I maximize it but does not happen if I simply change its size.

Also, I have to move the window a little bit in order to see changes on the terminal (or it will be frozen there.)

This doesn't happen on 2.*.
Comment 1 Christian Persch 2011-07-31 12:55:21 UTC
Make sure you use a gtk3 build of gnome-terminal.

Also, I'm not supporting running g-t under kde; so try if this is reproducible using either gnome-shell, or metacity (with compositing disabled); otherwise it's NOTGNOME.
Comment 2 Tony Houghton 2011-08-03 12:19:37 UTC
The same thing happens running gtk3 builds of g-t and roxterm with xfwm4 as the window manager. See <>. Despite what I said in comment 4 there I now think the bug is either in vte's size request methods or in how g-t and roxterm calculate the geometry hints.

I guess kwin and xfwm4 strictly enforce the geometry hint settings whereas metacity lets size requests from child widgets override them. I don't know which is correct, but even if xfwm4 is getting that wrong, vte and/or g-t and roxterm are incorrectly using geometry hints which don't match the sizes.

g-t and roxterm both read the "inner-border" style property to set the base width and height in geometry hints. This still returns a value of 1 for each border, but the property is not documented for VteTerminal or GtkWidget. Is this value now incorrect? But what should we use instead? There doesn't seem to be anything about padding or borders in the vte API reference.
Comment 3 Christian Persch 2011-08-03 12:27:34 UTC
Please do try with gnome-terminal running under either metacity (with compositing disabled) or gnome-shell; otherwise it's NOTGNOME.

Padding/borders are undocumented, but the gnome-terminal source shows how to correctly read it (get the 'inner-border' style property). Work is being done to fix that (and much more) on the vte-next branch in vte git, but that won't land for gnome 3.2.
Comment 4 Tony Houghton 2011-08-03 17:05:33 UTC
It does work for me in metacity and gnome-shell/mutter, but that doesn't prove that vte isn't bugged. If this is happening because xfwm4 is enforcing geometry hints in preference to size requests, is xfwm4 definitely wrong, or are there 2 possible ways to interpret something that isn't clear in the ICCM spec? And if that is the cause, vte must be negotiating sizes that aren't consistent with what g-t has set as geometry hints.
Comment 5 Christian Persch 2011-08-03 17:35:48 UTC
I assume you're testing this with a gtk3 roxterm, right? Because geometry is known to be broken on gtk2.

I don't think vte size negotiation has anything to do with this. vte requests the size based on the rows/columns, the char size and the padding. If it gets what it wants, it uses that, and otherwise reduces its row/column count. So this is likely either a bug in the gtk geometry code, or in your window manager, or both.
Comment 6 Tony Houghton 2011-08-04 23:34:16 UTC
I've written two test programs, one with a VteTerminal and one with a GtkTextView. They add this widget to a window, with an optional GtkNotebook (-t on the command line), and set geometry hints (arbitrary in the case of the TextView). The Vte one behaves itself without a notebook, but with a notebook maximizing then unmaximizing triggers the bug. The TextView misbehaves even without a notebook.

So it almost certainly isn't vte's fault, but I think there must be a problem in gtk3's geometry code rather than the window managers. If only the window manager was bugged I would have thought gtk2 would have the same problem, and it would only affect one window manager, not at least 2.

How do we get this bug reassigned and retitled? Should I open a new one and make this a duplicate of it?
Comment 7 Tony Houghton 2011-08-04 23:37:57 UTC
Created attachment 193284 [details]
Demonstrates the bug with vte

Use -t to include a GtkNotebook tab. Maximizing and restoring should trigger the bug with xfwm4.
Comment 8 Tony Houghton 2011-08-04 23:39:13 UTC
Created attachment 193285 [details]
Demonstrates the bug with a GtktextView

Use -t to include a GtkNotebook tab. Maximizing and restoring should trigger the bug with xfwm4.
Comment 9 Christian Persch 2011-08-05 10:51:54 UTC
-> gtk
Comment 10 Tony Houghton 2011-09-20 01:14:39 UTC
I can't find a way to add to See Also, but Bug 658928 may be related to this one.
Comment 11 Martin Edlman 2011-09-22 12:11:07 UTC
Hello, I tested gnome-terminal (gtk3 app), XFCE Terminal (gtk2 app) and xterm (no gtk app) to see how each of them behaves with xfwm4 (all in Fedora 15).
G-t enforces xfwm4 to resize the window until it's unusable. Terminal and xterm work as expected, they accept the size assigned to them by xfwm4. Which is correct I believe.
The same problem arises in other WMs (not only xfwm4) according to other posts. If it works in Metacity, then there must be some (un)wanted workaround or a bug which negates/eliminates the g-t bug.
I have the problem from when I upgraded to F15. In Fedora 14 everything was fine as there was g-t built on gtk2. So it's indeed a problem of g-t 3 (or even gtk3) and how it hints WM and enforces it to resize the window.
Comment 12 Tony Houghton 2011-09-22 13:48:31 UTC
It isn't just g-t, anything which sets geometry hints can be affected - see my attachments. I'm now convinced it's a gtk3 bug. The reason things work in metacity is because it isn't so strict at enforcing the hints as xfwm4 was. xfwm4 has been patched to make it more relaxed about hints to work about this problem. 

However, Bug 658928, which I think could be another side-effect of the same underlying issue, also affects metacity. I haven't tried the patched xfwm4 so far.

I wonder if the cause could be something like failing to take into account the extra space taken up by other container widgets in the nesting chain between the geometry widget and the top level window.
Comment 13 Martin Edlman 2011-09-22 14:15:01 UTC
(In reply to comment #12)
> It isn't just g-t, anything which sets geometry hints can be affected - see my
> attachments. I'm now convinced it's a gtk3 bug. The reason things work in
> metacity is because it isn't so strict at enforcing the hints as xfwm4 was.
> xfwm4 has been patched to make it more relaxed about hints to work about this
> problem. 
> ...

I've tried patched xfwm4 which really works with g-t3 (and possibly other gtk3 apps which use hints). But the fix created another bug in horizontal/vertical maximize. See comments at So I stay with pre-fix version of xfwm4 which works fine, except some gtk3 apps (g-t etc.)
I hope that gtk3/gnome dev team will fix this issue soon as it is obviously their problem.
Comment 14 2011-09-22 14:40:59 UTC
FWIW, I am also seeing the geometry issue while running gnome-terminal with kwin in Arch Linux.

Comment 15 Rex Dieter 2012-01-18 13:59:55 UTC
So, seems xfwm4 developer believes this to be an issue here as well, quoting
It's a bug either in VTE or gnome-terminal which sets its size increment and size hints in such a way that the size is not a multiple of the increments.

A well behaved window manager will resize the window to match the size increments specified and gnome-terminal will try to resize again, thus causing a loop between the window manager and the app.

But the bug is in gnome-terminal (or in VTE, dunno), and not in the window manager. 

The same happens in KDE's kwin. I have relaxed the rules in xfwm4 to avoid this
..., but the bug lies in the app itself, and not in the window manager.
Comment 16 Tony Houghton 2012-01-18 14:23:04 UTC
I don't know if you're aware, but when a workaround was added to xfwm4 to avoid the loop it caused more misbehaviour, to do with restoring size after maximizing.
Comment 17 Aron Griffis 2012-05-07 13:36:56 UTC
In case it's helpful to somebody, I've been able to work around this problem in KDE as follows:

Go to System Settings -> Window Behavior -> Window Rules. Add a new rule called "Gnome-terminal workaround" which sets "Obey geometry restrictions" to "Force No". See the screenshots here:

I'm running g-t with KDE 4.8.3 on Fedora 17.
Comment 18 Art Popp 2012-07-16 01:36:02 UTC
(In reply to comment #17)
Thanks Aron,

Works for me in Fedora 17, with updates:

gnome-terminal- and KDE 4.8.4
Comment 19 Christian Persch 2012-08-13 18:30:28 UTC
*** Bug 680710 has been marked as a duplicate of this bug. ***
Comment 20 Tony Houghton 2012-08-13 21:12:46 UTC
Has anyone has a look at the code to see if they can work out what's going wrong? I'm thinking of looking myself if I get some time, but I doubt whether I'll be able to understand it well enough.
Comment 21 Frédéric Delanoy 2012-12-06 23:54:40 UTC
Occurs for me on Ubuntu 12.10 x86_64 with XFCE 4.10
Comment 22 itsjustarumour 2013-10-22 17:00:23 UTC
Still getting this bug with KDE 4.11 on Ubuntu 13.10 (64-bit).  

This is reported on the Redhat bugtracker here:

... where they say it is an upstream GNOME Terminal bug and recommend follow-ups go on this thread on the GNOME Bugzilla.
Comment 23 Ruslan Kabatsayev 2014-03-04 07:14:00 UTC
Why is this bug still UNCONFIRMED if people have confirmed it and also created several duplicates in various bug trackers?
Comment 24 Matthias Clasen 2016-01-23 06:42:11 UTC
The problematic aspects of gtk_window_set_geometry (geometry widget handling) have been disabled by now, so this problem will no longer occur. Of course, the desired behavior will not occur either...
Comment 25 Tony Houghton 2016-01-23 13:49:06 UTC
Does that mean cell-based geometry won't work from now on (ie if I resize a terminal window it will no longer show the columns and rows in a caption an resize in steps)? It's a shame it couldn't be fixed properly, but I guess I can live without it.