> So that just leaves the _STATE_{ABOVE,BELOW} pieces.
Can these be removed (i.e. do we need to keep track of the earlier
state to return to it, as is the case for _FULLSCREEN)?
[ The answers below assume that there's no such need. ]
> 2) We could use them as a "set priority" sort of statement. This can
> have the odd effect that a window setting _ABOVE could _lower_ it,
> or _BELOW could _raise_ it, depending on where it was previously.
> That can't be right.
I'd take _ABOVE to mean "raise until _ABOVE" and _BELOW to mean "lower
until _BELOW" (so _ABOVE will never lower and _BELOW will never raise).
> So we have to come up with extra magic to be able to tell the
> difference between "has _ABOVE set because at some point the app
> asked to be _ABOVE" and "has _ABOVE set because config/user action
> set OTP to something positive and so we set it to inform the app"
> (and similarly for _BELOW). Ugh. Gremlins. [5]
I'm not sure we should bother with _BELOW and _ABOVE when the priority is
set from OTP itself rather than in response from EWMH.
I guess we could set _ABOVE if OTP decided to place it *exactly* in the
layer corresponding to _ABOVE (and remove it whenever it is moved to
some other layer), but for any other setting, better not mess with EWMH.
Stefan
