That's where they belong. As XDG was more or less broken in previous
xmonad releases, we can assume few people use it so now's the best time
to move files around.
For users of `~/.xmonad`, this only causes intermediate outputs (.o,
.hi) to go elsewhere.
Fixes: https://github.com/xmonad/xmonad/issues/178
Some layout and layout modifiers that keep track of some window
properties don't do garbage collection and update their state when
windows are destroyed. By broadcasting this event, it should be easier
for layouts to clean up
Related: https://github.com/xmonad/xmonad-contrib/pull/474
It's often difficult to make contrib modules work together. When one
depends on a functionality of another, it is often necessary to expose
lots of low-level functions and hooks and have the user combine these
into a complex configuration that works. This is error-prone, and
arguably a bad UX in general.
This commit presents a simple solution to that problem inspired by
"extensible state": extensible config. It allows contrib modules to
store custom configuration values inside XConfig. This lets them create
custom hooks, ensure they hook into xmonad core only once, and possibly
other use cases I haven't thought of yet.
For more, see the related pull request to xmonad-contrib.
Related: https://github.com/xmonad/xmonad-contrib/pull/547
pandoc's API changes often enough that distros like Debian were patching
our GenerateManpage.hs to work with their version of pandoc, and it
doesn't build against any Stackage LTS except the recently released
LTS-17. Also, building pandoc from source takes quite some time and
resources.
But for what benefit? We're not using any special pandoc functionality
whatsoever. It's just that it was all in Haskell and the entire build
was orchestrated by cabal, but is all that complexity and resource
consumption worth it? I think not.
(Frankly, this whole thing was just a massive waste of time as the help
text in Config.hs isn't generated at all, so we still need to do this
manually. And then, the default key-bindings in core are unlikely to
change ever again.)
Let's simplify this:
* drop all dependencies except base and just run it through runhaskell
* add a Makefile and GH Actions workflow that invokes this after push
* only ship the results in release tarball, not the scripts which are
considered our dev infrastructure
Closes: https://github.com/xmonad/xmonad/issues/283
Related: https://github.com/xmonad/xmonad/pull/260
Related: https://github.com/xmonad/xmonad/pull/261
Related: https://github.com/xmonad/xmonad/pull/265
Related: https://github.com/xmonad/xmonad/pull/266
Related: https://github.com/xmonad/xmonad/pull/267
Related: https://github.com/xmonad/xmonad/pull/268
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.
