On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff
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