On Fri, Sep 14, 2007 at 02:17:18PM +0200, Andrea Rossato wrote:

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.

But xmonad is also under rapid development, and has a long way to go (in my opinion--keep in mind I'm not a core developer). I'm sure once xmonad 1.0 is out, the config format will remain stable (apart from a hypothetical development branch), but for the forseeable future, I can certainly forsee changes to Config.hs, as we improve it--which is really a good thing for Haskell newbies! -- David Roundy Department of Physics Oregon State University

Don Stewart writes:

maillaxa:

...

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.

You can ensure better stability by following just the stable branch.

Also, using vimdiff (or some other diff tool) to compare your Config.hs against the default, should help with any merge.

-- Don

In this case, maintaining a local patch using darcs is much better. Xiao-Yong -- c/* __o/* <\ * (__ */\ <

sjanssen:

On Friday 14 September 2007 05:56:34 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.

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

Am I alone in this situation or not ? How haskell rookies like do ?

_______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

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

I think there are some steps you can take to alleviate your problem. First, you can upgrade less often. I think running the stable 0.3 release is a good idea -- it is robust and has nearly all of the features of the current development version. If you stick to stable releases you shouldn't have to update your Config.hs more than once a month.

Next, I think judicious use of a nice diff/merge tool will help. I'd use 'vimdiff xmonad-0.2/Config.hs xmonad-0.3/Config.hs', where the first is an old version with all your customizations, and the second is a pristine Config for the new version. Gradually port your customizations from left to right, and compile frequently to catch mistakes early.

Finally, if you're having trouble with a contrib module, check the usage info at the top of that module. Every module should have a working Config example (please report a bug if it does not!).

Should we add an FAQ on this, for how to manage Config.hs ? Examples include: * run the stable brance * diff with vimdiff or meld (another visual diff tool) * record your changes locally in darcs -- Don

alextarkovsky:

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.

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

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.

We use Haskell as the configuration language for expressivity only -- leading to the amazing explosion of extensions. Similar window managers make their own choices: ion -- you need to learn lua dwm -- you need to learn C wmii -- you need to write shell (or ruby) emacs -- you need to learn lisp Simple configuration of xmonad requires no Haskell skills, and we've had very very few complaints about config files not type checking, so all in all, I'm not terribly convinced the use of Haskell has been problematic. What would the alternatives look like? Some ad hoc 1st (or 0th) order, configuration language like .muttrc or something nasty like VimScript? -- Don

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.

I think a GUI to help set values, from a limited range based on their types, would be lovely. If someone is motivated enough to do this, the xmonad devs would happily support it. You could roll it up in gtk2hs in an hour or two, I'd imagine. Use the type information in the Config.hs file to determine acceptable ranges for values, and then have the gui constrain possible inputs to those ranges: strongly, statically typed config files, with a domain-specific gui. -- Don

Alex Tarkovsky writes:

Ideally a GUI-based configuration utility could be offered -- xmonad is

Practically, that's nearly impossible. Just imagine how it could be done to actually using a GUI-based configuration utility to do all the work of Emacs lisp.

an X11 application after all. If designed well, it could capture the flexibility of Config.hs. As for text file

Take an example of a window manager. There is not a useful GUI-based utility to configure FVWM. Only those window managers that have really few choices for users may have a beautifully designed utility. But those are barely configurable.

based configuration, the traditional UNIX option=value style is probably too limiting, so I concede that

I second that, since the option=value style is likely to introduce a new language -- most of the programs are moving to XML, though.

Config.hs should probably stick around for the more intrepid users.

It would be possible to make a GUI-based utility to configure some simple behaviours through some variables. However, maintaining a Config.hs file is indispensable to make xmonad highly configurable.

-- Alex Tarkovsky _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

-- c/* __o/* <\ * (__ */\ <

Sam Walters writes:

On Fri, Sep 14, 2007 at 07:35:22PM -0400, Xiao-Yong Jin wrote: :| It would be possible to make a GUI-based utility to :| configure some simple behaviours through some variables. :| However, maintaining a Config.hs file is indispensable to :| make xmonad highly configurable.

I think there has been an unspoken assumption that having a configuration utility excludes having a user-modifiable Config.hs file. If the

I would like a utility that can modify an existing Config.hs file. Probably, some special mark-ups in the file could permit this. Something like the customize-* functions in Emacs would do. Of course, it could also be a separated file. We could have two configuration files. One is automatically generated by the utility, and the other can be customized by the user. Some programs also do that.

utility generates a fresh Config.hs instead of modifying an existing one, you get the best of both worlds. The user would have the choice of using the generated file, modifying the generated file or using a file that came from another source.

In that case, you could only use that utility once, if you want to modify it a bit. But I don't think that utility is meant to be used only once.

Sam

-- Do not spoil what you have by desiring what you have not; remember that what you now have was once among the things you only hoped for. -- Epicurus _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

-- c/* __o/* <\ * (__ */\ <

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.

On Fri, Sep 14, 2007 at 02:44:13PM -0700, Don Stewart wrote:

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.

Yes, I can have a look (gtk2hs is something I'd like to start playing with). I'll report back on that. I think that when I'll have some time I'll also start writing some kind of tutorial about configuring and extending xmonad, something for a non-haskellers audience. Andrea

alextarkovsky:

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.

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

alextarkovsky:

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?

Its a generic architecture for mostly-native code Haskell apps, yet with dynamic reloading. Its a reimplementation of the `dynamic apps from the ground up' architecture described in the hs-plugins paper of 2004, where the static core runs in ghci. But we've got to play around with the code a bit first: its just an idea for now. -- Don

В Fri, 14 Sep 2007 15:59:20 -0700 Don Stewart пишет:

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

That would be cool! I disagree with the way dwm and xmonad are configured, because it complicates the distribution of this programs (dwm "hackers" think this is a Good Thing, bah!). Also xmobar uses configuration syntax similar to haskell and some parser library. Could this be an option for xmonad? -- Alexander Tsamutali

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

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?