Each time I try to update xmonad (from darcs), my Config.hs is broken. This is,
for me, the major drawback of xmonad. I do not understand any a line of Haskell
and thus I am lost after each upgrade.

Hi,

Each time I try to update xmonad (from darcs), my Config.hs is broken. This is,
for me, the major drawback of xmonad. I do not understand any a line of Haskell
and thus I am lost after each upgrade.

Although I love xmonad, it is useless since I can't benefit of any upgrade
without boring you about my new Config.hs's problems...

On Fri, Sep 14, 2007 at 10:56:34AM +0000, Xavier Maillard wrote:

Hi,

Each time I try to update xmonad (from darcs), my Config.hs is broken. This is,
for me, the major drawback of xmonad. I do not understand any a line of Haskell
and thus I am lost after each upgrade.

Well, there were some changes to Config.hs but the core developers
seem quite committed in keeping the configuration file as stable as
possible, so hopefully this should not be a major issue in the future.

Hi,

Each time I try to update xmonad (from darcs), my Config.hs is broken. This is,
for me, the major drawback of xmonad. I do not understand any a line of Haskell
and thus I am lost after each upgrade.

Config.hs has been called our Haskell trojan horse -- perhaps it is time to
learn Haskell? ;)

Spencer Janssen wrote:

Config.hs has been called our Haskell trojan horse -- perhaps it is time to
learn Haskell? ;)

This is also an unspoken assumption in many of the replies to the OP,
and there's an important point there which everyone seems to be brushing
aside: Users who have absolutely no interest in programming or learning
how to program (the majority of computer users -- and yes, even of Linux
users) are going to be put off by xmonad and move on to some other
window manager that's easier to configure. That's regrettable because I
believe xmonad could benefit more than just programmers.

Xmonad should be explicitly advertised as a "window manager you need to
learn minimal Haskell to configure" unless a conventional configuration
scheme is planned. Otherwise it's just wasting the time of users who
would have chosen some other window manager had they known ahead of time
what they were getting into. Frustrating such users on the off chance
that one or two may decide to join the ranks of Haskellers is an unfair
trade-off IMO.

How many non-programmers are using tiling window managers in X11 though?

We use Haskell as the configuration language for expressivity only --
leading to the amazing explosion of extensions.

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

Ideally a GUI-based configuration utility could be offered -- xmonad is
an X11 application after all. If designed well, it could capture the
flexibility of Config.hs. As for text file based configuration, the
traditional UNIX option=value style is probably too limiting, so I
concede that Config.hs should probably stick around for the more
intrepid users.

How many non-programmers are using tiling window managers in X11 though?

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

How many non-programmers are using tiling window managers in X11 though?

I don't think that line of thinking is the right direction to go. I've
liked the idea of a tiling window manager before I began using or
hacking on it. I don't think there's anything inherently more
programmer-ish about a window management scheme which deviates from the
de facto "piles of crap" layout.

So, I'd agree with Alex on this, but on the other hand I would also
recoil a bit at the suggestion that this feature be added to the core,
since there are bound to be many differing opinions on what is best.

What would the alternatives look like? Some ad hoc 1st (or 0th) order,
configuration language like .muttrc or something nasty like VimScript?

Gah! Scary.

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool? That way, (in addition to Don being able to avoid
this question altogether,)

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

I'm not enough of a Haskell/XMonad hacker to fully think this through
though... I expect it might even sound quite naive. I'm sure I'll be
able to learn a lot from your replies.

de facto "piles of crap" layout.

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

Michael F. Lamb wrote:

de facto "piles of crap" layout.

Thanks, I don't think I've heard the classic WIMP paradigm described so
eloquently. ;)

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

I also think contrib is where it belongs.

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

Distros such as Ubuntu would most likely bundle it by default, but more
flexible and technically-oriented distros like Gentoo would keep it
optional (just as Gentoo does with xmonad extensions).

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

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, and I believe it only exists to placate critics
of Gnome's many boneheaded nips and tucks to various interfaces. From a
backing store standpoint, Gnome proper and Gnome-targeted applications
(not general GTK+ applications) remain the only consumers of GConf
services to date, so why not just use a single configuration data format
that all platforms can use without the GConf dependencies?

It wouldn't be wise to have the GUI molest Config.hs either though,
which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Spencer has a possible architecture based on ghci, which would give us
zero-compile reloading, using just the bytecode interpreter.

Don Stewart wrote:

Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Spencer has a possible architecture based on ghci, which would give us
zero-compile reloading, using just the bytecode interpreter.

Good to hear. I'd be interested in using it in some of my own projects.
Do you know if this will be a generic framework, or will it be tightly
integrated into xmonad?

Michael F. Lamb wrote:

de facto "piles of crap" layout.

Thanks, I don't think I've heard the classic WIMP paradigm described so
eloquently. ;)

Might it not be possible for there to exist something in XMonadContrib
that contains all the bloat necessary to provide a gtk (or qt) gui
configuration tool?

I also think contrib is where it belongs.

- Distributors could enable it in Config.hs and compile it for the
"non-programmers," while the rest of us are happy with our lean,
efficient core XMonad.

Distros such as Ubuntu would most likely bundle it by default, but more
flexible and technically-oriented distros like Gentoo would keep it
optional (just as Gentoo does with xmonad extensions).

- Various configuration fronts could be contributed and selectively
enabled/ignored (GTK storing data in the gconf registry thing, QT
however the KDE people store application data, vimscript, .muttrc, etc.)

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, and I believe it only exists to placate critics
of Gnome's many boneheaded nips and tucks to various interfaces. From a
backing store standpoint, Gnome proper and Gnome-targeted applications
(not general GTK+ applications) remain the only consumers of GConf
services to date, so why not just use a single configuration data format
that all platforms can use without the GConf dependencies?

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

which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Andrea, perhaps you'd like to play with gtk2hs to write a tool to modify
Config.hs ? Or anyone else interested -- I'm happy to guide people on
this matter, and it could be quite robust and workable, I suspect.

Spencer has a possible architecture based on ghci, which would give us
zero-compile reloading, using just the bytecode interpreter.

which brings me to another issue: Will xmonad be configurable at runtime
in the future? I realize it's still in early development, but down the
road it'll be awkward if users have a nice GUI configuration utility yet
have to recompile xmonad after clicking on a checkbox or spinner button.
Runtime code modification is the only thing I admire about Smalltalk,
and it's something I hope is practical in Haskell.

Note that it's possible to run modifications without recompiling at all, just
make a script (cd $xmonaddir; runghc Main.hs) called xmonad in your path.

I think the current static configuration is okay, we just need to make
restarts more seemless. Who says we can't write out a new Config.hs and
restart xmonad each time a user clicks on a checkbox?

Spencer has a possible architecture based on ghci, which would give
us zero-compile reloading, using just the bytecode interpreter.

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, ...

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

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?