Monsterwm is a minimal, lightweight, tiny but monsterous dynamic tiling window manager. It will try to stay as small as possible. Currently under 750 lines with the config file included. It provides a set of four different layout modes (vertical stack, bottom stack, grid and monocle/fullscreen), and has floating mode support. Each virtual desktop has its own properties, unaffected by other desktops' settings.

Monsterwm is written with Xlib but there is also an XCB fork available.

Floating Mode

In floating mode one can freely move and resize windows in the screen space.
Changing desktops, adding or removing floating windows, does not affect the floating status of the windows.
Windows will revert to their tiling mode position once the user re-selects the current tiling mode.
Note, that one cannot "select" the floating mode,
but it will be enabled for any window if one tries to move or resize that window with the mouse.
The window is then marked, as being in floating mode.

Panel

The user can define an empty space on the bottom or top of the screen, to be used by a panel.
The panel is toggleable, but will be visible if no windows are on the screen.
Monsterwm does not provide a panel and/or statusbar itself.
Instead it adheres to the UNIX philosophy
and outputs information about the existing desktops
suchs as the number of windows and the tiling mode/layout of each desktop,
the current desktop and urgent hints whenever needed.
The user can use whatever tool or panel suits him best
(dzen2, conky, some-sorta-bar, w/e),
to process and display that information.

You can find an example of how to achieve this here.
You can actually parse that information with any language you want,
build anything you want,
and display the information as you'd like.
Do not be limited to that example.

Patches

There are several patches that extend monsterwm's functionality.

fib - adds fibonacci layout

monocleborders - adds borders to the monocle layout

showhide - adds a function to show and hide all windows on all desktops

uselessgaps - adds gaps around every window on screen

warpcursor - cursors follows and is placed in the center of the current window

bloat : bloat is merge of all patches with the current master, just for fun

core : core is is a very minimal subset of monsterwm, it's essentially its core, fully usuable at 610 loc

Customization

Application Rules

One can define rules for a specific application, which will be applied once the application spawns.
A rule is composed of four parts.

{ "MPlayer", 3, True, False },

the class or instance name of the application

the desktop in which the application should appear - index starts from zero/0

whether that desktop should be focused when the application is started

whether the application should start in floating mode

So the above rule, would place this to desktop Template:Keypress and change from the current desktop to that desktop, because follow is True. MPlayer will be tiled as every other window.

To get the application class or instance name you can use xprop .
If the desktop is set to a 'negative' number then the window spawns in the current desktop.

If we change the above rule to this one:

{ "MPlayer", -1, True, True },

then MPlayer will be spawned in the current desktop, floating.

Add Custom Keybinds

To add custom keybindings, you must edit config.h and recompile monsterwm.
That's why it is important to set them up on the initial installation to avoid having to do this again.
I'll show you a scenario in which you would need to add a keybinding to open the thunar filemanager with Template:Keypress.

First, you must add a line such as the following underneath the already-defined const char*'s
(Note: You can name it whatever you want. In this case, I named it thunarcmd):

const char* thunarcmd[] = {"thunar", NULL}};

thunarcmd is just a title for the command you want to construct and run.
Inside the curly brackets { and } is where you define the command to be executed.
Each command fragment that is seperated by a space is it's own value.
What I mean by that is that the command sequence ncmpcpp next
would be entered as {{ic|{"ncmpcpp", "next", NULL}}}.
The NULL value must be included at the end of each hotkey.

To actually register the hotkey with the window manager, you must look below that at the struct named {{ic|keys[].
This is where monsterwm stores all of it's keybindings.
An example entry for the thunarcmd we made above would be: