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

[Spencer Janssen]

On Friday 14 September 2007 17:55:27 Alex Tarkovsky wrote:
> 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,

Yeah, modifying Config.hs directly is surely a path towards destruction,
generating a boilerplate Main.hs which parses some sort of text database seems
perfectly reasonable, though.  (see notes about this in my other email)

> 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?


Cheers,
Spencer Janssen