Changes in the dev branch: xmonad can now be configured without recompiling the src!
Just an update on what's been happening in the development branch of xmonad. This is a quick summary of changes that will affect those who follow the darcs branch. The big merge is done, thanks to David for prototyping, and Spencer for kicking the types into shape! xmonad from darcs now builds as a library, as does the extension library. The (very) good news: * xmonad can be reconfigured without having to recompile the source! * multiple xmonad instances on a system can use different config settings * the contrib library builds as a normal library * Config.hs now lives in ~/.xmonad/xmonad.hs * configuration is now much simpler and shorter. My 100 line Config.hs is now around 5 lines, with the same result in particular point one was the key technical issue which made xmonad not quite a first class citizen on unix -- it had to be recompiled to be reconfigured. Those days are now passed. The bad news: * the format and location of Config.hs has changed slightly, meaning you'll have to edit your ~/.xmonad/xmonad.hs if you follow the darcs branch (and the upcoming 0.5 release) * documentation is now a little out of date. * xmonad now requires Cabal 1.2, which you can get with ghc 6.8, or from hackage.haskell.org Some initial examples of the ~/.xmonad/xmonad.hs configuration system are appearing on the wiki, http://haskell.org/haskellwiki/Xmonad/Config_archive and if you port your old Config.hs across to the new xmonad.hs style, please consider uploading both old and new to the wiki, to make it easier for others. Other documentation is likely to be out of date. If people have suggestions on how best to migrate users from the old to the new configuration system, I'd love to hear it. -- Don
On Tue, Nov 06, 2007 at 11:56:30AM -0800, Don Stewart wrote:
The big merge is done, thanks to David for prototyping, and Spencer for kicking the types into shape! xmonad from darcs now builds as a library, as does the extension library.
The (very) good news:
David and Spencer did really a great job. Thank you very very much! I've been fully playing with the new patches only in the last hour and I find all this library approach so exciting! It is just a regret for me not being able to fully participate to this branch. I'm teaching 3 courses this semester and it seems harder than I thought. Moreover the 6.8.1, which requires a new xmobar release, has taken away all my spare time. Which is bad, since I had to spend a lot of time to find a way to generate some documentation, and still I have no clue on how to solve my problems: it is not documented...:( By the way I hope I'll be able to help in the stabilization process: I'll start sending documentation fixes and so on. Once again: a big big thanks! Andrea
On Tue, Nov 06, 2007 at 11:56:30AM -0800, Don Stewart wrote:
Other documentation is likely to be out of date. If people have suggestions on how best to migrate users from the old to the new configuration system, I'd love to hear it.
As a reminder, to myself primarily, I think this should be the next priority before the 0.5 release. At a first sight this seems not very simple. Probably we should have some kind of a guidelines in order to have some kind of uniformity. Tomorrow I'll try to think a bit about it. And I join Don in asking for advice and suggestions. Thanks Andrea
mailing_list:
On Tue, Nov 06, 2007 at 11:56:30AM -0800, Don Stewart wrote:
Other documentation is likely to be out of date. If people have suggestions on how best to migrate users from the old to the new configuration system, I'd love to hear it.
As a reminder, to myself primarily, I think this should be the next priority before the 0.5 release. At a first sight this seems not very simple.
Probably we should have some kind of a guidelines in order to have some kind of uniformity. Tomorrow I'll try to think a bit about it. And I join Don in asking for advice and suggestions.
So the general rule is that your old config file goes into ~/.xmonad/xmoand.hs, you lift the top level bindings into a XConfig structure, and set: main = xmonad myconf where myconf is your XConfig structure. Its actually a lot simpler to rewrite, just selectively updating defaults you want to change. Leading to, e.g.: main = xmonad $ defaultConfig { borderWith = 4 } So to start this process off, we've got some 0.4 and 0.5 configs side by side on the wiki. http://haskell.org/haskellwiki/Xmonad/Config_archive Also nice, is now you can run arbitrary actions before xmonad runs, meaning all your .xinitrc and run-xmonad scripts can be moved into xmonad's config file. For example, no more dzen mucking around. You just: main = dzen xmonad to run default xmonad with a dzen logging status bar. Its all good. :)
On Wed, Nov 07, 2007 at 03:27:43PM -0800, Don Stewart wrote:
mailing_list:
As a reminder, to myself primarily, I think this should be the next priority before the 0.5 release. At a first sight this seems not very simple.
So the general rule is that your old config file goes into ~/.xmonad/xmoand.hs, you lift the top level bindings into a XConfig structure, and set:
main = xmonad myconf
where myconf is your XConfig structure.
The problem comes when, in each module, you have to write documentation to help a non haskeller to fill that XConfig structure... It seems not so obvious at a first sight. Ideas? Andrea
mailing_list:
On Wed, Nov 07, 2007 at 03:27:43PM -0800, Don Stewart wrote:
mailing_list:
As a reminder, to myself primarily, I think this should be the next priority before the 0.5 release. At a first sight this seems not very simple.
So the general rule is that your old config file goes into ~/.xmonad/xmoand.hs, you lift the top level bindings into a XConfig structure, and set:
main = xmonad myconf
where myconf is your XConfig structure.
The problem comes when, in each module, you have to write documentation to help a non haskeller to fill that XConfig structure... It seems not so obvious at a first sight.
Ideas?
I think then, hmm, that each extension module (all 72 of them...) need to have an example of how to insert its behaviour into the defaultConfig structure. (e.g. with M.union for bindings, and field setting for hooks). Does that make sense? -- Don
On Wed, Nov 07, 2007 at 03:45:41PM -0800, Don Stewart wrote:
I think then, hmm, that each extension module (all 72 of them...) need to have an example of how to insert its behaviour into the defaultConfig structure. (e.g. with M.union for bindings, and field setting for hooks).
Does that make sense?
Yes, it does indeed. I thought that it could be helpful installing a default xmonad.hs with all the XConfig records explicitly called when no xmonad.hs is found. This way each module could have something uniform to refer to. And what about the docstring stuff? As far as I understand it is not useful anymore, and we can get rid of it. Andrea
On Thu, Nov 08, 2007 at 01:15:33AM +0100, Andrea Rossato wrote: btw, why my mails keep on showing up with those 2 "-" in the subject? I cannot reproduce it elsewhere: as far as I can see it happens only on haskell.org.... :( The headers seem not very helpful here. Andrea
participants (2)
-
Andrea Rossato -
Don Stewart