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 326759 - constraints bug
constraints bug
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
2.13.x
Other All
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2006-01-12 20:10 UTC by Matthias Clasen
Modified: 2006-08-05 16:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Matthias Clasen 2006-01-12 20:10:52 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:
Comment 1 Elijah Newren 2006-01-12 21:46:02 UTC
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?)
Comment 2 Elijah Newren 2006-01-12 22:14:44 UTC
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.
Comment 3 Elijah Newren 2006-01-12 22:27:33 UTC
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.
Comment 4 Elijah Newren 2006-01-13 03:21:56 UTC
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.
Comment 5 Matthias Clasen 2006-01-16 14:36:27 UTC
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.
Comment 6 Elijah Newren 2006-01-16 17:40:55 UTC
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.
Comment 7 Elijah Newren 2006-01-21 01:11:46 UTC
Are you using a sliding or auto-hiding panel by any chance?  (Bug 327822)
Comment 8 Matthias Clasen 2006-01-21 04:27:12 UTC
no, I don't.
Comment 9 Matthias Clasen 2006-08-05 13:12:34 UTC
I haven't seen problems like this in a while
Comment 10 Elijah Newren 2006-08-05 16:57:23 UTC
Ok, I'll go ahead and close; feel free to reopen if you see it again.