Switching to the awesome window manager
Vincent Bernat
I have happily used FVWM as my window manager for more than 10 years. However, I recently got tired of manually arranging windows and using the mouse so much. A window manager is one of the handful pieces of software getting in your way at every moment which explains why there are so many of them and why we might put so much time in it.
I decided to try a tiling window manager. While i3 seemed pretty hot and powerful (watch the screencast!), I really wanted something configurable and extensible with some language. So far, the common choices are:
- awesome, written in C, configurable and extensible in Lua;
- StumpWM, written, configurable and extensible in Common Lisp; and
- xmonad, written, configurable and extensible in Haskell.
I chose awesome, despite the fact that StumpWM vote for Lisp seemed a better fit (but it is more minimalist). I hope there is some parallel universe where I enjoy StumpWM.
Visually, here is what I got so far:
Awesome configuration#
Without a configuration file, awesome does nothing. It does not come with any hard-coded behavior: everything needs to be configured through its Lua configuration file. A default one is provided but you can also start from scratch. If you like to control your window manager, this is somewhat wonderful.
awesome is well documented. The wiki provides a FAQ, a good introduction and the API reference is concise enough to be read from the top to the bottom. Knowing Lua is not mandatory since it is quite easy to dive into such a language.
I have posted my configuration on GitHub. It should not be used as is but some snippets may be worth to be stolen and adapted into your own configuration. The following sections put light on some notable points.
Keybindings#
Ten years ago was the epoch of scavanger hunts to recover
IBM Model M keyboards from waste containers. They were great to
type on and they did not feature the infamous Windows keys. Nowadays,
this is harder to get such a keyboard. All my keyboards now have
Windows keys. This is a major change with respect to configure a
window manager: the left Windows key is mapped to Mod4
and is
usually unused by most applications and can therefore be dedicated to
the window manager.
The main problem with the ability to define many keybindings is to
remember the less frequently used one. I have monkey-patched
the awful.key
module to be able to attach a documentation string to a
keybinding. I have documented the whole process on the
awesome wiki.
Quake console#
A Quake console is a drop-down terminal which can be toggled with some key. I was heavily relying on it in FVWM. I think this is still a useful addition to any awesome configuration. There are several possible solutions documented in the awesome wiki. I have added my own1 which works great for me.
XRandR#
XRandR is an extension which allows one to dynamically reconfigure outputs: you plug an external screen to your laptop and you issue some command to enable it:
$ xrandr --output VGA-1 --auto --left-of LVDS-1
awesome detects the change and will restart automatically. Laptops
usually come with a special key to enable/disable an external
screen. Nowadays, this key does nothing unless configured
appropriately. Out of the box, it is mapped to XF86Display
symbol. I
have associated this key to a function that will
cycle through possible configurations depending on the
plugged screens. For example, if I plug an external screen to my
laptop, I can cycle through the following configurations:
- only the internal screen
- only the external screen
- internal screen on the left, external screen on the right
- external screen on the left, internal screen on the right
- no change
The proposed configuration is displayed using naughty, the notification system integrated in awesome.
Widgets#
I was previously using Conky to display various system-related information, like free space, CPU usage and network usage. awesome comes with widgets that can fit the same use. I am relying on vicious, a contributed widget manager, to manage most of them. It allows one to attach a function whose task is to fetch values to be displayed. This is quite powerful.
Here is an example with a volume widget:
local volwidget = widget({ type = "textbox" }) vicious.register(volwidget, vicious.widgets.volume, '<span font="Terminus 8">$2 $1%</span>', 2, "Master") volwidget:buttons(awful.util.table.join( awful.button({ }, 1, volume.mixer), awful.button({ }, 3, volume.toggle), awful.button({ }, 4, volume.increase), awful.button({ }, 5, volume.decrease)))
You can also use a function to format the text as you wish. For example, you can display a value in red if it is too low. Have a look at my battery widget for an example.
Miscellaneous#
While I was working on my awesome configuration, I also changed some other desktop-related bits.
Keyboard configuration#
I happen to setup all my keyboards to use the QWERTY layout. I use a
compose key to input special characters like “é.” I have also
recently used Caps Lock as a Control key. All this is perfectly
supported since ages by X11 I am also mapping the Pause key to
XF86ScreenSaver
key symbol which will in turn be bound to a function
that will trigger xautolock
to lock the screen.
Thanks to a great article about extending the X keyboard map with xkb, I discovered that X was able to switch from one layout to another using groups.2 I finally opted for this simple configuration:
$ setxkbmap us,fr '' compose:rwin ctrl:nocaps grp:rctrl_rshift_toggle $ xmodmap -e 'keysym Pause = XF86ScreenSaver'
I switch from us
to fr
by pressing both left Control and left
Shift keys.
Getting rid of most GNOME stuff#
Less than one year ago, to take a step forward to the future, I
started to heavily rely on some GNOME components like GNOME
Display Manager, GNOME Power Manager, the screen saver,
gnome-session
, gnome-settings-daemon
and others. I had numerous
problems when I tried to setup everything without pulling the whole
GNOME stack. At each GNOME update, something was broken: the
screensaver didn’t start automatically anymore until a full session
restart or some keybindings were randomly hijacked by
gnome-settings-daemon
.
Therefore, I have decided to get rid of most of these components. I
have replaced GNOME Power Manager with system-level tools like
sleepd and the PM utilities. I replaced the GNOME screensaver with
i3lock and xautolock. GDM has been replaced by SLiM which
now features ConsoleKit support.3 I use ~/.gtkrc-2.0
and ~/.config/gtk-3.0/settings.ini
to configure GTK+.
The future will wait.
Terminal color scheme#
I am using rxvt-unicode as my terminal with a black background (and some light transparency). The default color scheme is suboptimal on the readability front.
Sharing terminal color schemes seems a popular activity. I finally opted for the “derp” color scheme which brings a major improvement over the default configuration.
I have also switched to Xft for font rendering using DejaVu Sans
Mono as my default font (instead of fixed
) with the following
configuration in ~/.Xresources
:
Xft.antialias: true Xft.hinting: true Xft.hintstyle: hintlight Xft.rgba: rgb URxvt.font: xft:DejaVu Sans Mono-8 URxvt.letterSpace: -1
The result is less crisp but seems a bit more readable. I may switch back in the future.
Next steps#
My reliance to the mouse has been greatly reduced. However, I still need it for casual browsing. I am looking at luakit a WebKit-based browser extensible with Lua for this purpose.
-
The console gets its own unique name. This allows awesome to reliably detect when it is spawned, even on restart. It is how the Quake console works in the mod of FVWM I was using. ↩︎
-
However, the layout is global, not per-window. If you are interested by a per-window layout, take a look at kbdd. ↩︎
-
Nowadays, you cannot really survive without ConsoleKit. Many PolicyKit policies do not rely on groups any more to grant access to your devices. ↩︎