Quoting Spencer Janssen :

(1) Full screen windows (2) ICCCM focus protocol/make Java work (3) Handling of a few window types: dock, desktop, etc. (4) Status bar without editing xmonad.hs (current plan is to do this via EWMH)

These are a good start. I assume (1) means (isFullscreen -> doFullFloat), and (3) means sticking avoidStruts/manageDocks in the core. To those, I would add smartBorders, modMask = mod4Mask, something to address http://www.reddit.com/r/xmonad/comments/aaexm/gnome_do_in_xmonad/c0glyav (not sure if there's even anything in contrib right now for this), and perhaps switching the default layouts to one of the hinted ones (can't count how many people complain about urxvt's, emacs' and vim's misbehavior in #xmonad). I think gwern's suggestion to have some kind of welcome-message for first-time users should also be considered part of the proposal. 2 cents, etc. etc. ~d

On Fri, Feb 12, 2010 at 04:54:56AM EST, Ivan Lazar Miljenovic wrote:

Spencer Janssen writes:

[..]

(seeing how many new users don't realise that xmonad by itself is rather boring).

.. which for a _user_ is exactly what a good window manager should be: I don't it to be 'interesting' like compiz and such.. so I'm not distracted and can focus on whatever I have to do. Obviously not for me to have a say in this, but I'd much prefer folks who have mastered this stuff wrote a detailed manual on xmonad configuration. CJ

On Mon, Feb 15, 2010 at 01:38:16PM EST, Adam Vogt wrote:

* On Monday, February 15 2010, Chris Jones wrote:

...

[..]

Obviously not for me to have a say in this, but I'd much prefer folks who have mastered this stuff wrote a detailed manual on xmonad configuration.

CJ

Hello Chris,

Hello Adam,

What is missing from the present documentation that you would like to see in this detailed manual?

I think that if I was able to provide a useful answer to your question, I should already be on my way to writing the manual. :-) Seriously.. here's the context: Over the years, I have toned down my current window manager of choice's functionalities to a barebones environment that does what I need and nothing else.. namely: 1. provide multiple workspaces 2. let me bind a few keyboard actions to launching frequently used applications, mainly 256-color xterms and differently configured instances of GNU screen 3. binding keys to navigating workspaces Naturally, I wanted to do the same thing in xmonad, which once I had tried it out of the box basically amounted to changing default workspace navigation keybindings and adjusting the terminal definition. One additional requirement, something I do not have in my current window manager setup was to have xmonad display stuff I like to keep an eye on at all times, such as CPU temperature, CPU%, mem%, swap%, network RX/TX, as well as the current date and time and outside temperature as recorded by my local weather station. I was not planning on anything fancy, just numbers, pretty much what I have implemented via short home-grown scripts in my current GNU/screen environment, but with one important difference: With my current setup, each instance of GNU/screen runs separate instances of my monitoring scripts, which is not optimal. So my needs were very modest indeed, and after a bit of digging, some copy-pasting and the usual trial and error cycles, I was able to pretty much set up the above environment in xmonad without bothering anybody here or on the IRC channel with questions you folks must have already answered hundreds of times. All the same, I have the following observations: 1. It would have been much better if I had been able to work with a document that walked me through the above configuration instead of having to dig for it in various places. 2. At this point, I have a file called xmonad.hs, that appears to do what I want, but since it was created by copy-pasting other users' configuration files, I have only a very vague idea how it does it. For instance, I have the following: ------------------------------------------------------------------------ import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Util.Run(spawnPipe) import XMonad.Util.EZConfig(additionalKeys) import System.IO ------------------------------------------------------------------------ What does this do? Why do I need it? Do I really need this? all of it? And further down: ------------------------------------------------------------------------ main = do xmproc <- spawnPipe "/usr/bin/xmobar /home/me/.xmobarrc" xmonad $ defaultConfig { manageHook = manageDocks <+> myManageHook <+> manageHook defaultConfig ... ------------------------------------------------------------------------ Same questions, basically.. And also what's a '$'.. what's a '<+>'.. Don't take me wrong, I am not being critical, I got xmonad to basically do what I need with possibly less frustration than if I was configure supposedly user-friendly desktops such as gnome, kde, etc. I was mainly wondering if it might be possible to have a document that takes a user who has little or no programming experience, and no prior knowledge of Haskell, just some fluency with an editor and the keyboard, and make configuring xmonad a meaningful experience, giving said user at least a general idea of what he is doing and why he needs to do it, rather than giving him a feeling that he's taken a dive into a dark pit, should count his blessings he's still alive but has come out none the wiser. No question that there are probably other new users out there who might want to set up something a bit more fun, with additional functionality, and maybe some eye candy and bells and whistles I have no use for. And it's true that the FAQ in particular does at least partially answer quite a few questions regarding individual practical aspects of the configuration, but they are all pretty much in terms of "copy-paste" the following two lines to xmonad.hs and hit mod+q. I know too little to be in a position to answer the question: is it possible to write such a document, and what would form it could take.. maybe it would turn out to be a short Haskell tutorial focusing on what parts of the language are necessary to configure xmonad? As stated before, I don't think a new user like me can speculate about this but what I do see is that in this same thread, using somewhat different terms, Ralph Hofmann, one other recent newcomer pretty much felt the same about the current documentation, it's basically OK, "aber etwas fehlt" (something is missing). I do wish I could be a little more specific, but as hinted above, if I could clearly identify what's missing, I probably have all the answers already: I'm pretty much in the position of the caveman who vaguely suspects that there ought to be a quicker better way to pay a visit to his cousins in the neighboring valley than trudging barefoot through mounds of snow, but unfortunately for him, it's another 30,000 years before someone more knowledgeable decides it's time to invent the snowmobile. Thanks, CJ

On Tue, Feb 16, 2010 at 09:25:37AM EST, Gwern Branwen wrote:

On Tue, Feb 16, 2010 at 3:12 AM, Chris Jones wrote:

[..]

Hold on. Didn't you earlier write that

...

xmonad 0.8 as shipped by debian squeeze let me do everything I needed without additional customization.

That seems like both customization & usage of -contrib modules (at least 4 of them). What then did you mean earlier?

Yes, that was earlier. But then, I figured that creating an xmonad.hs file specifying a terminal definition of 'xterm -tn xterm-256color' was cleaner than adding setting/exporting the TERM environment variable in my .bash_profile. Likewise, as described in my previous message, I have written a few short scripts that use GNU/screen's hard status line to display system monitoring information, the current date/time & outside temperature. This works regardless of the window manager, but having xmobar display the same data would be a better solution. I did not have to do any of that to have a perfectly workable environment. Just a couple of minor tweaks to improve on my current setup was all I changed from the default configuration. In other words, I reiterate that where I'm concerned: "xmonad 0.8 as shipped by debian squeeze let me do everything I needed without additional customization." Regarding "usage of -contrib modules.." I assume you mean the import statements? As stated in my previous message, I have absolutely no clue what these are for, what they do, whether I need them, and if so, why.. etc. I believe I copy-pasted them from John Goertzen's excellent step by step tutorial on how to integrate xmobar to xmonad. Since I have to boot to a different partition/system to configure xmobar, and since everything was working the way I wanted, I didn't look into these aspects further. I am pretty sure I could remove most of the stuff in the configuration file, but I have not been able to locate a detailed manual -- step by step is another good way to put it -- that describes what exactly I am supposed to do to configure xmonad. Which was precisely the object of my previous message. CJ

On Fri, Feb 12, 2010 at 12:06 AM, Spencer Janssen wrote:

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

On 13 February 2010 07:55, Gwern Branwen wrote:

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?

I've helped some people on #xmonad get XMonad working on its own without -contrib... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com Samuel Goldwyn - "I'm willing to admit that I may not always be right, but I am never wrong." - http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html