Re: Initial window placement

[Sasha_Vasko osca state mo us]

> If you think that ICCCM wording is bad and confusing, than it doesn't
> help to switch to a different terminology to clarify it without
> providing any reference points (pun intended).  Whether you like it or
> not, but ICCCM talks about frame/client ref points, so denial will
> just do no good.  If that language is confusing than take trouble to
> explain in the text why it's confusing, what new language you propose
> and how they are related to each other.

WEll, I thought that one should lookup list archives prior to posting
something like that. This all has been discussed about a year ago.
Still, since that question is of utter importance I'll take the trouble
and explain it all over again.

Just as a side note I'd like to mention that after reviewing this specs
David Rosenthal had specifically noted that this particular item has
been explained correctly and clarifies foggy ICCCM description rather
nicely.


ICCCM says :
In section 4.1.2.3. WM_NORMAL_HINTS Property:
<quote>
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.
</quote>

Then in section 4.1.5. Configuring the Window :

<quote>
The border width to be used and win_gravity position hint to be used
are those most recently requested by the client. 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.
</quote>

Now what is the problem with that language ?

1. It provides vague description on where the reference point
should be placed, instead of plainly providing formulas of
how it should be calculated based on exact values of window
size, position and border width.

2. The whole fact that you interpret last part of 4.1.2.3
as if it was talking about two different reference points is
an evidence of confusion resulting from reading it. In fact it
it speaks about single phisical location on screen :
"...reference point of the window manager frame
is placed at the location on the screen where the reference point of
the client window WAS...".

3. When it describes how ConfigureWindow request should be handled
it sends you back to 4.1.2.3 without mentioning that you really have
to recalculate reference point based on request's parameters and/or
original client's border width.

Now why does it talk about reference
point of the frame and client at all? What is really needed is
for window manager to have a way of calculating some anchor location
based on clients request and then translate this location into actuall
coordinates for the frame window. Here is what we get :

(client geometry)->Tc->(anchor point/reference point)->Tf->(frame geometry)

where Tc and Tf are conversion operators/procedures.