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

[Gwern Branwen]

On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff <wirtwolff at gmail.com> wrote:
> A bluetileConfig could also play a role similar to the template
> config in providing a reference for people picking and choosing parts
> of the bluetile configuration, or wanting to activate them all plus
> a few customizations.
>
> Thanks for bearing with the long-winded saying of:
> * Yes I agree they should continue as synced separate projects.
> * Some of the bluetile server commands should be available from contrib.
> * There should be a bluetileConfig providing all but the dock and greeter
> bits from bluetile. As much as possible normal Config.Foo customization
> methods should work, and any deviations be well documented and include
> integration helper functions if needed.
>
> regards,
> --
> wmw

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?

This, I think, could make everyone happy:

- The people concerned about keeping the core minimal and pure can
tell anyone suggesting 'hey, let's make SmartBorders the default
layout' to change the standardConfig and leave the core alone. The
tension between a default that is on par with TWM or raw X and a
bloated failing awesome-like core goes away.
- People who really want the stripped down xmonad have a name which
makes it very clear which one of 'xmonad', 'xmonad-core', and
'xmonad-contrib' they want.
- Distro & package maintainers bear very small costs since the package
is really small and simple. Quite possibly it may not need updating
for years or indefinitely once we get dynamic linking. (Since, if I
understand the idea right, the compiled program would not hardwire the
xmonad libraries but point to libxmonad.so or something, and would get
new versions of 'xmonad' and 'standardConfig' everytime the respective
libraries were changed.)
- The majority of our users' lives will be easier: by installing
'xmonad', they get the core and -contrib as dependencies, and they
don't have to struggle to get a comfortable setup. Sane defaults. I
think we could make a standardConfig which is competitive with fluxbox
or ratpoison. Even if a user doesn't want the spartan -core, but
dislikes the standardConfig, they could still be better off, since
it's unlikely they dislike the entire thing or even most of it. It
seems to me that most people tend to dislike 1 or 2 things; if a
person dislikes only 1 thing, they ideally will only have to change
one thing.
- People with existing configs are entirely unaffected. Because module
names are split from package names, their xmonad.hs will never know
the difference. (Presumably the new xmonad executable will see the
xmonad.hs and recompile/run it rather than continue with
standardConfig.)
- This idea is better than some separate 'bluetile' executable
package. dons and others have spent years publicizing xmonad. People
who want xmonad install 'xmonad'. The people who would benefit from it
are almost by definition the people who would not know about it until
too late.
     Nor can we add an executable section to XMonadContrib for exactly
the same reason. Someone just trying out XMonad may well never install
-contrib or even know about it until they begin complaining. If you
knew little about Xmonad and saw  the Debian description at
<http://packages.debian.org/sid/xmonad> would you be able to instantly
infer 100% of the time that "Xmonad is configured in Haskell, and
custom layout algorithms may be implemented by the user in config
files" implies that there is an enormous collection of extensions &
customizations called xmonad-contrib? I mean, -contrib isn't even a
recommended or suggests!

The major downsides I can think of:

- hardcore minimalists might complain that they have to relearn to
'install xmonad-core' rather than 'install xmonad', lest they pull in
-contrib as well. But then, these tend to be the people best able to
bear the costs; I cannot weep for them.
- the documentation might become misleading in places. Perhaps not
majorly; many problems will be averted by the fact that the old
'xmonad' executable could always be reached as 'xmonad-core', and to
do anything programming-wise would require using module names, and
since the new xmonad depends on xmonad-core, there'd be no breakage.
To be consistent, we might want to rename the darcs repo to
.../xmonad-core; but then, the new 'xmonad' is so small we could just
tuck it away in its own directory, or make the repo have 2 top-level
folders, xmonad-core & xmonad.
- this requires effort and approval from many people.
     (How many distro maintainers do we have? 3 or 4? Toss in another
3 for the -core devs, and then maybe a few more for people in favor of
the general idea of a default userfriendly config but really couldn't
we just make it another XMC module or something. Hard to have a
consensus or get anything done with 10 people complaining, and this
doesn't work if the official xmonad package doesn't change. It can't
be done as a fork, as I covered above.)

* this is what everybody in #xmonad seems to say to distinguish the
core package from contrib, anyway

-- 
gwern