ruby-wmii updated for use with wmii 3.6
It's been so long that many will not know what this is about. wmii is a lightweight, dynamic window manager for X11 that can be scripted with any language. It's not for everybody, but a few of us consider it way superior to the mainstream tools (I include all OSX has to offer here) in terms of workflow --- more on this below.
ruby-wmii is a wmii configuration and scripting system that controls the wmii WM. I had been procrastinating the long-needed update of ruby-wmii to make it work with recent versions of wmii under the excuse that wmii was a moving target and there hadn't been a stable release (not a development snapshot) for a long time. wmii 3.6 got finally released a couple weeks ago, which means that I was beginning to consider updating ruby-wmii some day, when Nathan Weizenbaum went ahead and ported it to 3.6. Big kudos go to him; who knows how long it would have taken me otherwise :)
I've migrated a few of my X sessions to 3.6 (dog-feeding means quicker bug correction), and the latest code can be found in the darcs repositories (that integrate Nathan's patches) at http://eigenclass.org/repos/ruby-wmii/head/ and http://eigenclass.org/repos/ruby-wmii/branch-ruby-ixp/
(The repositories with the 3.1 branches can be found here.)
wmii supports very dynamic work patterns thanks to a few fundamental features that aren't AFAIK combined in any other WM (apart from dwm, modulo the lack of scriptability):
- wmii is a tiling WM; you don't have to worry about overlapping windows and their positions/sizes
- you rarely (if ever) need a mouse. All but a few actions can be bound to arbitrary keys, and you don't have to take your hands away from the keyboard.
- the column layout with split, maximized and stacked modes is close to ideal. The stacked mode (a sort of vertical tabbing) is superior to plain old tabs.
- a client can be in different workspaces (with different geometries) at a time
- arbitrarily complex behavior can be scripted in any language and associated to any keybinding or a number of events
- in general, wmii's tagging system allows you to manage the applications very dynamically.
The last point is hard to get across without a screencast (I'll try to prepare one... someday). The best way is probably to point at the problems faced with other tools and explain how they are addressed in wmii.
Multiple desktops/workspaces are by no means new; any respectable window manager has had them for years, and they're becoming more common now with Leopard's Spaces. They are typically used in a fairly static way: you have a "web" workspace, a "IM/IRC" one, another for consoles, etc. Within each workspace, non-tiling WMs force you to place the windows carefully.
Note: you might want to skip this: it's way too long. I'm sorry, I had no time to make it shorter today.
This screencast shows how Ara Howard manages one such workspace. It's not a bad setup, that's how I did things a few years ago when I used KDE; I just find my current approach better.
He's got an iTerm console with many tabs, each of them holding a number of virtual terminals multiplexed in a screen session. Note how a IM window (I assume, the screencast doesn't make it clear) is placed on the top right hand corner so that it doesn't overlap with the iTerm. Also note the Mail.app (?) window behind the iTerm. What's wrong in that image? A few possible problems (note that this is based on my understanding of how he works, by analogy with the way I used to operate with KDE):
- in a non-tiling WM, the WM and the iTerm have to be resized and positioned manually (non-overlapping IM and iTerm windows)
- you only see one tab (and within a tab, one terminal) at once. What if I want to see 2 at a time (and get rid of the IM window)? Do I have to detach the tabs and place+resize the resulting 2 windows manually so that they don't overlap? What about N=3..5 simultaneous terminals? Can I reattach them easily when I'm done and recover all the client geometries (so the IM is where it used to be, etc.)?
- What about things besides terminals? What if I want to see both a firefox window holding API documentation and the current tab at once (again, non-overlap is a requirement)?
- say you want to pair some terms with some apps while keeping the ability to switch amongst terms easily. For instance, you want a firefox window with the API for some lib shown when you're editing a given file and only then, so it doesn't steal valuable screen space when you go to the next tab. Imagine the latter holds a related file (from the same project) that does not use that lib and for which you hence don't require the API documentation. You still want to be able to switch from one terminal to another, but you only want to see firefox when you're looking at one of them.
How would I manage something like that with wmii? Basically, there's one tag per project (each tag defines a dynamic workspace), and a few semi-permanent tags (mail, web, irc), plus a number of dynamic tags that come and go.
Now comes the important part, each client can have several tags simultaneously, so a firefox window can be both in web (in maximized form) and in myproject (where it takes e.g. the right hand column) at once. In fact, I could have several tags associated to the same project, say myproject:N. For instance, myproject:1 could hold all the terms for the project in stacked form (so I can see each one in maximized form; it takes but one key-press to create a new column and move a terminal there so I can see two simultaneously). A subset of those terminals would be in myproject:2 (maybe in "split" mode, maybe in multiple columns; it takes one keypress to change the layout), along with a firefox window which is also tagged as "web" (so all firefox instances can be found in "web", but a few can be found in other tags as well), and maybe a IM that is also in the irc tag.
Imagine I'm reading my mail and find a bug report. I want to have that email visible at the same time as a number of terminals I was using to work on the affected project. In Ara's setup, Mail.app and iTerm overlap; you'd have to resize and move them so that they don't (and hide the IM window that isn't needed at that moment). With wmii, I'll just retag the mutt terminal as +myproject and have it appear in the associated workspace, along with the (stacked) terminals I was using.
I then get more urgent news via IRC --- a critical bug is to be fixed now --- and want to leave that workspace as is and have some other terminals from "myproject" visible at the same time as the IRC window. ruby-wmii has got key bindings that allow me to create a new associated tag (myproject:tmp) with a subset of the currently visible clients and move along tags easily. When I'm finished with the critical bug, a single key press makes myproject:tmp vanish and I'm back to myproject. All the clients have the geometries they did before I got sidetracked.
When I'm finished, I just retag the mutt window as -myproject; it's now in "mail", where it's been available all the time.
branch-ruby-ixp uses Ruby-IXP to communicate with wmii instead of the wmiir command-line tool. It feels more reactive than head; unfortunately, there's a memleak in Ruby-IXP. This means that you have to reload wmiirc every 48H or so. It's not as bad as it sounds, though, as it can be done with a single keypress and it won't affect anything: the tags, the window geometries, etc. are preserved. In fact, it's so unobtrusive I'll probably automate it.
Can wmii control native OS X apps such as Mail.app and the IM client used by Ara? Or does it only work for X11 apps such as xterm and xeyes?
wmii is a WM for the X Window System, so it doesn't look like it'll be able to manage anything outside X11.app...
Excellent! How's the multi-head support?
I don't really know, as I don't need/use it myself. There were some talks about adding xinerama support last year, but AFAIK there's nothing of that in 3.6.
You might want to take a look at xmonad, ion or ratpoison.
thanks for that!! been waiting for it.
Thank Nathan Weizenbaum, I'm not lying when I say it could have taken months hadn't he done the port himself :)
You two rock. I had gone minimal with dwm for a few months, but I think it's about time for some wmii scripting madness again.
Is there really a memleak in Ruby-IXP (if so, which revision of SVN trunk) with wmii-3.6? Or are you thinking of the libixp overload bug back in wmii-3.1?
- 26 http://anarchaia.org
- 9 http://planetruby.0x42.net
- 6 http://www.anarchaia.org
- 4 http://planetrubyonrails.com
- 3 http://www.artima.com/forums/flat.jsp?forum=123&thread=219872
- 3 http://anarchaia.org/archive/2007/11/29.html
- 2 http://www.google.com/reader/view/feed/http://eigenclass.org/hiki.rb?c=rss;format=1;tags=blog
- 2 http://djur.desperance.net/feeds.html
- 2 http://textmode.at/2007/12/6/wmii-windowmanager
- 2 http://www.google.com/reader/view/feed/http://eigenclass.org/hiki.rb?c=rss;tags=blog