Breaking change in EWMH window activation

[liskin]

#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.

I believe this breaking change can be avoided if we designed that a bit differently.

#192 changed ewmhDesktopsEventHook to invoke logHook instead of focusing the window that requested activation through _NET_ACTIVE_WINDOW, and now logHook is supposed to invoke a ManageHook through activateLogHook which consults a global NetActivated in extensible state to tell if it's being invoked from ewmhDesktopsEventHook. This seems convoluted to me.

A much better and simpler design, in my opinion, is to invoke the ManageHook directly from ewmhDesktopsEventHook, and we just need to figure out how to configure it. I propose adding ewmh' which would take an additional EwmhConfig record with a focusHook field. Additionally, this record can be extended with a handleFullscreen :: Boolean to make ewmhFullscreen unnecessary (and thus impossible to get the order between ewmh and ewmhFullscreen wrong, improving the user experience). We should also add a pagerFocusHook because while one might want to ignore browsers activating themselves, one usually doesn't want to ignore pagers (rofi, alttab, etc.) asking to activate said browser windows.

I'm marking this as blocker for release because #192 had been reverted before for similar reasons (introducing a major behaviour change, #161), and I believe it's worthwhile to try to avoid breaking changes if possible. Especially if said breaking change comes with a convoluted design. :-)

[sgf-dma]

#192 changed ewmhDesktopsEventHook to invoke logHook instead of focusing the
window that requested activation through _NET_ACTIVE_WINDOW, and now logHook
is supposed to invoke a ManageHook through activateLogHook which consults a
global NetActivated in extensible state to tell if it's being invoked from
ewmhDesktopsEventHook. This seems convoluted to me.

Well.. it invokes logHook because i was told to rewrite it that way in #162.
I still think, that my original design of invoking 'manageHook' is the better
one, but i certainly doesn't know enough to argue that this is correct from
the xmonad point of view. And i was told, that indeed it is wrong, and changed
as was suggested (after all, it does not make any big difference for the
module).

Extensible state, well.. in previous version (#128) it still was used to tell
whether window was activated or not. There're should be a way to distinguish
in 'ManageHook' between new and activated windows, otherwise 'FocusHook' has
no sense.

A much better and simpler design, in my opinion, is to invoke the ManageHook
directly from ewmhDesktopsEventHook,

Isn't this the same as was in version #128 ? If so, then read #162 for the
reasons it was changed.

and we just need to figure out how to configure it. I propose adding ewmh'
which would take an additional EwmhConfig record with a focusHook field.
Additionally, this record can be extended with a handleFullscreen :: Boolean
to make ewmhFullscreen unnecessary (and thus impossible to get the order
between ewmh and ewmhFullscreen wrong, improving the user experience).

Well, i don't think, that having several ewmh is better, but it does not
make any difference for me. If you think, it's better, let's do it.

What other fields of 'EwmhConfig' would be?

We should also add a pagerFocusHook because while one might want to ignore
browsers activating themselves, one usually doesn't want to ignore pagers
(rofi, alttab, etc.) asking to activate said browser windows.

'NetActivated' extensible state can be easily amended with this information.
Then, it may be used in 'FocusHook' to decide how to activate (by e.g. adding
predicate 'activatedFromPager' etc).

I'm marking this as blocker for release because #192 had been reverted
before for similar reasons (introducing a major behaviour change, #161), and
I believe it's worthwhile to try to avoid breaking changes if possible.
Especially if said breaking change comes with a convoluted design. :-)

Not exactly. I hardly imaging someone who really cares about that confusing
focus stealing window activation behavior, which was and is default for years.
It was reverted, as i said above, because it breaks something by using
'manageHook' not the way it was intended.

Also, your patch in #110 allows far lesser ways to configure focus behavior,
than X.H.Focus module. In fact, i don't think, that those (few) people who
have used X.H.Focus can go with your patch.

[liskin]

Also, your patch in #110 allows far lesser ways to configure focus behavior,
than X.H.Focus module. In fact, i don't think, that those (few) people who
have used X.H.Focus can go with your patch.

Oh, this is an unfortunatel confusion. I'm not at all suggesting to go with #110! I like what you did, and I'm definitely in favor of keeping X.H.Focus. It's good! Just the changes in EwmhDesktops need a bit of love.

Sorry if my comments weren't clear about this. I should have stated upfront that most of your changes are wonderful and only then proceed to the critique. (This is also why I'm putting this at the top of this reply.) I'll keep it in mind next time.

#192 changed ewmhDesktopsEventHook to invoke logHook instead of focusing the
window that requested activation through _NET_ACTIVE_WINDOW, and now logHook
is supposed to invoke a ManageHook through activateLogHook which consults a
global NetActivated in extensible state to tell if it's being invoked from
ewmhDesktopsEventHook. This seems convoluted to me.

Well.. it invokes logHook because i was told to rewrite it that way in #162.

Yeah, you were told by @geekosaur to use logHook but @pjones suggested a separate hook in #162 (comment) and I believe that is a far better option.

I still think, that my original design of invoking 'manageHook' is the better
one, but i certainly doesn't know enough to argue that this is correct from
the xmonad point of view. And i was told, that indeed it is wrong, and changed
as was suggested (after all, it does not make any big difference for the
module).

Invoking the manageHook is indeed a terrible design choice and I agree with @geekosaur on this. Invoking a ManageHook (uppercase M) is okay, I think.
Invoking the logHook may be less terrible, but it still feels somewhat convoluted as it causes additional logging, refreshes, requires out-of-band communication via extensible state, etc. And fundamentally, both logHook and manageHook are wrong as they're built for a different purpose:

manageHook for decisions about new windows, logHook for telling external entities (panels, pagers, compositors, etc.) about xmonad state. For reacting to events, there's handleEventHook, and it's no accident that the activation code used to be there. @geekosaur's example of XMonad.Hooks.FadeWindows usage of logHook is unfortunate, as it's more about telling the compositor something than it is about reacting to a focus change.

Extensible state, well.. in previous version (#128) it still was used to tell
whether window was activated or not. There're should be a way to distinguish
in 'ManageHook' between new and activated windows, otherwise 'FocusHook' has
no sense.

Again, I'm not saying we should use the manageHook, I'm saying we should use a separate ManageHook (capital M).

A much better and simpler design, in my opinion, is to invoke the ManageHook
directly from ewmhDesktopsEventHook,

Isn't this the same as was in version #128 ? If so, then read #162 for the
reasons it was changed.

Nope, see above.

Well, i don't think, that having several ewmh is better, but it does not
make any difference for me. If you think, it's better, let's do it.

The only point of having several ewmh is backwards compatibility, of course. Ideally we'd have just one parametric ewmh, but that ship has sailed a long time ago.

What other fields of 'EwmhConfig' would be?

Right now I'm thinking about configrable fullscreen request handling and activation request handling (the issue at hand). In the past there was some trouble with _NET_WORKAREA (0a8e68b) which could also be made configurable instead of just removing it, as people with just one output could possibly use this feature. (Not suggesting to reintroduce this, just an example of what could possibly be made configurable in EwmhDesktops.)

We should also add a pagerFocusHook because while one might want to ignore
browsers activating themselves, one usually doesn't want to ignore pagers
(rofi, alttab, etc.) asking to activate said browser windows.

'NetActivated' extensible state can be easily amended with this information.
Then, it may be used in 'FocusHook' to decide how to activate (by e.g. adding
predicate 'activatedFromPager' etc).

Yeah, that's one option, but it'd really be better if we could avoid passing information out-of-band via extensible state. Having two ManageHooks isn't all that bad, is it? Especially given that you can define them as one myFocusHook :: Bool → ManageHook and then set focusHook = myFocusHook False and pagerFocusHook = myFocusHook True.

I'm marking this as blocker for release because #192 had been reverted
before for similar reasons (introducing a major behaviour change, #161), and
I believe it's worthwhile to try to avoid breaking changes if possible.
Especially if said breaking change comes with a convoluted design. :-)

Not exactly. I hardly imaging someone who really cares about that confusing
focus stealing window activation behavior, which was and is default for years.
It was reverted, as i said above, because it breaks something by using
'manageHook' not the way it was intended.

Anyone that uses a pager like rofi or alttab to switch windows will have to care as your changes break this (in the default configuration).

[sgf-dma]

#192 changed ewmhDesktopsEventHook to invoke logHook instead of focusing the
window that requested activation through _NET_ACTIVE_WINDOW, and now logHook
is supposed to invoke a ManageHook through activateLogHook which consults a
global NetActivated in extensible state to tell if it's being invoked from
ewmhDesktopsEventHook. This seems convoluted to me.

Well.. it invokes logHook because i was told to rewrite it that way in #162.

Yeah, you were told by @geekosaur to use logHook but @pjones suggested a
separate hook in #162
(comment)
and I believe that is a far better option.

Separate hook is certainly far better option, but i understand that as a
suggestion to add one more hook into 'XConfig', which (i suppose) will be far
more difficult and require far more discussions. So, i've choosed to modifying
existing ones.

I still think, that my original design of invoking 'manageHook' is the better
one, but i certainly doesn't know enough to argue that this is correct from
the xmonad point of view. And i was told, that indeed it is wrong, and changed
as was suggested (after all, it does not make any big difference for the
module).

Invoking the manageHook is indeed a terrible design choice and I agree
with @geekosaur on this. Invoking a ManageHook (uppercase M) is okay,
I think. Invoking the logHook may be less terrible, but it still
feels somewhat convoluted as it causes additional logging, refreshes,
requires out-of-band communication via extensible state, etc. And
fundamentally, both logHook and manageHook are wrong as they're built
for a different purpose:

manageHook for decisions about new windows, logHook for telling external
entities (panels, pagers, compositors, etc.) about xmonad state. For
reacting to events, there's handleEventHook, and it's no accident that the
activation code used to be there. @geekosaur's example of
XMonad.Hooks.FadeWindows usage of logHook is unfortunate, as it's more
about telling the compositor something than it is about reacting to a focus
change.

Extensible state, well.. in previous version (#128) it still was used to tell
whether window was activated or not. There're should be a way to distinguish
in 'ManageHook' between new and activated windows, otherwise 'FocusHook' has
no sense.

Again, I'm not saying we should use the manageHook, I'm saying we
should use a separate ManageHook (capital M).

Ok, so are you suggesting to add 'focusHook' to 'XConfig'?

A much better and simpler design, in my opinion, is to invoke the ManageHook
directly from ewmhDesktopsEventHook,

Isn't this the same as was in version #128 ? If so, then read #162 for the
reasons it was changed.

Nope, see above.

Well, i don't think, that having several ewmh is better, but it does not
make any difference for me. If you think, it's better, let's do it.

The only point of having several ewmh is backwards compatibility, of
course. Ideally we'd have just one parametric ewmh, but that ship has
sailed a long time ago.

What other fields of 'EwmhConfig' would be?

Right now I'm thinking about configrable fullscreen request handling and
activation request handling (the issue at hand). In the past there was some
trouble with _NET_WORKAREA
(0a8e68b)
which could also be made configurable instead of just removing it, as people
with just one output could possibly use this feature. (Not suggesting to
reintroduce this, just an example of what could possibly be made
configurable in EwmhDesktops.)

We should also add a pagerFocusHook because while one might want to ignore
browsers activating themselves, one usually doesn't want to ignore pagers
(rofi, alttab, etc.) asking to activate said browser windows.

'NetActivated' extensible state can be easily amended with this information.
Then, it may be used in 'FocusHook' to decide how to activate (by e.g. adding
predicate 'activatedFromPager' etc).

Yeah, that's one option, but it'd really be better if we could avoid passing
information out-of-band via extensible state. Having two ManageHooks isn't
all that bad, is it? Especially given that you can define them as one
myFocusHook :: Bool → ManageHook and then set focusHook = myFocusHook False and pagerFocusHook = myFocusHook True.

I'm marking this as blocker for release because #192 had been reverted
before for similar reasons (introducing a major behaviour change, #161), and
I believe it's worthwhile to try to avoid breaking changes if possible.
Especially if said breaking change comes with a convoluted design. :-)

Not exactly. I hardly imaging someone who really cares about that confusing
focus stealing window activation behavior, which was and is default for years.
It was reverted, as i said above, because it breaks something by using
'manageHook' not the way it was intended.

Anyone that uses a pager like rofi or alttab to switch windows will have to
care as your changes break this (in the default configuration).

Well, surprisingly, that annoying default comes in handy for someone :)
I couldn't even imagine.

I've tried these programs and as you said they don't work. But it's not that
easy to fix, as i suppose: when the window is on the hidden workspace,
rofi/alttab first send _NET_CURRENT_DESKTOP which switches workspace (avoiding
'FocusHook' altogether) and then send window activate request which is run
through 'FocusHook'.

So, to properly handle pagers we need to run 'FocusHook' also at
_NET_CURRENT_DESKTOP event, but 'FocusHook' just doesn't designed for that
(well, like 'ManageHook').

I think, this's more serious problem and i don't yet know how to solve it. So,
feel free to revert and make a release.

[geekosaur]

A few comments: * my `FadeWindows` example was intended to be of how to use a separate `ManageHook`, not the `logHook` * The proposal is to add a new config record for `ewmh`, not add a new field to `XConfig`

…

On Fri, Oct 30, 2020 at 1:08 PM sgf-dma ***@***.***> wrote: #192 <#192> changed ewmhDesktopsEventHook to invoke logHook instead of focusing the window that requested activation through _NET_ACTIVE_WINDOW, and now logHook is supposed to invoke a ManageHook through activateLogHook which consults a global NetActivated in extensible state to tell if it's being invoked from ewmhDesktopsEventHook. This seems convoluted to me. Well.. it invokes logHook because i was told to rewrite it that way in #162 <#162>. Yeah, you were told by @geekosaur <https://github.com/geekosaur> to use logHook but @pjones <https://github.com/pjones> suggested a separate hook in #162 (comment) <#162 (comment)> and I believe that is a far better option. Separate hook is certainly far better option, but i understand that as a suggestion to add one more hook into 'XConfig', which (i suppose) will be far more difficult and require far more discussions. So, i've choosed to modifying existing ones. I still think, that my original design of invoking 'manageHook' is the better one, but i certainly doesn't know enough to argue that this is correct from the xmonad point of view. And i was told, that indeed it is wrong, and changed as was suggested (after all, it does not make any big difference for the module). Invoking *the* manageHook is indeed a terrible design choice and I agree with @geekosaur <https://github.com/geekosaur> on this. Invoking *a* ManageHook (uppercase M) is okay, I think. Invoking *the* logHook may be less terrible, but it still feels somewhat convoluted as it causes additional logging, refreshes, requires out-of-band communication via extensible state, etc. And fundamentally, both logHook and manageHook are wrong as they're built for a different purpose: manageHook for decisions about new windows, logHook for telling external entities (panels, pagers, compositors, etc.) about xmonad state. For reacting to events, there's handleEventHook, and it's no accident that the activation code used to be there. @geekosaur <https://github.com/geekosaur>'s example of XMonad.Hooks.FadeWindows usage of logHook is unfortunate, as it's more about telling the compositor something than it is about reacting to a focus change. Extensible state, well.. in previous version (#128 <#128>) it still was used to tell whether window was activated or not. There're should be a way to distinguish in 'ManageHook' between new and activated windows, otherwise 'FocusHook' has no sense. Again, I'm not saying we should use *the* manageHook, I'm saying we should use *a separate* ManageHook (capital M). Ok, so are you suggesting to add 'focusHook' to 'XConfig'? A much better and simpler design, in my opinion, is to invoke the ManageHook directly from ewmhDesktopsEventHook, Isn't this the same as was in version #128 <#128> ? If so, then read #162 <#162> for the reasons it was changed. Nope, see above. Well, i don't think, that having several ewmh is better, but it does not make any difference for me. If you think, it's better, let's do it. The only point of having several ewmh is backwards compatibility, of course. Ideally we'd have just one parametric ewmh, but that ship has sailed a long time ago. What other fields of 'EwmhConfig' would be? Right now I'm thinking about configrable fullscreen request handling and activation request handling (the issue at hand). In the past there was some trouble with _NET_WORKAREA (0a8e68b <0a8e68b> ) which could also be made configurable instead of just removing it, as people with just one output could possibly use this feature. (Not suggesting to reintroduce this, just an example of what could possibly be made configurable in EwmhDesktops.) We should also add a pagerFocusHook because while one might want to ignore browsers activating themselves, one usually doesn't want to ignore pagers (rofi, alttab, etc.) asking to activate said browser windows. 'NetActivated' extensible state can be easily amended with this information. Then, it may be used in 'FocusHook' to decide how to activate (by e.g. adding predicate 'activatedFromPager' etc). Yeah, that's one option, but it'd really be better if we could avoid passing information out-of-band via extensible state. Having two ManageHooks isn't all that bad, is it? Especially given that you can define them as one myFocusHook :: Bool → ManageHook and then set focusHook = myFocusHook False and pagerFocusHook = myFocusHook True. I'm marking this as blocker for release because #192 <#192> had been reverted before for similar reasons (introducing a major behaviour change, #161 <#161>), and I believe it's worthwhile to try to avoid breaking changes if possible. Especially if said breaking change comes with a convoluted design. :-) Not exactly. I hardly imaging someone who really cares about that confusing focus stealing window activation behavior, which was and is default for years. It was reverted, as i said above, because it breaks something by using 'manageHook' not the way it was intended. Anyone that uses a pager like rofi or alttab to switch windows will have to care as your changes break this (in the default configuration). Well, surprisingly, that annoying default comes in handy for someone :) I couldn't even imagine. I've tried these programs and as you said they don't work. But it's not that easy to fix, as i suppose: when the window is on the hidden workspace, rofi/alttab first send _NET_CURRENT_DESKTOP which switches workspace (avoiding 'FocusHook' altogether) and then send window activate request which is run through 'FocusHook'. So, to properly handle pagers we need to run 'FocusHook' also at _NET_CURRENT_DESKTOP event, but 'FocusHook' just doesn't designed for that (well, like 'ManageHook'). I think, this's more serious problem and i don't yet know how to solve it. So, feel free to revert and make a release. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#396 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPRFIETTJ7EP2O2IO7Z63TSNLXIRANCNFSM4TE25KNQ> .

-- brandon s allbery kf8nh [email protected]

[liskin]

Again, I'm not saying we should use the manageHook, I'm saying we
should use a separate ManageHook (capital M).

Ok, so are you suggesting to add 'focusHook' to 'XConfig'?

No, I'm suggesting to add a EwmhConfig record type and a ewmh' that accepts it, and this record will have focusHook :: ManageHook, and perhaps a few other fields. Then ewmh becomes ewmh = ewmh' def and the default instance for EwmhConfig will have a focusHook that retains the original behaviour before your PR, that is to unconditionally honor the request and activate the window.

I've tried these programs and as you said they don't work. But it's not that
easy to fix, as i suppose: when the window is on the hidden workspace,
rofi/alttab first send _NET_CURRENT_DESKTOP which switches workspace (avoiding
'FocusHook' altogether) and then send window activate request which is run
through 'FocusHook'.

So, to properly handle pagers we need to run 'FocusHook' also at
_NET_CURRENT_DESKTOP event, but 'FocusHook' just doesn't designed for that
(well, like 'ManageHook').

I think, this's more serious problem and i don't yet know how to solve it. So,
feel free to revert and make a release.

No, to solve this we only need a different focusHook for pagers (which we detect via https://github.com/xmonad/xmonad-contrib/pull/110/files#diff-cf9308345d1d5de4c1e403c5874d91d723ffc5d4ff79b21c4dbfe6390a592598R236). Or, alternatively, we can simply hardcode into the event handler that if a pager is asking, no hook is consulted at all and the window is just activated. It's only if we wanted to actually tweak the pager activation behaviour that we'd need to introduce the second hook and maybe also care about _NET_CURRENT_DESKTOP.

Anyway, as I said, I'll be happy to make all these changes and I believe they're not difficult at all, I just wanted to hear what others think.

[sgf-dma]

Again, I'm not saying we should use the manageHook, I'm saying we
should use a separate ManageHook (capital M).

Ok, so are you suggesting to add 'focusHook' to 'XConfig'?

No, I'm suggesting to add a EwmhConfig record type and a ewmh' that
accepts it, and this record will have focusHook :: ManageHook, and perhaps
a few other fields. Then ewmh becomes ewmh = ewmh' def and the default
instance for EwmhConfig will have a focusHook that retains the original
behaviour before your PR, that is to unconditionally honor the request and
activate the window.

Ok.

I've tried these programs and as you said they don't work. But it's not that
easy to fix, as i suppose: when the window is on the hidden workspace,
rofi/alttab first send _NET_CURRENT_DESKTOP which switches workspace (avoiding
'FocusHook' altogether) and then send window activate request which is run
through 'FocusHook'.
So, to properly handle pagers we need to run 'FocusHook' also at
_NET_CURRENT_DESKTOP event, but 'FocusHook' just doesn't designed for that
(well, like 'ManageHook').
I think, this's more serious problem and i don't yet know how to solve it. So,
feel free to revert and make a release.

No, to solve this we only need a different focusHook for pagers (which we
detect via
https://github.com/xmonad/xmonad-contrib/pull/110/files#diff-cf9308345d1d5de4c1e403c5874d91d723ffc5d4ff79b21c4dbfe6390a592598R236).

Ok. Here is proof of concept fix for pagers based on your code.

https://github.com/sgf-dma/xmonad-contrib/tree/x.h.focus-2 with following main:

import XMonad

import XMonad.Hooks.EwmhDesktops
import XMonad.Hooks.Focus

main :: IO ()
main = do
        let fh :: ManageHook
            fh = activateByPager <+> activateOnCurrentKeepFocus
            xcf = ewmh $ def
                         { logHook    = activateLogHook fh <+> logHook def
                         , modMask    = mod4Mask
                         }
        xmonad xcf

activateByPager :: ManageHook
activateByPager = manageFocus (liftQuery isWmSourceUser --> switchFocus)

we don't need switchWorkspace in activateByPager because workspace is
switched by ewmh during handling of _NET_CURRENT_DESKTOP event.

Or, alternatively, we can simply hardcode into the event handler that if a
pager is asking, no hook is consulted at all and the window is just
activated. It's only if we wanted to actually tweak the pager activation
behaviour that we'd need to introduce the second hook and maybe also care
about _NET_CURRENT_DESKTOP.

In fact, because with this _NET_CURRENT_DESKTOP event sent by pagers
FocusHook's actions are not working properly (if i write 'keepWorkspace', i
expect, that it won't change), i think hardcoding pagers into ewmh is
better choice. And run 'FocusHook' only for windows, activated by
applications (source indication 1 and 0).

Anyway, as I said, I'll be happy to make all these changes and I believe
they're not difficult at all, I just wanted to hear what others think.

Ok, i didn't write any Haskell for a long time now, so it would be better, if
you implement this. Thanks.

[liskin]

Oh, I just realized that we already discussed a possible extensible API of EwmhDesktops with @geekosaur in #109. How could I forget that? I guess I better read up! :-))

Anyway, I'm working on this now, I'll have some code to show today or tomorrow I hope.

[liskin]

Especially insteresting is this comment of mine: #109 (comment). Apparently in 2016 I decided not to add a config parameter to ewmh, and now here I am, adding a config parameter and not being able to remeber why I decided against it. Fun times. :-/

[liskin]

Oh, right, back then I was talking about configurability of _NET_SUPPORTED, and decided it's better to just append to it using getWindowProperty32 and changeProperty32 … propModeReplace instead of centralizing the setting in EwmhDesktops. So that's a different kind of configuration parameter.

Also I'll try to summarize what @geekosaur and me were talking about: it seems we wanted to turn EwmhDesktops into a general framework that other modules like ManageDocks and UrgencyHook etc. (modules that are concerned with various aspects of EWMH) would plug into instead of being entirely separate and possibly colliding with one another.

I think that maybe adding an EwmhConfig could be a good first step. We can later add more fields and hooks into it, make it a Monoid, and let these other modules export their functionality as functions that construct EwmhConfig, which the user can then mappend together. Maybe we won't ever get to it, as the days of X11, and EWMH, and xmonad, seem to be numbered. I just wanted to understand and reiterate what the goal was, anyway.

So, yeah, focusHook or activateHook or whatever definitely seems to fit into this framework. Off I go to continue implementing it.

[liskin]

So far I got this: #399

Usage in my xmonad.hs looks like this:

myActivateHook = composeOne
    [ className =? "Google-chrome" <||> className =? "google-chrome" -?> mempty
    , pure True -?> doFocus
    ]

main = xmonad $
        … .
        ewmhFullscreen .
        ewmh' def
            { activateHook = myActivateHook
            } .
        … $
            def{ terminal = …, … }

Tomorrow I'll try to adapt X.H.Focus and address all the other TODOs (documentation, etc.).

[colonelpanic8]

Ugh I really don't care to read about everything that is going on here. All I know is that _NET_ACTIVE_WINDOW activation has stopped working from taffybar. @liskin do you have any idea why this might be?

EDIT: okay, now I see the change is described in EwmhDesktops. Not really sure why this had to be done this way. Pretty confusing for users... and seems like the interface is worse since now more configuration is required to get normal behavior.

[liskin]

It didn't have to be done this way, and it will be done differently, once I get my brain back into a usable state and turn #399 into something mergeable.

[liskin]

(Definitely do feel free to merge #399 into your local fork and use it. I've been running that code for months without any problems, it's just missing docs and stuff, and I might take a slightly different approach to API/configuration now that we have https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Util/ExtensibleConf.hs, but if you just want to bring back sane behaviour, #399 is easiest.)

[liskin]

@IvanMalison Oh, and I just realized that you commented that "_NET_ACTIVE_WINDOW activation has stopped working from taffybar" several months after I pushed 41ba7fd, which suggests that taffybar doesn't fill in source indication. If it did, window activation from taffybar would still work.

Indeed, https://github.com/taffybar/taffybar/blob/4d3227e9cd8308c1e43846496a8a7ab417ef8e5b/src/System/Taffybar/Information/X11DesktopInfo.hs#L191 should probably be

sendCustomEvent dpy cmd 2 root win

instead.

(This sendWindowEvent and sendCustomEvent abstraction is quite confusing, as the meaning of those data fields is different for each ClientMessage, and the type signature of setClientMessageEvent is downright idiotic, too. We do have setClientMessageEvent' now though.)

[geekosaur]

setClientMessageEvent is pretty much a mistake.