Comparison of tiling window managers

From ArchWiki
Revision as of 16:59, 19 February 2010 by Aedit (talk | contribs) (try to clarify)
Jump to navigation Jump to search

This article provides an unbiased comparison of the most popular tiling window managers (as opposed to floating window managers).

Comparison table

The following table lists the most popular tiling window managers alongside notable features, providing readers with a quick overview. More in-depth descriptions follow this table.

Comparison of tiling window managers
Window Manager Written in Configured with Management style System tray support On-the-fly reload Information bars Compositing Default layouts Pixel usage External control Library Multiple (n) monitor behavior
Awesome C Lua Dynamic Built-in Yes Built-in, images and text Yes, with an external manager such as xcompmgr 1-pix borders, h-tab titles XCB
dwm C C (recompile) Dynamic None Optional Built-in, reads from root window name Yes, with an external manager such as xcompmgr v-stack, max Xlib n regions, 9 workspaces fixed to each region
i3 C Text Manual None Yes i3status with dzen2 or xmobar No rows, columns, v-tab, h-tab, max 2-pix borders, titles XCB
Ion3 C Lua Manual trayion Yes configurable ? h-tab, max
Musca C Text, own command set, C(recompile) Manual None No, but allows running of musca commands on the fly None No h-split, v-split, max commands, hooks
Ratpoison C Text Manual None Yes Yes No max
Scrotwm C Text Dynamic None Yes Built-in, reads from user script No nv-stack, nh-stack, max 1-pix borders, no titles Xlib n regions, 10 workspaces visible in any region
Stumpwm Lisp Lisp Manual None Yes Yes No
subtle C Ruby Manual Built-in Yes Built-in (Ruby) No grid variable borders, no titles hooks
wmfs C Text Dynamic None Yes Built-in, set with command, color text No nh-stack (and invert), nv-stack (and invert), mirror-v, mirror-h, grid, max variable borders, titles commands Xlib
wmii C Anything Manual None Yes Built-in No columns, max, v-tab titles Plan 9 filesystem one big region
xmonad Haskell Haskell Dynamic None Yes No Yes, with xmonad-contrib and an external manager nv-stack, nh-stack, max 1-pix borders, no titles Xlib n regions, 9 workspaces visible in any region

Management style

Dynamic management emphasizes automatic management of window layouts for speed and simplicity. Manual management emphasizes manual adjustment of layout and sizing with potentially more precise control, at the cost of more time spent moving and sizing windows.


A number of common layout types appear in several tiling WMs, although the terminology varies somewhat.

  • max: one window shown fullscreen (with or without a status bar, title and borders). Aka: monocle (dwm).
  • h-stack: master area in top half, other windows stack up horizontally in the bottom half. The master area may be resizable. May be inverted top-bottom (wmfs). Aka: bottom stack (dwm).
  • v-stack: master area in left half, other windows stack up vertically in the right half. The master area may be resizable. May be inverted left-right (wmfs). Aka: tile (dwm).
  • nh-stack: h-stack allowing >=1 windows in master area. Aka: nbstack (dwm)
  • nv-stack: v-stack allowing >=1 windows in master area. Aka: ntile (dwm)
  • mirror-h: nh-stack with stacks above and below the master area
  • mirror-v: nv-stack with stacks to the left and right of the master area
  • h-tab: one window shown fullscreen with all window titles shown horizontally (like browser tabs)
  • v-tab: one window shown fullscreen with all window titles shown vertically. Aka: stack (wmii).
  • h-split: a keybinding splits the current window horizontally creating space for another
  • v-split: a keybinding splits the current window horizontally creating space for another
  • columns: manual layout style which treats windows as belonging to vertical columns
  • rows: manual layout style which treats windows as belonging to horizontal rows
  • grid: window positions and sizes based on a regular NxM grid. May be automatic (like wmfs) or manual (like Subtle).

Key bindings

Tiling window managers are usually designed to be used entirely with the keyboard or with keyboard & mouse. This is for speed (reaching for and moving a mouse is slow) and ease of use. Sensible key bindings are crucial to making workflow fast and efficient. Some default sets are better than others, but generally the keys can be rebound as desired by the user.


awesome on its own can provide many of the functions of a desktop environment. Configured in Lua, it has a system tray, information bar, and launcher built in. There are extensions available to it written in Lua, but they are less smoothly integrated than those of XMonad. Awesome uses XCB as opposed to Xlib, which may result in a speed increase. Awesome has other features as well, such as an early replacement for notification-daemon, a right-click menu similar to that of the *box window managers, and many other things.


dwm is by far the simplest of the window managers listed here. It does not include a tray app or automatic launcher, although dmenu integrates well with it, as they are from the same author. It has no text configuration file. Configuration is done entirely by modifying the C source code, and it must be recompiled and restarted each time it is changed. It is more lightweight than the others listed here, at the expense of certain features.


Home:, AUR: i3 was created because wmii, the authors' favorite window manager at the time, didn’t provide some features they wanted. Notable differences are in the areas of Xinerama and the table metaphor. For speed the Plan 9 interface of wmii is not implemented.


Ion is a tiling window manager with tabbed frames. It uses Lua as an embedded interpreter which handles all of the configuration. It mainly uses the keyboard to access the functions but also supports the mouse for some things.


A simple dynamic window manager for X, with features nicked from ratpoison and dwm: Musca operates as a tiling window manager by default. It uses manual tiling, which means the user determines how the screen is divided into non-overlapping frames, with no restrictions on layout. Application windows always fill their assigned frame, with the exception of transient windows and popup dialog boxes which float above their parent application at the appropriate size. Once visible, applications do not change frames unless so instructed.


Ratpoison is configured with a simple text file, as opposed to some of the other tiling window managers which are configured with programming languages. While this reduces flexibility, it can be easier to understand. The information bar in Ratpoison is somewhat different, as it shows only when needed. It serves as both an application launcher as well as a notification bar. Ratpoison does not include a system tray and is quite lightweight.


scrotwm is a small dynamic tiling window manager largely inspired by xmonad and dwm. It tries to stay out of the way so that valuable screen real estate can be used for much more important stuff. It has sane defaults and does not require one to learn a language to do any configuration, being configured with a text file. It was written by hackers for hackers and it strives to be small, compact, and fast. It has a built-in status bar fed from a user-defined script.


Stumpwm is similar to Ratpoison but is written and configured completely in Lisp. It can be reconfigured and reloaded while running. As with wmii and Ratpoison, it is a manual window manager. Its information bar can be set to show constantly or only when needed. It does not include a system tray.


subtle is a tiling window manager with flexible manual layouts based on predefined sizes and positions corresponding by default to 1x2, 2x1, 1x3, 2x2 and 2x3 grid elements. It has workspace tags and automatic client tagging, mouse and keyboard control as well as an extendable statusbar.


WMFS (Window Manager From Scratch) is a lightweight and highly configurable tiling window manager for X. It can be configured with a configuration file, supports Xft (Freetype) fonts and is compliant with the Extended Window Manager Hints (EWMH) specifications. It's still under heavy development


wmii uses a manual style of management -- the user must manually move windows around. While more work than dynamic management, this also provides more flexibility by default. wmii is configured via a Plan 9 file system, which allows any program that can work with text to configure it. The default configuration is in bash and rc (the Plan 9 shell), but programs exist written in ruby, for example. It has a status bar and launcher built in, but no system tray.


xmonad is written in Haskell, and it is configured in Haskell. This allows great flexibility, although this can be confusing at times. For all configuration changes, xmonad must be recompiled. However, this normally takes ~2 seconds, and can be done without affecting running programs. XMonad, in itself, is quite simple, but there is a large library called xmonad-contrib which provides many other features. XMonad does not include any utility programs, but others, such as dzen2 and xmobar, make it easy to display such things as workspace information. xmonad does not come with an application launcher, but there are modules in xmonad-contrib which provide one, as well as programs like dmenu and gmrun. There is no system tray, but this can be provided by applications such as stalonetray and trayer.