Re: Various comments, mostly on Implementation Notes

>> Window Movement
>> According to the ICCCM, applications should not see unnecessary
>> differences between running with or without a window
>> manager. Therefore window movements for already mapped windows, such
>> as ones requested by XMoveWindow(Display, Window, X, Y) have to move
>> the window Window to the coordinates (X, Y) and not cause the window's
>> window manager frame window to end up at (X, Y).
>This is just in complete disagreement with the ICCCM, which says:
>| Clients can resize and reposition their top-level windows by using the
>| ConfigureWindow request. The attributes of the window that can be
>| with this request are as follows:
>|  - The [x,y] location of the window's upper left-outer corner
>|  - The [width,height] of the inner region of the window (excluding
>| 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
>and section is pretty explicit in saying that X,Y should only
>be the upper left hand corner of the window when win_gravity is

Yep, you are absolutely right. With the default NorthWest gravity
client's position will be x+left_border_width, y+top_border_width.

Unfortunately many Window Managers, even thou they claim to be ICCCM
compliant, neglect to obey this. (Which is understandable, since its
much harder to implement then it looks like).

>Having this behavior be predictable is quite important... I don't want
>to have to try and guess in GTK+ whether I have a "ICCCM complaint WM"
>or a "Net WM Spec compliant window manager.
>(The current Java JDK tries to make this guess and falls flat, flat on
>its face.)

So true. Client apps should not attempt to set their exact location in X,
which makes things like NET_WM_STRUT kinda useless and dangerous.

>                                        Owen

Sasha Vasko

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]