For ease of use, provide `fixSteamFlicker` as a pre-packaged
`floatConfReqHook` that can easily be added directly to a
`handleEventHook`.
Also, for discoverability, re-export it from X.U.Hacks.
Implements a replacement event handler for 'ConfigureRequestEvent' to
work around misbehaving client applications such as Steam, URxvt and
others that try to restore their absolute window positions. Primarily
motivated by the Steam client being almost completely unusable in xmonad
lately.
(I've been running this code in my xmonad.hs for other purposes for
years.)
More specifically, ignore ClientMessageEvents for unmanaged windows.
Steam likes to send _NET_ACTIVE_WINDOW requests for all its windows,
including override-redirect ones, which used to result in an invocation
of `windows` with a no-op Endo—equivalent to a call to `refresh`. But
this refresh makes Steam close its menus immediately.
Fixes: https://github.com/ValveSoftware/steam-for-linux/issues/9376
Fixes: https://github.com/xmonad/xmonad/issues/451
`EwmhFullscreen` unconditionally sinks windows in response to a
`_NET_WM_STATE` root window message removing `_NET_WM_STATE_FULLSCREEN`.
Unfortunately, at least some versions of either the Gtk or GNOME
libraries send this on startup while restoring a window's last
known state, which means a `manageHook` `doFloat` will be undone.
This change ignores the remove if the window is not fullscreen.
A followup issue, #865, has been added for the follow-on problem
that the floating state of a window is not restored on removal of
the fullscreen state.
Fixes: #820
Useful for restoring browser windows to where they were before restart
(which is something one should do several times a week as security
updates get released).
Added support for several more properties, and fixed parsing of many
others. Still doesn't handle COMPOUND_TEXT and the code in DebugWindow
is wrong. I have correct code in C++ but it will require some work to
translate to Haskell so it can be used in both places.
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: https://github.com/xmonad/xmonad-contrib/issues/456
Related: https://github.com/xmonad/xmonad-contrib/issues/394
Related: https://github.com/xmonad/xmonad-contrib/pull/626
Originally, `dynamicLogString` could have a bottom hidden in it and
thereby crash the `logHook`. Under some circumstances (see #801)
this could cause xmonad to get stuck. We now force the result, and
`dynamicLogString` catches the exception and substitutes a
message (currently "_|_"). Use `dynamicLogString'` for the old behavior.
This combinator forces XMonad to *not* set _NET_DESKTOP_VIEWPORT.
This information is picked up by polybar's xworkspaces module and used
to re-group the workspaces by monitor. I (and others) find this super
confusing, but polybar doesn't not seem open to addressing it.
https://github.com/polybar/polybar/issues/2603
Opting in to the old behavior of not managing this property is one way
to work around it instead.
Libraries like Control.Monad are no longer exported from
Control.Monad.Reader et.al.
Related: https://github.com/xmonad/xmonad/pull/427
xmonad/xmonad#d170e99bc5e97db96be9a02b72149103e8d419af
The links were broken due to:
1. Incorrect quotes (' instead of " for module links and occasionally
vice-versa).
2. Changes in the name of the "target" module not reflected in the
"source" docs.
3. Typos to begin with.
4. Use of `<foo>` in the docs is rendered as just `foo` with a link to
`/foo`.
5. Similarly for `"Foo"` if it starts with a capital letter (and hence
could be a module).
6. Markup inside `@` code blocks still being applied.
e.g. `@M-<arrow-keys>@` is rendered as `M-arrow-keys` with a spurious
hyperlink from arrow-keys to `/arrow-keys`, which is confusing.
Three links from XMonad.Util.Run have been removed outright, since
they're no longer examples of the usage of 'runProcessWithInput'.
WmiiActions has been gone since 2008, while XMonad.Prompt.Directory
and XMonad.Layout.WorkspaceDir haven't been using
'runProcessWithInput' since 2020 and 2012, respectively.
In some cases the `<foo>` were surrounded with @, especially in the
case of key definitions, for consistency. (This wasn't done
everywhere, because it looks ugly in the source.)
MoreManageHelpers has never been in xmonad-contrib. ManageHelpers
seems to fill the expected role.
In the case of the module description for X.H.ManageDebug the quotes
were simply removed because none of the likely options to make the
link work were successful.
Users may not see the warning that insertPosition definitely needs to be
inserted at the leftmost position, which can cause undesired behaviour.
Having a combinator that handles this automatically seems like a sane
idea.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/709
(Note that `docs` wasn't changed since it already inserts itself
rightmost.)
Essentially, whenever the tutorial actually has decent material on the
subject matter. The replacement is roughly done as follows:
- logHook → tutorial
- keybindings → tutorial, as this is thoroughly covered
- manageHook → tutorial + X.D.Extending, as the manageHook stuff the
tutorial talks about is a little bit of an afterthought.
- X.D.Extending (on its own) → tutorial + X.D.Extending
- layoutHook → tutorial + X.D.Extending, as the tutorial, while
talking about layouts, doesn't necessarily have a huge focus there.
- mouse bindings → leave this alone, as the tutorial does not at all
talk about them.
This was only used in three places throughout the module and is sort of
non-standard terminology, hence it might confuse users. Talking about
functions of type
XConfig Layout -> M.Map (ButtonMask, KeySym) (X ())
is relatively standard in other modules as well, so it's probably best
to remove the type alias for it.
This fixes several issues related to parsing of parent PIDs:
* A process with lines or spaces or parentheses in its process name
would confuse the code in X.A.SpawnOn and possibly lead to a
`Prelude.read: no parse` exception.
* `X.H.WindowSwallowing.isChildOf` looked for the parent PID anywhere in
the output of pstree, so single-digit parent PIDs would be considered
as parents of any process with that digit anywhere in its chain of
parent PIDs. (Note that apps in PID namespaces like in Flatpak often
have single-digit PIDs.)
* `pstree` is no longer required in `$PATH`.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/726
As the XMonad config is commonly customized by saying
def { startupHook = ...
, manageHook = ...
, ...
}
It seems consistent to allow the same for an individual hook config:
let urgencyHook = def { suppressWhen = ...
, remindWhen = ...
}
Add support for EZConfig-style bindings while also maintaining some
guarantees as to which type of representation we will store in the
extensible state. This means that parsing of the keys will happen no
later than the call to `modal`.
Users can choose to use `mkKeysEz` or `mkKeysFun` to create a new
collection of keys to bind for a mode. This is deemed more ergonomic
than exporting the respective constructors directly.
Mostly small things, like making imports line up with the provided
comments. Also:
+ Rename mode' -> modeWithExit. This seems like a better name for
discoverability reasons.
+ Make the fields of Mode strict, because they have no reason not to,
really.
Some panels—such as polybar—require _NET_DESKTOP_VIEWPORT support in
order to know which workspace is on which monitor. They are then able
to only show workspaces defined on the same output as the bar with just
X11 properties.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/708
`ManageDebug` was continuing to report in the `logHook` even after
the `manageHook` was done. In diagnosing this, I discovered that
the original code was using a tuple of `Bool`s and not even a
comment about which meant what.
The code now uses a proper pair type, and dedicated `data`s for
the two flags that make it clear what each means. This also fixed
the bug, so apparently I had the `Bool`s confused somewhere.
I also took the chance to clarify the documentation a little (a
misleading "persistent", since it doesn't use persistent XS) and
a few more cleanups. Also, it now logs all `manageHook` runs
before the `logHook` in case multiple windows are opened.
In a multi-head setup, it might be useful to have screen information of the
visible workspaces combined with the workspace name, for example in a status
bar. This module provides utility functions to do just that.
Windows created by X.U.XUtils.createNewWindow have _NET_WM_WINDOW_TYPE =
_NET_WM_WINDOW_TYPE_DESKTOP, which caused checkDock to match them and an
UpdateDocks event to be sent, causing an additional layout refresh
whenever a decoration window appeared.
This could in theory lead to a refresh loop with a layout (modifier)
that dropped and recreated its decoration windows on every
runLayout—which isn't entirely unreasonable, X.L.MouseResizableTile does
it, just luckily happens to not mark its windows as
_NET_WM_WINDOW_TYPE_DESKTOP.
In practice, such a refresh loop could be triggered when buggy
X.A.DynamicWorkspaces (before 929a6a3f6f) duplicated a Window in a
single workspace's Stack, and buggy X.L.SubLayouts then kept duplicating
the duplication (2 → 4 → 8 → …), triggering the creation of new
decoration window in each iteration.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/565
There's no reason (other than me forgetting to update the docs when
these add-Hooks were added) to steer users towards the ugly record-based
low-level API.
