tacky-borders: custom window borders for Windows 10 and 11 in Rust

What tacky-borders actually does to a window

tacky-borders lets you customize window borders on Windows 10 and 11. The project is a small Rust program that draws a border around each window, in the style that Windows itself abandoned after Windows 7.

The mechanism is a separate border window per application window, drawn with Direct2D and composited by the Desktop Window Manager, which is why the feature list in the Cargo.toml includes Win32_Graphics_Direct2D, Win32_Graphics_Dwm and Win32_Graphics_DirectComposition. The Direct3D and Direct3D11 features are there as well, and the windows feature list also covers the UI side of the platform, including WindowsAndMessaging, HiDpi, Accessibility and Input_Ime.

That composition based approach is what makes the visual options possible, and it is also the source of the main caveat. The config file carries a warning that using the AboveWindow z-order may cause the border to flicker when used with some applications that manipulate window layering, leading to z-order conflicts. Applications that manage their own window layering, which includes several games, video players and fullscreen tools, are where you will see the artefacts.

The audience is a Windows desktop user who wants the look back, and a tiler or window manager user in particular. The komorebi_colors option in the config exists because komorebi manages its own window kinds, and tacky-borders has a dedicated integration for them.

The config file is the whole product

Everything you can change is in one YAML file, and the project ships the auto-generated file as a reference. The first block is the top level switches.

# watch_config_changes: Automatically reload borders whenever the config file is modified.
watch_config_changes: True

# enable_logging: Log messages (info, warnings, and errors) to a file.
# NOTE: Changes require an application restart to take effect.
enable_logging: True

# enable_ipc_server: Handle runtime IPC commands sent through the CLI.
enable_ipc_server: True

Under the global section come the geometry and colour options. The border_width is in pixels and defaults to 3. The border_offset is also in pixels, and the comment explains the sign convention: negative values shrink the border inwards, positive values expand it outwards. The default is -1.

The border_radius accepts Auto, which determines the radius automatically, Square for sharp corners, Round for fully rounded corners, RoundSmall for slightly rounded ones, or any numeric value for a custom radius. The default is Auto.

The colours are where the config is most expressive. Each of active_color and inactive_color takes a Solid form with a hex code or the word accent, a Gradient form with a list of colours and a direction in degrees or a start and end pair, or a theme-aware form with separate dark and light values. The theme-aware form is the one that reacts to the Windows system theme, and the config notes that borders update automatically when the system theme changes.

The active_color example in the shipped file is a gradient between two hex values at 45 degrees, and the inactive_color is a second gradient with an explicit start and end pair. The hex formats supported are #RGB, #RGBA, #RRGGBB and #RRGGBBAA.

Border behaviour per window and the timing delays

Two options decide whether a border appears at all, and they are the ones to read before anything else.

The first is follow_native_border, which follows Windows' own behavior for border visibility. Windows already shows or hides native borders depending on a window's type or state, and the native borders are hidden for borderless fullscreen windows. Enabling this option makes tacky-borders follow that visibility behavior. The important caveat is in the config: this setting only affects visibility for borders that have been initialized, and to make sure a border is initialized in the first place you have to use window_rules.

The second pair is the timing. initialize_delay is the time in milliseconds before the border appears after opening a new window, and unminimize_delay is the same for unminimizing one. The defaults are 200 and 150. The documented reason is to accommodate window animations, both open and unminimize animations, and the config says to set these to 0 if window animations are disabled. The same values can be used to accommodate border animations, such as fade animations.

The border_z_order option decides whether the border is drawn above or below its window, with AboveWindow and BelowWindow as the choices, and AboveWindow is the default.

So the practical question for a new user is whether the borders will even be initialised for the applications you care about, and the answer is that you use window_rules for that, and the follow_native_border setting only decides whether an already initialised border respects the native visibility rules.

Animations, the two renderers and the komorebi integration

The animations block is where the config shows its ambition and its cost.

Animation types are Spiral, ReverseSpiral and Fade, each with a duration in milliseconds and an easing, and each of the active and inactive window states is configured separately with a list of animations. There is also an fps setting, given as 60, and an enabled switch which is off in the shipped file. The config warns that spiral animations may be resource-intensive on low-end systems, and that is a fair warning given that a border is redrawn on every frame for every window.

The rendering_backend option picks between two implementations. V2 is described as a more complex, feature-rich renderer available in v1.2.0 and above, and Legacy as a simpler, more limited renderer available in v0.1.0 and above. The config is honest that performance between the two may vary system to system and tells you to choose whichever works best. That is a slightly unusual thing to write in a config file and it tells you the two backends are not yet equivalent.

The komorebi_colors block is an additional integration for komorebi's special window kinds. The active_color is used for komorebi's Single window kind, the inactive_color for its Unfocused kind, and there are separate stack_color, monocle_color and floating_color entries. It is disabled by default. The stack colour is a pink, the monocle colour a green, and the floating colour near-white.

So the tool is not only a border painter. It has a specific opinion about how a tiling window manager should look, and it can colour a window differently depending on how the compositor has arranged it.

Installing, building and uninstalling

The easiest route is a pre-built release from the releases page. When you run the executable for the first time, tacky-borders automatically generates a config file for you in the folder %userprofile%/.config/tacky-borders/.

Building it yourself needs two things: Rust and the MSVC build tools. Then the sequence is a clone, a directory change and a build.

   git clone https://github.com/luke-you/tacky-borders.git

   cd tacky-borders

   cargo build --release

The same directory change also works with cargo run --release if you want to run it straight from the build.

The config location is not a Windows convention, and that is deliberate in the sense that it follows the same shape as other tools in this ecosystem, using a dot directory under the user profile rather than the AppData tree. You can reach it from the tray icon by right clicking and choosing Show Config.

Uninstallation is described as easy: delete tacky-borders.exe. The note adds the two steps people usually miss. If you want to remove all traces, you should also disable auto-start through the tray menu and delete the config folder at %userprofile%/.config/tacky-borders/. That auto-start behaviour is worth knowing about before you install, since a program that restarts itself on login is not what some people expect from a window decoration.

Where tacky-borders is the wrong tool

The first limit is the platform. This is a Windows program and only a Windows program. The dependency list is entirely Windows API bindings, from the windows crate with Direct2D and DWM features through winreg for the registry and windows-numerics for the geometry, and there is no cross platform build.

The second is the flicker problem, which is the same limitation seen from a different angle. The border is a separate composited window, so anything that manipulates window layering itself, which includes games, video players and fullscreen applications, can fight with it. BelowWindow is the mitigation, and it is a trade rather than a fix, since a border drawn below the window is not visible where the window covers it.

The third is that the borders are decoration, not native chrome. Windows 11 has its own rounded corners and system accent colours, and this tool overlays a border on top of that rather than replacing the system's rendering. A user who wants the borders to follow the system theme exactly is served better by the built-in setting, and the theme-aware colour option is the closest this project gets.

The fourth is the overhead of an always running process. A tray icon, an auto-start entry, and per window redraw work for the animations, on every open and closed window, for the whole session. The config's own warning about spiral animations on low-end systems is the performance story stated plainly.

Compare that with the tiling window manager route. If you already use komorebi, it does window borders and decorations itself, and this project explicitly integrates with it rather than replacing it. The difference in approach is that a tiling compositor owns the window layout and the decorations as part of the same model, while tacky-borders attaches a decoration to windows it did not create, which is why it needs the z-order, delay and native-border visibility options to behave.

Licence, releases and the state of the tree

tacky-borders is released under the MIT licence, with the text in the LICENSE file at the repository root. The MIT terms are permissive, which matters here because this program installs itself, registers an auto-start entry and draws over other applications' windows, and a redistribution of a modified build carries only the obligation to keep the copyright notice and licence text. Read the LICENSE file yourself for the exact terms.

The release history shows steady minor version work. v1.4.1 came on 2026-02-13, v1.5.0 on 2026-04-27 and v1.6.0 on 2026-08-01, and the Cargo.toml declares the current version as 1.6.0 with edition 2024. The repository is not archived, and the last push was on 2026-08-19, so the tree is a couple of months old relative to today.

The dependency list is short and tells you the implementation is thin. serde, serde_yaml_ng and serde_json for the config and the IPC protocol, serde_json_borrow for borrowed JSON handling, tray-icon for the system tray, open for launching the browser or URLs, dirs for the config path, regex for window rules, log and sp_log for logging, anyhow for error handling, windows-numerics for the geometry arithmetic, winreg for the registry, and pico-args for command line parsing. The windows crate at 0.62.2 carries the API bindings, and the build script uses winres to embed the Windows resources that give the executable its icon and version metadata.

The repository is minimal: a Cargo.toml, Cargo.lock, a build.rs, src/, tests/ and the LICENSE, with a .github/ directory for the workflows. There is one dev dependency, serial_test at 3.5.0, which is the tool you use when a test needs to run alone because it touches global window state.

What to verify first is a visual check on the applications you actually use. Install the pre-built release, open the config from the tray menu, set the border width to something obvious, and watch for flicker on the applications that manage their own layering, because that is the failure mode the config warns about and the one you cannot see from a screenshot.

Editorial conclusion

tacky-borders fits a Windows user who wants coloured, animated window borders on Windows 10 and 11 and who is comfortable with a YAML file and a tray icon, particularly if they already run the komorebi compositor, since there is a dedicated integration for its special window kinds. It does not fit a Linux or macOS user, and it is the wrong tool if the borders have to follow the operating system theme exactly rather than sit on top of it. Before adopting it, read the border_z_order note about flicker with applications that manipulate window layering, decide whether the follow_native_border behaviour matches how you want borderless fullscreen windows handled, and delete the config folder as well as the executable if you want a clean uninstall.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. luke-you/tacky-borders on GitHub
4. README
5. Releases