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,
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.
Awesome configuration
Keybindings
Quake console
XRandR
Widgets
Miscellaneous
Keyboard configuration
Getting rid of most GNOME stuff
Terminal color scheme
Next steps
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. Of course, 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
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 to dynamically reconfigure
outputs: you plug an external screen to your laptop and you issue
some command to enable it:
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:
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 use 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
groups2. I finally opted for this simple configuration:
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 those 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 support3. 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:
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. ↩