[xmonad] Small announce about the completion of the bluetile merge

[Jan Vornberger]

On Mon, Dec 07, 2009 at 07:27:31PM -0500, Gwern Branwen wrote:
> Here's something I've been thinking. What if we came up with an
> xmonad.hs that included all the stuff everybody asks for and the
> obvious newbie aids like a first-run xmesage prompt? (Let's call this
> a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.)
> 
> Then we could take the current xmonad package, rename it
> 'xmonad-core'*; the new 'xmonad' would be basically a cabal file
> depending on xmonad-core and xmonad-contrib, and an executable reading
> 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main =
> xmonad standardConfig'. (xmonad-core's executable would be left alone
> of course.)
> 
> If we get ambitious, the new xmonad main could do more. Perhaps we
> could check for XineRama in main and then modify our standardConfig to
> use SmartBorders or not?

I also think this is a good idea! I was playing around with the same
thought, but as you said, it will need a number of people behind this
effort as it requires some restructuring.
Maybe one should go as far as move all the xmonad.hs-detection and
-compiling code from xmonad-core to this new xmonad. Now that I think
about it, it is actually necessary, isn't it? Because the standardConfig
should only be invoked, if there is no user-xmonad.hs.
But I think that would be a better separation anyway. Have this new
xmonad be the single entry point, which decides to run a standardConfig
or compile and run a xmonad.hs. Then xmonad-core could just be a library
and this somewhat confusing - in my opinion at least - hybrid nature of
an executable as well as a library would stop. The disadvantage would
be, that you could no longer run xmonad-core on its own. You would have
to write an explicit, minimal xmonad.hs.
Just a few thoughts on this idea.

I also remember that - I think - Don was thinking of maybe doing some
sort of popularity module to figure out what stuff from contrib is used
most often. I think that sort of information could be really interesting
in deciding what to put into a standardConfig. But that's maybe just an
optional extra step.

Regards!

Jan