[Xmonad] [HUMOR] xmonad useless without programming skills ?
Michael F. Lamb
mike at datagrok.org
Mon Sep 17 14:09:53 EDT 2007
> 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?
More information about the Xmonad