Re: resizing with gravity

["Elijah Newren" <newren gmail com>]

It seems that half the time or more when I speak up on this list, I
make a fool of myself -- and sometimes don't even realize it until
weeks or months later.  But, throwing caution to the wind, I'll pipe
up again...

Disclaimer: I wasn't around when this section of the EWMH was written.
 I also don't feel like an expert on gravity.  I did, however, finally
fix all remaining known bugs in metacity with respect to EWMH's
interpretation of win_gravity last fall...

On 4/17/06, Dan Winship <danw novell com> wrote:
<snip>
> 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:
<snip>

Personally, I don't see how the win_gravity text from the ICCCM
contradicts anything in the EWMH.

> "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.

I can see how it could be interpreted differently.  Quite honestly,
when I was trying to fix gravity and other constraints (size limits,
size hints, aspect ratio, etc.) in Metacity last fall, I recall I
reading the ICCCM and thinking that I didn't know how to implement it
and didn't know what it meant.  The EWMH was clear to me.  It's worth
noting that according to
  http://mail.gnome.org/archives/wm-spec-list/2002-November/msg00027.html
there were 8 or more existing interpretations of this part of the
ICCCM spec at the time this part of the EWMH was written.  (I.e. that
this portion of the text of the ICCCM is essentially useless)

Anyway, you focused on the "making room for the window manager frame"
part of the text, I would prefer to focus on the "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."  By focusing on that
part, the EWMH interpretation seems to fit just fine, to me.

> 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.

IMO, it is the text of the ICCCM itself that violates that principle
given that there were more than 8 different interpretations of it.  I
think the text of the EWMH is a fix to the ICCCM in order to follow
this principle.  See also
http://mail.gnome.org/archives/wm-spec-list/2002-November/msg00015.html.

Given that window managers still don't agree, we do have to pick
something and stick with it and will have to fix lots of apps & WMs. 
But, the EWMH already did that.  And it isn't at all clear to me that
there are more that behave one way than another, except that I'd
expect more to follow the EWMH now since the EWMH did declare correct
behavior.  It's worth noting that we only finally got the last little
bugs out of metacity with respect to the EWMH text and released in a
stable version 5 weeks ago.  Further changes to declared 'correct'
behavior would mean lots more time needed to fix everything, and it'd
probably also make people wonder why they could trust the new text.  I
think it'd do more harm than good.

> (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.)

That seems like a less useful hint to me.  Further, it seems to be
prone to be buggy in implementations -- if an app tries to move &
resize itself with e.g. SouthEast gravity so that its bottom right
corner is in the bottom right corner of the screen, and the app
happens to have a maximum size less than the apps requested size, then
the WM needs to resize the app.  According to your interpretation,
gravity shouldn't come into play in the resize, and thus the app would
be resized so that the southeast corner doesn't touch the edges of the
screen.  That doesn't seem like the app author intention; the EWMH
reading does give consistent and expected behavior if all WMs (and X,
as you point out) would implement it.  (Yes, that's a big 'if', but no
bigger than declaring any other interpretation to be correct and
hoping it gets adopted -- probably less so)

> So, I recommend that that section of the EWMH be gutted and rewritten

You'll probably not be surprised to find that my recommendation is
against.  Of course, feel free to point out anything I might have
missed.

Cheers,
Elijah