doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4.
This causes getDirectoryContents to raise an exception and X.P.Shell does not
render. This is only an issue if you have an empty string in your PATH.
Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so
this should not be an issue in the future.
The problem was that certain layouts keep their "world" state in their value,
which was thrown away and forgotten after ReleaseResources during toggle.
In particular, decorated layouts store some X11 handles in them and
allocate/deallocate it as appropriate. If any modification to their state is
ignored, they may try to deallocate already deallocated memory, which results
in a crash somewhere inside Xlib.
This patch makes Transformers reversible so that nothing is ever ignored. As a
side effect, layout transformers now do receive messages and messages for the
base layout do not need the undo/reapply cycle -- we just pass messages to the
current transformed layout and unapply the transformer when needed.
(This, however, doesn't mean that the base layout is not asked to release
resources on a transformer change -- we still need the transformer to release
its resources and there's no way to do this without asking the base layout as
well.)
The description for mirrored MouseResizableTile is now "Mirror
MouseResizableTile", to follow the standard of other layouts that can be
mirrored using the Mirror modifier.
Imagine a screen layout like this:
11111111
11111111
11111111
222222 <--- xmobar here
222222
222222
When placing xmobar as indicated, the partial strut property indicates that an
entire height of screen 1 is covered by the strut, as well as a few lines at
the top of screen 2. The original code would create a screen rectangle of
negative height and wreak havoc. This patch causes such strut to be ignored on
the screen it covers entirely, resulting in the desired behaviour of a small
strut at the top of screen 2.
Please note that this semantics of _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL is
different to what is in wm-spec. The "correct" thing to do would be to discard
the covered portion of screen 1 leaving two narrow areas at the sides, but
this new behaviour is probably more desirable in many cases, at least for
xmonad/xmobar users.
The correct solution of having separate _NET_WM_STRUT_PARTIAL for each
Xinerama screen was mentioned in wm-spec maillist in 2007, but has never
really been proposed, discussed and included in wm-spec. Hence this "hack".