-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
EWMH: Improve interface for custom sorting, filtering, renaming and window activation #626
Conversation
ee388b7
to
de7217f
Compare
I like the pragmatic approach 👍 Good job! |
This better matches the documentation. It is still, however, considered bad practice to rely on the order of these operations. `f` isn't meant to touch any extensible configuration. If it happens to do so anyway, it no longer loops. :-)
de7217f
to
e841081
Compare
Just one last missing TODO: X.H.Focus docs, so marking as ready to review and will hopefully finish that tomorrow morning. |
8c05c5e
to
1802f7a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not an expert on EWMH, but didn't notice anything wildly off; this approach looks pretty good to me 👍
331acc2
to
78c73ec
Compare
…ult types For configuration values that don't compose well using a Semigroup instance, provide a high-level API allowing arbitrary modification of the value, taking its Default if absent. This API is only usable for separate configuration data and cannot be used to guard addition of hook using `once`.
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
…tering and renaming Now that we have `XMonad.Util.ExtensibleConf`, users can comfortably use the `ewmh` combinator and still customize workspace ordering, filter out scratchpads and expose altered workspace names. To make this all work nicely, we introduce not one, but two configuration options: a sort/filter function and a rename function. This is because renaming and sorting in one go makes it hard (perhaps even impossible) to decide which workspace to switch to upon receipt of a _NET_CURRENT_DESKTOP request from a pager or wmctrl/xdotool. (The only reason this wasn't a problem before is because one could pass the renaming function to `ewmhDesktopsLogHookCustom` only, not `ewmhDesktopsEventHookCustom`, which is a confusing hack as can be seen in the related closed pull requests.) Related: xmonad#238 Related: xmonad#105 Related: xmonad#122
Related: xmonad#105 Related: xmonad#122 Related: f271d59 ("X.A.WorkspaceNames: Provide workspaceListTransform for EwmhDesktops")
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
Fixes: xmonad#396 Related: xmonad#192 Related: xmonad#128
We should get rid of this error-prone interface ASAP, so mark it as deprecated to give people some time to adapt their configs.
f7e4d44
to
f666cf4
Compare
Fairly straightforward, just add two hooks for (un)fullscreening. There are multiple motivations for this: * Users are calling for unfullscreened windows to revert back to their original location if they were floating. * XMonad.Layout.Fullscreen uses some deprecated exports from XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook. This commit only adds the hooks. Neither of the motivations are dealt with yet, so the docs are a bit terse still. Related: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fairly straightforward, just add two hooks for (un)fullscreening. There are multiple motivations for this: * Users are calling for unfullscreened windows to revert back to their original location if they were floating. * XMonad.Layout.Fullscreen uses some deprecated exports from XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook. This commit only adds the hooks. Neither of the motivations are dealt with yet, so the docs are a bit terse still. Related: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fixes: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fairly straightforward, just add two hooks for (un)fullscreening. There are multiple motivations for this: * Users are calling for unfullscreened windows to revert back to their original location if they were floating. * XMonad.Layout.Fullscreen uses some deprecated exports from XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook. This commit only adds the hooks. Neither of the motivations are dealt with yet, so the docs are a bit terse still. Related: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fixes: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fairly straightforward, just add two hooks for (un)fullscreening. There are multiple motivations for this: * Users are calling for unfullscreened windows to revert back to their original location if they were floating. * XMonad.Layout.Fullscreen uses some deprecated exports from XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook. This commit only adds the hooks. Neither of the motivations are dealt with yet, so the docs are a bit terse still. Related: xmonad#456 Related: xmonad#394 Related: xmonad#626
Fixes: xmonad#456 Related: xmonad#394 Related: xmonad#626
Description
Work in progress on #396. “#399 done right but quick.”
Yesterday's #625 is the glorious future, but it's too big a leap at this point in the release cycle. #399 is the ugly past with an ugly interface and no docs. This one is a pragmatic compromise: (mostly) backwards compatible interface extended with just enough ExtensibleConf bits to fix the problems at hand.
Supersedes #399.
Fixes #396.
TODO:
activateHook
And that's it! Fullscreen hooks are not critical and will be done post-release in #625 or a followup thereof.
Checklist
I've read CONTRIBUTING.md
I've considered how to best test these changes (property, unit, manually, ...) and concluded: the plan is to try to migrate my xmonad config that makes use of most relevant features and hope any bugs are apparent; I'm not expecting any, this should primarily be a change in interface, not in behaviour; the only risk is in the X.H.Focus module, which I'm afraid will need to be accepted
I updated the
CHANGES.md
file: existing commits update CHANGES.md, so this part is ready for reviewn/a I updated the
XMonad.Doc.Extending
file (if appropriate)