5c50387db0
ConfigureEvents may occur after a window has been deleted, an UnmapEvent has already been sent (and thus xmonad already unmanaged the window), but before a DestroyWindowEvent is caught by the eventHook. For example, this is the case when one uses smartBorders with a single window (such that smartBorders is "active"). The ConfigureEvents sensibly already have an empty stack (because the UnmapEvent has already been received), which we then copy to the history. Whenever a parent window has been found, the sensible thing to do is to always restore it. The fact that oldStack is Nothing simply encodes an empty workspace and is thus something we definitely need to handle as well. Fixes: https://github.com/xmonad/xmonad-contrib/issues/638
xmonad-contrib
Community-maintained extensions for the XMonad window manager.
xmonad core is minimal, stable, yet extensible. xmonad-contrib is home to hundreds of additional tiling algorithms and extension modules. The two combined make for a powerful X11 window-manager with endless customization possibilities. They are, quite literally, libraries for creating your own window manager.
Installation
For installation and configuration instructions, please see:
If you run into any trouble, consult our documentation or ask the community for help.
Contributing
We welcome all forms of contributions:
- bug reports and feature ideas (also to xmonad)
- bug fixes, new features, new extensions (also to xmonad)
- documentation fixes and improvements: xmonad, xmonad-contrib, xmonad-web
- helping others in the community
- financial support: GitHub Sponsors, Open Collective
Please do read the CONTRIBUTING document for more
information about bug reporting and code contributions. For a brief overview
of the architecture and code conventions, see the documentation for the
XMonad.Doc.Developing module. If in doubt, talk to
us.
License
Code submitted to the xmonad-contrib repo is licensed under the same license as xmonad core itself, with copyright held by the authors.