wmii+node.js, Part 0: Introduction

I’ve used Linux for years, but over the past few months I’ve fallen in love with tiling window managers in general, and wmii in particular. wmii is a manual tiling window manager (like i3, ratpoison, or stumpwm, and unlike awesome or xmonad), meaning that windows stack on top of each other by default, and the user creates extra “panes” for tiled windows as needed.

A screenshot of my current wmii desktop.

I find wmii better than most of its competition for 3 reasons:

1. Unlike a lot of other tiling window managers (with the notable exception of i3), it has actual window titlebars. This means that stacked windows remove the need for a taskbar completely, while still allowing windows to be “minimized.”
2. Its style of manual tiling is very simple: instead of nested frames that can be split in any direction, it only has columns, and each column may be either stacked, split, or maximized. Though this is limiting at times, it prevents getting lost in a sea of confusing nested frames, which was often my experience with i3 and stumpwm.
3. This is the most interesting one: you are able to (and somewhat expected to) write a large portion of the window manager yourself. The wmiirc script file handles all event processing and user interaction, and, although a basic one is provided, you can only do really cool things with wmii by writing your own. This is somewhat like the built-in scripting languages of awesome or xmonad, except that it’s not tied to a single language and it has a very simple API consisting of a pseudo-filesystem accessed through the wmiir command.

 

The cool thing about wmii is that its configuration script is event-driven, but those “events” consist of lines being written to a file (not a real file; wmii uses a virtual filesystem based on concepts from Plan 9), which then show up immediately to any programs that are reading from that file. Any number of running programs can be sending and receiving events on this messagebus, just by running the executable wmiir. They can then modify windows, the wmii bar, and wmii settings by using wmiir to write to other virtual files.

Soon after starting to use wmii, I became irritated with the defaults and decided to write my own wmiirc setup–in bash. The default wmiirc is written in bash, so how hard can it be, right? I ended up writing a fairly complex set of modular bash scripts and configuration files (parsed by awk), which is available on my GitHub. The problem is, it ended up being very slow and buggy, and I couldn’t restart it or modify details (like the bar widgets) without “leaking” forked processes. The code was becoming a mess, and I needed an alternative.

I’ve seen examples of complex wmii configurations written in Python and Ruby, but neither of those seemed interesting to me, both because those languages have a tendency to be slow and because the majority of my programming is done in either Java or HTML/JavaScript. Java seems like a bad choice for something that’s running 100% of the time and needs to call external programs constantly, so that leaves me with… JavaScript.

And that gave me an idea.

There’s been a lot of hype lately about node.js and its fast, responsive asynchronous I/O model. And it just so happens that event-driven, asynchronous I/O fits almost perfectly with wmii’s event-driven, I/O-based not-quite-an-API. I have extensive experience with the JavaScript language (including Ext JS, which is heavily callback-based, much like Node), and I’ve read a lot about Node, but I’ve never actually used it before.

So I’ve decided: I’m going to write a new wmii configuration–which includes event handling, menus, widgets, themes, error handling, autostarting applications, and more–and I’m going to write it in node.js, learning it as I go. I’ll make it modular, so that other people can create their own cool wmii setup by downloading it and modifying a few JSON config files. I’ll also add a console (probably a web console, since Node’s HTTP server is so lightweight) that allows JavaScript commands to be run in the wmii environment in real time.

And I’ll document the whole process in this blog.

Next post: Event Handling >>

Advertisement