DWM – Or how I learned to stop floating and love the keyboard

It began four years ago when I switched from XP to Ubuntu. It happened again two years ago when I migrated from Ubuntu to Arch. It repeated a year ago when I ditched KDE in favor of Openbox. Now, after twelve whole months of relative calm in the 1049088px digital utopia I had established using Openbox, XFCE4 Panel, Conky and a dozen cronjobs, a newer, more esoteric succubus is here to lure me away from my virtual Shangri-La. In just two weeks, it has already made me succumb to it enigmatic charms. I feel nauseated when faced with conventional floating window managers now, and make a mental note to sacrifice a baby in my dreams for each pixel I see wasted on petty trivialities like taskbars, titlebars, system trays, minimize buttons, maximize buttons, close buttons and other pointless doodads.

What is a tiling window manager (WM) anyway?

Let’s start with what a window manager is first. It is, as the name implies, a piece of software that manages all your open windows, nothing less nothing more. Whenever you perform an action on a particular window, like move, resize, minimize, maximize or close, you are interacting with a WM. Every OS running a GUI has a WM running too. Of course, presenting an end-user with just a bunch of windows to move around isn’t considered nice manners. Hence WMs are often relegated to being just another process in the system started alongside a myriad others to provide a nice and coherent and, not to mention, bloated experience to the user.

It shouldn’t come as a surprise that there is variety in WMs too. The ones that most people are used to, courtesy to them being default in Windows, GNOME, KDE and Mac alike, are called floating WMs. The title window “manager” is outright misleading here, since the actual window management is left to you, the user. It is you who has to manually move the window to desired position and resize it to the right size. The WM only remembers the position of the window and controls placement and ordering of newly opened windows. This works fine so long as you work solely with maximised windows. But try viewing more than one window side by side and the inherent shortcoming of the floating approach shines through.

As if moving and resizing to get the windows to fit without overlapping critical parts of each other wasn’t enough, you are forced to do it again for a newly opened window. And again for each new window you open! To add smelly icing to the crumbling cake, try closing a window now and scratch your sorry ass trying to fathom what good that gaping hole, about the same size as the one in your underwear, left on your desktop offering the world a peek at the aubergine panties of Jenna Jameson wallpaper, is for.

Enter Tiling WMs.

These WMs take a totally different approach to managing windows, in the sense that all windows belong to the same 2D plane. Basically, they abandon the faux-3D illusion of floating WMs (in which windows can overlap each other) and respect the fact that 2D surfaces (your monitor, in case you happen to be thinking about babies overrun by bulldozers) aren’t good for representing 3D.So, in tiling WMs, windows never overlap each other. Think about it. Most of the frustration of using a floating WM arises from the fact that non-maximised windows can – and will – overlap each other, forcing you to go through the resize-move-open-resize-move-close-resize-move-rinse-repeat rigmarole. These problem just doesn’t exist in tiling WMs.

This simpler mode of representing non-overlapping windows in one plane has an added benefit that each window can now be thought of as simple rectangular subsection of a larger rectangle. But what about those gaping underwear-sized wallpaper-exposing holes that are the bane of floating WMs? In tiling WMs, the holes are themselves guaranteed to be rectangles.And what do you put in a rectangle (besides a baby emerging from a bar soap manufacturing line)? Hint: it starts with a W, ends with a W and is not a wheelbarrow.

Since all windows and holes are rectangles, what is the point of having any holes at all? Why not let a window take the maximum dimensions it can take without overlapping other open windows? This is exactly what tiling WMs do, and is probably their biggest advantage too. They live up to their title of window “manager” in a way more glorious than floating WMs fail to. Not having to worry about rearranging windows each time a new one opens is a huge productivity booster once you have more than a couple open. You may feel a lack of control, what with your currently open windows suddenly moving and shrinking to make way for new one, or expanding to fill a void left by a closed window, at least initially. But trust the WM, it knows it’s job better than you do. You will be astonished to discover how much more effective this can be once you get over the getting-used-to phase.

Did I mention that all tiling WMs can be controlled entirely though the keyboard? Yup, they manage to totally circumvent the need for what is perhaps the most recognizable piece of desktop computing equipment ever – the ubiquitous-as-a-motherfuck – mouse! This ideology of ditching the pointy rodent in favour of its CTP-advancing cousin gels well with other stellar Unix applications like vim, tmux, the CLI itself and the excellent vimperator (or its newer cousin pentadactyl) add-on for Firefox.

DWM on Arch Linux

Which tiling WM you choose is purely a matter of personal preference. I chose dwm because it did the most of what I needed and none of what I didn’t. Here’s the last statement again with a bit more loquacity:

It’s Small

  • Weighing in at just under 41kb (compiled binary size), I have seen mere crash dumps of heavyweight programs with size greater than this thing

It’s a joy to configure

  • This depends on how well you know C, since the only way to modify any settings is by editing its source code and recompiling. While it may sound like a chore to recompile each time you make one small change, it also offers the freedom to customise in ways that a text-based config file just can’t

It’s fast and lightweight

  • “# init 5” will never be a reason to get a much-needed toilet break anymore!

Arch Linux offers a binary package for dwm, but it’s kind of pointless since you need the source code for configuring it. There’s also a couple of PKGBUILDs floating around in the AUR. But being the extraordinary piece of software that dwm is, it is only fitting to run it an extraordinary manner. So, I just have a .dwm directory in my home that contains the dwm source code and makefiles, along with my custom scripts and conky configs to run with dwm.

Configuring dwm is done by editing the config.h file (and, if you are feeling particularly masochistic, the dwm.c file). The file is commented well enough to make editing a trivial matter for people even remotely familiar with C. Note that you need to recompile and restart dwm in order for the changes to take effect. To make the process a bit less painful, first configure dwm to restart instead of exit on quit function is called. Start dwm from within a while loop inside your ~/.xinitrc or whatever script you use to start dwm:

while true; do
    dwm 1 > ~/dwmlog 2 >& 1 || exit
done

Now make a shell alias for compiling dwm:

alias cdwm="pushd ~/.dwm; sudo make clean install; popd"

Replace ~/.dwm with whatever directory your source files are located in.
Now, just run cdwm followed by Mod+Shift+Q (or your custom keybind for quit function) to apply the changes without losing currently open windows.

In case you find that you need some functionality that dwm doesn’t provide, try searching for a patch before messing around with the dwm.c file. Good places to look for patches are:

Do browse through the links at the bottom of the dwm site for more dwm foo.

That’s about it! Happy tiling and baby-squashing!

Advertisements

Arch Linux and Me

I have been using this wonderful distro on my laptop for the past 3 months. Now I have reached a level of comfort with it that makes the idea of switching to or even trying out another distro seem outrageous, blasphemous, traitorous. Yep, I will consider myself a traitor if I ever abandon Arch in favor of another distro. The point of no return has been passed. In this post, I will try to put out all the experiences I have had with Arch Linux ever since I decided to install it to the present day.

The Beginning…:

Want something to drool over.? How about this:

Intel Core i5 460m @ 2.53 Ghz

4GB DDR3 RAM @ 1066Mhz

ATI Radeon Mobility HD5470

Take the above three lines, add a few more phrases, like 320GB HDD, 14″ WXGA Display etc. to spice things up, wave your text-to-hardware conversion wand over the mix and Behold.! the technological marvel you now have in front of you is what I call my laptop and what Dell calls Inspiron 14R N4010. On shipping, it came pre-installed with yours truly – one and only Windows 7. But this was to change soon. The star child of MS was soon to meet it’s humbler, less pretentious sibling. I could have taken the coward’s path and stuck with graphical distros like Ubuntu or Mint or Opensuse.

* (Mind you, back in my desktop days, I had been an avid Ubuntu user when, one fine day, my stone age relic of a desktop succumbed to XP’s “Luna“tic charms and refused to get “turned on” by Ubuntu’s lustful “human” touch. Since my CD-ROM had found a place in silicon heaven a few years (or was it centuries.?) ago and the concept of booting from USB was too modern for my desktop’s antiquated tastes, I was left at the sole mercy of XP’s fickle whims for a whole year.) *

But then it dawned on me, I am a die-hard geek doing a course in Information Technology. Should I really care about things like ease of use, simplicity of installation, fancy point-n-click wizards for mundane tasks.?. No, I needed something that exposed to me to all it’s inner nitty-gritty of working, something that, instead of trying to hide it’s bloated, slow, and clunky code under the garb of a fancy-looking but equally bloated, slow, and clunky GUI, stayed away from the bloat in the first place, something that is put together so simply and efficiently that it leaves you in awe in each time you use it.

That something is Arch Linux.

What’s Arch.?

Four words perfectly sum up Arch Linux : Keep It Simple, Stupid.! A fresh install of Arch is nothing more than a kernel, bootloader, basic utilities we expect on every Linux system like cp, ping, grep etc and a few Arch-specific tools. It provides no GUI, no audio support, no pre-configured network settings, no users except root, no automount for USB drives, CD/DVDs etc by default. Everything is left for the end user to install and configure. What it does provide are two excellent tools to get the job done, namely pacman and Arch Build System (or ABS)

Pacman:

A package manager can make or break a Linux distro. In Arch’s case, pacman more than makes up this distro and a few neighbouring ones too. The three main switches that govern most of it’s usage are -S (or –sync) which deals with packages available in repositories, -Q (or –query which deals with locally installed packages) and -R (or –remove) which deals with removing packages. Examples follow:

To install package foo:

pacman -S foo

To cleanly remove a package alongwith with its unneeded dependencies and configuration files:

pacman -Rsn foo

To get info on any installed package:

pacman -Qi foo

And (best for the last.!) the ‘magic’ command:

pacman -Syu

This command is what makes Arch a rolling release distro. You run it and your entire system is brought up-to-date with all installed packages upgraded to latest available versions automatically. In distros like Ubuntu, if upstream (the actual developer of the program) releases a newer version of a software than what is available in repos, you either have to wait six months for new Ubuntu version to include the this package or compile it from source. Not in Arch. Here, the developers release the newer version to the repos within 2-3 days of upstream release AFTER testing it for stability (a common criticism against rolling release model is that packages released into the repos are often untested, resulting in an unstable system and unexpected bugs, which is just plain FUD).

Another area where pacman excels is speed.Here’s why:

$ time pacman -Rsn libreoffice
..<snip>..
Total Removed Size: 321.83 MB
Do you want to remove these packages? [Y/n] y
..<snip>..
real 0m4.683s                 <-- dafuq?!
user 0m0.637s
sys 0m0.320s

That’s 320 mb worth of software uninstalled in less than 5 secs. Let’s see how fast it installs:

$ time pacman -S libreoffice
..<snip>..
Total Installed Size: 321.83 MB
Proceed with installation? [Y/n] y
..<snip>..
real 0m18.833s                <--dafuq?!
user 0m16.646s
sys 0m0.557s

Less than 20 secs. A typical Windows install of libreoffice can take upto 5 minutes. This is a package manager with it’s a** on fire.!

Arch Build System (ABS):

In their hunt for software, most distro users are afraid to venture beyond the reaches of their respective distro’s repos and with a good reason.Installing software from source code typically involves downloading the source tarball from the developer’s site, untarring it, referring the DEPS (or equivalent) file to know what it depends on, hunting for those missing dependencies, referring the README (or equivalent) for instructions on compiling, actually compiling the source code and finally installing the generated binary file. Uninstalling is another headache that forces you to remove every single file owned by the package.

Enter ABS. With it, you can create pacman binaries from any source code package. The binary can then installed to the system with pacman -U /path/to/binary. The keyword here is PKGBUILD. It’s a simple text file that contains details like the URL where the source code is located, the dependencies of the package, the package version etc. and functions like build() which details the exact steps needed to compile the source code. Finding the PKGBUILD for a package is not very difficult courtesy the Arch User Repository (AUR). The AUR is a huge collection of PKGBUILDs that are uploaded and maintained by the Arch users. If a software you are looking for is not available in the official repos, you can almost always be sure to find a PKGBUILD for it in the AUR.

The functionality of ABS extends beyond providing packages not included in repos. The Arch developers offer a “PKGBUILD tree” of  sorts for all packages available in repos. This gives you a choice between installing repo packages using pacman -S foo or building it from source using ABS (particularly useful if you want to compile a package in some other way than what the the package maintainer intended (Pssst….custom kernel.!)). To get this “PKGBUILD tree”  on your system, do a pacman -S abs followed by abs. This will download PKGBUILDs for all repo packages and store them neatly under /var/abs. Installing from a PKGBUILD is as simple as copying the PKGBUILD to a temporary directory (/var/abs/local is a sensible choice), cd‘ing there and running makepkg -s. The generated pacman binary can be installed with pacman -U <binary>.

Networking Woes:

So the famous saying goes, “A Linux system that works flawlessly on first try is not worth the effort.” The outright fabrication popular adage definitely held true in my case. Trouble began before the installation could. You see, I had downloaded the netinstall iso which includes only the kernel and installation scripts. During installation, it connects to the servers and downloads the latest and greatest versions of all specified packages (as opposed to bundling the entire kitchensink in the install CD/DVD itself) to give you the newest, freshest install possible. IF you can manage to get a working conection before beginning the installation, that is. For me, this was easier said than done: the installer could not find any network interfaces to connect to the internet with. Logging in from another console, I did an ifconfig -a which confirmed my fear: only the loopback interface had been detected. Feeling a bit dejected, I let lspci -n give me the following insight on my NICs:

.....
04:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01]
]05:00.0 Ethernet controller [0200]: Atheros Communications AR8152 v1.1 Fast Ethernet [1969:2060] (rev c1)
.....

A hour of Googling and IRCing later, I knew the cause of my networking woes. Support for my Ethernet NIC had been added in kernel 2.6.34 while the kernel on the install CD was 2.6.33. As for my Wireless NIC, it needed a binary blob from Broadcom to perform it’s duties. Once the cause was known, solution was another 572MB plus a few more away. The newer kernel on the Archboot CD detected my ethernet and the AUR package enabled wireless connectivity. What exactly had I accomplished.? I could now, by a mere click of an inconspicious button, set off a chain of TCP packets to travel at blazing speeds through the humungous complexity of fibre-optic pathways criss-crossing the length and breadth of the planet to reach with unerring precision their intended destination, a UNIX server clocking billions of cycles per seconds on it’s 16-core Intel Xeon processor, which scours the deep recesses of it’s underlying filesystem structure to retrieve a very specific document and sends it back over the same labyrinthine pathways to finally reach my browser window, all because I wanted to read my favourite XKCD comic. Or, for the brewity-conscious, I was now a part of the Internet.

Multimedia Keys in Openbox:

Here I will describe how I got my multimedia keys working in Openbox. The complete listing of multimedia keys and their keycodes is:

$ xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
246 XF86WLAN
244 XF86Battery
232 XF86MonBrightnessDown
233 XF86MonBrightnessUp
121 XF86AudioMute
122 XF86AudioLowerVolume
123 XF86AudioRaiseVolume
173 XF86AudioPrev
172 XF86AudioPlay
171 XF86AudioNext
199 XF86TouchpadToggle

The intended function of each key is pretty evident from it’s name. The keys that worked without any extra configuration were XF86WLAN and XF86MonBrightness[Down|Up]. To get the rest working, I added the following code to the keyboard section of rc.xml:

<keybind key="XF86AudioMute">
<action name="Execute">
<command>amixer -q set Master toggle</command>
</action>
</keybind>
<keybind key="XF86AudioLowerVolume">
<action name="Execute">
<command>amixer -q set Master playback 10%- unmute</command>
</action>
</keybind>
<keybind key="XF86AudioRaiseVolume">
<action name="Execute">
<command>amixer -q set Master playback 10%+ unmute</command>
</action>
</keybind>
<keybind key="XF86TouchpadToggle">
<action name="Execute">
<command>~/bin/tptoggle</command>
</action>
<!--more-->
</keybind>
<keybind key="XF86AudioPrev">
<action name="Execute">
<command>/usr/bin/exaile -p</command>
</action>
</keybind>
<keybind key="XF86AudioNext">
<action name="Execute">
<command>/usr/bin/exaile -n</command>
</action>
</keybind>
<keybind key="XF86AudioPlay">
<action name="Execute">
<command>/usr/bin/exaile -t</command>
</action>
</keybind>

~/bin/tptoggle is an executable file containing the one-liner:

/usr/bin/synclient TouchpadOff=`expr $(synclient -l | grep TouchpadOff | grep -o .$) = 0`

Getting the XF86Audio* keys to work with Exaile was easy since it supports most of it’s GUI functions from CLI too. I have no idea whether other music players can do the same thing. I haven’t yet found a way to get the XF86Battery key to display anything meaningful.

…And The End.

I am currently using KDE 4.6 (Openbox is fun, but KWin’s effects reign supreme.! :P). Need to use Catalyst drivers since open source ATI drivers don’t support 3D for my GPU…yet. With kernel 2.6.37, brcm80211 driver has been integrated as a kernel module, allowing me to get rid of the Broadcom’s STA driver for my wireless. Sleep doesn’t work, probably because of catalyst drivers acting up. That about sums it up. The distro purrs along flawlessly, needing only a bit of attention when pacman -Syu is performed. This one’s here to stay.!