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

[Gwern Branwen]

On Tue, Feb 16, 2010 at 3:12 AM, Chris Jones <cjns1989 at gmail.com> wrote:
> 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
> ...
> ------------------------------------------------------------------------


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?

-- 
gwern