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")
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).
This fixes a bug when using multiple screens with different dimensions,
causing some floating windows to be smaller/larger than the size they
requested.
Some applications (e.g. pinentry) always map their window at (0, 0) so
floatLocation would compute the window size relative to the screen
containing (0, 0) and if the current workspace is on another screen with
a different size, this relative size results in a different absolute
size, which is undesirable for fixed size floats.
Other applications like ssh-agent place their window at the center of
the framebuffer (ignoring xinerama layout). Same problem.
Then there are apps that remember their position/size when minimizing to
tray and then attempt to restore it when reopened. Again, if they
restore it on another screen, we miscalculate the size.
The fix is to use the current screen for calculating dimensions of new
(not yet mapped) floating windows.
Co-Authored-By: Vincent Vinel <narthorn@gmail.com>
A side effect of that change is that our code no longer compiles with GHC
versions prior to 8.0.x. We could work around that, no doubt, but the resulting
code would require CPP and Cabal flags and whatnot. It feels more reasonable to
just require a moderately recent compiler instead of going through all that
trouble.
Particularly with the addition of build scripts, it can be tricky to figure out
what XMonad is doing when attempting recompilation. This makes it clearer by
adding some logging.
Due to this logging, I noticed that the lag of xmonad start was because it was
always recompiling! When I startup my computer, I do not want it to delay
rebuilding my window manager. This also fixes that issue such that it only
recompiles XMonad if it is going to reinvoke due to getProgName not being the
expected string.
This is slight change to the original implementation. This version
forces a recompile if XMonad detects a custom build script. The
previous version took into consideration the time stamps of the source
files.
For a custom build script, the source files may be located in another
location, or there could be dependencies unknown to XMonad. Better to
just always call the build script and let it work out if something
needs to be built.
