The ppVisibleNoWindows was added in #241 but none of the modules that
rename/mangle workspace names were updated (or didn't exist at the
time). This fixes this.
Related: https://github.com/xmonad/xmonad-contrib/pull/241
Related: 670eb3bc60 ("Added pretty printer for empty visible workspaces")
The last release of wmctrl was in 2005 and it doesn't correctly set
source indication in _NET_ACTIVE_WINDOW client messages
(https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#sourceindication),
which is obviously completely irrelevant here, but if one decides to
implement clickableWrap for switching windows as well (like I did), it's
nice to use the same tool for it.
It's also nice to use a tool that compiles and runs on 64-bit
architectures without having to patch it (taken care of by distros,
though). :-)
526336ecec introduced a bug where
tab-completion has an issue when a completion contains spaces; it only
deletes the last word of that completion, causing the next TAB to again
select the current selection and add it to the command. In this way,
the prompt can get "stuck" on an item, endlessly adding all but the
first word to the command every time TAB is pressed.
C.f. xmonad/xmonad-contrib/issues/455
Just because there are some completions doesn't mean that the given
index may not still be too big.
Incidentally, this now allows every prompt to cycle through its items in
a nice way.
- `logWhenActive` to have loggers active only when a certain screen is
active.
- `logTitleOnScreen`, `logCurrentOnScreen` and `logLayoutOnScreen` as
screen-specific variants of `logTitle`, `logCurrent`, `logLayout`
- `logConst` to log a constant `String`
- `logMaybe` and `.|` to combine loggers.
Before c6cdb77e3b, handling of floats was
trivial (too trivial, and thus inefficient and flickery): any float
whose rectangle covered (RationalRect 0 0 1 1), regardless of what
screen or workspace it belonged to, got its borders hidden.
Then c6cdb77e3b added some nuance
(OnlyLayoutFloatBelow, OnlyLayoutFloat, OnlyScreenFloat) which requires
looking at floats in the context of individual screens. Unfortunately
the implementation only worked in singlehead setups, as it always used
only the active screen/workspace regardless of which screen/workspace
was currently being layouted. This resulted in the new functionality not
working correctly on inactive screens and also regressed the handling of
fullscreen floats on inactive screens.
The fix is conceptually easy: use the screen that is being layouted.
There is a catch, unfortunately: this code runs in redoLayout, but the
information we need is only available in modifyLayout and
modifyLayoutWithUpdate. I could store a screen id in the
ConfigurableBorder record in modifyLayoutWithUpdate and use it later in
redoLayout, but that'd be a massive hack, so what I do instead is to
find the relevant screen by searching for one that covers the `lr`
(layout/screen rectangle). In most setups, this should be reliable. If
it turns out it is not, we can fix this later.
Fixes: c6cdb77e3b ("'XMonad.Layout.NoBorders': various improvements:")
Fixes: https://github.com/xmonad/xmonad-contrib/issues/280
In c6cdb77e3b, several new constructors
were added but not "In order of increasing ambiguity (less borders more
frequently)" as the docs for data Ambiguity say. Correct the order and
clarify that Never only considers ambiguity of tiled windows (as in the
doc for smartBorders).
Fixes: c6cdb77e3b ("'XMonad.Layout.NoBorders': various improvements:")
Related: https://github.com/xmonad/xmonad-contrib/issues/280
If this is not done, trying to select another window with the mouse when
the treeselect window is up, the X server executes a pointer/keyboard
grab until `allowEvents' is called; which it never is and so both remain
frozen indefinitely.
C.f.:
- xmonad/xmonad/issues/116
- xmonad/xmonad-contrib/issues/445
If this is not done, trying to select another window with the mouse when
the prompt is up, the X server executes a pointer/keyboard grab until
`allowEvents' is called; which it never is and so both remain frozen
indefinitely.
C.f.:
- xmonad/xmonad/issues/116
- xmonad/xmonad-contrib/issues/445
So far, when `alwaysHighlight' was enabled and the user selected an item
while not having completely written it out in the prompt, the input
string and not the eventual completion string would be entered into the
prompt history, which is obviously not the desired behaviour. This can
cause the history to clutter up with all these abbreviations, making
subsequent invocations of the prompt tedious to work with.
For example, an input of "xm" would narrow to both "xmonad" and
"xmobar", but thanks to `alwaysHighlight' "xmobar" was selected. If the
user now pressed enter, the prompt would correctly return "xmobar" as
the string to act upon, but "xm" would be entered into the prompt
history!
This is needed because the cache directory is now a part of XConf, which
is calculated once on startup and hence any recalculation would be
fragile.
Some internal functions that are not exposed (like writeHistory) were
also changed to accept that directory as an argument.
Fixes#164.
It's not clear to me why these functions take in XPState as a param only
to then produce some XP () values. It seems like they could just as well
call `get`.
In order to effectively restart status bars without relying
on pipes, spawnStatusBarAndRemember saves the PID of status
bars to kill them with cleanupStatusBars.
Removed checking for docks
Cleaned imports
Use signalProcesGroup instead of inverting the PID
Updated the documentation
Updated the documentation
Stop recommending pipes as the best/first thing to do and instead
recommend property based logging for all bars that support it. Also
strongly recommend users to use the already pre-made functions that do
all of the plumbing.
Add comments for the arguments of the most important user-facing
functions.
In an effort to modernize XMonad.Hooks.DynamicLog (and thus to stop
recommending pipes as the best way to interface with xmobar), implement
property log based solutions for the most important functions. Sadly
dzen does not seem to support this kind of interfacing with xmonad.
The descriptions of xmobar, statusBar, and statusBar' have been updated
to reflect that they should be seen as secondary choices.
Starting with 5240116f3c we only support
GHC versions 8.4.4 and up (more precisely, the GHC version associated
with stackage lts-12 and up). The imports in question are now in
Prelude and need not be imported explicitly.
