Proposal for ConfigureRequest handling

[Dominik Vogt <dominik vogt gmx de>]

There has long been a problem with ConfigureRequest event handling
between clients and window managers.  In short, if the
ConfigureRequest contains a position for the window, there are two
possible ways to interpret it.

 1) The top left corner of the *client window* is placed at the
    given position relative to root.
 2) The top left corner of the *WM Frame* is placed there.

Strictly speaking, the ICCCM2 demands (2), but traditionally, many
clients ignored this rule and so do most window managers.  Some
of the newer WMs started to honour this rule, I assume mostly
because Java does.  Almost everybody should know the problem:
windows that try to move themselves to (0, 0) may end up with the
border off screen (with a type 1 WM) or have an additional of the
size of the borders (type 2 WM).  Furthermore, some applications
run off screen if confronted with eiter type WM.

For both placement strategies there are WMs that implement it and
clients that expext it - so the problem is not going to vanish
anytime soon, we simply have to live with it in general.

Right now I'm in contact with a Java developer who is willing to
finally find a solution for this problem and proposed setting some
environment variable or property.  So, the issue is somewhat
pressing if we don't want that another hack in Java is made that
almost nobody knows about.

----------------------- PROPOSAL ------------------------

What I propose the window manager sets a property on the root
window to indicate which placement strategy it uses, thus
allowing applications to detect the type of window manager and act
accordingly.

  _NET_WM_CONFIGURE_USES_STATIC_POSITION (1 x CARD32)

    0 = ConfigureRequest events that contain a position use the
        win_gravity field to find out the new position (type 2 WM)
    1 = ConfigureRequest events that contain a position ignore the
        win_gravity field and always assume StaticGravity to find
        out the new position (type 1 WM)
    UNSET = The application is out of luck and has to guess the
        type of WM

The window manager sets this property when started up and deletes
it when it terminates.

To allow switching window managers without restarting the X
client, there should be some client message sent to the client
indicating a change (?)

Maybe the client should evaluate this property each time it is
reparented?

Another option would be to set it on the client window itself,
thus allowing the window manager to treat each window differently.
The benefit would be that a WM can be configured to cope with both
types of application.  Personally, I'd prefer it this way, even at
the cost of wasting some memory per window.

-------------------- END OF PROPOSAL --------------------

Bye

Dominik ^_^  ^_^