Elijah Newren wrote:
> Disclaimer: I wasn't around when this section of the EWMH was written.
Nor was I.
> 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:
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.
The EWMH interprets "in the same manner as ... 4.1.2.3" quite literally,
as meaning that for every ConfigureRequest, "[t]he 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". Right?
Whereas I'm claiming that when 4.1.5 says "in the same manner as ...
4.1.2.3", that it's just understood that that means that references to
"transition from Withdrawn state" in 4.1.2.3 are to be translated into
references to ConfigureRequests in the 4.1.5 context, and so we end up
calculating a new reference point for every ConfigureRequest.
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.)
> IMO, it is the text of the ICCCM itself that violates that principle
> given that there were more than 8 different interpretations of it.
No, that just means it was badly written. :)
> 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.
> 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.
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. :)
> That seems like a less useful hint to me.
Well, sure, but that doesn't mean my explanation is wrong. There are
lots of things in the ICCCM that could be more useful if we changed our
interpretation of them.
> the EWMH
> reading does give consistent and expected behavior if all WMs (and X,
> as you point out) would implement it.
But WM_NORMAL_HINTS is explicitly defined as a channel of communication
between the app and the *window manager*, not the server. If the intent
had been for the X server to implement the EWMH 1.3 behavior, then the
WM_NORMAL_HINTS.win_gravity field would have been put somewhere else,
like XWindowAttributes* (and we wouldn't need _NET_MOVERESIZE_WINDOW,
because there'd be a field for gravity in XWindowChanges).
-- Dan
* Yes, actually XWindowAttributes already does have a win_gravity field,
but it refers to the behavior of the window when its *parent* is resized.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
