Re: resizing with gravity

["Elijah Newren" <newren gmail com>]

On 4/17/06, Dan Winship <danw novell com> wrote:
> > 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.
>
> Oh... I get it now. 4.1.5 says:
<snip>
> And if the ICCCM meant what the EWMH claims, then I don't see where the
> EWMH gets "If the Application requests a new position (x, y)..., the
> Window Manager calculates a new reference point" from. What in the ICCCM
> justifies computing a new reference point when the position changes, but
> not when the size changes? (Yes, it would be ridiculous to NOT compute a
> new reference point in that case, but IMHO that's just evidence that the
> EWMH reading of 4.1.5 is wrong.)

What justifies the totally arbitrary choice of keeping the top-left
corner of the client window fixed when getting a configure request
that specifies a new size without specifying a new position?  You
pointed out that the EWMH made an arbitrary choice required to make
sense of something not spelled out in the ICCCM, but you had to do the
same thing.  Stated differently:

As pointed out by Joe, section 4.1.5 also says
  Client configure requests are interpreted by the window manager in the same
  manner as the initial window geometry mapped from the Withdrawn state, as
  described in section 4.1.2.3.
But it can't be exactly the same, because (a) the application already
has a previously known position and size when it sends a configure
request, and (b) the configure request does not need to come with all
of x, y, width, and height specified -- any combination of the 4 (or
even none of the four) is allowed.  How to handle the difference is
left up to interpretation.  The EWMH tries to honor the specified
reference point (as a way of making room for the window decorations,
if you want to think of it that way), with the obvious interpretation
being that a new reference point must be computed when a new x & y are
specified.  You thought in terms of resizing keeping the top left
pixel of the client window fixed and making room for the decorations
when necessary.

At least, that's the best I can make of it.  I may still be missing
something, though.  Anyway, I'm still not seeing any inherent conflict
between the ICCCM and the EWMH interpretation (nor of the ICCCM and
what you suggest; it seems the ICCCM is just too vague)

> > 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.
>
> Yes, that's why I suggested the text about "Clients SHOULD always
> include x and y in this case", because then it works regardless of how
> the WM behaves. IOW, we declare the disputed functionality to be
> deprecated and essentially undefined, since as you note, it is unlikely
> that we will ever reach a state where all WMs implement it the same.

If we can verify that there's a method that does work well with
many/most non-EWMH-compliant WMs while still getting correct behavior
under EWMH compliant ones, I see no problem with adding an
implementational note section for application authors in this area of
the spec.

Further, declaring the resize-only behavior as deprecated may be fine,
but I don't like the idea of declaring the resulting behavior to be
undefined.  Noting that there are still (possbily widespread)
compliance problems is fine, but I think the EWMH definition of
correct behavior should stand.

> I guess that whether or not to change the recommended behavior is a
> separate question from whether or not the recommendation actually
> matches what the ICCCM says. But if it doesn't match the ICCCM, we
> should at least update the text to not claim it does. :)

True.  :)  But I really don't see where the two conflict; the EWMH
just declares what it feels should be the correct interpretation,
AFAICT.