This is hopefully harmless with well-behaved clients and ordinary xmonad
configs, and it enables using re-floating to apply size hints to
existing windows. The only visible behaviour change I can foresee is
that tiled windows (which ignore hints by default, unless
X.L.LayoutHints is used) will now snap to size hints whenever they're
floated (either via a keybinding or on mouseMoveWindow), whereas
previously they'd only do so on mouseResizeWindow.
My use-case for this is the following: when I change fonts in my
terminal, it updates its size hints and then sends a
ConfigureRequestEvent to change its size to keep the number of rows and
columns the same, and it also happens to reset the position to 0, 0. If
it's tiled, that request is just ignored and hintsEventHook handles the
layout refresh. If it happens to be floating, I want neither the move to
0, 0 nor the window size change to keep rows/colums, so I have a
handleEventHook that ignores that ConfigureRequestEvent and just
refloats the window, but I need a way to reapply size hints.
I could add a separate function that applies these hints to the floating
RationalRect, but that seems like a lossy operation due to the Doubles
in there. So I'd probably end up replicating most of the code from
floatLocation, and then I might just improve that instead… :-)
(I'll submit that custom ConfigureRequestEvent-ignoring hook to
xmonad-contrib later.)
`windows` generates mappings one screen at a time, starting with the
current. Tracking the windows it's already generated mappings for,
it excludes them from the tiles under consideration, hence supporting
window duplication in a first-biased manner. This allows the current
screen to win against any contenders and keep duplicated tiles within
reach.
However, it neglects to extend this treatment to floats; they end up
mapped in a last-biased manner. Consequently, duplicated floats become
very slippery, escaping to any inactive screen they can. This change
rectifies that issue.
See: xmonad/xmonad-contrib#797
Debian stable is not on 8.6, which was always our guide as to which GHC
versions we want to support.
In particular, this lets us get rid of all the quickcheck-classes
special treatment.
Related: 400730fe3b
This reverts commit 29475fa7f8f04dcb68913b78bffcdfa2e99ee33a.
xmonad/xmonad-contrib#731 fixes the WindowNavigation issue with alpha
channels, so we can re-enable alpha support. A subsequent commit will
bump versions/dependencies to keep things in sync, although strictly
speaking that's not necessary here.
This reverts commit c537a0658a3b9ec25cb1ce108d3cdd3dce27f111.
A discussion of why, as well as a new way forward, in being discussed in
https://github.com/xmonad/xmonad/issues/395
However, since we would like to release a new minor version soon-ish,
it's better to revert this for now.
Fixes: e5a258f19c0a ("Revert "Merge pull request #350 from Thiago4532/opaque-window-border"")
When dragging and resizing windows, users may expect the cursor to
change to indicate the respective behaviour. In particular, many other
window managers already do this [1] [2].
Thus, introduce a new (non-exported) `mouseDragCursor` function that
takes a cursor shape and change the generic resize and move functions to
use that. The reason that we don't change `mouseDrag` itself (for now)
is that this is exported and quite a few contrib modules use it—breaking
compatibility with xmonad-0.17.0 so soon after the release seems unwise.
Fixes: https://github.com/xmonad/xmonad/issues/348
[1]: https://git.suckless.org/dwm/file/dwm.c.html#l1567
[2]: 7a8fa9d27a/lib/awful/mouse/resize.lua (L23)
Create three sections (enhancements, bug fixes, breaking changes) in
order to organise the changes for the v0.17.0 release.
As discussed in [1], the breaking changes really aren't breaking changes
to normal users. The only exception could be the GenerateManpage
change, but even that is only important for distro maintainers. Hence,
move all of these to the very back, such that we can mention exciting
features like the stack integration at the top instead.
Related: https://github.com/xmonad/xmonad/pull/340
[1]: https://github.com/xmonad/xmonad/pull/340#discussion_r734956547
Turns out there was another aspect of `broadcastMessage` behaviour that
I missed in my review of the refactor: X.L.Tabbed updates the windowset
during handleMessage (via `X.O.focus`) and expects that change to
persist (by returning `Nothing` and hoping no other layout or layout
modifier returns `Just`). That's quite a hack, but the LayoutClass
interface doesn't allow a cleaner way to do this (well, some extensible
state plus a custom event hook might work, but then the layout isn't
self-contained any more).
And since rereading workspace layouts during `modifyLayouts` would force
this back into O(n²), we might as well revert the whole refactor. :-/
Fixes: https://github.com/xmonad/xmonad/issues/329
We now use this in `broadcastMessage`, so to not change which workspaces
get the message first, we need to change the order here. This wouldn't
normally be safe to do either, but there are no other uses of
`runOnWorkspaces` neither here nor in xmonad-contrib, so it should
actually be fine.
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 4565e2c90ef5, 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 4565e2c90ef5 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 (3cb64d74617), 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: 4565e2c90ef5 ("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>
