I think if one lives on heavy customization and want to play with every corner of the desktop, xmonad is great and may be preferred to awesome. I also heard a lot of people saying that xmonad is more stable than awesome. In my opinion, there isn't so much big difference between 99.9% and 97%. Awesome crashed only once or twice a year. This is a reasonable number for me.
For the configuration thing, I have to say awesome takes the step to today's 3.4 for already 2 years. Maybe I am lucky that I haven't experienced much the rapid changing period of awesome. It is usual that software changes a lot at the beginning of the development. The theory world is developing and so as the fundamental tools and platforms. If we find much better architecture, we need to evolve. It is always a balance between changing or abandoning something and maintaining the compatibility. Python 3 (Python 3000) is a vivid example in the software world. With awesome 3.4.10 fixed the gap bug, I cannot tell feature differences between xmonad and awesome from a user's view (not a developer). Actually, awesome is more user-friendly to coming users and is ready to use out of box. I use awesome because I am not a desktop environment developer, I just want to use it to finish my work efficiently. Even xmonad marks it as the best multi-display WM, I find it not easy to configure multi-display on the fly, while awesome put it easy, simple, and elegant, and you can even get it more easy and user-friendly by using gnome-settings-daemon in gnome 2. General usability and heavy customization is always a contradictory in software design. Like constrained and unconstrained navigation in Information Visualization field, in which the former guides the user better, making less errors while the latter gives more possibility for professional user to do more with their imagination. The truth in software design is that most software is just a tool that helps users to do what they want, especially OS and desktops. I think xmonad is designed for very few professional people while awesome aims to let more normal people to feel the advance of tile WM. Apple Inc. understands this well and does similar things designing their OSes with Job's "post computer age" theory. In my opinion, there is nothing that fits everyone. Awesome can't, xmonad cannot, either. No argue is needed. Take the item that satisfies your needs and obeys your philosophy, and then live a happy life. It is life itself which is colorful and awesome. I prefer to argue less, choose the way that fits you and live more :-) (I am not in xmonad maillist. If needed, please forward my opinion to xmonad) Best, Xiaokui On Sat, Oct 1, 2011 at 2:15 AM, Teika Kazura <[email protected]> wrote: > Hi. A comment critical on Awesome appeared in xmonad mailing > list[1]. I also often came across these points browsing web. Some may > be outdated, as he says, and for Awesome's sake, it's worth > correcting, if possible. (And add them to the FAQ.) So please advocate > Awesome. (I'm not an Awesome user.) > > [1]http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/11551 > > On Tue, 27 Sep 2011 17:40:15 -0300, Norbert Zeh wrote: >> I came to xmonad via awesome. Here are my reasons for the switch, >> in no particular order. >> >> 1) [...] The awesome config file syntax is a moving target, changing with >> pretty >> much every major release. This may have changed in the recent past. >> 2) xmonad never once crashed on me, while awesome segfaulted at some very >> inopportune moments while I used it. Again, stability may have improved >> in recent releases, [...] >> >> 3) I always considered xmonad's configuration files much more readable than >> an >> awesome configuration file doing the same thing. I guess that's a >> result of >> the greater expressive power of Haskell vs lua and, probably even more >> so, a >> result of the well thought-out interface provided by the base xmonad >> library. >> >> 4) Using the same language for implementing xmonad and for configuring it >> blurs the line between configuring things and implementing new features. >> In >> this instance, this is a good thing because it makes it much easier to >> add >> non-standard features and tinker with ideas that over time may grow into >> new >> add-on modules in XMonadContrib. When I used awesome, I tried to apply >> the >> kind of heavy customization I apply to xmonad nowadays and I almost >> always >> found myself either hacking C or writing really clunky and round-about >> lua >> code. Of course one may argue that, since xmonad is implemented in >> Haskell, >> writing non-trivial Haskell code in my configuration file is the same as >> adding >> to the C code base of awesome, but it's not because Haskell allows me to >> express myself at a much higher level of abstraction. >> > > Let me deepen this point a bit. I'm a user of Sawfish and Emacs, and > I understand what he says about Xmonad. But a good structure to harness > your own hack and upstream codes is lacking. (For example, I override > /usr/share/emacs/.../paren.el with my own code. But upgrading Emacs > is a bit of headache.) I think there should be "something" in this point. > >> 5) The power of a DIY windowmanager such as xmonad or awesome depends >> heavily >> on the quality of the documentation. In the case of xmonad, I find the >> base >> xmonad library and the vast majority of the modules in XMonadContrib to >> be >> extremely well documented and as a result easy to use. In contrast, I >> find >> awesome's documentation nearly useless. The wiki provides documentation >> by >> example without a comprehensive list of objects/functions that are >> available. >> The API documentation just strikes me as extremely terse and possibly >> incomplete. > > This person also says there's pros of Awesome over Xmonad, but I omit > them. See the reference URL above. > > With best regards. > Teika (Teika kazura) > > > > -- > To unsubscribe, send mail to [email protected]. > -- To unsubscribe, send mail to [email protected].
