# spectrwm: A Compact Dynamic Window Manager for X11

> spectrwm is a small C-based dynamic tiling and reparenting window manager for X11. It suits users who want keyboard-driven layouts, persistent workspaces, and configuration without learning a programming language, but its X11-only scope excludes Wayland users.

**conformal/spectrwm** — A small dynamic tiling window manager for X11.

- Repository: https://github.com/conformal/spectrwm
- Stars: 1,410 · Forks: 105
- Language: C
- License: ISC
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/conformal-spectrwm

## Why spectrwm Targets Keyboard-Centered X11 Work

spectrwm solves a specific desktop-management problem: arranging application windows predictably without spending screen area on window decoration or manually resizing every window. It is aimed at users of X11 who prefer dynamic tiling, keyboard commands, workspaces, and a text configuration file. The README explicitly presents configuration as human-readable and says that users do not need to learn a programming language to configure it.

The project supports several kinds of workspace manipulation. Windows can enter or leave the master area, move between workspaces or regions, and become floating. Floating windows can be moved and resized, while drag-to-float changes the behavior of pointer-based window placement. Regions can be user-defined, and the master area can be resized. These controls address a common tiling-window-manager trade-off: automatic placement saves space, but users still need exceptions for dialogs, media viewers, tools that benefit from temporary free positioning, or applications with unusual geometry requests.

It also targets multi-screen X11 sessions through dynamic RandR support. That matters when displays are connected, disconnected, or rearranged, although the README does not describe the exact event sequence. Navigation can use either the keyboard or mouse across screens, and the status bar can be customized. The intended user is therefore not limited to a single-window workstation. The feature set is aimed at people managing several displays and many windows through configured keys rather than relying primarily on a desktop shell.

The project draws on xmonad and dwm. Its own positioning is a compact C implementation with human-readable configuration. It does not present itself as a general desktop environment, panel suite, or complete session replacement. It manages windows and layout behavior, which leaves the broader session around it as a separate adoption concern.

## spectrwm's Tiling, Reparenting, and X11 Data Path

The repository identifies `spectrwm.c` as the principal C source file and links spectrwm against several X11 and XCB libraries. That dependency set provides the clearest view of the implementation boundary. The program links `libX11`, `libX11-xcb`, and multiple `libxcb` components for XRandR, XInput, XTest, ICCCM, keysyms, and other X11-facing functions. It also links FreeType, Xft, Fontconfig, and Xcursor. These libraries support its window handling, input, monitor awareness, fonts, status drawing, and pointer interaction.

The README describes spectrwm as both a tiling and reparenting window manager. Tiling determines how managed windows are divided among the screen, master area, workspaces, and configurable regions. Reparenting means clients can be placed under windows managed by the window manager. The project documentation confirms the feature, but it does not describe the internal client lifecycle or drawing sequence in enough detail to claim more about that mechanism.

Configuration is file-based rather than code-based. Repository entries include `spectrwm.conf` and several translated examples, including `spectrwm_cz.conf`, `spectrwm_es.conf`, `spectrwm_fr.conf`, `spectrwm_fr_ch.conf`, and `spectrwm_se.conf`. The documented feature list identifies a user-definable modifier key, key bindings, application launch bindings, quirk bindings, regions, colors, and border width. This makes the configuration surface broader than a fixed set of tiling commands, although the README does not enumerate every valid key or directive.

The feature list also names EWMH support and customizable tile gaps. A configurable gap can produce a one-pixel border between tiled windows, according to the README. The stated restart behavior preserves state rather than ending the session whenever configuration changes are applied. The documentation does not explain whether all open applications survive a restart, so the safe conclusion is narrower: spectrwm provides a restart mechanism intended to avoid losing its state.

## Building spectrwm from the BSD-Style Makefile

The README sends new users to the project's current Installation guide on the GitHub wiki rather than embedding a complete build recipe in `README.md`. Based on the repository layout, compilation is centered on the BSD-style `Makefile`. It defaults `PREFIX` to `/usr/local`, builds `spectrwm` as `PROG`, and places the executable under `${PREFIX}/bin`. The man page is handled as `MAN=spectrwm.1`.

The repository files do not contain the text of the linked installation guide, so they do not establish package-manager commands, prerequisite package names, a tested startup command, or a universal set of build commands. Inventing those details would make the tutorial unreliable across the BSD, Linux, macOS, and Cygwin systems named in the README. Start with the linked Installation guide and use the platform instructions there.

The `Makefile` confirms several build constraints. Compilation uses C99 and enables warnings including `-Wmissing-prototypes`, `-Wall`, `-Wextra`, and `-Wshadow`. Include paths refer to `${X11BASE}/include` and the FreeType 2 include directory. Linking requires X11, XCB, Fontconfig, Xft, and related libraries, so a successful compiler is not sufficient. The local development headers and link libraries for those dependencies must exist before the documented build procedure can complete.

There is also a `beforeinstall` rule that creates a symbolic link from `spectrwm` to `scrotwm` in the installation binary directory. Based on the repository contents, that rule exists because the older project name appears in that installation path. The documentation does not say whether current configurations or startup entries expect either name, so do not assume the alias replaces every reference. The repository also includes `initscreen.sh`, platform-specific directories, a desktop entry, and a man page.

## A First spectrwm Session Without Guessing Its Startup

A first real use starts with the wiki's installation procedure, followed by inspection of the repository's default configuration, `spectrwm.conf`. Because that file's contents are not included in the README, this article cannot safely reproduce directives or invent a minimal configuration. The concrete first step is to compare `spectrwm.conf` with the current `spectrwm.html` man page and identify the modifier key and basic navigation bindings documented for the installed version.

Once spectrwm is started according to the platform-specific guide, the documented feature set indicates several behaviors to verify. Open two or more application windows and confirm that they are divided into the configured tiling regions. Check whether the first window occupies the master area and whether subsequent windows fill the remaining space according to the selected layout. These are the central operations for which spectrwm is intended.

Next, exercise a documented floating-window control. Dragging an application window should invoke drag-to-float, while configured keys can move or resize floating windows. Confirm that the window stays outside automatic tiling after the operation. This check matters because floating placement changes normal resize and movement expectations, and it is one of the features that distinguishes spectrwm from a manager restricted entirely to tiled clients.

The remaining first-session checks should follow `spectrwm.conf` rather than assumptions. Verify the modifier key, workspace movement, application launch bindings, status bar, monitor changes, and the selected tile gap. The README claims restartability without state loss, but it does not provide a restart procedure. Use the current man page or linked documentation for that exact command instead of guessing. A successful first session should therefore end with known key bindings, correct placement across configured regions, expected behavior for floating windows, and a documented way to restart or exit.

## X11 Scope and Configuration Trade-offs in spectrwm

The most significant boundary is X11. spectrwm targets X11 sessions and its implementation links directly to X11 and XCB libraries. It is therefore not a Wayland compositor or window manager, and users running a Wayland-only desktop cannot adopt it for that session. The README lists support for multiple operating systems, including BSD systems, Linux, macOS, and Windows through Cygwin, but broad operating-system support does not change the display-server requirement.

The configuration model has a similar constraint. spectrwm avoids requiring users to learn a programming language, yet its supported customization includes regions, layouts, bindings, quirks, colors, borders, and application launches. That is more capable than a manager with fixed behavior, but it also creates a learning curve around syntax, key identifiers, and the relationship between regions and screens. The README does not include a complete directive reference, configuration validation behavior, or an error-reporting explanation. Those details should be checked in `spectrwm.html` before deployment.

The project may also be the wrong choice for someone who wants autonomous layout management. Its manual commands and quick launch menu are useful, but the README does not claim automatic window placement rules comparable to dedicated auto-tiling systems. Likewise, the feature list does not describe a compositing pipeline, animation system, or comprehensive desktop shell. Treating spectrwm as a complete modern desktop stack would exceed what the repository confirms.

A further limitation concerns behavior details. The README states that Xinerama support is one of xmonad's benefits, while spectrwm advertises dynamic RandR support for multiple heads. It does not establish that every display arrangement behaves identically, nor does it explain handling of mixed DPI, scaling, hot-plug events, or unusual client requests. Those cases require direct verification on the target X11 configuration.

## spectrwm Compared with xmonad and dwm

The README names two real alternatives and explains its differences from each. xmonad is described as having useful defaults, key bindings, and Xinerama support, while spectrwm is positioned as a C implementation that does not require a programming language for configuration. The README also criticizes xmonad for not being written in C. The meaningful distinction described here is implementation and configuration style: xmonad is not written in C, whereas spectrwm provides a human-readable configuration in a compact C program.

dwm is the second alternative. Its ideas influenced spectrwm, according to the README. spectrwm instead emphasizes human-readable configuration that can be edited without learning a programming language. The README does not catalog dwm's feature parity, current maintenance, packaging, or extension mechanisms, so the comparison should remain tied to these documented design choices rather than broad performance claims.

Neither alternative removes the need to assess the X11 session itself. spectrwm's X11 and XCB dependencies make it unsuitable where Wayland is mandatory. Its C codebase and BSD-style build file may also appeal to users who prefer a compact native program, but the repository's size claims are project positioning rather than measured evidence. The README states that spectrwm is small, compact, and fast; it supplies no benchmark or resource-use data.

A practical comparison should focus on configuration format, required libraries, session startup, monitor behavior, and desired window-management rules. For users already committed to an xmonad or dwm configuration with a working ecosystem around it, migration is not justified merely by spectrwm's feature list. For users seeking an X11 tiling manager configured through text without a programming language, the documented design is a clearer reason to evaluate it.

## spectrwm Maintenance, Release, and Licensing Costs

The repository is not archived, and its last push was on 2026-07-20. Recent tagged releases include `SPECTRWM_3_7_0` on 2025-08-27, `SPECTRWM_3_6_0` on 2024-07-10, and `SPECTRWM_3_5_1` on 2023-11-25. This indicates that release and repository activity continued after the older releases, but the repository does not document a long-term support policy, compatibility matrix, or migration guarantee.

Upgrade cost should be assessed against configuration syntax and native dependencies. The repository includes `CHANGELOG.md`, versioned releases, translated configuration examples, and a generated HTML man page derived from `spectrwm.1`. Those files provide places to inspect changes. A user should compare the installed configuration with the configuration shipped for the target release before updating. The default branch is `master`.

Building from source also creates an ongoing ownership burden. The `Makefile` expects multiple development libraries and BSD build infrastructure, while supported platform directories include `freebsd/`, `linux/`, `netbsd/`, and `osx/`. Package availability is not documented in the repository files available here. Distributions or operating systems without an established build recipe may therefore leave the user responsible for dependencies and installation.

spectrwm is licensed under ISC unless an individual file states otherwise. The README says patches can be accepted provided they are also licensed under ISC. That is a favorable licensing boundary for source reuse and modification, but it does not answer questions about bundled dependencies, trademarks, or user-created configurations. No legal advice is offered here.

## Conclusion

Adopt spectrwm if you need a compact X11 tiling manager and can work through its C build dependencies and configuration model. Do not adopt it if Wayland support or a large built-in configuration ecosystem is a prerequisite. Verify the linked installation guide, X11 and XCB development dependencies, startup method, and configuration behavior before replacing an existing session.

## FAQ

### What display server does spectrwm require?

spectrwm targets X11 and links against X11 and XCB libraries. It is not a Wayland window manager or compositor.

### Do I need to learn a programming language to configure spectrwm?

No. The README says spectrwm uses a human-readable configuration file and does not require learning a programming language for configuration.

### Where are spectrwm installation instructions documented?

The README links to the project's current Installation guide on the GitHub wiki. The repository also contains a BSD-style `Makefile`, but the README does not provide a complete platform-specific command sequence.

## Sources

- [conformal/spectrwm on GitHub](https://github.com/conformal/spectrwm)
- [Issues](https://github.com/conformal/spectrwm/issues)
- [License: ISC](https://github.com/conformal/spectrwm/blob/master/LICENSE)
- [README](https://github.com/conformal/spectrwm/blob/master/README.md)
- [Releases](https://github.com/conformal/spectrwm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/conformal-spectrwm