On Fri, Sep 14, 2007 at 08:12:25PM -0500, Spencer Janssen wrote:
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?
I disagree about the desirability of runtime configuration, but note that we already support quite a bit of runtime configurability, with runtime-configurable layouts (which can be abused to configure all sorts of other things). This is all transiently configurable, but that something we're keen to fix, by adding show and read capabilities to layouts. Just about the only thing that *isn't* runtime configurable is key bindings, and I'd definitely be glad to have that made configurable. For instance, it might be nice to be able to define a layout in which almost all key-bindings are available to the applications, which one could use for running emacs, for instance. In a language such as Haskell, it's hard to see why *any* configuration should be made static. What would be the benefit of this? Sure, it's not too hard to restart xmonad (and it would be nice to make this even less painful), but why require it at all? -- David Roundy Department of Physics Oregon State University