[Haskell-cafe] How to have a managed window unfocusable?
allbery.b at gmail.com
Mon Jul 7 03:17:24 UTC 2014
On Sun, Jul 6, 2014 at 10:57 PM, Magicloud Magiclouds <
magicloud.magiclouds at gmail.com> wrote:
> Thank you for the explanation. I always thought "focus" was managed by WM.
Explicit focus is managed by the WM. But you don't explicitly choose a
window to receive focus when the focused window goes away. The window
manager is not invoked then, instead the server checks the focus
inheritance policy *of the window that just closed*. And the default is to
give focus to (the X server's idea of) the "previous window". It doesn't
ask the window manager which that is, or ask the window manager to change
the focused window; it determines that and assigns focus itself, and the
window manager finds out about it from the subsequent FocusIn event.
> Is "above" also controlled by X instead of WM? I tried to patch the code
> of the clock to manage itself (keep itself topmost), but did not seem to
Older programs do it themselves; modern programs tend to expect the window
manager to do it based on EWMH hints, but xmonad does not implement the
window layers part of the spec --- and it's not clear *how* to implement it
in xmonad's model, as it runs into the same problems as Bug 4 (all the
horrible problems with floating windows in xmonad's model).
More or less, the way you'd have to do it is to call XRaiseWindow()
regularly, possibly in response to any X11 event other than Expose (sending
it on that event risks an infinite loop since the server will generate an
Expose event if any part of your window was covered). (This kind of thing
is why EWMH moved it into the window manager. Now if only we could do it
right given how the StackSet works....)
brandon s allbery kf8nh sine nomine associates
allbery.b at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe