icewm keeps the X11 window manager small and out of the way

A window manager whose stated goal is to disappear

IceWM is a window manager for the X Window System, and the project states its features plainly: speed, simplicity, and not getting in the user's way. The project documentation adds a note about the name being decided on a very hot day, and that the aim of IceWM is to have good Feel and decent Look, with Feel being much more important than Look. That is a design brief rather than a slogan, and it explains the whole shape of the software. A tiling compositor wants your screen to be a structured workspace you configure in advance. IceWM wants floating windows that behave predictably, keyboard shortcuts that do the obvious thing, and no animation in the way. The audience is people running a plain X session, typically on Linux, who find a full desktop environment too heavy or too opinionated. That group is smaller than it was a decade ago, and it is exactly the group this project serves well.

This is a fork, and the fork is the point

The provenance matters when judging the maintenance story. This is a fork of the IceWM CVS tree on SourceForge, and it includes all changes from the icewm-1-3-BRANCH branch, greatly enhanced EWMH and ICCCM compliance, and patches collected from Arch Linux, Debian, pld-linux, the IceWM bug list and various other GitHub forks. In other words, the original upstream went quiet and this fork picked up the distribution patches and the protocol work. The version story reflects that history and is worth reading carefully. The tagged releases listed on the repository are 1.4.0, 1.4.1 and 1.4.2, all from July 2017. The project documentation, however, describes the current package as icewm-3.7.2, released on 2025-03-09. So the tag names and the documented version numbers are on different tracks, and if you are pinning a version you should confirm which scheme the artefact you install actually uses. The last push to the repository was on 2026-10-13 and it is not archived, so the fork itself is alive. There is also a VERSION file at the root, which is the most reliable place to check what a given checkout contains.

The build is autotools, and the quick start is five commands

Building from git is the documented path and the quick start is short:

    $> git clone https://github.com/bbidulock/icewm.git
    $> cd icewm
    $> ./autogen.sh
    $> ./configure
    $> make
    $> make DESTDIR="$pkgdir" install

That configures, compiles and installs, and the project notes that for those who like to spend the extra fifteen seconds reading ./configure --help, some compile time options can be turned on and off before the build. Two of them are named: --without-icesound disables sound support, and --disable-librsvg and --disable-nanosvg can be used when the image library supports SVG natively. An alternative CMake based build is documented separately in INSTALL-cmakebuild.md, and the repository holds both build systems, with a top level CMakeLists.txt alongside configure.ac and Makefile.am. The dependency list for building from a tarball is a set of X libraries, gcc or clang, and imlib2 or libgdkpixbuf for images, plus libxcomposite, libxdamage, libxfixes, libxft, libxinerama, libxpm, libxrandr and libxrender. Building from git needs more on top: a complete autoconf or cmake toolchain, either markdown or asciidoctor, and pod2man.

Protocol compliance is tracked in a file you can actually read

The most useful thing in the repository for anyone integrating with a modern desktop is the COMPLIANCE file, which lists the current state of EWMH and ICCCM compliance. Window managers live or die by how well they speak the X11 protocols, because taskbars, pagers, screen lockers, docks and the XDG menu generators all talk to the window manager through those protocols, and a stale implementation shows up as broken third party tools rather than as an obvious error. The fork's stated contribution is greatly enhanced compliance with both standards, and a tracked file makes that checkable rather than a claim. The documentation also points out that since version 1.4.3 a complete and up to date set of manual pages is provided, with icewm(1) as the starting point, and configuration documentation is available on the IceWM website and in the online manual. The icewmhint utility, which sets IceWM specific window options hints, and icewm-menu-fdo, which regenerates XDG menus, both belong to that same theme of interop with the wider desktop.

The bundled utilities are the visible part of the design

The list of included utilities says a lot about what the project considers its own responsibility. There is icesh, described as a versatile window manipulation tool, icewmbg for setting the background, icewm-session, a program that launches the window manager, icewmbg and icewmtray in an orderly fashion, icewm-menu-fdo to regenerate XDG menus, icewmhint to set IceWM specific window option hints, and icesound, which plays audio files when interesting GUI events happen. That last one explains why sound support is a configure option at all. A few capabilities are explicitly out of scope and delegated to third party tools. Unspecified keyboard shortcuts are handled with bbkeys, and XDG compliant menus can be generated with xde-menu, both maintained as separate GitHub projects, with the IceWM FAQ pointing to further utilities. This is a sensible division. A window manager that does its own job and lets the surrounding X11 ecosystem supply the extras stays small, and the practical cost is that a fresh install needs a couple of extra packages to feel complete.

What you give up by choosing an X11 window manager in 2026

The honest limitation is the platform, not the code. This is an X Window System window manager, and the repository topics say so plainly with linux and window-manager alongside ewmh, icccm and floating. If your session is Wayland, none of this applies, and the project does not offer a Wayland implementation. Even within X11, a modern tiling compositor gives you a declarative layout model, per monitor workspaces and animation, and the community has largely moved that way. What you get in return is a different set of properties: a very small memory and CPU footprint, no compositor process sitting between you and the display server, and a keyboard driven model where the window manager does not rearrange your windows without being asked. There is a smaller point too, visible in the version history. The fork has been carrying the project since the upstream stalled, and the 3.7.2 line is a continuation rather than a redesign, so any feature you would want from a compositor built in the last few years is simply not part of the plan. The TODO file at the repository root lists features not yet implemented, which is the place to look for what is coming.

Editorial conclusion

Adopt icewm if you run X11 and want a window manager that stays out of the way, with keyboard driven operation, a small dependency set and a project that still receives bug fixes. Do not adopt it if you are on Wayland, since this is an X Window System window manager and nothing in it changes that, and do not expect the feature set of a modern tiling compositor. Before you build, read the COMPLIANCE file to see the current state of EWMH and ICCCM support, check the VERSION file against the 3.7.2 release the project documents, and confirm your distribution packages the fork rather than the older SourceForge original.

Frequently asked questions

Official sources

1. bbidulock/icewm on GitHub
2. Issues
3. README
4. Releases