Opinions (skip if you are busy)
Hi, I was bothering some people on IRC and someone suggested me to send my opinions in an email, so here it goes: To clarify things: I love Xmonad, I admire much of it's simplicity in some ways and complexity in others (taling about code) but I think it fails in one main thing: communication. I'm relatively new to Xmonad and totally new to haskell, but when some of my co-workers show me Xmonad I fell in love with it at the moment, and I tried to learn everything I could about it. So I reviewed the hole contrib documentation. What was my first thinking? No screenshots of the results of the usage of the module (only the withIM LayoutModifier had one, my preferred contrib), overlapping and difficult to understand functionality and some real gems that make your day-to-day life with Xmonad worh it. I'm really amazed of how some really experienced Xmonad users are recently discovering UrgencyHook, I myself had encounter recently ShellPrompt and replaced dmenu for good. What was the difficult thing? finding them, and understanding their intended usage. UrgencyHook can tell you about Pidgin messages, Mutt mails, IRSSI messages, everything (unluckly it depends on extenal programs) and it's poor documented. When I found smart borders I thought: "why isn't it the default behaiviour for all layouts and make me explicitely add it", also found that perworkspace makes Xmonad so much powerfull that I think it should be a main feature selecting the layouts to apply to a workspace. Even Tabbing is hidden and Full is the preferred one, altough they deliver almost same funcionality only that Tabbed doesn't hide windows like Full does. When I told my coworkers of my discoveries (they were using xmonad for ages) it was really difficult to convince them to use withIM (or IM in that time) Layout for their Pidgin workspace (we all work connected to jabber channels), they found difficult to configure and were using the "remember windows placement" feature of xmonad. Short time after they've seen my buddy list aligned to the right of my screen (Reflect++ and Roman++ for an excellent doc in its module) they were all asking me how to get that. I did't understand a line of Haskell, it was only preety readable and logic to me. Then i saw SPJ (Simon Peyton Jones) using xmonad to do a great talk about Haskell, I fell in love instantly, but was very difficult using this new approach of doing things, then looked at some Haskell books, liked the type system and how you can abstract and describe the world with it, but I still can't code Haskell :). So, I think Xmonad is the most usefull thing installed on my machine right now besides vim, and I think that Xmonad should tell the world why we think it's like this. Awesome ... pleople are switching to awesome cause they provide widgets out of the box, I don't say that providing them is good, Xmonad should care about windows, but making easy to integrate a status bar will be great (I'm aware of the contrib efforts being done to do this), Xmonad should sail away from maintaining dwm compatibility (in keybindings) for ex, and making it own standards, provide more sane defaults for new users and hooks (or facilitators) to modify the config in the most-changed parts. So ... what could be done, first ... make XMonad findable to an average person, and tell him what he can do with it, show him the goodness of tiling WMs, preconfigured workspaces, known windows positions, screen usage maximization, low resource usage, etc. How to do this ? Pimp your XMonad is a good example, but aimed at people that already know XMonad, we should target new users, and show them the benefits of using Xmonad over the "pain" of learning/downloading (ghc is huge) a new language/compiler. Also make Xmonad gentler to newcomers (keeping haskell config file, but maybe providing some config hooks), more sane or complete defaults, maybe with config templates, xmonad.hs, xmonadDzen.hs, xmonadXmobar.hs, xmonadGnome, no need to import some config that they don't know what is doing or to copy/paste, give them tools to understand it and in the future tweak it and become interested in haskell, so they became future contributors of xmonad. In short, I think that Xmonad core should care about providing the best abstractions of everything a Tiled WM coul implement and some basic implementations. Also provide a common Library or Framework to contribute/extend it, and XMonadContrib should do the rest. Sorry for the ranting, I'm willing to help in everything that I can, bye!
On Sat, Apr 04, 2009 at 10:38:43PM -0300, Ismael Carnales wrote:
What was my first thinking? No screenshots of the results of the usage of the module (only the withIM LayoutModifier had one, my preferred contrib), overlapping and difficult to understand functionality and some real gems that make your day-to-day life with Xmonad worh it.
Yes, yes, yes! For a number of contrib modules, the documentation is minimal, they don't explain what the module is for, what the results should be, what the parameters *mean*. Sure, they have a one-sentence description, but that isn't enough. A picture paints a thousand words; while screenshots wouldn't replace good documentation, they would augment good documentation. The difficulty, though, with providing screenshots is that they would be best seen *with* the documentation for a module, but said documentation is in the haskell code of the module (which is a Good Thing, don't get me wrong) but that doesn't provide (so far as I know) the ability to add in images to the generated HTML. I know that someone did some screenshots on a separate page, but the problem with that is that it's separated from the modules in question, and also it has limited coverage. I'm not sure what the solution is, but it would be nice to have one... *thinks* Ah, there's a page on the wiki full of screenshots: http://haskell.org/haskellwiki/Xmonad/Screenshots But it's a rather wild mixture... What would make it easier for people to contribute screenshots? Ones that were clear examples of different layouts? What would be nice would be a) a list of all known layouts (alphabetical?) b) a screenshot of each c) a snippet of code which shows how that particular layout was configured. That's probably too much for one person to do, but maybe a bunch of people...? Kathryn Andersen -- _--_|\ | Kathryn Andersen http://www.katspace.com / \ | \_.--.*/ | GenFicCrit mailing list http://www.katspace.com/gen_fic_crit/ v | ------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere Maranatha! | -> Earth -> Sol -> Milky Way Galaxy -> Universe
HI, On Sun, Apr 5, 2009 at 12:47 PM, Kathryn Andersen < kat_lists@katspace.homelinux.org> wrote:
What would make it easier for people to contribute screenshots? Ones that were clear examples of different layouts? What would be nice would be a) a list of all known layouts (alphabetical?) b) a screenshot of each c) a snippet of code which shows how that particular layout was configured.
That is a great idea! Maybe include a simple vector representation of the layout suitable for use as an icon (when scaled down) for those who use icons in their status bars. I'm pretty happy with the XMonad documentation. After a brief flirtation with another wm believe me the XMonad docs are at least up to date. I sometimes use the web based documentation however recently I started keeping darcs repos of the source for XMonad and the contrib modules solely for reference as I run xmonad from my distros repos. Having the source available makes it easy to check something with a quick grep. Most of the issues I have are due to my lack of skills in Haskell. I have read a couple of books on Haskell but have yet to become as skilled in it as python, C or C++. I have a long way to go. :) Mike
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
Sorry, my English is not the best, I'm from Uruguay.
To clarify some things:
* I've never tried to make this an XMonad vs Awesome thread (I hate the latter)
* As I explain in my mail I think XMonad is the most useful piece of
software running in my machine :)
What I do say is that Awesome does some things good in aspects that
XMonad could do better:
These are:
* Being more friendly for customization out of the box: I don't talk
here about changing configuration system or anything like that.
Altough I think it would be good to include 2 or 3 different
functional config.hs (with some common twaks) and an annotated one
maybe saying things like: # for a status bar you can use xmonadDzen or
xmonadXmobar, or look at the modules X, Y .... and other basic things
like UrgencyHook, etc.
* Publicity/Advertising: Awesome is pure blah, and unluckily its
everywhere. I know that some efforts are being done to improve the
communication in general (Webpage, Blog etc) and I think that we
should help with this, writing beginner-oriented info, and some guides
like the official tour but for the contrib set of modules (that could
go in the main page instead of wiki) and also try to show the world
what XMonad is capable of.
As I said before I offer my help to go in this direction (or the one
that we think could be more appropriate), I've made an effort in the
past to made a tour-a-like of the contribs, it's in here:
http://haskell.org/haskellwiki/XMonadContribTour
The las Pimp your XMonad used part of the document
(http://haskell.org/haskellwiki/XMonadContribTour#Getting_notifications_on_ev...)
as a starting-point (yay!) I think that this kind of documents belong
somewere in the homepage, to be really easy to find, and one more
thing .. we need screenshots, lots of screenshots, of simple separated
things.
So feel free to contact me or ask for help in getting some of these
things (or others) done, bye!
On Sun, Apr 5, 2009 at 7:03 PM, Norbert Zeh
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 _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
The XMonad.Config namespace seems like it could use some love: it has some redundancy (Xfce, Kde, Desktop), and it could probably showcase more elabourate configs. Another thing that I've found is that the sample configs on the wiki are based on the template: personally they are (in general) a bit verbose. Would it be a good thing to show just the minimum necessary, or is it helpful that the configs are explicit? * On Sunday, April 05 2009, Ismael Carnales wrote:
Sorry, my English is not the best, I'm from Uruguay.
To clarify some things:
* I've never tried to make this an XMonad vs Awesome thread (I hate the latter) * As I explain in my mail I think XMonad is the most useful piece of software running in my machine :)
What I do say is that Awesome does some things good in aspects that XMonad could do better:
These are:
* Being more friendly for customization out of the box: I don't talk here about changing configuration system or anything like that. Altough I think it would be good to include 2 or 3 different functional config.hs (with some common twaks) and an annotated one maybe saying things like: # for a status bar you can use xmonadDzen or xmonadXmobar, or look at the modules X, Y .... and other basic things like UrgencyHook, etc.
* Publicity/Advertising: Awesome is pure blah, and unluckily its everywhere. I know that some efforts are being done to improve the communication in general (Webpage, Blog etc) and I think that we should help with this, writing beginner-oriented info, and some guides like the official tour but for the contrib set of modules (that could go in the main page instead of wiki) and also try to show the world what XMonad is capable of.
As I said before I offer my help to go in this direction (or the one that we think could be more appropriate), I've made an effort in the past to made a tour-a-like of the contribs, it's in here:
http://haskell.org/haskellwiki/XMonadContribTour
The las Pimp your XMonad used part of the document (http://haskell.org/haskellwiki/XMonadContribTour#Getting_notifications_on_ev...) as a starting-point (yay!) I think that this kind of documents belong somewere in the homepage, to be really easy to find, and one more thing .. we need screenshots, lots of screenshots, of simple separated things.
So feel free to contact me or ask for help in getting some of these things (or others) done, bye!
On Sun, Apr 5, 2009 at 10:46 PM, Adam Vogt
The XMonad.Config namespace seems like it could use some love: it has some redundancy (Xfce, Kde, Desktop), and it could probably showcase more elabourate configs.
Another thing that I've found is that the sample configs on the wiki are based on the template: personally they are (in general) a bit verbose. Would it be a good thing to show just the minimum necessary, or is it helpful that the configs are explicit?
I don't entirely follow this. Configs haven't been based on the template since 0.5; are you looking at the ones in the old section? -- gwern
participants (6)
-
Adam Vogt -
Gwern Branwen -
Ismael Carnales -
Kathryn Andersen -
Mike Sampson -
Norbert Zeh