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