On Fri, Feb 12, 2010 at 12:06 AM, Spencer Janssen
I don't see the point of adding another package, what problem does it really solve? Some of the arguments for adding a third package border on intellectual dishonesty: we can't claim that xmonad is the same minimal window manager if we quadruple the lines of code used in the default configuration.
If we're going to throw around phrases like 'intellectual dishonesty', then I submit that presenting the current xmonad-core as anything more than a demo is dishonest. Does anyone use xmonad-core without any customizations? Or without anything from xmonad-contrib? For that matter, I see people in #haskell who still think xmonad-core is ~500 lines. Is it dishonest that http://www.cse.unsw.edu.au/~dons/code/xmonad-web/ still says ~500? Even adding in all the suggestions, the new xmonad will still be minimalistic compared to most every WM, if not xmonad-core. Any claim about 'the same minimal window manager' will be just as true with a simple s/xmonad/xmonad-core/.
I'd like to see concrete suggestions of what ought to be added if we made this xmonad/core/contrib split.
Regarding "sane defaults", I think there are just a few things that need to be added to xmonad proper: - Full screen windows - ICCCM focus protocol/make Java work - Handling of a few window types: dock, desktop, etc. - Status bar without editing xmonad.hs (current plan is to do this via EWMH)
Each of these could be added to the xmonad we know now without changing packaging policy.
Cheers, Spencer Janssen
If they really could be added so easily, then why haven't they? Some of those may be unpolished, but others are old. In the same email, you complain about the dishonesty of quadrupling the codebase and then suggest adding those specific ones in; aren't those non-minimalistic too? -- gwern