Since 4565e2c90e, not only do we raise the floating window to top when
starting dragging, we also restack all other managed windows directly
below it (mouse{Move,Resize}Window now call `float` while dragging,
which invoke `windows` and that restacks all windows). This means that
as soon as we start dragging, all xmonad-managed windows are raised to
the top, obscuring any unmanaged (override-redirect) windows that were
at the top before.
The good thing about 4565e2c90e is that since we refloat and refresh
on every mouse move while dragging, we no longer need the `raiseWindow`.
It was probably only there so that it stays visible when dragging
between Xinerama screens (3cb64d7461), and that's taken care of by
refloating the window on every move. As the refresh restacks everything
anyway, the only function of the `raiseWindow` is to stack windows above
unmanaged ones, which is likely undesirable.
There is still one known issue related to obscuring notifications:
https://github.com/xmonad/xmonad/issues/89
That one is caused by X opening new windows at the top of stacking order
and xmonad then restacking all other windows directly beneath them if
the new window is in the master position of the stack. Some notification
daemons like dunst work around this by raising themselves whenever a new
window is opened
(77bfbc4f7f/src/x11/x.c (L348)).
Fixing this one is considerably more complicated as we'd need to keep
track of (unmanaged) windows that wish to be stacked above new windows,
therefore this won't be addressed here, and probably won't be addressed
in xmonad core ever.
Fixes: https://github.com/xmonad/xmonad/issues/208
Fixes: 4565e2c90e ("fix #63: window jumping to origin position when dragging")
Unfortunately, our CI builds have a hard-coded assumption that all kinds of
LTS-X builds can be performed with the same stack.yaml file, which is not true.
We need to use specialized build instructions for each version of the
environment we're building in, e.g. stack-lts-16.yaml, stack-nightly.yaml, and
so on. Making that change is not super hard, but it's not completely trivial
either because the hooks use a hash of the stack file to determine whether the
cash is still valid, etc., and I'm not entirely sure about the best way to
adapt that code to support multiple YAML files.
For the time being, the most important build IMHO is Stackage Nightly,
because (a) we really want to support the nightly snapshot since (b) it can
compile the genmanpage executable relatively easily.
Let's use a moderately recent compiler like ghc-8.10.3
instead of the old 8.8.x branch for development. Same goes
for our dependencies; development should take place with
recent versions of our dependencies.
Improve handling of the whole XDG situation. This now looks as follows
1. If all three of xmonad's environment variables (XMONAD_DATA_DIR,
XMONAD_CONFIG_DIR, and XMONAD_CACHE_DIR) are set, use them.
2. If there is a build script `build' or configuration `xmonad.hs' in
`~/.xmonad', set all three directories to `~/.xmonad'.
3. Otherwise, use XDG_DATA_HOME, XDG_CONFIG_HOME, and
XDG_CACHE_HOME (or their respective fallbacks).
If none of the above exist, we default to using the XDG_* variables,
creating the necessary directories if needed.
* Updated CONTRIBUTING.md and MAINTAINERS.md
* Fixed broken GitHub links
* Added instructions on how to run tests
* Linked XMonad.Doc.Developing
* updated hackage link
This turns off the warnings about unused imports _unless_ one is using
the oldest supported version of GHC (right now that's 8.4.4 or older);
then it turns them into errors! This prevents xmonad from emitting
warnings about imports that have to be there due to backwards
compatibility, but are obsolete in newer versions (think MFP), while at
the same time preventing bitrot.
Starting with 28e75da77f we only support
GHC versions 8.4.3 and up (more precisely, the GHC version associated
with stackage lts-12.0 and up). The imports in question are now in
Prelude and need not be imported explicitly.
This makes it possible to query the current layout state, which might be
useful to e.g. show the current X.L.WorkspaceDir in xmobar.
Example of use (assuming myLayout is the layout that is assigned to
layoutHook):
asMyLayout (Layout l) = (`asTypeOf` myLayout) <$> cast l
…
layout <- asMyLayout . W.layout . W.workspace . W.current <$> gets windowset
case layout of
Just (WorkspaceDir d) -> …
Unfortunately this requires adding the Typeable constraint to a bunch of
classes in xmonad-contrib, so we need to merge those changes there first
(fortunately it doesn't need to go in lockstep, adding a Typeable
constraint to those classes in xmonad-contrib is harmless).
