"dirs" is used several times in xmonad-contrib as a short for
"directions" and when I tried renaming those uses, I had a really hard
time coming up with something nice/meaningful. Therefore I think it's
best if we rename this instead, "dirs" is a valuable part of the
namespace. :-)
Fixes: 735fb58f6c ("Revise XDG handling")
grabKeys doesn't check that a KeySym is valid before looking up the
KeyCode(s) it's bound to. In particular, KeySym 0 (NoSymbol) gets mapped to every
unbound KeyCode, since that's what XKeycodeToKeysym returns for those.
This can most easily be reproduced using `statusBar` in xmonad-contrib,
with def as the key-mapping function; this unexpectedly invokes the
following instances:
instance Default b => a -> b where def = const def
instance (Default a, Default b) => (a, b) where def = (def, def)
instance Default CInt where def = 0
thus producing a function which binds `toggleStruts` to the (KeyMask,
KeySym) pair (0, 0) (and demonstrating why Default is a dangerous
abstraction). The person who reported this used xmodmap to clear KeySyms
from their numpad keys, and then xmonad would bind strut toggling to the
entire numpad.
Note that it is not reliably possible to override `def` in this
situation (without introducing a new type); the only thing we can do is
try to avoid the aftermath, and I would expect that an inadvertent 0
KeySym is the most common error here anyway.
Fixes: https://github.com/xmonad/xmonad/issues/293
Fixes: 40cb12ce17 ("Grab all keycodes linked to each keysym, not just one")
Co-authored-by: Brandon S Allbery KF8NH <allbery.b@gmail.com>
These past months I've spent a lot of time working on xmonad¹ and I feel
like I've done a lot. This is, however, not sustainable long term. :-(
¹) primarily xmonad-contrib and the community in general
I'd like to try making my GitHub Sponsors profile a bit more visible,
hoping that would allow me to continue dedicating time to xmonad.
I know that the correct approach probably is for the xmonad project to
find a fiscal sponsor like the Software Freedom Conservancy or Open
Collective or something and accept donations as a project, and then
redistribute that to people, but I don't think the project has enough
momentum to do something as complicated as that. :-/
Related: https://github.com/xmonad/xmonad-contrib/pull/544
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
Since actions/virtual-environments#3268, the GHC PPA is no longer
enabled by default. :-(
(It would be better to use the haskell/actions/setup action, but it
insists on doing `cabal update` even if all we need is to install GHC
and Stack, which adds noticeable delay:
https://github.com/haskell/actions/issues/29)
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
Make it clearer that we in fact do not require implementations for a
minimal complete definition, but that the default implementations have a
certain kind of dependency structure.
The tests are implemented by using a newtype wrapper `TestStack`. This is to
avoid creating `Eq1` and `Show1` instances for `Stack` itself, which are needed
by quickcheck-classes to run with GHC less than 8.5. Tests are automatically
generated by `traversalLaws` and `foldableLaws` using the `Arbitrary` instance
for `TestStack`.
`Functor` is provided by DeriveFunctor.
`Foldable` uses `integrate` (`Stack`'s `toList`).
`Traversable` uses the `Reverse` Applicative to traverse the `up` list in
reverse order.
migrateState is only necessary when _live_ upgrading from xmonad 0.12,
so I believe we can drop it now.
This fixes a compilation warning that we'd otherwise have to suppress.
* rename workflow to Stack
* test all branches (provides feedback before opening a PR)
* split into buildenv deps and stack build
* make the deps list more git-friendly; tweak the deps
* use stack from github environment (I've seen the curl fail intermittently)
* use `*.cabal` to minimize diff between our repos
Related: https://github.com/xmonad/X11/pull/75
Related: https://github.com/xmonad/xmonad/issues/283
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.
