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