Re: Various comments, mostly on Implementation Notes
- From: Sasha_Vasko osca state mo us
- To: John Harper <john dcs warwick ac uk>, Tim Janik <timj gtk org>
- Cc: Julian Adams <julian adams gmx net>,Sasha_Vasko osca state mo us,Matthias Ettrich <ettrich trolltech com>,Owen Taylor <otaylor redhat com>, wm-spec-list gnome org
- Subject: Re: Various comments, mostly on Implementation Notes
- Date: Fri, 18 Aug 2000 15:34:25 -0500
>On Fri, 18 Aug 2000, John Harper wrote:
>> Julian Adams writes:
>> |> I think we should remove that section from the spec, and possibly
>> |> replace it with a clear explanation of the ICCCM-required behaviour
>> |> (since this is often misunderstood).
>> |
>> |Could one of you guys rough this out - I have no idea what the exact
>> |ICCCM mandated behaviour is. Perhaps more importantly - would this
>> |compromise any other aspect of the WM-SPEC integrity ?
>>
>> How about:
>>
>> Window Movement
>> ===============
>>
>> Window manager implementors should refer to the ICCCM for definitive
>> specifications of how to handle MapRequest and ConfigureNotify events.
>> However, since these aspects of the ICCCM are easily misread, this
>> document offers the following clarifications:
>>
>> - Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS
>> for both MapRequest _and_ ConfigureNotify events [1]
>>
>> - Applications are free to change their win_gravity setting at any time
>>
>> - When generating synthetic ConfigureNotify events, the position given
>> MUST be the top-left corner of the client window in relation to the
>> origin of the root window (i.e., ignoring win_gravity) [2]
>>
>> [1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5
>> [2] ICCCM Version 2.0, §4.2.3
>>
>>
>> These are the things I was confused about, anyway; does anything else
>> need to be added?
>
>well, that cares of the response, but what exactly happens if
>an app (r third party app like a pager) issues XMoveWindow (w, x, y);
>does w end up at x,y or does it's frame end up at x,y. that's the
>one thing i want certainty about ;)
It depends on Gravity:
If an app (r third party app like a pager) issues XMoveWindow (w, x, y)
then;
StaticGravity:
window's left top corner will be placed at (x,y)
NorthWestGravity:
window frame's left top corner will be placed at (x,y)
NorthEastGravity:
window frame's right top corner will be placed at (x,y)
SouthWestGravity:
window frame's left bottom corner will be placed at (x,y)
SouthEastGravity:
window frame's right bottom corner will be placed at (x,y)
CenterGravity:
window frame's center will be placed at (x,y)
(x,y) will become a new "reference point" for the client window.
Implementation Note for Application developers:
When client window is resized - its reference point does not move.
So for example if window has SouthEastGravity and it is resized -
the bottom-right corner of its frame will not move but instead
top-left corner will be adjusted by the difference in size.
Implementation Note for WM developers :
when calculating reference point at the time of initial placement -
initial window's width should be taken into consideration, as if it
was the frame for this window.
Also I think we should add explanation ( since it is not covered by ICCCM )
for :
>> - Applications are free to change their win_gravity setting at any time
If application changes its gravity then Window manager should adjust the
reference point, so that client window will not move as the result.
For example if client's gravity was NorthWestGravity and reference point
was
at the top-left corner of the frame window, then after change of gravity to
the SouthEast reference point should be adjusted to point to the
lower-right
corner of the frame.
>
>>
>> |
>> |It would be a disaster if afterstep, kwin, sawfish, blackbox etc.
>> |implemented differing versions of the spec, but all posted the same
>> |_NET_SUPPORTED hints.
>>
>> Agreed.
>>
>> John
>
>---
>ciaoTJ
Thanks
Sasha Vasko
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]