On Sat, Apr 04, 2009 at 10:38:43PM -0300, Ismael Carnales wrote:
Hi, I was bothering some people on IRC and someone suggested me to send my opinions in an email, so here it goes:
[...]
Sorry for the ranting, I'm willing to help in everything that I can, bye!
In general, I agree that documentation lowers the entry threshold and is great for advertising something as awesome as xmonad (pun intended). However, since awesome was mentioned here, I feel I have to put a few things in perspective. [This is probably a bit OT.] As for the reasons why people choose awesome or xmonad, they are varied. The fact that xmonad was written in haskell was one of the reasons I switched from awesome to xmonad, while it made a friend of mine switch the other way. I guess it's a matter of taste. Here, however, are a few more objective comments that make xmonad shine, even as far as documentation is concerned, and which were part of the reasons I quickly fell in love with xmonad. 1) Stability (as in no crashes). Xmonad never crashed on me, while just before switching, awesome did this about 3 times a day at random. (I found xmonad rather by accident while looking for something that could do what awesome does and is more stable.) 2) Stability (as in stable API). The lua api of awesome seems to change quite frequently without warning, in ways that often break the existing config file. The awesome developers consider this okay because they consider awesome under development. Nothing wrong with this, but it's a plus for xmonad that so far I never ran into API changes that would cripple my current xmonad.hs. 3) Documentation. It is true that the xmonad API has the potential to be improved (as everything does). In my experience, however, doing rather standard customizations in awesome required trips to the mailing list, while I can do much more in xmonad without asking someone by digging through the available documentation. In fact, for some of the things I asked about how to do things in awesome, I simply got the reply to look at the C source code to find out which lua properties of the objects it exports. I don't have to browse the source code in xmonad to see which module lets me do what. 4) Abstraction. Once you move to a tiling window manager, you almost immediately accept that you'll be building your own window manager from the right set of lego bricks. That's true both for awesome and xmonad. Doing this effectively depends on having the right abstractions, playing with Duplo most of the time and playing with Lego only when needed. I feel that xmonad does an excellent job here, making moderately advanced configuration a piece of cake, and allowing the manipulation of exactly the necessary information without touching (or worrying about) anything else when doing slightly more advanced stuff (such as writing one's own layout, for example). In awesome, on the other hand, writing a new layout requires some quite low-level C hacking, and even somewhat non-basic customization requires a bit of lifting in lua where one feels the lack of the right abstractions. Overall, in my opinion, the main thing that awesome has going over xmonad is the built-in status bar (including widgets), but with apps like xmobar and dzen, I don't really miss this in xmonad. As far as documentation and ease of customization is concerned, I don't think Ismael's post does xmonad justice, as it is miles ahead of awesome in my experience. Of course, as I said, there's always room for improvement, and Ismael's suggestions are good. Cheers, Norbert