-
-
Notifications
You must be signed in to change notification settings - Fork 280
X.H.EwmhDesktops: add a way to selectively ignore _NET_ACTIVE_WINDOW #110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Enough people are annoyed by the focus stealing behavior that I have On Sat, Oct 29, 2016 at 8:02 PM, Tomáš Janoušek [email protected]
brandon s allbery kf8nh sine nomine associates |
Maybe. I'm not the right person to ask that, anyway, as I rarely use the defaults, anywhere really. Anyway, I wanted to warn people that chrome/chromium 55 is broken and will crash when its _NET_ACTIVE_WINDOW requests aren't honored immediately. I'm getting bitten by that several times a day (as I'm unfortunately unable to change my habits quickly). Here's the report: https://bugs.chromium.org/p/chromium/issues/detail?id=670959 |
Is anyone still working on this? If not, I'll merge this code with #93 and re-submit... |
I sort of intended to look at the design suggested by @geekosaur in #109, but I don't think I'll get to it any time soon. Feel free to use my code in any way you like. :-) |
@SirBoonami take a look at #128 |
Didn't really have the time to look into it the last few months, but it certainly seems to be a better thought out solution than my clueless fumblings. I'll close my PR in shame and go help this guy out instead =) |
Closing as a duplicate since this can be done via #128 now. |
Uh, not quite. There is still no way to turn off the EWMH focus grabbing
behavior --- and a window requesting focus does not go through the
ManageHook.
…On Mon, Apr 10, 2017 at 3:29 PM, Peter J. Jones ***@***.***> wrote:
Closing as a duplicate since this can be done via #128
<#128> now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#110 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8SoPher75VD4hHRx66y4sQnumtc53lks5ruoMYgaJpZM4KkQEk>
.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
|
@geekosaur In that case, are you in favor of merging this PR? If so I'll bug @liskin about a |
As a stopgap, yes. Ideally I'd like something more flexible but it seems like nobody's in a position to write it. |
@liskin Please add a |
First, sorry for not responding, I was somewhat busy at the time and never got to it later. :-( From reading the code in #128 it seems to me that it does what this one does, and much more. I expect to try it myself soon, but I don't mind if this one is closed sooner if anyone else shares my feeling that it's completely obsoleted by #128. |
Oh, it's been reverted. :-/ |
a8a515e
to
837804c
Compare
837804c
to
f945045
Compare
This makes window switching apps like rofi and alttab able to activate ignored windows as well.
f945045
to
a0c971f
Compare
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Related: xmonad#396 Related: xmonad#110
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
…gnored This makes window switching apps like rofi and alttab able to activate windows even if the logHook doesn't activate them (which it doesn't by default, and that's a regression). Fixes: 45052b9 ("X.H.EwmhDesktops. run 'logHook' for activated window.") Related: xmonad#396 Related: xmonad#110 Related: xmonad#192
TODO: documentation in X.H.EwmhDesktops TODO: changelog TODO: adapt X.H.Focus Related: xmonad#396 Related: xmonad#110
These are useful when one blocks some _NET_ACTIVE_WINDOW requests but still wants to somehow show that a window requested focus. Related: xmonad#110 Related: xmonad#128 Related: xmonad#192
These are useful when one blocks some _NET_ACTIVE_WINDOW requests but still wants to somehow show that a window requested focus. Related: xmonad#110 Related: xmonad#128 Related: xmonad#192
These are useful when one blocks some _NET_ACTIVE_WINDOW requests but still wants to somehow show that a window requested focus. Related: xmonad#110 Related: xmonad#128 Related: xmonad#192
TODO Fixes: xmonad#396 Related: xmonad#110 Related: xmonad#192 Related: xmonad#128
These are useful when one blocks some _NET_ACTIVE_WINDOW requests but still wants to somehow show that a window requested focus. Related: xmonad#110 Related: xmonad#128 Related: xmonad#192
xmonad#192 introduced a breaking change: * `XMonad.Hooks.EwmhDesktops`   `ewmh` function will use `logHook` for handling activated window. And now  by default window activation will do nothing. This breaking change can be avoided if we designed that a bit differently. xmonad#192 changed `ewmhDesktopsEventHook` to invoke `logHook` instead of focusing the window that requested activation and now `logHook` is supposed to invoke a `ManageHook` through `activateLogHook` which consults a global `NetActivated` extensible state to tell if it's being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me. A better design, in my opinion, is to invoke the `ManageHook` directly from `ewmhDesktopsEventHook`, and we just need a way to configure the hook. Luckily, we now have `X.U.ExtensibleConf` which makes this straightforward. So we now have a `setEwmhActivateHook`, and the activation hook defaults to focusing the window, undoing the breaking change. Fixes: xmonad#396 Related: xmonad#110 Related: xmonad#192 Related: xmonad#128
xmonad#192 introduced a breaking change: * `XMonad.Hooks.EwmhDesktops`   `ewmh` function will use `logHook` for handling activated window. And now  by default window activation will do nothing. This breaking change can be avoided if we designed that a bit differently. xmonad#192 changed `ewmhDesktopsEventHook` to invoke `logHook` instead of focusing the window that requested activation and now `logHook` is supposed to invoke a `ManageHook` through `activateLogHook` which consults a global `NetActivated` extensible state to tell if it's being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me. A better design, in my opinion, is to invoke the `ManageHook` directly from `ewmhDesktopsEventHook`, and we just need a way to configure the hook. Luckily, we now have `X.U.ExtensibleConf` which makes this straightforward. So we now have a `setEwmhActivateHook`, and the activation hook defaults to focusing the window, undoing the breaking change. Fixes: xmonad#396 Related: xmonad#110 Related: xmonad#192 Related: xmonad#128
xmonad#192 introduced a breaking change: * `XMonad.Hooks.EwmhDesktops`   `ewmh` function will use `logHook` for handling activated window. And now  by default window activation will do nothing. This breaking change can be avoided if we designed that a bit differently. xmonad#192 changed `ewmhDesktopsEventHook` to invoke `logHook` instead of focusing the window that requested activation and now `logHook` is supposed to invoke a `ManageHook` through `activateLogHook` which consults a global `NetActivated` extensible state to tell if it's being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me. A better design, in my opinion, is to invoke the `ManageHook` directly from `ewmhDesktopsEventHook`, and we just need a way to configure the hook. Luckily, we now have `X.U.ExtensibleConf` which makes this straightforward. So we now have a `setEwmhActivateHook`, and the activation hook defaults to focusing the window, undoing the breaking change. Fixes: xmonad#396 Related: xmonad#110 Related: xmonad#192 Related: xmonad#128
These are useful when one blocks some _NET_ACTIVE_WINDOW requests but still wants to somehow show that a window requested focus. Related: xmonad#110 Related: xmonad#128 Related: xmonad#192
xmonad#192 introduced a breaking change: * `XMonad.Hooks.EwmhDesktops`   `ewmh` function will use `logHook` for handling activated window. And now  by default window activation will do nothing. This breaking change can be avoided if we designed that a bit differently. xmonad#192 changed `ewmhDesktopsEventHook` to invoke `logHook` instead of focusing the window that requested activation and now `logHook` is supposed to invoke a `ManageHook` through `activateLogHook` which consults a global `NetActivated` extensible state to tell if it's being invoked from `ewmhDesktopsEventHook`. This seems convoluted to me. A better design, in my opinion, is to invoke the `ManageHook` directly from `ewmhDesktopsEventHook`, and we just need a way to configure the hook. Luckily, we now have `X.U.ExtensibleConf` which makes this straightforward. So we now have a `setEwmhActivateHook`, and the activation hook defaults to focusing the window, undoing the breaking change. Fixes: xmonad#396 Related: xmonad#110 Related: xmonad#192 Related: xmonad#128
This comes handy if e.g. the focus stealing behaviour of some browsers
is undesirable.