Case study · Open source

Wintaskbar

A Windows 11 utility that restyles the taskbar into a floating, blurred dock with rounded corners and a separate tray. A small tray application written in Go validates and compiles the theme; a minimal C++/WinRT component loaded into Explorer applies it. Published under the MIT licence.

Role
Sole author
Stack
Go · C++/WinRT · Win32
Licence
MIT
Source
Public on GitHub
The default theme running on a Windows 11 desktop.

Overview

Windows 11 offers no supported way to change how the taskbar looks: no rounded corners, no blur, no floating dock. Wintaskbar fills that gap. It reads a small YAML theme — selectors, styles and variables — and applies it to the real taskbar elements while Windows is running, so the result is the system's own taskbar, restyled, and not a replacement drawn on top of it. It is a personal engineering project that deliberately works against an undocumented interface, and it is published open source so the technique and its risks can be inspected rather than asserted.

My contribution

I am the sole author of the repository. I designed the split between the Go agent and the in-Explorer component, wrote the theme model, validator and compiler, the tray application with its custom menu, the installer, the C++/WinRT component that applies the styles, and the test suites for each. I also wrote the build scripts, the Makefile and the project documentation, including the architecture decision records.

The project exists to practise systems-level engineering: working across a managed language and native code, the Win32 and COM surface, process lifecycle and recovery, and keeping a risky component as small and as easy to reason about as possible.

Architecture

Two programs with one narrow contract between them. The Agent is a single native Go executable that lives in the tray: it validates the theme, compiles it into a flat file and attaches the second program to Explorer. The TAP is a C++/WinRT DLL that runs inside explorer.exe, reads that compiled file and applies the styles to the taskbar's XAML elements.

How Wintaskbar applies a theme The user edits theme.yaml. The Go Agent validates it and writes theme.compiled with resolved selectors and values. The Agent finds the Explorer through the Shell_TrayWnd window and calls InitializeXamlDiagnosticsEx to load the TAP DLL inside Explorer. The TAP reads theme.compiled and applies the styles to the taskbar XAML elements. The Agent also watches Explorer and reattaches the TAP when Explorer restarts. theme.yaml selectors, styles, variables AGENT · GO Validate theme before Explorer is touched Compile contract theme.compiled, versioned Attach TAP InitializeXamlDiagnosticsEx Tray menu + watchdog reattach when Explorer restarts, autostart, logs theme.compiled flat lines, no grammar EXPLORER.EXE TAP C++/WinRT DLL reads and applies only Taskbar XAML dock, tray, frame rounded corners, blur Dashed: the Agent attaches the TAP to the running Explorer
Flow drawn from the project documentation and the cmd/, internal/ and tap/ directories.

Code layout

  • cmd/wintaskbar composes the application and the development commands.
  • cmd/setup is the standalone installer, with the Agent and the TAP embedded.
  • internal/modules/theme holds the model, validation, YAML reading and compilation.
  • internal/modules/agent holds apply, restore and monitoring.
  • internal/platform/windows isolates the native APIs, tray, autostart and shell.
  • tap is the C++/WinRT component loaded into Explorer.

Stack

  • Agent: Go, a single native executable with no runtime and no extra service installed.
  • In-Explorer component: C++/WinRT built with clang/MinGW-w64.
  • Integration: the XAML diagnostics API, Win32 tray, scheduled-task autostart.
  • Themes: YAML with selectors, variables and blur parameters.
  • Delivery: a per-user installer and a portable ZIP, both built from a Makefile.

Engineering decisions

Three decisions that shaped the project, each with the alternative considered and what it costs. The repository keeps sixteen decision records in total.

1. The Agent compiles the theme; the TAP only applies it

Decision:
the Go Agent reads, validates and decomposes the theme and writes a flat, versioned file; the component inside Explorer only reads that file and applies it, without interpreting the selector grammar.
Alternative:
have the in-Explorer component parse the YAML theme and resolve selectors and variables itself.
Reason:
a mistake inside Explorer costs a restart of the taskbar and is expensive to debug. Validation in the Agent can answer immediately with every error in the theme, before Explorer is touched, and the native component stays small.
Limitation:
the two programs share a contract that has to be versioned and kept in step; the Agent and the TAP should be updated together.

2. Depend on the native auto-hide instead of changing system settings

Decision:
for the dock to float over maximised windows, the user turns on Windows' own “Automatically hide the taskbar”. The tray menu offers a toggle for it, but the application never changes system settings on its own.
Alternative:
force the setting on at start-up so the layout always works.
Reason:
without auto-hide Explorer reserves the taskbar strip and undoes desktop-area changes. Leaving the choice to the user keeps the tool from silently altering the machine, and quitting never changes the setting.
Limitation:
without auto-hide the dock still shares the screen with the reserved strip, which is documented but is a visible compromise.

3. A scheduled logon task instead of the Run key for autostart

Decision:
start-up with Windows is a per-user scheduled task at logon, without elevation. The Run key remains as a fallback, and during the first minute the Agent polls for the taskbar frequently and treats its absence as “wait”.
Alternative:
the Run registry key, the usual way to start a per-user program.
Reason:
Windows delays Run entries on purpose, so the original taskbar stayed visible for several seconds before the theme appeared.
Limitation:
it is one more artefact to create and remove cleanly; the uninstaller has to delete it, and a portable copy should enable autostart only after it is placed in its final folder.

Quality, safety and cost

Everything below is present in the public repository and can be checked against the source. The measured figures come from a single development machine and are not a guarantee for other hardware.

Tests

  • 21 Go test files covering the use cases, the COM contract and the tray lifecycle.
  • C++ contract tests read the same reference file the Go compiler is checked against: selectors, attributes, escapes, blur parameters, invalid files and the adaptive layout calculation.
  • A tray test exercises the custom menu — keyboard, click, disabled items, state updates and GDI resources over repeated opens — without running real commands.
  • Run everything with make check, which prepares its own binaries and does not install the app, apply a theme or restart Explorer.

Safety

  • The theme is validated — selectors, variables and values — before Explorer is restarted; errors are shown in the menu with the offending lines.
  • Disable theme and Quit and restore bring the original taskbar back; the uninstaller does the same and keeps the user's themes and logs.
  • The default theme is original to the project, and third-party notices are listed in the repository.
  • The README states plainly that the technique uses an undocumented API and that the binaries are unsigned.

Footprint

  • Agent memory of about 19 MB and idle CPU of about 0.2% of one core.
  • wintaskbar.exe is about 3.1 MB and tap.dll about 1.6 MB.
  • The Agent does not poll windows: it only checks Explorer every two seconds to reattach the TAP if it restarted, and the blur is drawn by Windows' own compositor.
  • The figures do not include the memory the TAP uses inside Explorer.

Results and limitations

What exists today is a working utility: a floating dock and a separate tray with blur, rounded corners and a gradient border; an editable YAML theme with an adaptive dock layout that keeps the overflow button reachable on narrow screens; a tray menu that follows the system's light and dark mode with full keyboard support; and both a one-file installer and a portable build that need neither Go, a compiler nor administrator rights to use.

Stated limitations

  • It relies on an undocumented Windows API. A Windows update can change the XAML element tree and make the theme stop applying, or apply only in part.
  • Only one Windows build has been verified. It was tested on Windows 11 x64 build 26300; other versions are not claimed to work.
  • Applying, disabling and quitting restart Explorer. The taskbar and desktop disappear for a moment and open File Explorer windows can close.
  • The binaries are not code-signed. SmartScreen or an antivirus may warn about a program that loads a DLL into Explorer; building from source is the alternative.
  • The TAP does not yet release every element reference the diagnostics API hands it, which needs to improve for long sessions, and the blur does not implement saturation, luminosity, noise or reaction to battery saver.
  • There is no real-world usage data. This is a personal project; I am not claiming users, downloads or adoption.

Explore

The repository is public and includes the README with the warnings, install and build instructions, the theme reference, the security policy and the architecture decision records under docs/.

View source on GitHub Read the theme reference

The repository README is written in Portuguese. Read the warnings in it before running the program: it restarts Explorer and uses an undocumented API, so a virtual machine is the safe way to try it first.

Gallery

Captures of the default theme on Windows 11 — select an image to enlarge it and browse the gallery.

Desktop with the dock and the tray as two separate surfaces.

Floating dock with blur and rounded corners.

Tray with the clock and the hidden icons menu.

← Back to projects Talk to me about this project