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)
Using `ppPrinters` with `WorkspacePredicate` and `WorkspaceFormatter`
allows users to define custom workspace types, beyond the ones
integrated in PP (i.e. urgent, current, visible, visible with no
windows, hidden, and hidden with no windows). `WorkspacePredicate`s are
added for these predicates (`isType`) with unsafe versions that assume
that predicates with a higher precedence already faield `isType'`.
`WorkspacePredicate`s can also be combined and modified with `notWP`,
`andWP`, and `orWP`.
Related: https://github.com/xmonad/xmonad-contrib/issues/557
Co-authored-by: Tomáš Janoušek <tomi@nomi.cz>
This will make it easier to transition to an implementation of EWMH that
doesn't expose the individual hooks: X.H.ManageDocks would become a
deprecated compatibility reexport of X.H.EWMH.Struts for a release or
two, but the individual hooks need to be removed before that.
Note that individual hooks in X.H.EwmhDesktops were deprecated earlier
and individual hooks in XMonad.Hooks.UrgencyHook aren't exported any
more (or perhaps never been), so this only leaves X.H.SetWMName, which
unfortunately does not have a combinator interface at this point.
Related: https://github.com/xmonad/xmonad-contrib/pull/625
https://github.com/xmonad/xmonad-contrib/pull/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. #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: https://github.com/xmonad/xmonad-contrib/issues/396
Related: https://github.com/xmonad/xmonad-contrib/pull/110
Related: https://github.com/xmonad/xmonad-contrib/pull/192
Related: https://github.com/xmonad/xmonad-contrib/pull/128
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: https://github.com/xmonad/xmonad-contrib/pull/238
Related: https://github.com/xmonad/xmonad-contrib/pull/105
Related: https://github.com/xmonad/xmonad-contrib/pull/122
