Added support for several more properties, and fixed parsing of many
others. Still doesn't handle COMPOUND_TEXT and the code in DebugWindow
is wrong. I have correct code in C++ but it will require some work to
translate to Haskell so it can be used in both places.
It turns out qutebrowser will place an entire `data:` URL in
`_NET_WM_NAME`, up to at least 389K characters including
newlines and possibly binary characters.
Clamping window titles to the first line, and to 2K chars
because `defaultShrinker` is quadratic in the title length.
Fairly straightforward, just add two hooks for (un)fullscreening. There
are multiple motivations for this:
* Users are calling for unfullscreened windows to revert back to their
original location if they were floating.
* XMonad.Layout.Fullscreen uses some deprecated exports from
XMonad.Hooks.EwmhDesktops and reimplements fullscreenEventHook.
This commit only adds the hooks. Neither of the motivations are dealt
with yet, so the docs are a bit terse still.
Related: https://github.com/xmonad/xmonad-contrib/issues/456
Related: https://github.com/xmonad/xmonad-contrib/issues/394
Related: https://github.com/xmonad/xmonad-contrib/pull/626
We test against 9.2.7 now, so we should make our stack config reflect
that—plus, it's more convenient for users, since one is more likely to
already have the latest minor version of GHC installed.
Related: 67064ddd9264bbe39d6fa88fd8336086817dd0db
The stack CI already tests against 9.2.7 instead of 9.2.5 (as the cabal
file said), since we just specify the major version of the LTS resolver,
and lts-20 is up to 9.2.7 by now. Not much has changed since 9.2.5, but
update the haskell-ci workflow regardless. Likewise, 9.4 can be bumped
one minor version, so do that as well.
Technically, contrib still does not build with stack, as it forces
xmonad-0.17.0, while only HEAD builds with newer mtl versions. However,
until our dependencies are at least revbumped, this may be the best we
can do.
Related: https://github.com/xmonad/xmonad-contrib/issues/805
Originally, `dynamicLogString` could have a bottom hidden in it and
thereby crash the `logHook`. Under some circumstances (see #801)
this could cause xmonad to get stuck. We now force the result, and
`dynamicLogString` catches the exception and substitutes a
message (currently "_|_"). Use `dynamicLogString'` for the old behavior.
X.L.StateFull's `FocusTracking` and the eponymous `TrackFloating` were
redundant, hence the former was slated for deprecation. However,
the latter and its host module are somewhat poorly named; the layout
modifier has little relation to floats. As such, it's renamed and
rehosted, becoming the eponymous `FocusTracking`.
The redundant offerings in the original modules are redefined in terms
of the new module where possible, and deprecated.
See: #418; comments on #253, #783.
These modules were duplicating a substantial amount of low-level code.
`X.A.CycleWorkspaceByScreen` had already separated most of the
implementation details from the logic with `repeatableAction`; all that
was left was to generalise it a little further, put it in a suitable
place and express the other modules through it.
This combinator forces XMonad to *not* set _NET_DESKTOP_VIEWPORT.
This information is picked up by polybar's xworkspaces module and used
to re-group the workspaces by monitor. I (and others) find this super
confusing, but polybar doesn't not seem open to addressing it.
https://github.com/polybar/polybar/issues/2603
Opting in to the old behavior of not managing this property is one way
to work around it instead.
hlint 3.5 is built against libtinfo6 and works on Ubuntu 22.04 without
needing to install libtinfo5.
Fixes: b7afb0c0bc3f ("ci: Pin runner in hlint, nix workflows to ubuntu-20.04")
...by introducing yet another special case. Unsurprisingly, this is
just a bandaid—the logic in this module is just wrong. It
purposefully (not introduced with this change) computes the wrong
positions for certain extreme points such that splitVertically (which
simply goes down the list of stack windows _in order_) still works.
What we should do instead is to either
- keep track of windows that want to change their size and compute a
rectangle for them first, or
- immediately when handling the resize message, compute *all* of the
new sizes immediately (instead of only for the window getting
resized).
The latter would force us to keep track of the size of the current stack
we operate in, but since 'handleMessage' lives in X this should not pose
a big problem. I reckon this is the better approach.
Fixes: https://github.com/xmonad/xmonad-contrib/issues/788
