[xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS Small announce about the completion of the bluetile merge

[Chris Jones]

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