The silent error `user error (createFontSet)` would break certain
modules (like the prompt) by simply not showing anything.
Pango 1.44 dropped support for FreeType in favor of HarfBuzz, losing
support for traditional BDF/PCF bitmap fonts. Hence, some distributions
don't ship `xorg-fonts-misc` anymore.
Fixes https://github.com/xmonad/xmonad-contrib/issues/348
* New logout options
Factor out Mate logout action and add a shutdown action which the user can bind additionally or in its place.
* Add documentation
* Update CHANGES.md
Short-circuiting the search isn't worth the code complexity, so just
search for all windows with the same leader and then pick the first one
using `listToMaybe` and pass that to `doShiftTo`.
Also, rename to `shiftByLeader` because we aren't really shifting to the
leader itself. We just shift to another window that has the same leader.
Will be useful for shiftToLeader.
Use W.shiftWin instead of W.shift as it isn't guaranteed that the window
being managed by the ManageHook is still in focus.
When focus changes¹ on an inactive workspace (not `current`, but
`visible`), TrackFloating and UseTransientFor would think they should
use the remembered focus point as they look at the wrong (`current`)
workspace instead of the workspace they're supposed to layout, and so
focus seems to be out of their set of windows, when actually it is not.
Fix this by looking at the correct workspace.
¹) This isn't entirely straightforward, as there are normally no
keybindings or StackSet operations for this, but it's perfectly legal
to `W.view` the inactive workspace, change focus, and `W.view` back
in a single `windows` action.
If a manually crafted ClientMessageEvent with invalid (nonexistent)
ev_window is sent to xmonad (by sending it to the root window), the
nonexistent window is added to Urgents and stays there forever.
This can also happen when a window in Urgents disappears while xmonad is
restarting, in which case xmonad never sees the DestroyWindowEvent and
never gets to remove the window from Urgents.
As both of these are fairly unlikely, only do the cleanup in
startupHook to not waste cycles.
The EWMH support added in 7e9c986217 only added handling of
_NET_WM_STATE_DEMANDS_ATTENTION to handleEvent and cleanupUrgents, but
manual urgency clearing via clearUrgents or automatic urgency clearing
via filterUrgencyHook was left without EWMH support. This commit adds
the missing pieces.
Fixes: 7e9c986217 ("Add EWMH DEMANDS_ATTENTION support to UrgencyHook.")
Atoms are at most 32-bit even on 64-bit platforms, per the X protocol,
despite them being stored in a CLong. Even if they weren't (and they
are, see /usr/include/X11/Xproto.h and
https://stackoverflow.com/a/23265984/3407728), xmonadctl isn't unpacking
the CLong into multiple data items.
Stop pretending it has anything to do with time, it's zero, and it's not
being read anywhere, we're passing the parameter only because
setClientMessageEvent needs one. We should switch to
setClientMessageEvent' and pass no data, but that would move the X11
dependency lower bound.
- StatusBarConfig serves as an abstraction over status bars. This
enables users to customize their status bars without having to do
the plumbing themselves.
- Multiple status bars can be used directly thanks to the
StatusBarConfig, which provides a way to compose status bars
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
