Currently xmonad layouts have to be instances of Show so that the state can be
saved between restarts. XMonad.Util.Invisible works for state that can be
replaced without looking at the user's configuration.
To work around this, modules like XMonad.Util.WindowProperties have to be
written for layouts like XMonad.Layout.IM, when it would have been easier on
everybody to pass a function (ie ManageHook) to the IM layout.
The attached patch to xmonad core adds Data instances for layouts. The module
MergeLayout provides a startupHook that replaces the (I Nothing) that xmonad
gets on restart with what's in the xmonad.hs at the same spot.
Pushing this would break all layouts. Fixing them involves adding Data (and
Typeable) instances or contexts to existing instances. Normally that involves
just a `deriving(Data,Typeable)'. I can't convince ghc to generate the
instances in some cases: I manually wrote instances for Mirror and Choose in
the dpatch file attached.
Finally there is a possible objection that the Data instance will break
abstractions: having a (derived) Data instance allows access to the
constructors. Most of the time I think constructors are not exported to make
some changes easier, rather than to make sure invalid values cannot be
constructed (ex. Data.Map).
Original issue reported on code.google.com by vogt.a...@gmail.com on 29 Dec 2012 at 8:56
Original issue reported on code.google.com by
vogt.a...@gmail.comon 29 Dec 2012 at 8:56Attachments: