[Xmonad] [HUMOR] xmonad useless without programming skills ?

[Michael F. Lamb]

> Agreeing with Don that this is a perfect project for Gtk2Hs, I must also
> caution against storing anything in GConf. From a usability standpoint
> GConf is an abomination, ...

I wasn't advocating for GConf per se, only for the idea that whatever 
configuration format such a GUI-configurator might use stay separate and 
modular from XMonad base.

> It wouldn't be wise to have the GUI molest Config.hs either though,

Speaking very abstractly (which may of course be completely vacuous,) I 
think the strong Haskeller should be able to write (in Config.hs) code 
which queries configuration information from a GUI configuration tool 
plugin, rather than have a configuration tool which manipulates the 
XMonad state directly by writing a Config.hs or the like. That keeps 
things modular, allows various GUI builders to design however they like, 
and doesn't take any power away from a power user.

I notice that when I restart XMonad with alt+q, it somehow keeps its 
state. Having not investigated the code very deeply and only seeing what 
happens to the description in my process list, it looks like the current 
state is (pardon my vocabulary) serialized into a string which is passed 
to the new process and interpreted. Is this right?

Please correct me if I have this wrong (because I would love to know 
exactly how it works.) If it's about right, would it also be possible to 
do the same thing with the "state" of the GUI configurator? To be 
specific, serializing its state to a text file when changes are made, 
and loading it when initialized?

Does there exist an elegant pattern among Haskell programs for state 
serialization over multiple invocations?