StarPie: a radial mouse gesture menu for Windows 10 and 11

The problem StarPie solves, and who it is for

Windows has no built-in radial menu. If you want a ring of actions that appears under the cursor and fires on release, you either buy a gesture utility or write one. StarPie is the second option, already written. The README describes it as a lightweight mouse radial gesture tool for Windows 10 and 11, and the repository topics include windows-10-11, wpf-application, local-first and offline-first. The intended user is someone who repeats the same handful of actions in an editor, a CAD program or a browser, and wants those actions on muscle memory rather than on a keyboard shortcut they have to remember.

The feature list is aimed at that person specifically. Sectors can hold shortcuts, programs, URLs, folders, commands and system controls, and the menu can be bound to the right button, the middle button, a side button, or a keyboard key. The README is explicit that a normal right click still opens the native context menu, so the gesture layer does not take the button away. Per-app profiles let Chrome, VS Code, Photoshop and SolidWorks each get their own layout, with a fallback to the global configuration when no profile matches.

The design priorities are stated in the README: no bundled browser engine, a typical idle memory figure of roughly 15 to 30 MB, and low-latency handling through the Win32 WH_MOUSE_LL hook. Those are the project's own claims, not measurements I can confirm. What is verifiable is the packaging: a single-file build with the .NET runtime inside, and configuration stored locally in config.json.

How the pie menu is triggered and drawn

The trigger is a drag, not a click. According to the README, you hold the chosen mouse button, move past a configured threshold, and the wheel appears; you slide toward a sector and release to fire its action. The README also describes a long-press delay as an alternative way to summon it. The hook is WH_MOUSE_LL, which is the low-level mouse hook in Win32, and the README says this is why the normal right-click behaviour survives.

Sector counts are 4, 8 or 12. The 8-sector layout is the default. The centre circle can hold its own action and has a wake dead zone. Sub-menus are the interesting part: any sector can expand into one to four second-level actions, and the README says the outer ring opens with an elastic animation when the cursor rests inside a sector. Two second-level shapes exist, an outer ring and a honeycomb. The README mentions hysteresis and debounce logic to stop the sub-ring flickering when the cursor crosses a boundary.

Cancelling is handled by what the README calls outer escape cancel. Instead of pulling back to the centre, you flick outward past the rim, the wheel turns semi-transparent, and releasing fires nothing. The sensitivity is a slider from 140px to 320px. A separate trajectory gesture system exists alongside the wheel, with up to three segments and eight directions, bound to its own button.

Screen handling is centralised in a component the README names ScreenHelper, which deals with multiple monitors, mixed DPI and screen-edge coordinates. The README says this reduces summon drift on secondary displays. Full-screen and game detection pass the native right click through, modifier keys can bypass the wheel, and a process blacklist is available.

Installing StarPie and configuring a first sector

The README points at the releases page for downloads and describes a portable single-file build that carries the .NET runtime, so it unpacks and runs without a separate .NET install. The README does not give a command-line install, an installer flag list, or a package manager command, so there is nothing honest to put in a shell block here. There is an installer/ directory in the repository, but the README does not document what it contains or how to invoke it.

The configuration itself is a local config.json, and the README says imported icons are copied into the local configuration directory. If you want to inspect or back up a profile, that file is the thing to copy. The README does not publish its schema, so treat it as something to back up rather than something to hand-edit.

Building from source is the documented alternative. The repository has a WinPieGestures/ directory, a tests/ directory and a CHANGELOG.md, and the badge line in the README names .NET 8.0 WPF as the stack. The README's own navigation links to a local build section, but the text available here does not include its contents, so the exact build commands are not something I can quote. What can be said from the repository layout is that the application project and the tests live in separate top-level directories, and a CONTRIBUTING.md exists for anyone sending changes.

Once it runs, the workflow described in the README is: open the action page, pick a sector on the live canvas, and assign an action. The application picker lists installed programs with name search, and a window capturer lets you grab a running window or process instead of typing an executable path. Sectors and second-level actions can be swapped by dragging on the canvas.

Where StarPie gets in the way

The first limitation is the release channel. The three most recent releases listed are v1.7.4-beta.1, v1.7.4-beta.2 and v1.7.4-beta.3, dated 2026-09-13, 2026-09-14 and 2026-09-16. The README's own badge advertises v1.6.8 as the release version. So the newest code is beta, and anyone who wants the last stable build has to go looking for it rather than take the top of the releases list. The repository is not archived and the last push was on 2026-09-16, so the project is moving, but movement on a beta line is not the same as a stable one.

The licence is the second problem. The README's badge says MIT and links to LICENSE, but the repository metadata reports NOASSERTION, which means the file could not be classified automatically. Those two things are not necessarily in conflict, and I am not going to guess which is right. Read the file before you ship StarPie inside anything.

Third, this is Windows only, and the README is specific about Windows 10 and 11 on x64. There is no Linux or macOS path. If your team is mixed, the tool covers part of it.

Fourth, the hook is global. A low-level mouse hook sees every mouse event on the machine, and the README's mitigations (full-screen detection, modifier pass-through, a process blacklist) are exactly the kind of controls you add when the default behaviour is intrusive. If you already run another gesture tool, or a macro recorder, expect to spend time on the blacklist. The README does not describe how conflicts between two global hooks are resolved.

Finally, the README does not document rollback. There is no described way to downgrade from a beta to the previous stable build, and no documented migration for config.json between versions.

Alternatives and the difference in approach

The obvious comparison is AutoHotkey. AutoHotkey is a scripting language first: you write a script, and a pie menu is something you build with it, usually through a community library. StarPie is the inverse. The menu, the sector editor, the icon importer, the theme presets and the per-app profile switcher are the product, and there is no scripting layer to learn. If you want a menu that behaves exactly like your own code, AutoHotkey gives you that control and takes the maintenance. If you want a menu that already has a settings window, StarPie is the shorter path.

A second comparison is with the gesture features bundled into mouse vendor utilities such as Logitech Options+ or Razer Synapse. Those are tied to one vendor's hardware, and their gesture sets are usually fixed shapes rather than a configurable radial layout with sub-menus. StarPie works with whatever mouse Windows sees, which is the point, but it also means it cannot reconfigure the mouse's own onboard buttons.

A third is the Windows PowerToys suite. PowerToys is a collection of separate utilities with no radial menu among the ones the README implies, and its scope is broad rather than deep. StarPie does one thing, and the feature list is deep in that one thing: 4/8/12 sectors, sub-rings, trajectory gestures, OCR, window tiling. The trade-off is that a single-purpose tool has a single-purpose maintenance story, and StarPie's story currently runs through beta releases.

Maintenance cost, licence and what to check first

The last push was on 2026-09-16, and three beta releases landed in the four days before that. That is a fast cadence for a small utility, and it cuts both ways: fixes arrive quickly, and the surface you depend on can move between betas. The README's badge line claims 19 of 19 tests passed and links to the tests/ directory, which is the only quality signal in the repository. It is a test count, not a coverage figure, and it says nothing about how the hook behaves on your specific machine.

Upgrade cost is mostly configuration. The README states that settings live in config.json and that imported icons are stored in the local configuration directory, so an upgrade that changes the schema puts both at risk. The README does not describe a migration path or a version field in that file. Back up the configuration directory before moving between betas, and keep the previous build around.

On licensing: the README badge says MIT and links to LICENSE, while the repository metadata reports NOASSERTION. I cannot resolve that here and I am not giving legal advice. If StarPie is going into a company image or a commercial product, open LICENSE and CONTRIBUTING.md and read them yourself. If it is a personal tool on your own laptop, the practical exposure is smaller, but the file is still the file.

Editorial conclusion

Adopt StarPie if you work on one Windows 10 or 11 machine and want a radial menu bound to a mouse button, with per-app profiles and a portable single-file build. Do not adopt it if you need a stable release, a documented licence, or Linux and macOS support; the repository has no such builds and every listed release is a beta. Before installing, read LICENSE and CONTRIBUTING.md, confirm the newest release is not a beta, and check whether the per-app profile matching works for the process names you actually use, because the README does not describe how a foreground program is matched to a profile.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Star-Pie/StarPie on GitHub