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. -- Alex Tarkovsky