I spent the weekend communing with the ICCCM and the EWMH and will be sending a bunch of messages...
My first issue is with window gravity. The EWMH says: > Window manager implementors should refer to the ICCCM for definitive > specifications of how to handle MapRequest and ConfigureRequest > events. However, since these aspects of the ICCCM are easily misread, > this document offers the following clarifications: And then it proceeds to explain window gravity in a manner that, I'm fairly certain, is exactly wrong: > If an Application requests just a new size, its reference point does > not move. So for example if client window 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. There is nothing in the ICCCM that supports this idea. This seems to be confusing the win_gravity WM_NORMAL_HINTS field with the win_gravity XWindowAttributes field, which has the same name and uses the same values, but is otherwise unrelated (and doesn't normally apply to top-level windows). Here's the entirety of what the ICCCM says about WM_NORMAL_HINTS.win_gravity: > 4.1.2.3. WM_NORMAL_HINTS Property > > The win_gravity may be any of the values specified for WINGRAVITY in > the core protocol except for Unmap : NorthWest (1), North (2), > NorthEast (3), West (4), Center (5), East (6), SouthWest (7), South > (8), and SouthEast (9). It specifies how and whether the client window > wants to be shifted to make room for the window manager frame. > > If the win_gravity is Static , the window manager frame is > positioned so that the inside border of the client window inside the > frame is in the same position on the screen as it was when the > client requested the transition from Withdrawn state. Other values > of win_gravity specify a window reference point. For NorthWest , > NorthEast , SouthWest , and SouthEast the reference point is the > specified outer corner of the window (on the outside border edge). > For North , South , East , and West the reference point is the > center of the specified outer edge of the window border. For Center > the reference point is the center of the window. The reference point > of the window manager frame is placed at the location on the screen > where the reference point of the client window was when the client > requested the transition from Withdrawn state. > > 4.1.5. Configuring the Window > > The border width to be used and win_gravity position hint to be used > are those most recently requested by the client. "It specifies how and whether the client window wants to be shifted *to make room for the window manager frame*." That is the ONLY meaning that the ICCCM gives to that field, and there's nothing in 4.1.5 to suggest anything beyond that. Furthermore, interpreting gravity the way the EWMH does violates one of the core principles of the ICCCM: > 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. A principle which the EWMH even quotes at one point: > To fulfill the ICCCM principle that clients should behave the same > regardless whether a window manager is running or not... The X server does not look at WM_NORMAL_HINTS. Thus, in the absence of a window manager, it is always the top-left corner of the window that remains pinned when the window is resized. Thus, an application that depends on the EWMH-specified behavior will behave incorrectly if no WM is running. (qv http://bugzilla.gnome.org/show_bug.cgi?id=338729) (So what's the point of the hint then? If an app wants to place itself in the lower-right corner of the screen, it should set its location to (screen_width - window_width, screen_height - window_height), with SouthEast WM_NORMAL_HINTS.win_gravity, and then if there is no window manager running, it will be placed flush against the corner of the screen, but if there *is* a window manager running, the wm will move the window up and to the left a few pixels so that the *window manager frame* is placed up against the edge of the screen, rather than being placed offscreen. Then if the window wants to resize itself while staying in the lower-left corner, it should simultaneously resize itself and move itself to (screen_width - new_window_width, screen_height - new_window_height), which again will result in either the window itself or the wm frame being flush against the edge of the screen, depending on whether or not a wm is running. The app behaves "the same" whether a windowmanager is running or not.) So, I recommend that that section of the EWMH be gutted and rewritten (I'll provide text if there is consensus that this is correct, though I haven't yet re-figured-out the parts about compensating for border_width), with a note pointing out that (a) a previous version of the spec recommended the wrong behavior, and (b) pre-EWMH window managers have differed in how they interpreted this anyway, and so therefore Clients SHOULD always include x and y coordinates in ConfigureRequests and _NET_MOVERESIZE_WINDOW requests for windows with non-NorthWest, non-Static gravity, to ensure that they get the behavior they want. -- Dan _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list