2bwm: a floating X11 window manager with two borders and no panel

Everything is reachable from the keyboard, the mouse is optional

2bwm is a floating window manager written over the XCB library and derived from mcwm by Michael Cardell. Its defining trait, stated in the README, is that everything is accessible from the keyboard, while a pointing device can be used for move, resize and raise or lower. That is the inverse of the usual floating manager arrangement, where the mouse leads and the keyboard is a shortcut.

The README is direct about who this is for: it carries a warning that the window manager and the repository are experimental and that 2bwm is only meant for advanced users. That is not a formality. The project ships a configuration header that you edit before compiling, and the feature list is expressed entirely in terms of window operations rather than a settings interface.

The inheritance from mcwm is listed in the README as a set of features that came with the original: maximise horizontally, maximise vertically, 10 virtual workspaces, crash proof window placement, snappy borders, and control entirely with the keyboard. The mcwm project pages are linked for the full picture.

So the shape of the tool is a small C program, a header of key bindings and behaviour toggles, and a manual page. There is no configuration file format, no runtime IPC, and no graphical settings editor, which is both the reason it is small and the reason it is not for beginners.

Teleporting windows is the feature set, not resizing

The features 2bwm adds to mcwm are listed exhaustively in the README, and they describe a window manager built around placing windows precisely rather than around decorating them.

You can teleport windows into the corners, teleport them into the top, middle or bottom centre, teleport them to cover half of the monitor, and add offsets around the monitor. You can multiply or divide a window's width or height by 2, grow or shrink windows while keeping the aspect ratio, and move or resize windows by two user defined amounts. The two borders are fully customisable and show the window status.

Those two borders are the actual signature of the project, and they are what gives it its name. In a tiling manager the frame around a window is decorative; here the border carries the status of the window it surrounds, which in a floating arrangement is the only way to see at a glance what a given window is, since windows overlap.

The fixed ratio operations and the corner teleports are the keyboard equivalent of the layout management a tiling manager gives you structurally. The cost is that you have to remember bindings, and the README's warning about advanced users is really about that.

No bar is shipped, docks are ignored instead

2bwm does not come with any bar or panel. Instead it respects the _NET_WM_WINDOW_TYPE_DOCK property of windows and ignores them, so most panels should work with it.

That design decision is what makes the README list of working panels credible: cairo-dock, fbpanel, hpanel, lxpanel, tint2 and xfce4-panel are listed as tested and working, and two bars, bar and dzen2, are listed separately. A window manager that drew its own bar would fight these programs for screen space and for the dock property itself.

The practical consequence is that 2bwm is not a self contained desktop. You pick a panel, or you run without one. If you are moving from a full desktop environment and expect the window manager to fill that role, the first session will feel empty.

The README also has a troubleshooting section for clickable areas with bar, which points to a known issue with that particular bar program. It is the only troubleshooting item shown in the document.

Dependencies include an XCB extension that is not yet official

2bwm depends on the XCB libraries, and the README warns that some of them are quite new, so most systems will not have them installed by default. The list it gives is not exhaustive: xcb-randr, xcb-keysyms, xcb-icccm, xcb-ewmh and xcb-xrm, with xcb-xrm singled out as quite new.

The xcb-xrm note is the important one. The README states that xcb-xrm is not official yet and links to a separate repository for it, noting that Archlinux and Voidlinux carry it in their repositories as xcb-util-xrm. If your distribution does not package it, the README gives the build sequence:

    cd xcb-util-xrm
    git submodule update --init
    ./autogen.sh --prefix=/usr
    make
    sudo make install

bash

That is a source build of a dependency that the window manager's own Makefile links against unconditionally. The link flags in the Makefile confirm the dependency set, listing -lxcb, -lxcb-randr, -lxcb-keysyms, -lxcb-icccm, -lxcb-ewmh and -lxcb-xrm.

So the real installation cost of 2bwm on a minimal system is not the window manager, it is the dependency chain.

Building from source means editing config.h before make

The from source route is short. The README gives four commands:

    $ git clone git://github.com/venam/2bwm.git
    $ cd 2bwm
    $ ${EDITOR:=vi} config.h
    $ make
    # make install

bash

The third line is the interesting one. config.h is opened in your editor before the build, and the Makefile lists it among the sources and the dependencies of the 2bwm.o object, so changing it changes the binary. That file is where the key bindings and the behavioural options live, and it is why the project can ship without a configuration file format.

The Makefile itself is a compact one. It sets VERSION=2014-8, builds with -Os and -s for size, and produces two targets: 2bwm from 2bwm.c, and hidden from hidden.c. The install target copies both binaries into the bin directory and installs the two manual pages, 2bwm.man and hidden.man, into the man1 directory.

There is also a dist target that produces a bzip2 compressed tarball from the listed distribution files, and uninstall and clean targets. The existence of hidden.c and hidden.man suggests a companion utility, and the README does not describe what hidden does beyond that.

Note the git protocol in the clone line, git:// rather than https://, and the commented install line, which the README leaves to the reader.

Distribution packages cover most of the usual Linux desktops

The README documents packaging across a wide set of systems, which is unusual for a project of this size and is a practical argument in its favour.

Archlinux offers 2bwm and 2bwm-git through the AUR, installed by cloning the package repository and running makepkg. Slackware has it on SlackBuilds.org for the 15.0 series. Void carries it in its official repositories, and CRUX offers 2bwm-git through z3bra's collection with an httpup sync and pkgmk sequence. pkgsrc is supported through /usr/pkgsrc/wm/2bwm with make and make install. Gentoo and Funtoo users have an ebuild from a separate nixers repository.

OpenBSD needs adjustments, and the README is specific about them: add /usr/X11R6/include to the search path, install gcc-4.7, and build with CC=egcc make.

For comparison, the size table in the README lists compiled executable sizes of 36KB for 2bwm, 33KB for dwm, 37KB for dvtm and 343KB for i3, and the memory table lists resident sizes of 728 KB for 2bwm against 1384 KB for dwm, 964 KB for bspwm and 4248 KB for i3. The README itself notes that all those window managers are small and that size does not really matter in the end, which is a fair warning against reading too much into the numbers.

Maintenance state and the licence gap

The repository is not archived and the last push was on 2026-09-03. There are no GitHub releases, and the version string inside the Makefile is 2014-8, so the project does not publish tagged versions through the release system. The default branch is master.

The top level of the repository holds 2bWM.png, 2bwm.c, 2bwm.man, Makefile, README.md, config.h, definitions.h, hidden.c, hidden.man, khash.h, list.h and types.h. The layout tells you how little code this is: a main file, a hidden utility, a handful of headers including khash.h and list.h for hash tables and linked lists, and a configuration header. The names khash.h and list.h suggest the hash table and list implementations, and the Makefile distribution list also includes a TODO file.

On licensing, the picture is unclear and you should check it yourself. The licence field for the project is recorded as unknown, and there is no licence file among the top level entries. For a program that is free to read and modify, that matters if you intend to redistribute it, package it, or build on its code, so treat the absence as a question to resolve with the author rather than as permission.

The security question is not addressed in the README either, so there is no published advisory channel for this project.

Editorial conclusion

2bwm suits an X11 user who wants floating windows, a keyboard first workflow and a footprint measured in kilobytes, and it is the wrong choice for a Wayland session, for a newcomer, or for anyone whose distribution has not packaged it. Before you commit, read the README warning that the window manager and the repository are experimental and meant for advanced users, check that your system provides the XCB libraries including the still unofficial xcb-xrm, and confirm the licensing position yourself, since no licence file appears at the top level of the repository even though the code is available to read.

Frequently asked questions

Official sources

1. Issues
2. README
3. venam/2bwm on GitHub