Mondrian is a tiling window manager built with Rust for Windows 11.

• Automatic/manual window placement with different tiling layouts;
• Keybindings;
• Multi-monitor support;
• Mouse movements support (moving/resizing windows);
• Compatible with Virtual Desktops;
• Workspaces;
• System tray application;
• Multiple animations;
• Highly customizable.

To start Mondrian, just download the mondrian.exe executable from the latest release and run it.

The application takes the following arguments (all of them are optional):

./mondrian.exe --log <LOG_TYPE> --loglevel <LOGLEVEL> --dumpstateinfo --healthcheck

Where:

• <LOG_TYPE> can be 0 (no log file is created), 1 (error log files is created) or 2 (all log files are created). By default, it is set to 1.
• <LOG_LEVEL> can be 0 (off), 1 (trace), 2 (debug), 3 (info), 4 (warn) or 5 (error). By default, it is set to 3.
• dumpstateinfo dump the application state into a file (./logs/app_state.txt) at the start of the application;
• healthcheck enables health checks to detect freezes.

All the log files will be stored in the application directory under the logs subfolder. When a log file reaches 10MB, it will be archived in a .gz file (up to three previous versions).

You can swap two windows in the same monitor just by dragging one of them into the other. While dragging, you can:

• hold ALT, to swap the windows and to invert the direction of the tiles;

When the window is dragged to another monitor, by default it will be inserted. In this case, you can:

• hold SHIFT while dragging the window to swap the windows;
• hold ALT while dragging the window to insert the windows and to invert the direction of the tiles.

By changing the insert_in_monitor configuration option to false, the window will be swapped in the other monitor by default. In this case, you can:

• hold SHIFT while dragging the window to insert the windows;
• hold ALT while dragging the window to insert the window and to invert the direction of the tiles.

If you drag a window while holding CTRL, you can place the window freely based on the cursor position relative to an other window. In particular:

• if the cursor is at the top of an other window (i.e. <=20% of its height), the moving window will be placed above it;
• if the cursor is at the bottom of an other window (i.e. >=80% of its height), the moving window will be placed below it;
• if the cursor is to the left of an other window (i.e. <=50% of its width), the moving window will be placed to the left of it;
• if the cursor is to the right of an other window (i.e. >50% of its width), the moving window will be placed to the right of it.

Holding CTRL has the same effect when dragging the window to another monitor (by default).

You can set the free_move_in_monitor configuration option to true if you want to place the window freely in another monitor without holding CTRL (in this case, holding CTRL will position the window automatically).

Below a table that shows the keybindings for moving/swapping windows in different monitors, depending on the values of the insert_in_monitor and free_move_in_monitor configuration options:

If more than one modifier is held, the precedence order is as follows: ALT > CTRL > SHIFT.

Windows can be resized as usual just by dragging their borders.

Mondrian can be configured by editing the mondrian.toml file located in the ~/.config/mondrian directory. If the configuration file does not exist, it will be created automatically when the application starts. The configuration generated by the application can be found here.

All the options are optional and if not specified, the default values will be used.

You can specify custom keybindings with the modules.keybindings.bindings option. Each binding has the following format:

bindings = [
    { modifiers = "MODIFIERS", key = "KEY", action = "ACTION" } # "modifiers" can be also spelled as "modifier" or "mod"
]

The available modifiers are LALT/RALT, LCTRL/RCTRL, LSHIFT/RSHIFT, LWIN/RWIN or any combination of them joined by + (e.g. LALT+LSHIFT). If you omit the left/right prefix (e.g. use ALT instead of LALT or RALT), the binding will be created for both the left and right versions: for instance, ALT+LSHIFT is equivalent to creating a binding with LALT+LSHIFT and one with RALT+LSHIFT. Without the prefix you use both the left and right versions of the modifier (e.g. ALT instead of LALT and RALT). This parameter is required, except when the key is a function key, in which case it can be omitted.

The available keys are:

• alphanumeric keys (A to Z, a to z, 0 to 9);
• arrow keys (up, down, left, right);
• SPACE key;
• symbols `, ', ., ,, ;, [, ], -, =, /, \;
• numpad keys (NUM0 to NUM9);
• function keys (F1 to F24).

The keys and modifiers are case-insensitive.

The available actions are:

• refresh-config: reloads the configuration and restarts the application;
• open-config: opens the configuration file in the default editor;
• retile: re-tiles the windows;
• minimize: minimizes the focused window. This action also works with unmanaged windows;
• close: closes the focused window. This action also works with unmanaged windows;
• toggle-topmost: toggles the topmost state of the focused window. This action only works with floating windows;
• focus <left|right|up|down>: focuses the window in the specified direction;
• focus-monitor <left|right|up|down>: focuses the monitor in the specified direction;
• focus-workspace <WORKSPACE_NAME> [MONITOR_NAME]: focuses the workspace¹ on the specified monitor (if provided, otherwise it will be focused on the current monitor);
• move-to-workspace <WORKSPACE_NAME> [MONITOR_NAME]: moves the focused window into the workspace¹ and focuses it. The [MONITOR_NAME] behaves the same way as in the focus-workspace action;
• move-to-workspace-silent <WORKSPACE_NAME> [MONITOR_NAME]: moves the focused window into the workspace¹ without changing the focused workspace. The [MONITOR_NAME] behaves the same way as in the focus-workspace action;
• switch-focus: switches focus between tiled and floating windows;
• move <left|right|up|down> [40-1000]: if applied to a tiled window, swaps the focused window with the window in the specified direction. If applied to a floating window, moves the window in the specified direction by the amount in pixels defined in the third parameter (which defaults to 200 if not specified);
• insert <left|right|up|down>: adds the focused window in the monitor in the specified direction;
• moveinsert <left|right|up|down> [40-1000]: first tries the move and then the insert action if no window is found in the specified direction;
• resize <left|right|up|down> <40-500> [40-500]: if applied to a tiled window, resizes the focused window in the specified direction by the amount defined in the third parameter (in pixels). If applied to a floating window, increases (right/down) or decreases (left/up) the size of the window by the amount defined in fourth parameter (which defaults to the previous one if not specified);
• peek <left|right|up|down> <10-90>: restricts tiling, keeping a percentage of the screen free in the specified direction;
• invert: inverts the orientation of the focused window and the neighboring windows;
• release: removes the focused window from the tiling manager, or adds it back;
• focalize: focalizes the focused window (i.e. hides the neighboring windows) or unfocalizes it (i.e. restores the neighboring windows);
• half-focalize: hides all the windows except the focused and largest one on the same monitor. Running the action again restores the previous layout;
• cycle-focalized [next|prev]: swaps the currently focalized/half-focalized window with the next/previous window in the same monitor. If no parameter is specified, next is used;
• amplify: swaps the focused window with the biggest one in the same monitor;
• dumpstateinfo: dumps the current application state info to the ./logs/app_state.txt file;
• pause [keybindings|overlays]: if no parameter is specified, pauses/unpauses the application. Otherwise, pauses/unpauses the specified module;
• quit: closes the application.

The syntax of the actions is as follows:

• action <v1|v2> means "action v1" or "action v2" (i.e. required parameter);
• action [v1|v2] means "action", "action v1" or "action v2" (i.e. optional parameter);

Some examples:

[modules.keybindings]
enabled = true
bindings = [
    { key = "F4", action = "quit" },                                  # F4 to "quit"
    { modifiers = "WIN+ALT",  key = "F4", action = "release" },       # WIN+ALT+F4 to "release"
    { modifiers = "CTRL+ALT", key = "left", action = "focus left" }   # CTRL+ALT+Left to "focus left"
]

You can create custom rules with the core.rules option to control the behavior of specific windows. Each rule has the following format (or any equivalent format allowed by the TOML specification):

[core]
rules = [
    # Single behavior with no parameters
    { filter = { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" }, behavior = "behavior1" },

    # Single behavior with parameters
    { filter = { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" }, behavior.behavior2 = {param = "value" } },

    # Multiple behaviors
    { filter = { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" }, behaviors = ["behavior1", { behavior2 = { param = "value" } }] },

    # Invalid rules
    # { filter = { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" } } # missing behavior/behaviors
    # { filter = { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" }, behavior = "behavior1", behaviors = ["behavior2", "behavior3"] } # only one of behavior/behaviors must be specified
]

Eache rule has a:

• filter field that specifies the window(s) to apply the rule to;
• behavior or behaviors field that specifies the action to apply to the window(s);

You can specify at least one or more parameters in the filter field and the rule will be matched if all the parameters match the corresponding window property. Each parameter can be either a string or a regex (enclosed in slashes).

The following table shows the available behavior/behaviors values:

Some example:

[core]
rules = [
   # Match any window with a title="Title" and exename="app.exe" and classname="ApplicationWindow" and style="00000000"
   { filter = { title = "Title", exename = "app.exe", classname = "ApplicationWindow", style = "00000000" }, behavior = "ignore" },

   # Match any window with a title="Title"
   { filter = { title = "Title" }, behavior.insert = { monitor = "MONITOR1" } },

   # Match any window with a title that matches the regex "Title[0-9]"
   # For the `float` behavior, `topmost` and `size` are inherited from the global options
   { filter = { title = "/Title[0-9]/" }, behaviors = ["float", { insert = { monitor = "MONITOR2" } }] },

   # Match any window with a title="Title"
   # overrides `general.floating_wins.topmost` and `general.floating_wins.size`
   { filter = { title = "Title" }, behavior.float = { topmost = true, size = "preserve"} },
]

To understand how to match specific windows, you can trigger the dumpstateinfo action, then open the ./logs/app_state.txt file and look for the Currently managed windows subsection, which will look like this:

--------------------------------------------------------------------------------
                              [ 🔲 Tiles Manager ]
--------------------------------------------------------------------------------
...

🗔 Currently managed windows
   ▸ Window { hwnd: 12345, exe: "app1.exe", class: "ClassName1", style: "00000000", ... }
      ▸ Monitor: MONITOR1
      ▸ State: Normal
   ▸ Window { hwnd: 54321, exe: "app2.exe", class: "ClassName2", style: "00000000", ... }
      ▸ Monitor: MONITOR2
      ▸ State: Floating
   ...

...

You can ignore windows with the core.ignore_rules option. Each rule has the following format:

[core]
ignore_rules = [
    { title = "TITLE", exename = "EXENAME", classname = "CLASSNAME", style = "STYLE" }
]

These rules are equivalent to the core.rules option with the ignore behavior:

[core]
ignore_rules = [
    { title = "TITLE"}
]

# is equivalent to

[core]
rules = [
    { filter = { title = "TITLE" }, behavior = "ignore" }
]

You can override some configuration for each monitor with the monitors option:

# with this syntax
[monitors."Monitor 1 name"]
# ...

[monitors."Monitor 2 name"]
# ...

# or with this one
[monitors]
"Monitor 1 name" = { ... }
"Monitor 2 name" = { ... }

The following options are available:

To find the name of the monitors, you can start the application with the --dumpstateinfo flag (or you can trigger the dumpstateinfo action), then open the ./logs/app_state.txt file and look for the Monitors subsection under the Tiles Manager section. The section looks like this:

--------------------------------------------------------------------------------
                              [ 🔲 Tiles Manager ]
--------------------------------------------------------------------------------
...

🖥️ Monitors
   ▸ Monitor { handle: 1234567, id: "MONITOR1", primary: true, ... }
   ▸ Monitor { handle: 7654321, id: "MONITOR2", primary: false, ... }

...

The id field is the name of the monitor, which you can use in the monitors option:

[monitors."MONITOR1"]
layout.tiling_strategy = "horizontal"

[monitors."MONITOR2"]
layout.paddings.borders = 12

Workspaces are created automatically when the corresponding actions are triggered (see the actions section). Using the workspaces option, you can override some default configurations for each workspace:

# with this syntax
[workspaces."workspace-name1"]
# ...

[workspaces."workspace-name2"]
# ...

# or with this one
[workspaces]
"workspace-name1" = { ... }
"workspace-name2" = { ... }

The following options are available:

The monitors and workspaces options allow you to override the default configuration for specific monitors and workspaces. Configuration precedence is applied in the following order, from highest to lowest:

1. workspaces.*.monitors.*;
2. workspaces.*;
3. monitors.*;
4. default configurations.

For example, with the following configuration:

layout.paddings.borders = 8

[monitors."MONITOR1"]
layout.paddings.borders = 12

[workspaces."1"]
layout.paddings.borders = 14
monitors."MONITOR1".layout.paddings.borders = 16

The resulting borders padding will be:

• 16 when on workspace "1" and monitor "MONITOR1";
• 14 when on workspace "1" but not on monitor "MONITOR1";
• 12 when not on workspace "1" but on monitor "MONITOR1";
• 8 when not on workspace "1" and not on monitor "MONITOR1".

It sounded like a fun project to build, and I used it to learn Rust and the Win32 API.

In the beginning, I just wanted to build a simple tiling window manager for Windows, which allowed me to:

• automatically place windows in the correct positions, in multiple monitors;
• use the mouse to move and resize windows.

Then, I started working on it and new features were added. In any case, the main idea is to have an application that "just works" out-of-box, without any special configuration.

Yes, there are others tiling window managers for Windows out there. In particular, I used komorebi and GlazeWM before building this project. Both of them are really good and with great features, and they are in active development. If you need a more mature and established TWM, I recommend trying them.

There are different configurations options that can improve the performances. Here the most important ones:

• general.animations.enabled = false: disables the animations;
• general.animations.framerate: you can set this option to reduce the framerate of the animations;
• modules.overlays.enabled = false: disables the overlays;
• modules.overlays.update_while_dragging = false: the overlays will be updated only when the window move/resize operation is done;
• modules.overlays.update_while_animating = false: the overlays will be updated only when the animations are completed;
• general.detect_maximized_windows = false: disables the detection of maximized windows. Disabling this feature may cause issues when overlays are enabled.

You can create a rule in the configuration file (see the core.ignore_rules section or the core.rules section for more info).

The target window is selected from those touching the currently focused window in the specified direction. If there are multiple candidates, the selection depends on the value of the general.history_based_navigation config option:

• false: the window at the top is chosen for left/right directions, or the leftmost window for up/down directions;
• true: the most recently focused window among the candidates will be selected.

Imagine a layout like this:

+-----------------+
|         |   C   |
|    A    |-------+
|         |       |
|---------|   D   |
|         |       |
|    B    |-------+
|         |   E   |
+----+------------+

If the currently focused window is B, and you use the focus right command, windows D and E will be considered as adjacent in the right direction:

• If general.history_based_navigation = false, D will be selected, as it is the window at the top;
• If general.history_based_navigation = true, E will be selected if it was the most recently focused window.

This project is licensed under the GPLv3 license. See the LICENSE.md for more information.

• Andrey Sitnik for easings.net, which I used as reference for implementing the animations.