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.
This technically introduces a regression with regards to the way that
modifier masks are printed in X.U.NamedActions and X.H.DebugEvents.
However, since this way of printing masks is move in line with
X.U.EZConfig, I personally don't think that this is noteworthy.
Hidden windows are now ignored by the layout so that hidden windows in
the stack don't offset position calculations in the layout.
Also in X.H.ManageHelpers: added `isMinimized`
The XS.modify was leaving thunk on the history that the demand analyser
could not prove to be neccesary as they depended on the future user
interaction. This was bad as the time advance there was less and less
neccesity to force such value, so the thunk would be increasing. Since the
datatypes that the `WorkspaceHistory` are really simple, we can just
evaluate and save a good chunk of memory.
This changes how the "is*Of" infix operators are hoisted into the
ManageHook context. Instead of `q ~? x` being a lifted version of
`isPrefixOf q x` we instead let it be a lift of `isPrefixOf x q`.
While this obviously does not matter for symmetric operators like `(==)`
and `(/=)`, for `isInfixOf` it is rather essential. The reason for that
is that the given `q` on the left side is an atom that can't (shouldn't)
be changed (by the user) and we only have control over the right hand
side. Otherwise, things like
title ~? "foo"
would read "only match if `title` is an infix of `foo`" instead of the
much more useful "only match if `foo` is an infix of `title`".
Fixes: 8b6f17ba66
Whenever possible, prefer the safe wrappers withWindowAttributes or
safeGetWindowAttributes to getWindowAttributes.
Places where these are not applicable are limited to layouts, where
there is not good "default value" to give back in case these calls fail.
In these cases, we let the exception handling of the layout mechanism
handle it and fall back to the Full layout.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/146
ConfigureEvents may occur after a window has been deleted, an UnmapEvent
has already been sent (and thus xmonad already unmanaged the window),
but before a DestroyWindowEvent is caught by the eventHook. For
example, this is the case when one uses smartBorders with a single
window (such that smartBorders is "active"). The ConfigureEvents
sensibly already have an empty stack (because the UnmapEvent has already
been received), which we then copy to the history.
Whenever a parent window has been found, the sensible thing to do is to
always restore it. The fact that oldStack is Nothing simply encodes an
empty workspace and is thus something we definitely need to handle as
well.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/638
In [1] we changed the return type to not be an IO action and hence this
example can't work, even with an otherwise correct configuration.
[1]: 168cb6a6c3 (Removed unnecessary IO)
