Xmonad/Notable changes since 0.12

This page is for keeping a record of significant changes in git xmonad and xmonad-contrib since the 0.12 releases (Dec 18, 2015). See git log in the source repositories for the patches and more details covering documentation and bug fixes not noted here.

non-breaking changes

(to come)

breaking changes

ManageDocks changes

The XMonad.Hooks.ManageDocks strut cache, introduced (buggily) in 0.12, has been rewritten. The current version requires, in addition to docksEventHook which became required in 0.12), addition of docksStartupHook to initialize the strut cache from existing windows.

A new docks combinator was also added; it adds all of the hooks needed to a config. This is now the preferred way to use ManageDocks, as it can be kept up to date with any new hooks that might be added in the future without requiring user config changes.

There is still a bug in the new strut code, insofar as it only detects struts on windows with the EWMH NET_WM_WINDOW_TYPE_DOCK window type (there is code to handle other windows, but it does not appear to be being used). Notably, this means that if you use dzen, you will need to add the -dock parameter for struts to work.

xmonad.state file bug

0.13 contains a change to pass state information in a file instead of on the command line, to avoid a state size limit that exists on all platforms other than FreeBSD. The release version has a bug: it doesn't remove the xmonad.state file (which is in the same directory as xmonad.hs) after reading it, so anything serialized across mod-q restarts ends up applying also to future sessions. This is known to include both XRandR screen information (part of the layout information that lives in the StackSet) and ExtensibleState information (including spawnOnce receipts, used to avoid rerunning them).

Current git versions of xmonad have this bug fixed. With 0.13 release, you will want to modify your X11 session's xmonad startup to remove the xmonad.state file before launching xmonad. (Note that you cannot do this in xmonad.hs, because either it will happen too late or you will break mod-q restarts.)

You also must be careful about removing xmonad.state while xmonad is running, since it will be recreated on mod-q. (Removing it and immediately exiting with mod-shift-q is okay.)