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 338728 - wrong handling of resize with gravity
wrong handling of resize with gravity
Status: RESOLVED NOTABUG
Product: metacity
Classification: Other
Component: general
2.14.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on: 338729
Blocks:
 
 
Reported: 2006-04-16 19:26 UTC by Dan Winship
Modified: 2006-04-17 01:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2006-04-16 19:26:52 UTC
If a window with non-NorthWest win_gravity asks to be resized but not moved, metacity moves it so as to keep the gravity-specified corner in the same place after the resize.

I'm pretty certain this is wrong (and that win_gravity is only meaningful in the case where the window is being moved, or simultaneously moved and resized). In particular, metacity's behavior for the win_gravity WM_NORMAL_HINT seems to have been mistakenly influenced by either the specification of the win_gravity window attribute, or the gtk_window_set_gravity() method.

A particular example of this bug is with the calendar popup in the clock applet. If you place the applet in a bottom panel, click it to pop up the calendar, and then click back and forth between two days with different numbers of events listed, then under metacity, the bottom of the popup will stay pinned to the top of the panel, but under most other WMs (or with no WM), the top-left will stay pinned and the popup will either shrink and detach itself from the panel or grow and overlap the panel.
Comment 1 Dan Winship 2006-04-17 00:10:55 UTC
Oy. I've just discovered that this behavior is in fact explicitly "clarified" by the EWMH:

    * If an Application requests just a new size, its reference point does not
      move. So for example if a client has win_gravity SouthEastGravity and is
      resized, the bottom right corner of its frame will not move but instead
      the top left corner will be adjusted by the difference in size.

I still say that this isn't at all justified by the text of the ICCCM, and it seems to be a confusion based on other uses of gravity.

In particular, the ICCCM says:

    It is a principle of these conventions that a general client should
    neither know nor care which window manager is running or, indeed, if one
    is running at all.

The calendar popup works as intended when metacity is running, but behaves quite differently when there is no window manager running. This means that either (a) the authors of the ICCCM were just lying when they said clients shouldn't need to know if a wm is running, or (b) metacity is misinterpreting the ICCCM when it comes to ConfigureRequest events, and WM_NORMAL_HINTS.win_gravity is only supposed to apply to the way in which the window is shifted to make room for windowmanager decorations.
Comment 2 Elijah Newren 2006-04-17 01:22:14 UTC
We're going to do our best to follow the EWMH.  If you think the EWMH
is wrong, bring it up on the wm-spec-list (@gnome.org since
freedesktop didn't exist when that list was created).  It's NOTABUG
until then.