GNOME Bugzilla – Bug 326759
constraints bug
Last modified: 2006-08-05 16:57:23 UTC
Please describe the problem: There is a bug in the new constraints code, which sometimes causes windows to shrink to a narrow vertical stripe. I have seen this happen to my emacs on theme changes (probably because some neighbouring window got larger). Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Edge resistance only applies for manual user interaction, so having a neighboring window get larger from a theme change doesn't seem to make sense as a cause. I'd be more likely to suspect resize increment constraints. Anyway, this is really weird...by constantly switching between Crux and Glider metacity themes I can get gnome-terminal to slowly shrink (I don't notice any adverse affects on emacs but maybe different themes would do so?). A little extra debug spew produced seems to suggest that gnome-terminal is sending buggy configure requests: Window manager warning: At end of constraints; new : 842,693 +625,437 Window manager warning: ConfigureRequest: [5,22 +621,437] + 0 border_width; CWX: 1, CWY: 2, CWWidth: 4, CWHeight: 8, Mask: 12 Window manager warning: Setting up constraint info: orig: 842,693 +625,437 new : 842,693 +621,437 fgeom: 5,5,22,5 action_type : Resize is_user_action : false resize_gravity : NorthWestGravity fixed_directions: Y fixed work_area_xinerama: 0,27 +1600,1123 entire_xinerama : 0,0 +1600,1200 Window manager warning: At end of constraints; new : 842,693 +621,437 With each an every theme change, I get another configure request to reduce the width by 4 pixels. This seems especially odd given that gnome terminal has a resize increment of 8 x 17, and even odder that we apparently always honor it despite that fact. Any idea why gnome-terminal might do that? How do you get the emacs thing to trigger? (specific themes or something?)
Had a typo above; it's the gtk2 theme I'm changing, not the metacity theme. Also, it seems the base width of the terminal is changing every time the theme changes, so metacity isn't ignoring the size increment constraint after all--it's just always satisfied by these bizarre configure requests coming for gnome-terminal.
So, I have been trying all kinds of themes and can't duplicate the bug you claim with emacs. Are you using a GTK2 (i.e. CVS) based version of emacs or an older one with whatever crappy toolkit it uses? What font and what size are you using in emacs? Also, just to make sure I can reproduce, what's the output of 'xprop | grep -A 4 WM_SIZE_HINTS' for the emacs window? Which themes do you change between in order to notice the difference? The gnome-terminal bug appears to not be Metacity's fault as far as I can tell since it's just obeying the ConfigureRequests that it receives, but that was the only bug I was able to find in my testing.
One interesting point to note--I just tried this on a machine running a version of Gnome about 3 months out of date, except for Metacity for which it is running HEAD. It does not display the same gnome-terminal problem (the gnome-terminal shifts back and forth in side between themes instead of steadily shrinking with every change). I suspect the emacs thing you found may be similar to the gnome-terminal thing I found but need more info.
Hmm, I just saw it happen again, this time squishing my emacs to a small horizontal stripe. I'll watch it and report one I find a reliable way to reproduce.
If you see it again but don't realize how to reproduce, could you provide a screenshot when it happens? Seeing your general setup might give me ideas about methods to attempt to reproduce the problem. Anyway, I'll mark as needinfo for now.
Are you using a sliding or auto-hiding panel by any chance? (Bug 327822)
no, I don't.
I haven't seen problems like this in a while
Ok, I'll go ahead and close; feel free to reopen if you see it again.