Some users like to include type signatures in their configuration. The
HiddenWindows type constructor was not exported, making it impossible to
write a type signature when using hiddenWindows.
With this change, a user can write an xmonad.hs like:
import XMonad
import XMonad.Layout.Hidden (HiddenWindows, hiddenWindows)
import XMonad.Layout.LayoutModifier
myLayout :: ModifiedLayout
HiddenWindows
(Choose Tall (Choose (Mirror Tall) Full))
Window
myLayout = hiddenWindows $ layoutHook def
main :: IO ()
main = xmonad def { layoutHook = myLayout }
The current handle returned by `spawnPipe` doesn't have any encoding
and it uses the function fdToHandle which returns a Binary
Handle. When spawnPipe is used with a program like xmobar, this can
easily lead to errors:
λ> h <- spawnPipe "xmobar"
λ> hPutStrLn h
"\35753Haskell\25110\32773Ghci\33021\27491\30830\26174\31034\27721\23383\24182\19988\35835\21462\27721\23383\21629\21517\30340\25991\26723"
<stdin>: hGetLine: invalid argument (invalid byte sequence)
One workaround, to avoid this is to use `hSetEncoding`. But from
reading GHC's source code - the entire Handle and write operations
seems stateful. So doing something like hPutStr and hSetEncoding can
theoretically lead to an undefined state as the first write will use
latin encoding and the second write will use the new encoding. More
details about it are present here:
* http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Handle.Internals.html#writeCharBuffer
* http://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Buffer.html#CharBuffer
So having these new functions will ensure that we get the handles in
the proper encoding in the first place.
Prompts based on `mkComplFunList` and `mkComplFunList'` were not
taking into account the `searchPredicate` funtion from `XPConfig`.
This was rather confusing.
We fix it by passing `XPConfig` to these functions; although
this is strictly more than they need, it makes the breaking change very
easy to fix and is also more future-proof.
Provide a way to advertise _NET_WM_STATE_FULLSCREEN in _NET_SUPPORTED.
I had this hardcoded for a while but read the mpv manpage recently:
Specifically, yes will force use of NetWM fullscreen support, even
if not advertised by the WM. This can be useful for WMs that are
broken on purpose, like XMonad. (XMonad supposedly doesn't advertise
fullscreen support, because Flash uses it. Apparently, applications
which want to use fullscreen anyway are supposed to either ignore
the NetWM support hints, or provide a workaround. Shame on XMonad
for deliberately breaking X protocols (as if X isn't bad enough
already).
I'm not sure Flash is still a good reason these days to not advertise
fullscreen support yet still handle it and look like idiots while doing
so. (And if anyone thinks it is a good reason, their unchanged xmonad
config will continue behaving that way.)
