Small codebase. Plain text config. No surprises.

Then you will love ace. Read the README to see how it works, and build ace!

➡ Build the latest ace version

ace is a floating window manager, completely written from scratch. The target platform is GNU/Linux, our code is Free and Open Source Software (FOSS) under the GPLv3 license. ace is primarily targeted at people who want a small, readable codebase they can actually understand and modify. We agreed upon the following goals for ace:

1. Write well readable, well documented code, split into small, single-responsibility modules instead of one large file.
   This includes being modifiable by people who do know how to program but who are not necessarily familiar with all of X11’s internals. That is, document why things happen and when they happen so that the user gets a picture of the whole process a Window Manager is responsible of by just reading the source code.
2. Use Xlib for interacting with X11.
3. Keep configuration a plain text file at ~/.config/ace/config. No embedded scripting language is required to get started.
4. Support the freedesktop.org EWMH standard, so that tools like wmctrl and status bars can inspect ace's state.
5. Ship as a single small binary. No background daemon, no IPC socket.
6. Be UTF-8 clean.
7. The usual elitism amongst minimal window managers: Don’t be bloated, don’t be fancy (simple borders are the most decoration we want to have).
   However, we do not enforce unnecessary limits such as a maximum amount of source lines of code. If it needs to be a bit bigger, it will be.
8. Do not add further complexity when it can be avoided. We are generally happy with the feature set of ace and instead focus on fixing bugs and maintaining it for stability. New features will therefore only be considered if the benefit clearly outweighs the additional complexity.

In addition to these stated goals, we try our best to uphold the following values when considering contributions to the project:

• Never break configuration files or existing workflows. Breaking changes require a major version bump.
• Keep mental complexity low: once you know ace's key features, other features should be easy to understand.
• Only add features which benefit many people, instead of going to great lengths to support rarely used workflows.
• Only documented behavior is supported. Clear documentation is a requirement for contributions.