The tale of two tiling WMs

I love tinkering with my system. About a year ago, I got this crazy idea of trying different window managers (WM). Until then, I had mostly used GNOME and occasionally explored KDE. Before that I was a happy Windows XP users (that means, I did not know what I WM was!). After trying XFCE and a couple of *boxes, I came across tiling window managers. The first one that I tried was wmii (actually wmii-ruby), which I found to be very nifty. At that time, I was gung-ho about ruby, and was elated to use a WM based on ruby. After a while, I found wmii-ruby to be a bit slow. The reason the wmii was slow was ruby. The bare bones wmii was amazingly fast. So, I switched to it. But wmii is that it is very poorly documented and uses an arcane language to configure (plan9!!). It is a struggle to figure out how to change anything. There are ruby, phython, and perl ports, but then you have to deal with the idiosyncrasy of the  port.

These days I am gung-ho about Haskell. What luck then that Haskell has a tiling window manager — XMonad. Whenever I feel frustrated with wmii, I check out XMonad. It is developing at an amazing pace, is well documented (well, if you know how to read Haskell documentation) and comes with an awful lot of addons called xmonad-contrib. However, everytime I try XMonad, after a while I switch back to wmii.

After repeating this process for the n-th time, I decided to write down what is wrong with XMonad.  The major inconvenience is the tags and the key bindings. In wmii, you can have as many alpha-numeric tags as you want. In XMonad, you have nine numeic tags. With alphanumeric tags, I can name the tags based on what project I have on them, and I do not need to remember it. I look at the tag name and I know which project is there. With XMonad, things are a bit different. Tags 1 and 2 are easy (mail and browser), but tags after that are a mess. What happens when I start a project on tag 3, start another on 4, and another on 5. After a week, the first project is over. I remove everything from tag 3, and reuse it. After three weeks, I need to carry the state of all my tags in my head. It is agonizing. And usually that  is the time when I switch back to wmii. I wish XMonad would implement named tags correctly. Which means, I do not have to change my config file and recompile xmoand to change the names of my tags!

My second gripe with XMonad is that its window management model does not fit my work model (rather the work model that I have gotten used to while using wmii). Most of the time, I am either writing a paper in tex, or writing code in haskell. In both cases, I have the screen split vertically. When working on a paper, I have two xterms on the left: one with vim displaying the tex file, and the other for compiling the file. On the right side,  I have three-four pdfs open (for reference), with the column in stack mode, so that I can read the title of the pdf file. The situation is similar while coding in haskell. Vim with Haskell code on one side, ghci on the other. Another xterm for compiling the code. And a couple of browser windows for checking the documentation. So, I work in a two column mode, with two main windows: the editor and the typeset pdf, or the editor and the debugger. XMonad’s philosophy is having one main window.  That is really irritating to me. There are user packages that allows you to split the screen in two columns, where I can achieve something similar to stacked mode in each column, but the key bindings are horrible (I mean, I might as well use Emacs).

I love XMonad, especially the new prompt and integration with xmobar. And I really like hacking around in Haskell to configure my WM. But, XMonad comes in the way. And after fighting with it for a while, I realize that there is nothing really wrong with wmii. And I switch back to wmii. I hope XMonad will implement proper named tags and a true two column layout sometime in the future.


7 thoughts on “The tale of two tiling WMs

  1. Thanks for the insights! You can have an arbitrary number of tags, of any data type (strings , integers, booleans, whatever!). Just tweak the workspaces variable in your config.

    An example in the config file itself:

    — > workspaces = [“web”, “irc”, “code” ] ++ map show [4..9]

    Do really get the power of tags, use XMonad.Actions.TagWindows, which lets you dynamically assign and use tags.

    If you’re unhappy with the keybindings for the two-column mode, I’d suggest changing your keybindings in the config file.

    All this stuff is configurable!

  2. Also, you don’t need a contrib to get more than one window in the left column. mod-comma & mod-period modify the number. Of course, opening a new window when you’re focused on the left column will just bump the bottom one out — that’s non-optimal, but with a little bit of Haskell coding, fixable.

  3. Oh, I agree it would be nice to rename your workspaces on the fly. You could probably do that with an empty list for XConfig.workspaces and then use DynamicWorkspaces solely… but that sounds scary. 🙂

  4. Don: Your example regarding naming of tags is what I meant by settings tags at compile time. My tags keep on varying pretty frequently, and I do not know in advance what they will be. Xmonad.Action.TagWindows sound exactly like what I want. I will try it the next time I test XMonad.

    Devin: I not only need two columns, I need two columns with the ability to hide most of the windows (I only need to look at two of them at a time; which two keeps on varying). Xmoand-contrib provides tabs, IIRC, which does exactly that for one column. I actually never tried tabs with two column, I will try them when I testing XMonad next.

    ADEpt: Thank. I did not know XMoand.Actions.TagWindows. The documentation does suggest that it does exactly what I want. I will test it.

  5. “The reason the wmii was slow was ruby.”

    That is simply not true. The reason why you found ruby+wmii to be slow is that it talks to wmii via the command-line wmiir tool.

    In this approach, every user interaction causes ruby+wmii to fork a subprocess and execute the wmiir tool (which then establishes a connection to wmii’s plan9 filesystem interface via a UNIX domain socket and performs a one-time dialogue with wmii). This overhead causes significant latency, which you rightfully observe as “slowness”.

    Furthermore, this approach would make a wmiirc implemented in *any* language seem “slow”, not just interpreted languages, and certainly not just Ruby.

    Finally, if ruby+wmii talked directly to wmii’s plan9 filesystem interface via a UNIX domain socket (as is the case in my Rumai library[1] and in the Ruby-IXP library[2]) then this overhead would be largely eliminated.


  6. @suraj: Thank you for the clarification. Rumai looks like a great package. I will try it out.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s