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.
