## 🔨 Utilities
PowerToys includes over 30 utilities to help you customize and optimize your Windows experience:
| | | |
| --- | --- | --- |
| [ Advanced Paste](https://aka.ms/PowerToysOverview_AdvancedPaste) | [ Always on Top](https://aka.ms/PowerToysOverview_AoT) | [ Awake](https://aka.ms/PowerToysOverview_Awake) |
| [ Color Picker](https://aka.ms/PowerToysOverview_ColorPicker) | [ Command Not Found](https://aka.ms/PowerToysOverview_CmdNotFound) | [ Command Palette](https://aka.ms/PowerToysOverview_CmdPal) |
| [ Crop And Lock](https://aka.ms/PowerToysOverview_CropAndLock) | [ Environment Variables](https://aka.ms/PowerToysOverview_EnvironmentVariables) | [ FancyZones](https://aka.ms/PowerToysOverview_FancyZones) |
| [ File Explorer Add-ons](https://aka.ms/PowerToysOverview_FileExplorerAddOns) | [ File Locksmith](https://aka.ms/PowerToysOverview_FileLocksmith) | [ Grab And Move](https://aka.ms/PowerToysOverview_GrabAndMove) |
| [ Hosts File Editor](https://aka.ms/PowerToysOverview_HostsFileEditor) | [ Image Resizer](https://aka.ms/PowerToysOverview_ImageResizer) | [ Keyboard Manager](https://aka.ms/PowerToysOverview_KeyboardManager) |
| [ Light Switch](https://aka.ms/PowerToysOverview_LightSwitch) | [ Mouse Utilities](https://aka.ms/PowerToysOverview_MouseUtilities) | [ Mouse Without Borders](https://aka.ms/PowerToysOverview_MouseWithoutBorders) |
| [ New+](https://aka.ms/PowerToysOverview_NewPlus) | [ Peek](https://aka.ms/PowerToysOverview_Peek) | [ PowerDisplay](https://aka.ms/PowerToysOverview_PowerDisplay) |
| [ PowerRename](https://aka.ms/PowerToysOverview_PowerRename) | [ PowerToys Run](https://aka.ms/PowerToysOverview_PowerToysRun) | [ Quick Accent](https://aka.ms/PowerToysOverview_QuickAccent) |
| [ Registry Preview](https://aka.ms/PowerToysOverview_RegistryPreview) | [ Screen Ruler](https://aka.ms/PowerToysOverview_ScreenRuler) | [ Shortcut Guide](https://aka.ms/PowerToysOverview_ShortcutGuide) |
| [ Text Extractor](https://aka.ms/PowerToysOverview_TextExtractor) | [ Window Hopper](https://aka.ms/PowerToysOverview_WindowHopper) | [ Workspaces](https://aka.ms/PowerToysOverview_Workspaces) |
| [ ZoomIt](https://aka.ms/PowerToysOverview_ZoomIt) | | |
## 📦 Installation
For detailed installation instructions and system requirements, visit the [installation docs](https://learn.microsoft.com/windows/powertoys/install).
But to get started quickly, choose one of the installation methods below:
Download the .exe file from GitHub
Go to the [PowerToys GitHub releases](https://aka.ms/installPowerToys), scroll down and select **Assets** to reveal the installation files, and choose the one that matches your architecture and install scope. For most devices, that would be _x64 per-user_.
Microsoft Store
You can easily install PowerToys from the Microsoft Store:
WinGet
Download PowerToys from [WinGet](https://github.com/microsoft/winget-cli#installing-the-client). Updating PowerToys via winget will respect the current PowerToys installation scope. To install PowerToys, run the following command from the command line / PowerShell:
- User scope installer (default)
```powershell
winget install Microsoft.PowerToys -s winget
```
- Machine-wide scope installer
```powershell
winget install --scope machine Microsoft.PowerToys -s winget
```
Other methods
There are [community driven install methods](https://learn.microsoft.com/windows/powertoys/install#community-driven-install-tools) such as Chocolatey and Scoop. If these are your preferred install solutions, you can find the install instructions there.
## ✨ What's new?
[](https://github.com/microsoft/PowerToys/releases)
To see what's new, check out the [release notes](https://github.com/microsoft/PowerToys/releases/).
## 🛣️ Roadmap
For [v0.103][github-next-release-work], we're working on a new Awake flyout, improving Screen Ruler, and continuing to modernize more utilities with WinUI 3.
## ❤️ PowerToys Community
The PowerToys team is extremely grateful to have the [support of an amazing active community][community-link]. The work you do is incredibly important. PowerToys wouldn't be nearly what it is today without your help filing bugs, updating documentation, guiding the design, or writing features. We want to say thank you and take time to recognize your work. Your contributions and feedback improve PowerToys month after month!
## Contributing
This project welcomes contributions of all types. Besides coding features / bug fixes, other ways to assist include spec writing, design, documentation, and finding bugs. We are excited to work with the power user community to build a set of tools for helping you get the most out of Windows. We ask that **before you start work on a feature that you would like to contribute**, please read our [Contributor's Guide](CONTRIBUTING.md). We would be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort. Most contributions require you to agree to a [Contributor License Agreement (CLA)][oss-CLA] declaring that you grant us the rights to use your contribution and that you have permission to do so. For guidance on developing for PowerToys, please read the [developer docs](./doc/devdocs) for a detailed breakdown. This includes how to setup your computer to compile.
## Code of conduct
This project has adopted the [Microsoft Open Source Code of Conduct][oss-conduct-code].
## Privacy statement
The application logs basic diagnostic data (telemetry). For more privacy information and what we collect, see our [PowerToys Data and Privacy documentation](https://aka.ms/powertoys-data-and-privacy-documentation).
[oss-CLA]: https://cla.opensource.microsoft.com
[oss-conduct-code]: CODE_OF_CONDUCT.md
[community-link]: COMMUNITY.md
[github-next-release-work]: https://github.com/microsoft/PowerToys/milestone/47
---
### Doc Devdocs Website README (`doc/devdocs-website/README.md`)
# Dev Docs Website
This folder hosts the [docmd](https://docmd.io/) project that turns the PowerToys developer
documentation in [`doc/devdocs`](../devdocs) into a static website.
## Generated site
The `site/` folder is the docmd build output. It is **not committed** to the repository — it is
git-ignored and rebuilt on demand. You only need it locally when previewing your changes (see below).
Publishing is handled by the
[Publish Dev Docs Website](../../.github/workflows/regenerate-devdocs-website.yml) GitHub Action, which
runs whenever files under `doc/devdocs` (or this folder) change on the `main` branch — it can also
be triggered manually from the **Actions** tab. The action builds the site and deploys it straight to
GitHub Pages as an artifact, so nothing is written back to the repository.
> [!NOTE]
> The action requires GitHub Pages to be enabled with **Source: GitHub Actions** under the repository
> **Settings → Pages**.
## Editing the docs
To change the documentation, edit the Markdown files under [`doc/devdocs`](../devdocs). The remaining
files in this folder are maintained by hand and are safe to edit:
- `docmd.config.json` — docmd configuration (title, source, output, plugins)
- `package.json` — pins the docmd version used to build the site
- `docmd-plugins/` — local build-time docmd plugins
> [!TIP]
> Link to repository files with repo-root-relative paths such as `/src/modules/.../Foo.cpp`.
> VS Code resolves these against the workspace root (so they open the local file), and the
> bundled `github-source-links` plugin rewrites them to
> `https://github.com/microsoft/PowerToys/blob/main/...` on the published site.
## Building locally
Requires [Node.js](https://nodejs.org/).
```powershell
npm install # install dependencies (first time only)
npm run dev # start a local preview server at http://localhost:3000
npm run build # generate the static site into ./site
```
---
### Doc Devdocs Readme (`doc/devdocs/readme.md`)
# PowerToys Developer Documentation
Welcome to the PowerToys developer documentation. This documentation provides information for developers who want to contribute to PowerToys or understand how it works.
## Getting Started
### Prerequisites
1. Windows 10 April 2018 Update (version 1803) or newer
1. [Visual Studio 2026](https://visualstudio.microsoft.com/downloads/) (recommended) or Visual Studio 2022 17.4+ with the following workloads/components:
- Desktop Development with C++
- WinUI application development
- .NET desktop development
- Windows 11 SDK (10.0.22621.0)
- Windows 11 SDK (10.0.26100.3916)
1. .NET 8 SDK
1. Enable long paths in Windows (see [Enable Long Paths](https://learn.microsoft.com/windows/win32/fileio/maximum-file-path-limitation#enabling-long-paths-in-windows-10-version-1607-and-later) for details)
> **Tip:** You can install Visual Studio with all required workloads automatically using the [WinGet configuration files](https://github.com/microsoft/PowerToys/tree/main/.config) in the repository:
> ```powershell
> winget configure .config\configuration.winget
> ```
> Pick the file that matches your VS edition (e.g., `configuration.vsProfessional.winget` or `configuration.vsEnterprise.winget`).
### Fork, Clone, and Set Up
1. Fork the repo on GitHub if you haven't already
1. Clone your fork locally
1. Run the automated setup script (**recommended**):
```powershell
.\tools\build\setup-dev-environment.ps1
```
This script will:
- Enable Windows long path support (requires administrator privileges)
- Enable Windows Developer Mode (requires administrator privileges)
- Guide you through installing required Visual Studio components from `.vsconfig`
- Initialize git submodules
Run with `-Help` to see all available options.
Manual setup (if you prefer not to use the script)
#### Install Visual Studio dependencies
1. Open the `PowerToys.slnx` file.
1. If you see a dialog that says `install extra components` in the solution explorer pane, click `install`
Alternatively, import the `.vsconfig` file from the repository root using Visual Studio Installer to install all required workloads.
#### Initialize submodules
This is a one-time step required before you can compile most parts of PowerToys.
1. Open a terminal
1. Navigate to the folder you cloned PowerToys to.
1. Run `git submodule update --init --recursive`
### Building
#### Using Visual Studio
- Open `PowerToys.slnx` in Visual Studio.
- In the `Solutions Configuration` drop-down menu select `Release` or `Debug`.
- From the `Build` menu choose `Build Solution`, or press Control+Shift+b on your keyboard.
- The build process may take several minutes depending on your computer's performance. Once it completes, the PowerToys binaries will be in your repo under `x64\Release\`.
- You can run `x64\Release\PowerToys.exe` directly without installing PowerToys, but some modules (i.e. PowerRename, ImageResizer, File Explorer extension etc.) will not be available unless you also build the installer and install PowerToys.
#### Using Command Line
You can also build from the command line using the provided scripts in `tools\build\`:
```powershell
# Build the full solution (auto-detects platform)
.\tools\build\build.ps1
# Build with specific configuration
.\tools\build\build.ps1 -Platform x64 -Configuration Release
# Build only essential projects (runner + settings) for faster iteration
.\tools\build\build-essentials.ps1
# Build everything including the installer (Release only)
.\tools\build\build-installer.ps1
```
### Debugging
See [Debugging](development/debugging.md) for detailed debugging techniques, including Visual Studio setup, attaching to child processes, and troubleshooting build errors.
### Creating a New PowerToy
See [Creating a New PowerToy](development/new-powertoy.md) for an end-to-end guide covering module architecture, settings integration, installer packaging, and testing.
### Building Command Palette Extensions
If you want to build your own extensions for Command Palette, check out the [Command Palette extensibility documentation](https://aka.ms/building-cmdpal-extensions). It covers how to create, package, and distribute custom extensions that integrate with Command Palette.
## Development Guidelines
- [Coding Guidelines](development/guidelines.md) - Development guidelines and best practices
- [Coding Style](development/style.md) - Code formatting and style conventions
- [Logging and Telemetry](development/logging.md) - How to use logging and telemetry
- [Localization](development/localization.md) - How to support multiple languages
- [UI Testing](development/ui-tests.md) - How to write UI tests for PowerToys
- [Developing with VS Code](development/dev-with-vscode.md) - Build, debug, and contribute using VS Code
## Rules
- **Follow the pattern of what you already see in the code.**
- [Coding style](development/style.md).
- Try to package new functionality/components into libraries that have nicely defined interfaces.
- Package new functionality into classes or refactor existing functionality into a class as you extend the code.
- When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.
## GitHub Workflow
- Before starting to work on a fix/feature, make sure there is an open issue to track the work.
- Add the `In progress` label to the issue, if not already present. Also add a `Cost-Small/Medium/Large` estimate and make sure all appropriate labels are set.
- If you are a community contributor, you will not be able to add labels to the issue; in that case just add a comment saying that you have started work on the issue and try to give an estimate for the delivery date.
- If the work item has a medium/large cost, using the markdown task list, list each sub item and update the list with a check mark after completing each sub item.
- **Before opening a PR, ensure your changes build successfully locally and functionality tests pass.** This is especially important for AI-assisted (vibe coding) contributions—always verify AI-generated code works as intended. Exploratory PRs or draft PRs for discussion are exceptions.
- When opening a PR, follow the PR template. **You must write the PR description yourself.** You can include AI-generated text only inside a collapsed `` section. Maintainers can close PRs whose description they think was not written by a human. See [Pull request descriptions must be written by a human](../../CONTRIBUTING.md#pull-request-descriptions-must-be-written-by-a-human). AI-assisted translations are allowed as long as the original text is still your own words.
- When you'd like the team to take a look (even if the work is not yet fully complete) mark the PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
- When the PR is approved, let the owner of the PR merge it. For community contributions, the reviewer who approved the PR can also merge it.
- Use the `Squash and merge` option to merge a PR. If you don't want to squash it because there are logically different commits, use `Rebase and merge`.
- Close issues automatically when referenced in a PR. You can use [closing keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in the body of the PR to have GitHub automatically link your PR to the issue.
## Core Architecture
- [Architecture Overview](core/architecture.md) - Overview of the PowerToys architecture and module interface
- [Runner and System tray](core/runner.md) - Details about the PowerToys Runner process
- [Settings](core/settings/readme.md) - Documentation on the settings system
- [Installer](core/installer.md) - Information about the PowerToys installer
- [Modules](modules/readme.md) - Documentation for individual PowerToys modules
## Common Components
- [Context Menu Handlers](common/context-menus.md) - How PowerToys implements and registers Explorer context menu handlers
- [Monaco Editor](common/monaco-editor.md) - How PowerToys uses the Monaco code editor component across modules
## Tools
- [Tools Overview](tools/readme.md) - Overview of tools in PowerToys
- [Build Tools](tools/build-tools.md) - Tools that help building PowerToys
- [Bug Report Tool](tools/bug-report-tool.md) - Tool for collecting logs and system information
- [Debugging Tools](tools/debugging-tools.md) - Specialized tools for debugging
- [Fuzzing Testing](tools/fuzzingtesting.md) - How to implement and run fuzz testing for PowerToys modules
## Processes
- [Release Process](processes/release-process.md) - How PowerToys releases are prepared and published
- [Update Process](processes/update-process.md) - How PowerToys updates work
- [GPO Implementation](processes/gpo.md) - Group Policy Objects implementation details
## Other Resources
- [aka.ms links](akaLinks.md) - List of short links
- [Issue/PR commands](commands.md) - Special commands for managing issues and pull requests
## Building the Installer
Our installer is two parts, an EXE and an MSI. The EXE (Bootstrapper) contains the MSI and handles more complex installation logic.
- The EXE installs all prerequisites and installs PowerToys via the MSI. It has additional features such as the installation flags (see below).
- The MSI installs the PowerToys binaries.
The installer can only be compiled in `Release` mode; steps 1 and 2 must be performed before the MSI can be compiled.
1. Compile `PowerToys.slnx`. Instructions are listed above.
1. Compile `BugReportTool.sln` tool. Path from root: `tools\BugReportTool\BugReportTool.sln` (details listed below)
1. Compile `StylesReportTool.sln` tool. Path from root: `tools\StylesReportTool\StylesReportTool.sln` (details listed below)
1. Compile `PowerToysSetup.slnx` Path from root: `installer\PowerToysSetup.slnx` (details listed below)
See [Installer](core/installer.md) for more details on building and debugging the installer.
---
### Doc Dsc Overview (`doc/dsc/overview.md`)
---
description: Overview of PowerToys Desired State Configuration (DSC) support
ms.date: 10/18/2025
ms.topic: overview
title: PowerToys DSC Overview
---
# PowerToys DSC Overview
## Synopsis
PowerToys supports Desired State Configuration (DSC) v3 for declarative configuration management of PowerToys settings.
## Description
PowerToys includes Microsoft Desired State Configuration (DSC) support
through the `PowerToys.DSC.exe` command-line tool, enabling you to:
- Declare and enforce desired configuration states for PowerToys
utilities.
- Automate PowerToys configuration across multiple systems.
- Integrate PowerToys configuration with WinGet and other DSC-compatible
tools.
- Version control your PowerToys settings as code.
The PowerToys DSC implementation provides a **settings** resource that
manages configuration for all PowerToys utilities (modules). Each utility
can be configured independently, allowing granular control over your
PowerToys environment.
## Usage methods
PowerToys DSC can be used in three ways:
### 1. Direct execution with PowerToys.DSC.exe
Execute DSC operations directly using the PowerToys.DSC.exe command-line
tool:
```powershell
# Get current settings for a module
PowerToys.DSC.exe get --resource 'settings' --module Awake
# Set settings for a module
$input = '{"settings":{...}}'
PowerToys.DSC.exe set --resource 'settings' --module Awake --input $input
# Test if settings match desired state
PowerToys.DSC.exe test --resource 'settings' --module Awake --input $input
```
For detailed information, see [PowerToys.DSC.exe command reference][01].
### 2. Microsoft Desired State Configuration (DSC)
Use PowerToys DSC resources in standard DSC configuration documents:
```yaml
# powertoys-config.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Configure Awake
type: Microsoft.PowerToys/AwakeSettings
properties:
settings:
properties:
keepDisplayOn: true
mode: 1
name: Awake
version: 0.0.1
```
### 3. WinGet Configuration
Integrate PowerToys configuration with WinGet package installation:
```yaml
# winget-powertoys.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
winget:
processor: dscv3
resources:
- name: Install PowerToys
type: Microsoft.WinGet.DSC/WinGetPackage
properties:
id: Microsoft.PowerToys
source: winget
- name: Configure FancyZones
type: Microsoft.PowerToys/FancyZonesSettings
properties:
settings:
properties:
fancyzones_shiftDrag: true
fancyzones_mouseSwitch: true
name: FancyZones
version: 1.0
```
## Available resources
PowerToys DSC provides the following resources:
| Resource | Description |
| ---------- | ------------------------------------------------------------------ |
| `settings` | Manages configuration for PowerToys utility modules. |
| `profile` | Manages the Keyboard Manager remapping profile (keys, shortcuts). |
For detailed information, see the [Settings Resource Reference][03] and the
[Keyboard Manager Profile Resource Reference][34].
## Available modules
The settings resource supports configuration for the following PowerToys
utilities:
| Module | Description | Documentation |
| ---------------------- | -------------------------------------------- | ------------------------------------- |
| App | General PowerToys application settings. | [App module][04] |
| AdvancedPaste | Advanced clipboard operations. | [AdvancedPaste module][05] |
| AlwaysOnTop | Pin windows to stay on top. | [AlwaysOnTop module][06] |
| Awake | Keep computer awake. | [Awake module][07] |
| ColorPicker | System-wide color picker utility. | [ColorPicker module][08] |
| CropAndLock | Crop and lock portions of windows. | [CropAndLock module][09] |
| EnvironmentVariables | Manage environment variables. | [EnvironmentVariables module][10] |
| FancyZones | Window layout manager. | [FancyZones module][11] |
| FileLocksmith | Identify what's locking files. | [FileLocksmith module][12] |
| FindMyMouse | Locate your mouse cursor. | [FindMyMouse module][13] |
| Hosts | Quick hosts file editor. | [Hosts module][14] |
| ImageResizer | Resize images from context menu. | [ImageResizer module][15] |
| KeyboardManager | Remap keys and create shortcuts. | [KeyboardManager module][16] |
| MeasureTool | Measure pixels on screen. | [MeasureTool module][17] |
| MouseButtonLock | Lock mouse buttons for hands-free dragging. | [MouseButtonLock module][18] |
| MouseHighlighter | Highlight mouse cursor. | [MouseHighlighter module][19] |
| MouseJump | Jump across large or multiple displays. | [MouseJump module][20] |
| MousePointerCrosshairs | Display crosshairs centered on mouse. | [MousePointerCrosshairs module][21] |
| Peek | Quick file previewer. | [Peek module][22] |
| PowerAccent | Quick accent character selector. | [PowerAccent module][23] |
| PowerOCR | Extract text from images. | [PowerOCR module][24] |
| PowerRename | Bulk rename files. | [PowerRename module][25] |
| RegistryPreview | Visualize and edit registry files. | [RegistryPreview module][26] |
| ShortcutGuide | Display keyboard shortcuts. | [ShortcutGuide module][27] |
| Workspaces | Save and restore application sets. | [Workspaces module][28] |
| ZoomIt | Screen zoom and annotation tool. | [ZoomIt module][29] |
## Common operations
### List all supported modules
```powershell
PowerToys.DSC.exe modules --resource 'settings'
```
### Get current configuration
```powershell
# Get configuration for a specific module.
PowerToys.DSC.exe get --resource 'settings' --module FancyZones
# Export configuration (identical to get).
PowerToys.DSC.exe export --resource 'settings' --module FancyZones
```
### Apply configuration
```powershell
# Set configuration for a module.
$input = '{"settings":{...}}'
PowerToys.DSC.exe set --resource 'settings' --module FancyZones --input $input
```
### Validate configuration
```powershell
# Test if current state matches desired state.
$input = '{"settings":{...}}'
PowerToys.DSC.exe test --resource 'settings' --module FancyZones --input $input
```
### Generate schema
```powershell
# Get JSON schema for a module's settings.
PowerToys.DSC.exe schema --resource 'settings' --module FancyZones
```
### Generate DSC manifest
```powershell
# Generate manifest for a specific module.
$outputDir = "C:\manifests"
PowerToys.DSC.exe manifest --resource 'settings' --module FancyZones `
--outputDir $outputDir
# Generate manifests for all modules.
PowerToys.DSC.exe manifest --resource 'settings' --outputDir $outputDir
```
## Examples
For complete examples, see:
- [Settings Resource Examples][30]
- Individual module documentation in the [modules][31] folder
## See also
- [Settings Resource Reference][03]
- [PowerToys.DSC.exe Command Reference][01]
- [Module Documentation][31]
- [Microsoft DSC Documentation][32]
- [WinGet Configuration Documentation][33]
[01]: ./modules/
[03]: ./settings-resource.md
[04]: ./modules/App.md
[05]: ./modules/AdvancedPaste.md
[06]: ./modules/AlwaysOnTop.md
[07]: ./modules/Awake.md
[08]: ./modules/ColorPicker.md
[09]: ./modules/CropAndLock.md
[10]: ./modules/EnvironmentVariables.md
[11]: ./modules/FancyZones.md
[12]: ./modules/FileLocksmith.md
[13]: ./modules/FindMyMouse.md
[14]: ./modules/Hosts.md
[15]: ./modules/ImageResizer.md
[16]: ./modules/KeyboardManager.md
[17]: ./modules/MeasureTool.md
[18]: ./modules/MouseButtonLock.md
[19]: ./modules/MouseHighlighter.md
[20]: ./modules/MouseJump.md
[21]: ./modules/MousePointerCrosshairs.md
[22]: ./modules/Peek.md
[23]: ./modules/PowerAccent.md
[24]: ./modules/PowerOCR.md
[25]: ./modules/PowerRename.md
[26]: ./modules/RegistryPreview.md
[27]: ./modules/ShortcutGuide.md
[28]: ./modules/Workspaces.md
[29]: ./modules/ZoomIt.md
[30]: ./settings-resource.md#examples
[31]: ./modules/
[32]: https://learn.microsoft.com/powershell/dsc/overview
[33]: https://learn.microsoft.com/windows/package-manager/configuration/
[34]: ./profile-resource.md
---
### Doc Gpo README (`doc/gpo/README.md`)
# Group Policies
Since version 0.64, PowerToys is released on GitHub with [Administrative Templates that allows you to configure PowerToys using Group Policies](/previous-versions/windows/desktop/policy/group-policy-objects). You can get the group policy files in each release of PowerToys over at .
For detailed instructions and notes, head over to [learn.microsoft.com](https://aka.ms/PowerToysOverview_GPO) and see the PowerToys Group Policy section.
---
### Doc Specs Readme (`doc/specs/readme.md`)
# Specs
All approved specs are inside the [Wiki spec section](https://github.com/microsoft/PowerToys/wiki/Specs)
## Spec process
1. A proposed item is either new or requesting additional design
2. Spec is written inside the Specs folder and a PR happens with feedback.
3. Once spec is signed off, we move it into the [Wiki spec section](https://github.com/microsoft/PowerToys/wiki/Specs).
## Thought process behind this
We want a single wholistic for PowerToys. This includes both source code, docs, and specs. At the same time, we want to ensure items have pull requests and feedback. Since the wiki cannot do PR's, we will do the process above.
This process will allow specs to be image rich but not impact the primary repository's size as more items come online.
---
### Doc Devdocs Common Readme (`doc/devdocs/common/readme.md`)
# Common
The [common](/src/common) folder contains projects with code, that is used in multiple projects.
## [FilePreviewCommon](FilePreviewCommon.md)
This project contains common code for file previewing.
---
### Doc Devdocs Modules Readme (`doc/devdocs/modules/readme.md`)
# PowerToys Modules
This section contains documentation for individual PowerToys modules, including their architecture, implementation details, and debugging tools.
## Available Modules
| Module | Description |
|--------|-------------|
| [Advanced Paste](advancedpaste.md) | Tool for enhanced clipboard pasting with formatting options |
| [Always on Top](alwaysontop.md) | Tool for pinning windows to stay on top of other windows |
| [Awake](awake.md) | Tool to keep your computer awake without modifying power settings |
| [Color Picker](colorpicker.md) | Tool for selecting and managing colors from the screen |
| [Command Not Found](commandnotfound.md) | Tool suggesting package installations for missing commands |
| [Crop and Lock](cropandlock.md) | Tool for cropping application windows into smaller windows or thumbnails |
| [Environment Variables](environmentvariables.md) | Tool for managing user and system environment variables |
| [FancyZones](fancyzones.md) ([debugging tools](fancyzones-tools.md)) | Window manager utility for custom window layouts |
| [File Explorer add-ons](fileexploreraddons.md) | Extensions for enhancing Windows File Explorer functionality |
| [File Locksmith](filelocksmith.md) | Tool for finding processes that lock files |
| [Hosts File Editor](hostsfileeditor.md) | Tool for managing the system hosts file |
| [Image Resizer](imageresizer.md) | Tool for quickly resizing images within File Explorer |
| [Keyboard Manager](keyboardmanager/README.md) | Tool for remapping keys and keyboard shortcuts |
| [Mouse Utilities](mouseutils/readme.md) | Collection of tools to enhance mouse and cursor functionality |
| [Mouse Without Borders](mousewithoutborders.md) | Tool for controlling multiple computers with a single mouse and keyboard |
| [NewPlus](newplus.md) | Context menu extension for creating new files in File Explorer |
| [Peek](peek/readme.md) | File preview utility for quick file content viewing |
| [Power Rename](powerrename.md) | Bulk file renaming tool with search and replace functionality |
| [PowerToys Run (deprecation soon)](launcher/readme.md) | Quick application launcher and search utility |
| [Quick Accent](quickaccent.md) | Tool for quickly inserting accented characters and special symbols |
| [Registry Preview](registrypreview.md) | Tool for visualizing and editing Registry files |
| [Screen Ruler](screenruler.md) | Tool for measuring pixel distances and color boundaries on screen |
| [Shortcut Guide](shortcut_guide.md) | Tool for displaying Windows keyboard shortcuts when holding the Windows key |
| [Text Extractor](textextractor.md) | Tool for extracting text from images and screenshots |
| [Workspaces](workspaces.md) | Tool for saving and restoring window layouts for different projects |
| [ZoomIt](zoomit.md) | Screen zoom and annotation tool |
## Adding New Module Documentation
When adding documentation for a new module:
1. Create a dedicated markdown file for the module (e.g., `modulename.md`)
2. If the module has specialized debugging tools, consider creating a separate tools document (e.g., `modulename-tools.md`)
3. Update this index with links to the new documentation
4. Follow the existing documentation structure for consistency
---
### Doc Devdocs Tools Readme (`doc/devdocs/tools/readme.md`)
# PowerToys tools
Tools in PowerToys are standalone apps and scripts that run outside of the PowerToys runner. They help developers and users to debug and test PowerToys features.
The source code of the tools can be found in the [tools folder](/tools). The compiled tools are saved under `{PowerToysInstallPath}\tools`.
## Overview of the tools
Following tools are currently available:
* [BugReportTool](bug-report-tool.md) - A tool to collect logs and system information for bug reports.
* [Build tools](build-tools.md) - A set of scripts that help building PowerToys.
* [Monitor info report](monitor-info-report.md) - A small diagnostic tool which helps identifying WinAPI bugs related to the physical monitor detection.
* [project template](/tools/project_template/README.md) - A Visual Studio project template for a new PowerToys project.
* [StylesReportTool](styles-report-tool.md) - A tool to collect information about an open window.
* [Verification scripts](verification-scripts.md) - A set of scripts that help verifying the PowerToys installation.
---
### Doc Devdocs Core Settings Project Overview (`doc/devdocs/core/settings/project-overview.md`)
# Overview
`Settings` is Windows App Sdk WinUI3 .Net Unpackaged desktop application. More details about Windows App Sdk can be found in [Windows App SDK - Calling all Windows developers!](https://github.com/microsoft/WindowsAppSDK#windows-app-sdk---calling-all-windows-developers). More details about WinUI can be found in [Build apps with WinUI](https://developer.microsoft.com/en-us/windows/develop/).
## Settings V2 Project structure
The Settings project .Net WinUI3 based project which
follows the [MVVM architectural pattern][MVVM] where the graphical user interface is separated from the view models.
#### [UI Components:](/src/settings-ui/Settings.UI/)
The UI Components are part of PowerToys.Settings project. It contains the xaml files for each of the UI components. It also contains the Hotkey logic for the settings control.
#### [Viewmodels:](/src/settings-ui/Settings.UI.Library)
The Settings.UI.Library project contains the data that is to be rendered by the UI components.
#### [Settings Runner:](/src/settings-ui/Settings.UI)
The function of the settings runner project is to communicate all changes that the user makes in the user interface, to the runner so that it can be dispatched and reflected in all the modules.
[MVVM]: https://learn.microsoft.com/windows/uwp/data-binding/data-binding-and-mvvm
---
### Doc Devdocs Core Settings Readme (`doc/devdocs/core/settings/readme.md`)
# PowerToys Settings System
PowerToys provides a comprehensive settings system that allows users to configure various aspects of the application and its modules. This document provides an overview of the settings system architecture and links to more detailed documentation.
# Table of Contents
1. [Settings overview](/doc/devdocs/core/settings/project-overview.md)
2. [UI Architecture](/doc/devdocs/core/settings/ui-architecture.md)
3. [ViewModels](/doc/devdocs/core/settings/viewmodels.md)
4. [Settings Implementation](/doc/devdocs/core/settings/settings-implementation.md)
5. [Group Policy Integration](/doc/devdocs/core/settings/gpo-integration.md)
6. Data flow
- [Inter-Process Communication with runner](/doc/devdocs/core/settings/runner-ipc.md)
- [Communication with modules](/doc/devdocs/core/settings/communication-with-modules.md)
7. [Settings Utilities](/doc/devdocs/core/settings/settings-utilities.md)
8. [Custom Hotkey control and keyboard hook handling](hotkeycontrol.md)
9. [Compatibility with legacy settings and runner](/doc/devdocs/core/settings/compatibility-legacy-settings.md)
10. [XAML Island tweaks](/doc/devdocs/core/settings/xaml-island-tweaks.md)
11. [Telemetry](/doc/devdocs/core/settings/telemetry.md)
12. [DSC Configuration](/doc/devdocs/core/settings/dsc-configure.md)
---
### Doc Devdocs Modules Keyboardmanager README (`doc/devdocs/modules/keyboardmanager/README.md`)
# Table of Contents
[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/keyboard-manager)
## Quick Links
[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Keyboard%20Shortcut%20Manager%22)
[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Keyboard%20Shortcut%20Manager%22)
[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Keyboard+Shortcut+Manager%22+)
The devdocs for Keyboard Manager have been divided into the following modules:
1. [Keyboard Manager Module](keyboardmanager.md)
2. [Keyboard Event Handlers](keyboardeventhandlers.md)
3. [Keyboard Manager UI](keyboardmanagerui.md)
4. [Keyboard Manager Common](keyboardmanagercommon.md)
5. [Debugging Guide](debug.md)
---
### Doc Devdocs Modules Launcher Readme (`doc/devdocs/modules/launcher/readme.md`)
# Table of Contents
1. [Architecture](/doc/devdocs/modules/launcher/architecture.md)
2. [Debugging](/doc/devdocs/modules/launcher/debugging.md)
3. [New Plugin Checklist](/doc/devdocs/modules/launcher/new-plugin-checklist.md)
4. [Project Structure](/doc/devdocs/modules/launcher/project_structure.md)
5. [Telemetry](/doc/devdocs/modules/launcher/telemetry.md)
6. Plugins
- [Overview](/doc/devdocs/modules/launcher/plugins/overview.md)
- [Calculator](/doc/devdocs/modules/launcher/plugins/calculator.md)
- [Folder](/doc/devdocs/modules/launcher/plugins/folder.md)
- [History](/doc/devdocs/modules/launcher/plugins/history.md)
- [Indexer](/doc/devdocs/modules/launcher/plugins/indexer.md)
- [OneNote](/doc/devdocs/modules/launcher/plugins/onenote.md)
- [Program](/doc/devdocs/modules/launcher/plugins/program.md)
- [Registry](/doc/devdocs/modules/launcher/plugins/registry.md)
- [Shell](/doc/devdocs/modules/launcher/plugins/shell.md)
- [Time and Date](/doc/devdocs/modules/launcher/plugins/timedate.md)
- [Unit Converter](/doc/devdocs/modules/launcher/plugins/community.unitconverter.md)
- [Uri](/doc/devdocs/modules/launcher/plugins/uri.md)
- [Value Generator](/doc/devdocs/modules/launcher/plugins/community.valuegenerator.md)
- [Web Search](/doc/devdocs/modules/launcher/plugins/WebSearch.md)
- [Windows Settings](/doc/devdocs/modules/launcher/plugins/windowssettings.md)
- [Windows System Commands](/doc/devdocs/modules/launcher/plugins/system.md)
- [Window Walker](/doc/devdocs/modules/launcher/plugins/windowwalker.md)
---
### Doc Devdocs Modules Mouseutils Readme (`doc/devdocs/modules/mouseutils/readme.md`)
# Mouse Utilities
[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/mouse-utilities)
## Quick Links
[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Mouse%20Utilities%22)
[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Mouse%20Utilities%22)
[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Mouse+Utilities%22)
Mouse Utilities is a collection of tools designed to enhance mouse and cursor functionality on Windows. The module contains several sub-utilities that provide different mouse-related features.
## Overview
Mouse Utilities includes the following sub-modules:
- **[Find My Mouse](findmymouse.md)**: Helps locate the mouse pointer by creating a visual spotlight effect when activated
- **[Mouse Highlighter](mousehighlighter.md)**: Visualizes mouse clicks with customizable highlights
- **[Mouse Jump](mousejump.md)**: Allows quick cursor movement to specific screen locations
- **[Mouse Pointer Crosshairs](mousepointer.md)**: Displays crosshair lines that follow the mouse cursor
- **[Mouse Button Lock](mousebuttonlock.md)**: A ClickLock equivalent for the left, right, and middle mouse buttons - hold a button to lock it down for hands-free dragging, then click any button to release (left is optional and off by default)
## Architecture
Most of the sub-modules (Find My Mouse, Mouse Highlighter, Mouse Pointer Crosshairs, and Mouse Button Lock) run within the PowerToys Runner process as separate threads. Mouse Jump is more complex and runs as a separate process that communicates with the Runner via events.
### Code Structure
#### Settings UI
- [MouseUtilsPage.xaml](/src/settings-ui/Settings.UI/SettingsXAML/Views/MouseUtilsPage.xaml)
- [MouseJumpPanel.xaml](/src/settings-ui/Settings.UI/SettingsXAML/Panels/MouseJumpPanel.xaml)
- [MouseJumpPanel.xaml.cs](/src/settings-ui/Settings.UI/SettingsXAML/Panels/MouseJumpPanel.xaml.cs)
- [MouseUtilsViewModel.cs](/src/settings-ui/Settings.UI/ViewModels/MouseUtilsViewModel.cs)
- [MouseUtilsViewModel_MouseJump.cs](/src/settings-ui/Settings.UI/ViewModels/MouseUtilsViewModel_MouseJump.cs)
#### Runner and Module Implementation
- [FindMyMouse](/src/modules/MouseUtils/FindMyMouse)
- [MouseHighlighter](/src/modules/MouseUtils/MouseHighlighter)
- [MousePointerCrosshairs](/src/modules/MouseUtils/MousePointerCrosshairs)
- [MouseJump](/src/modules/MouseUtils/MouseJump)
- [MouseJumpUI](/src/modules/MouseUtils/MouseJumpUI)
- [MouseJump.Common](/src/modules/MouseUtils/MouseJump.Common)
- [MouseButtonLock](/src/modules/MouseUtils/MouseButtonLock)
## Community Contributors
- **Michael Clayton (@mikeclayton)**: Contributed the initial version of the Mouse Jump tool and several updates based on his FancyMouse utility
- **Raymond Chen (@oldnewthing)**: Find My Mouse is based on Raymond Chen's SuperSonar
## Known Issues
- Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0
## UI Test Automation
Mouse Utilities is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
[Mouse Utils UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/MouseUtils/MouseUtils.UITests/Release-Test-Checklist-Migration-Progress.md)
## See Also
For more detailed implementation information, please refer to the individual utility documentation pages linked above.
#### Activation Process
1. A keyboard hook detects the activation shortcut (typically double-press of Ctrl)
2. A `WM_PRIV_SHORTCUT` message is sent to the sonar window
3. `StartSonar()` is called to display a spotlight animation centered on the mouse pointer
4. The animation automatically fades or can be cancelled by user input
### Mouse Highlighter
Mouse Highlighter visualizes mouse clicks by displaying a highlight effect around the cursor when clicked.
#### Key Components
- Uses Windows Composition API for rendering
- Main implementation in `MouseHighlighter.cpp`
- Core logic handled by the `WndProc` function
#### Activation Process
1. When activated, it creates a transparent overlay window
2. A mouse hook monitors for click events
3. On click detection, the highlighter draws a circle or other visual indicator
4. The highlight effect fades over time based on user settings
### Mouse Pointer Crosshairs
Displays horizontal and vertical lines that intersect at the mouse cursor position.
#### Key Components
- Uses Windows Composition API for rendering
- Core implementation in `InclusiveCrosshairs.cpp`
- Main logic handled by the `WndProc` function
#### Activation Process
1. Creates a transparent, layered window for drawing crosshairs
2. When activated via shortcut, calls `StartDrawing()`
3. Sets a low-level mouse hook to track cursor movement
4. Updates crosshairs position on every mouse movement
5. Includes auto-hide functionality for cursor inactivity
### Mouse Jump
Allows quick mouse cursor repositioning to any screen location through a grid-based UI.
#### Key Components
- Runs as a separate process (`PowerToys.MouseJumpUI.exe`)
- Communicates with Runner process via events
- UI implemented in `MainForm.cs`
#### Activation Process
1. When shortcut is pressed, Runner triggers the shared event `MOUSE_JUMP_SHOW_PREVIEW_EVENT`
2. The MouseJumpUI process displays a screen overlay
3. User selects a destination point on the overlay
4. Mouse cursor is moved to the selected position
5. The UI process can be terminated via the `TERMINATE_MOUSE_JUMP_SHARED_EVENT`
## Debugging
### Find My Mouse, Mouse Highlighter, and Mouse Pointer Crosshairs
- Debug by attaching to the Runner process directly
- Set breakpoints in the respective utility code files (e.g., `FindMyMouse.cpp`, `MouseHighlighter.cpp`, `InclusiveCrosshairs.cpp`)
- Call the respective utility by using the activation shortcut (e.g., double Ctrl press for Find My Mouse)
- During debugging, visual effects may appear glitchy due to the debugger's overhead
### Mouse Jump
- Start by debugging the Runner process
- Then attach the debugger to the MouseJumpUI process
- Note: Debugging MouseJumpUI directly is challenging as it requires the Runner's process ID as a parameter
## Known Issues
- Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0
---
### Doc Devdocs Modules Peek Readme (`doc/devdocs/modules/peek/readme.md`)
# PowerToys Peek
[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/peek)
## Quick Links
[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-Peek)
[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-Peek)
[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-Peek)
> Documentation is currently under construction
## Dev file previewer
The previewer for developer files uses the project in [FileExplorerCommon] common project to render monaco. You can find its documentation here: [/doc/devdocs/common/FilePreviewCommon.md](/doc/devdocs/common/FilePreviewCommon.md).
---
### Doc Devdocs Modules Launcher Plugins Overview (`doc/devdocs/modules/launcher/plugins/overview.md`)
# Structural Overview
The following basic functions are common to each of the plugins. They perform some rudimentary operations such as initialization of the plugin, executing the query that has been entered, loading context menu icons, updating settings when configurations are altered in the settings UI, and updating the theme of the icons when the theme changed event is triggered.
## IPlugin Interface
Each plugin implements the `IPlugin` interface which comprises of the `Init()` and `Query()` functions.
### `Init`
- The `Init()` function initializes the context, storage and settings of each plugin. This is equivalent to a constructor and is the first function to be called in the `Main.cs` file for each plugin.
### `Query`
- For every query that the user enters into PT Run, the `PluginManager.cs` executes the `Query()` function in the `Main.cs` file corresponding to each Plugin.
### Context Menu Icons
- The `ContextMenus` are loaded for each result based on the type of the result.
- The various types of `ContextMenu` functionalities are:
- Open containing folder
- Run as Administrator
- Open in console
- Copy path
### UpdateSettings
- This function updates the settings of each plugin based on the changes made by the user in the settings UI.
- Eg: To disable drive detection in the indexer plugin, when the user checks or unchecks the drive detection check box, the `UpdateSettings()` function dispatches the changes in the check box to the plugin.
### ThemeChanged
- This function is invoked when there is a change in the theme of PT Run.
- It is used to update the `IconPath` for each plugin based on the theme.
### Save
- This function saves the configurations of each plugin so that they can be loaded the next time.
### Score
- The user query is executed against each of the plugins and the result list view is updated with results from each of the plugins.
- The ordering of the results is based on the `Score` of each Result.
- Each plugin assigns a score to a result based on its relevance. The results with higher scores are displayed higher in the list view and vice versa.
## Plugin settings
Plugin settings that are editable from the settings are stored in `PowerToys Run\settings.json`. In the very first run, those settings are populated from plugin' `plugin.json` file. Unlike Wox we do not support multiple action keywords. Instead, we have `ActionKeyword` and `IsGlobal` options.
---
### Doc ThirdPartyRunPlugins (`doc/thirdPartyRunPlugins.md`)
# Third-Party plugins for PowerToy Run
This is a collection of third-party plugins for PowerToys Run created by the community.
## Installing and upgrading third-party PowerToys Run plugins
The recommended path for the plugins is `%LOCALAPPDATA%\Microsoft\PowerToys\PowerToys Run\Plugins`.
1. Close PowerToys.
1. Copy the plugin folder to `%LOCALAPPDATA%\Microsoft\PowerToys\PowerToys Run\Plugins`.
1. If you're upgrading a plugin, delete the previous version.
1. Open PowerToys.
Refer to plugin instruction for more details.
## Disclaimer
The following plugins are created and maintained by third-party and not officially supported or recognized by Microsoft. Users install and use these plugins at their own risk, and Microsoft takes no responsibility for their functionality or any potential issues they may cause.
## Support
Contact the developers of a plugin directly for assistance with a specific plugin.
## General plugins
| Plugin | Author | Description |
| ------ | ------ | ----------- |
| [BrowserSearch](https://github.com/TBM13/BrowserSearch) | [TBM13](https://github.com/TBM13) | Search your browser history |
| [GitHub Emoji](https://github.com/hlaueriksson/GEmojiSharp) | [hlaueriksson](https://github.com/hlaueriksson) | Search GitHub Emoji |
| [PowerTranslator](https://github.com/N0I0C0K/PowerTranslator) | [N0I0C0K](https://github.com/N0I0C0K) | Text translator based on Youdao |
| [Quick Lookup](https://github.com/GTGalaxi/quick-lookup-ptrun) | [gtgalaxi](https://github.com/GTGalaxi) | Search across multiple cyber security tools |
| [Input Typer](https://github.com/CoreyHayward/PowerToys-Run-InputTyper) | [CoreyHayward](https://github.com/CoreyHayward) | Type the input as if sent from a keyboard |
| [Clipboard Manager](https://github.com/CoreyHayward/PowerToys-Run-ClipboardManager) | [CoreyHayward](https://github.com/CoreyHayward) | Search and paste text from your clipboard history |
| [Currency Converter](https://github.com/Advaith3600/PowerToys-Run-Currency-Converter) | [advaith3600](https://github.com/advaith3600) | Convert real and crypto currencies |
| [FastWeb](https://github.com/CCcat8059/FastWeb) | [CCcat](https://github.com/CCcat8059) | Open website in browser |
| [WebSearchShortcut](https://github.com/Daydreamer-riri/CmdPal-WebSearchShortcut) | [Daydreamer-riri](https://github.com/Daydreamer-riri) | Web Search Shortcut Plugin for PowerToys Run |
| [UnicodeInput](https://github.com/nathancartlidge/powertoys-run-unicode) | [nathancartlidge](https://github.com/nathancartlidge) | Copy Unicode characters to the clipboard |
| [PowerHexInspector](https://github.com/NaroZeol/PowerHexInspector) | [NaroZeol](https://github.com/NaroZeol) | Peek other forms of an input number |
| [GitHubRepo](https://github.com/8LWXpg/PowerToysRun-GitHubRepo) | [8LWXpg](https://github.com/8LWXpg) | Search and open GitHub repositories |
| [ProcessKiller](https://github.com/8LWXpg/PowerToysRun-ProcessKiller) | [8LWXpg](https://github.com/8LWXpg) | Search and kill processes |
| [ChatGPT](https://github.com/ferraridavide/ChatGPTPowerToys) | [ferraridavide](https://github.com/ferraridavide) | Ask a question to ChatGPT |
| [CanIUse](https://github.com/skttl/ptrun-caniuse) | [skttl](https://github.com/skttl) | Look up browser feature support with caniuse.com |
| [TailwindCSS](https://github.com/skttl/ptrun-tailwindcss) | [skttl](https://github.com/skttl) | Search the documentation of TailwindCSS |
| [HttpStatusCodes](https://github.com/grzhan/HttpStatusCodePowerToys) | [grzhan](https://github.com/grzhan) | Search for http status codes |
| [SVGL](https://github.com/Sameerjs6/powertoys-svgl) | [SameerJS6](https://github.com/SameerJS6) | Search, Browse and copy SVG logos from SVGL. |
| [QuickNotes](https://github.com/ruslanlap/CommunityPowerToysRunPlugin-QuickNotes) | [ruslanlap](https://github.com/ruslanlap) | Create, manage, and search notes directly from PowerToys Run. |
| [Quick Shell](https://github.com/tonythethompson/QuickShell) | [tonythethompson](https://github.com/tonythethompson) | Open saved project folders in any terminal; shared shortcuts with the Quick Shell extension |
| [Weather](https://github.com/ruslanlap/PowerToysRun-Weather) | [ruslanlap](https://github.com/ruslanlap) | Get real-time weather information directly from PowerToys Run. |
| [Pomodoro](https://github.com/ruslanlap/PowerToysRun-Pomodoro) | [ruslanlap](https://github.com/ruslanlap) | Manage Pomodoro productivity sessions directly from PowerToys Run. |
| [Definition](https://github.com/ruslanlap/PowerToysRun-Definition) | [ruslanlap](https://github.com/ruslanlap) | Lookup word definitions, phonetics, and synonyms directly in PowerToys Run. |
| [Hotkeys](https://github.com/ruslanlap/PowerToysRun-Hotkeys) | [ruslanlap](https://github.com/ruslanlap) | Create, manage, and trigger custom keyboard shortcuts directly from PowerToys Run. |
| [RandomGen](https://github.com/ruslanlap/PowerToysRun-RandomGen) | [ruslanlap](https://github.com/ruslanlap) | 🎲 Generate random data instantly with a single keystroke. Perfect for developers, testers, designers, and anyone who needs quick access to random data. Features include secure passwords, PINs, names, business data, dates, numbers, GUIDs, color codes, and more. Especially useful for designers who need random color codes and placeholder content. |
| [Open With Cursor](https://github.com/VictorNoxx/PowerToys-Run-Cursor/) | [VictorNoxx](https://github.com/VictorNoxx) | Open Visual Studio, VS Code recents with Cursor AI |
| [Open With Antigravity](https://github.com/artickc/PowerToys-Run-Antygravity) | [artickc](https://github.com/artickc) | Open Visual Studio, VS Code recents with Antigravity AI |
| [Project Launcher Plugin](https://github.com/artickc/ProjectLauncherPowerToysPlugin) | [artickc](https://github.com/artickc) | Access your projects using Project Launcher and PowerToys Run |
| [CheatSheets](https://github.com/ruslanlap/PowerToysRun-CheatSheets) | [ruslanlap](https://github.com/ruslanlap) | 📚 Find cheat sheets and command examples instantly from tldr pages, cheat.sh, and devhints.io. Features include favorites system, categories, offline mode, and smart caching. |
| [QuickAI](https://github.com/ruslanlap/PowerToysRun-QuickAi) | [ruslanlap](https://github.com/ruslanlap) | AI-powered assistance with instant, smart responses from multiple providers (Groq, Together, Fireworks, OpenRouter, Cohere) |
| [Launchy](https://github.com/PsychodelEKS/PowerToysRun-Launchy) | [PsychodelEKS](https://github.com/PsychodelEKS) | Index and launch files from configured folders |
| [DevDocs](https://github.com/jan-jaros/PowerToys-Run-DevDocs) | [jan-jaros](https://github.com/jan-jaros) | Search programming documentation from DevDocs.io |
| [PoetSearch](https://github.com/Greyaircraft/PowerToysRun-PoetSearch) | [Greyaircraft](https://github.com/Greyaircraft) | Search 78,581 classical Chinese poems (全唐诗 + 全宋词) |
| [GoogleTranslate](https://github.com/nzcodes/GoogleTranslate) | [nzcodes](https://github.com/nzcodes) | Google Translate translations |
## Extending software plugins
Below are community created plugins that target a website or software. They are created and maintained by a third-party and not officially supported or recognized by the website or software they extend.
| Plugin | Author | Description |
| ------ | ------ | ----------- |
| [Edge Favorite](https://github.com/davidegiacometti/PowerToys-Run-EdgeFavorite) | [davidegiacometti](https://github.com/davidegiacometti) | Open Microsoft Edge favorites |
| [Edge Workspaces](https://github.com/quachpas/PowerToys-Run-EdgeWorkspaces) | [quachpas](https://github.com/quachpas) | Open Microsoft Edge workspaces|
| [Everything](https://github.com/lin-ycv/EverythingPowerToys) | [Yu Chieh (Victor) Lin](https://github.com/Lin-ycv) | Get search results from Everything |
| [GitKraken](https://github.com/davidegiacometti/PowerToys-Run-GitKraken) | [davidegiacometti](https://github.com/davidegiacometti) | Open GitKraken repositories |
| [RDP](https://github.com/anthony81799/PowerToysRun-RDP) | [anthony81799](https://github.com/anthony81799) | Open Remote Desktop connections |
| [Visual Studio Recents](https://github.com/davidegiacometti/PowerToys-Run-VisualStudio) | [davidegiacometti](https://github.com/davidegiacometti) | Open Visual Studio recents |
| [WinGet](https://github.com/bostrot/PowerToysRunPluginWinget) | [bostrot](https://github.com/bostrot) | Search and install packages from WinGet |
| [Scoop](https://github.com/Quriz/PowerToysRunScoop) | [Quriz](https://github.com/Quriz) | Search and install packages from Scoop |
| [Spotify](https://github.com/waaverecords/PowerToys-Run-Spotify) | [waaverecords](https://github.com/waaverecords) | Search Spotify and control its player |
| [PowerSearch for 1Password](https://github.com/KairuDeibisu/PowerToysRunPlugin1Password) | [KairuDeibisu](https://github.com/KairuDeibisu) | An unofficial plugin for searching 1Password for usernames and passwords |
| [HackMD](https://github.com/8LWXpg/PowerToysRun-HackMD) | [8LWXpg](https://github.com/8LWXpg) | Open HackMD notes |
| [SSH](https://github.com/8LWXpg/PowerToysRun-SSH) | [8LWXpg](https://github.com/8LWXpg) | Connect to ssh clients |
| [Bilibili](https://github.com/Whuihuan/PowerToysRun-Bilibili) | [Whuihuan](https://github.com/Whuihuan) | Use AVID or BVID to parse and jump to Bilibili |
| [YubicoOauthOTP](https://github.com/dlnilsson/Community.PowerToys.Run.Plugin.YubicoOauthOTP) | [dlnilsson](https://github.com/dlnilsson) | Display generated codes from OATH accounts stored on the YubiKey in powerToys Run |
| [Firefox Bookmark](https://github.com/8LWXpg/PowerToysRun-FirefoxBookmark) | [8LWXpg](https://github.com/8LWXpg) | Open bookmarks in Firefox based browser |
| [Linear](https://github.com/vednig/powertoys-linear) | [vednig](https://github.com/vednig) | Create Linear Issues directly from Powertoys Run |
| [PerplexitySearchShortcut](https://github.com/hugobatista/PowerToys-Run-PerplexitySearchShortcut) | [hugobatista](https://github.com/hugobatista) | Search Perplexity |
| [SpeedTest](https://github.com/ruslanlap/PowerToysRun-SpeedTest) | [ruslanlap](https://github.com/ruslanlap) | One-command internet speed tests with real-time results, modern UI, and shareable links. |
| [DiskAnalyzer](https://github.com/valley-soft/powertoys-diskanalyzer) | [ValleySoft](https://github.com/valley-soft) | Scan folders, find the largest files, and view drive space usage. |
| [New Chat for Claude](https://github.com/tit-exe/PowerToys-Run-for-Claude) | [tit-exe](https://github.com/tit-exe) | Start a new Claude conversation in the desktop app or the browser. |
---
### Doc Devdocs AkaLinks (`doc/devdocs/akaLinks.md`)
# Full list of aka links
| ShortUrl | TargetUrl |
|----------|----------|
| getpowertoys | ms-windows-store://pdp/?productid=XP89DCGQ3K6VLD |
| installpowertoys | https://github.com/microsoft/PowerToys/releases/latest |
| powertoys-license | https://github.com/microsoft/PowerToys/blob/main/LICENSE |
| powertoys | https://github.com/microsoft/PowerToys |
| PowerToysAppCompat | https://github.com/microsoft/PowerToys/wiki/Application-Compatibility |
| powerToysCannotRemapKeys | https://learn.microsoft.com/windows/powertoys/keyboard-manager#keys-that-cannot-be-remapped |
| powerToysColorPickerImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/ColorPicker_small.png |
| powerToysColorPickerSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/ColorPicker_large.png |
| powertoysDetectedElevatedHelp | https://learn.microsoft.com/windows/powertoys/administrator |
| powertoys-docs | https://learn.microsoft.com/windows/powertoys |
| powerToysFancyZoneImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/FancyZones_small.png |
| powerToysFancyZoneSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/FancyZones_large.png |
| powerToysGiveFeedback | https://github.com/microsoft/PowerToys/issues |
| powerToysImageResizerImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/ImageResizer_small.png |
| powerToysImageResizerSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/ImageResizer_large.png |
| powerToysKBMImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/KBM_small.png |
| powerToysKBMSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/KBM_large.png |
| PowerToysOverview | https://learn.microsoft.com/windows/powertoys/ |
| PowerToysOverview_ColorPicker | https://learn.microsoft.com/windows/powertoys/color-picker |
| PowerToysOverview_FancyZones | https://learn.microsoft.com/windows/powertoys/fancyzones |
| PowerToysOverview_FileExplorerAddOns | https://learn.microsoft.com/windows/powertoys/file-explorer |
| PowerToysOverview_ImageResizer | https://learn.microsoft.com/windows/powertoys/image-resizer |
| PowerToysOverview_KeyboardManager | https://learn.microsoft.com/windows/powertoys/keyboard-manager |
| PowerToysOverview_MouseUtilities | https://learn.microsoft.com/windows/powertoys/mouse-utilities |
| PowerToysOverview_PowerRename | https://learn.microsoft.com/windows/powertoys/powerrename |
| PowerToysOverview_PowerToysRun | https://learn.microsoft.com/windows/powertoys/run |
| PowerToysOverview_ShortcutGuide | https://learn.microsoft.com/windows/powertoys/shortcut-guide |
| powerToysPowerLauncherImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/PowerLauncher_small.png |
| powerToysPowerLauncherSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/PowerLauncher_large.png |
| powerToysPowerPreviewImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/PowerPreview_small.png |
| powerToysPowerPreviewSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/PowerPreview_large.png |
| powerToysPowerRenameImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/PowerRename_small.png |
| powerToysPowerRenameSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/PowerRename_large.png |
| powerToysPTImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/PT_small.png |
| powerToysPTSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/PT_large.png |
| powerToysReportBug | https://github.com/microsoft/PowerToys/issues/new?assignees=&labels=Issue-Bug%2CTriage-Needed&template=bug_report.yml&title= |
| powerToysRequestFeature | https://github.com/microsoft/PowerToys/issues/new?assignees=&labels=&template=feature_request.md&title= |
| powerToysShortcutGuideImageSmall | https://github.com/microsoft/PowerToys/wiki/images/overview/ShortcutGuide_small.png |
| powerToysShortcutGuideSettingImage | https://raw.githubusercontent.com/microsoft/PowerToys/main/doc/images/overview/ShortcutGuide_large.png |
| powertoyswiki | https://github.com/microsoft/PowerToys/wiki |
---
### Doc Devdocs Cli Conventions (`doc/devdocs/cli-conventions.md`)
# CLI Conventions
This document describes the conventions for implementing command-line interfaces (CLI) in PowerToys modules.
## PATH-Visible Command Naming and Location
- Name module CLI command shims `PowerToys..CLI.exe` (for example, `PowerToys.ImageResizer.CLI.exe`).
- Install these shims in the `bin` subfolder of the PowerToys installation directory, which the installer adds to `PATH`.
Every command is the same `PowerToys.CliShim.exe` payload (`tools/CliShim/`) installed under a different name. The shim resolves which CLI to launch from its own file name, forwards the raw argument tail unchanged, shares the caller's console, and returns the CLI's exit code. The CLI runs in a job object owned by the shim, so killing the shim kills the CLI with it; processes the CLI itself starts (the Settings window, for example) break away and survive.
On a per-machine install the `bin` folder is created with a protected DACL (`MachinePathFolderSddl` in `installer/PowerToysSetupVNext/Common.wxi`) so that a custom installation root cannot leave a machine-`PATH` folder writable by standard users. Author that `` on the same component as the folder's `` `PATH` entry, so the two cannot drift apart.
### Adding a new shim
1. Add a `` item to `tools/CliShim/CliShimManifest.props` with the command name and the target's path relative to `bin`. Write that path with `/` separators, and against the *installed* layout (see [Signing and Deployment](#signing-and-deployment)) - which is where the CLI ends up, not where it is built from.
2. Add the matching `` and `` to `installer/PowerToysSetupVNext/CliShims.wxs`, using the command name as the `File/@Name`.
`CliShim.vcxproj` fails the build if the command names in those two drift apart, `build-installer.ps1` fails the build if a `RelativeTarget` does not resolve to a real executable, and `CliShim.UnitTests` generates its expectations from the same manifest, so there is no third list to update.
### Shim exit codes
The shim returns the target CLI's exit code unchanged. It substitutes one of its own codes only when the CLI never ran, using values outside the range the CLIs use themselves:
| Code | Meaning |
| --- | --- |
| `9009` | No CLI is mapped to the invoked command name (matches `cmd.exe`'s "command not found"). |
| `9010` | The mapped target executable is missing from the installation. |
| `9011` | The shim could not start the target, including when it cannot resolve its own path. |
## Library
Use the **System.CommandLine** library for CLI argument parsing. The version is already defined in `Directory.Packages.props`:
```xml
```
Add the reference to your project:
```xml
```
## Option Naming and Definition
- Use `--kebab-case` for long form (e.g., `--shrink-only`).
- Use single `-x` for short form (e.g., `-s`, `-w`).
- Pass the long name first, then any aliases: `new Option("--silent", "-s")`.
- Create options using `Option` and set `Description` to descriptive help text.
- Add validators (`option.Validators.Add(...)`, reporting failures with `result.AddError(...)`) for options that require range or format checking.
## RootCommand Setup
- Create a `RootCommand` with a brief description.
- Add all options and arguments to the command (`rootCommand.Options.Add(...)`, `rootCommand.Arguments.Add(...)`).
- `RootCommand` includes the standard `--help` and `--version` options. Remove them from `rootCommand.Options` if the CLI renders its own help or reuses their aliases.
## Parsing
- Use `rootCommand.Parse(args)` to parse CLI arguments.
- Extract option values using `parseResult.GetValue(option)`.
- To run a handler, register it with `command.SetAction(parseResult => ...)` and call `parseResult.Invoke()` or `parseResult.InvokeAsync()`.
### Parse/Validation Errors
- On parse/validation errors, print error messages and usage, then exit with non-zero code.
## Examples
Reference implementations:
- Awake: `src/modules/Awake/Awake/Program.cs`
- ImageResizer: `src/modules/imageresizer/ui/Cli/`
## Help Output
- Provide a `PrintUsage()` method for custom help formatting if needed.
## Best Practices
1. **Consistency**: Follow existing module patterns.
2. **Documentation**: Always provide help text for each option.
3. **Validation**: Validate input and provide clear error messages.
4. **Atomicity**: Make one logical change per PR; avoid drive-by refactors.
5. **Build/Test Discipline**: Build and test synchronously, one terminal per operation.
6. **Style**: Follow repo analyzers (`.editorconfig`, StyleCop) and formatting rules.
## Logging Requirements
- Use `ManagedCommon.Logger` for consistent logging.
- Initialize logging early in `Main()`.
- Use dual output (console + log file) for errors and warnings to ensure visibility.
- Reference: `src/modules/imageresizer/ui/Cli/CliLogger.cs`
## Telemetry and Privacy Requirements
- Every module CLI must record usage telemetry through the existing PowerToys telemetry infrastructure, respecting the user's diagnostic data consent.
- Record a fixed, allowlisted command category and a success flag based on the final exit code. Do not collect raw arguments, file paths, monitor IDs, profile values, or other user-provided content.
- Telemetry failures must not change command output, exit codes, or exception behavior.
- Add every new CLI telemetry event to [DATA_AND_PRIVACY.md](../../DATA_AND_PRIVACY.md) in the same PR, describing its purpose and collected data.
- Follow [Telemetry Events](events.md) for event naming, privacy tags, and implementation details.
## Error Handling
### Exit Codes
- `0`: Success
- `1`: General error (parsing, validation, runtime)
- `2`: Invalid arguments (optional)
### Exception Handling
- Always wrap `Main()` in try-catch for unhandled exceptions.
- Log exceptions before exiting with non-zero code.
- Display user-friendly error messages to stderr.
- Preserve detailed stack traces in log files only.
## Testing Requirements
- Include tests for argument parsing, validation, and edge cases.
- Place CLI tests in module-specific test projects (e.g., `src/modules/[module]/tests/*CliTests.cs`).
## Signing and Deployment
- CLI executables are signed automatically in CI/CD.
- **New CLI tools**: Add your executable and dll to `.pipelines/ESRPSigning_core.json` in the signing list.
- CLI executables are deployed either to the installation root (e.g., `C:\Program Files\PowerToys\FancyZonesCLI.exe`) or, for WinUI 3 modules, next to their module in `WinUI3Apps\` (e.g., `C:\Program Files\PowerToys\WinUI3Apps\PowerToys.ImageResizerCLI.exe`). PATH-visible shims are deployed to `C:\Program Files\PowerToys\bin\`, and a shim's `RelativeTarget` is resolved from that `bin` folder against the *installed* layout - not against the source tree.
- Use self-contained deployment (import `Common.SelfContained.props`).
---
### Doc Devdocs Commands (`doc/devdocs/commands.md`)
# Issue/PR commands
The PowerToys repository uses some special keywords to help manage issues and pull requests. Here is a list of the most important commands you can use in issue and PR descriptions or comments.
| Command | Description |
|---------|-------------|
| `/azp run` | Triggers the Azure Pipelines CI build for the current PR. Useful if you want to re-run the build without creating a new commit. |
| `/bugreport` / `/reportbug` | Adds a comment with a manual for the Bug Report Tool, which helps users collect logs and system information for debugging purposes. It requests to upload this file and adds the `Needs-Author-Feedback` label. |
| `/feedbackhub` | Adds a comment with a link to the Feedback Hub app on Windows, where users can submit feedback about PowerToys. Closes the issue and adds the `Resolution-Please File on Feedback Hub` label. |
| `/dup #...` / `/duplicate #...` / `/dup https://...` / `/duplicate https://...` | Marks the current issue as a duplicate of another issue. It closes the current issue and applies the `Resolution-Duplicate` label. Replace `#...` with the issue number or a link to the issue. |
| `/needinfo` | Adds the `Needs-Author-Feedback` label to the issue or PR, indicating that more information is needed from the author. |
| `/helped` | Closes the issue and adds the `Resolution-Helped User` label. Furthermore a comment is added with a link to the PowerToys user documentation. |
| `/loc` | Adds a comment informing the user that the issue was forwarded to the localization team and will soon be fixed. It adds the `Loc-Sent To Team` label. |
## Defining new commands
Most of these commands are using the [Microsoft GitHub Policy Service](https://github.com/apps/microsoft-github-policy-service) bot. Its commands are defined in the [PowerToys policy configuration file](/.github/policies/resourceManagement.yml).
## Other automated tasks
### AI-assisted issue triage
New and updated issues are processed by a GitHub Agentic Workflow that combines
deterministic checks with a bounded GitHub Copilot pass. It maintains one
triage comment, adds a matching primary `Product-*` label and version label,
requests blocking author information, recommends updating older PowerToys
versions, surfaces likely duplicates, and analyzes a sanitized subset of
attached PowerToys diagnostic reports.
Duplicate closure is submitted as a native GitHub suggestion. A maintainer must
accept or decline it. Accepting the suggestion closes the issue as a duplicate
and links it to the selected canonical issue.
### The `Needs-Author-Feedback` label
If an issue or pull request retains this label without activity for 7 days, the
bot closes it. An author comment removes the label from issues and pull
requests, and an author push removes it from pull requests. Removing the label
manually also disables scheduled closure.
### Filtering users that want to contribute
If a user utters their intention to contribute (e.g., by using the phrase "I want to contribute" in an issue or PR), the bot will add a comment with a link to the ["Would you like to contribute to PowerToys?" thread](https://github.com/microsoft/PowerToys/issues/28769).
---
### Doc Devdocs Disk Usage Footprint (`doc/devdocs/disk-usage-footprint.md`)
# PowerToys disk usage footprint overview
As of the v0.66 of PowerToys, core runtime dlls are being shipped self-contained as a part of PowerToys. During the installation process, hard-links are being created for every module that needs any of these shared libraries.
## Why do this work?
Our main motivations for doing are the following:
1. Be able to install PowerToys without UAC elevation
2. PowerToys has a reduced disk space when components are shared.
3. Reduce additional downloads for dependencies
## Current self-contained runtimes
These dll's are installed in `/dll/` folder structure.
- [Windows Application SDK runtime](https://learn.microsoft.com/windows/apps/windows-app-sdk/downloads)
- [.NET Desktop Runtime 7](https://dotnet.microsoft.com/download/dotnet/7.0)
- [Microsoft Visual C++ Runtime](https://learn.microsoft.com/cpp/windows/latest-supported-vc-redist?view=msvc-170)
## So why does PowerToys have a larger footprint now?
Before the hard-link work was done, each of these runtimes had to be installed, so there were more items being installed outside just the PowerToys install directory. This space would not have been accounted.
File Explorer treats hard-links the same as "original"/regular files/directories (https://learn.microsoft.com/troubleshoot/windows-server/backup-and-storage/disk-space-problems-on-ntfs-volumes#other-ntfs-features-that-may-cause-file-allocation-confusion), not as links. This results in File Explorer reporting size of PowerToys installation directory bigger than it is (more than 2GB).
## How much space is actually being used
As of v0.66 of PowerToys, the installed footprint is ~660MB.
When we were prototyping and validating, here was our running table of results and why we took the route we did.
| Moment | Installer size | App size | Installation dir size | Real size | Deps downloaded and installed during PT install | Total (installer size + real size + deps downloaded and installed during PT install) |
|---|---|---|---|---|---|---|
| v0.62.0.1 no deps self-contained | 125 MB | 817 MB | 529 MB | 534 MB | 418 MB | 1,077 MB |
| v0.63.0 WAS and VCRedist | 83 MB | 587 MB | 567 MB | 396 MB | 394 MB | 873 MB |
| v0.63.0 WAS1.2preview and VCRedist| 80 MB | 574 MB | 539 MB | 385 MB | 394 MB | 859 MB |
| Full Test WAS, VCRedist, .NET | 149 MB | 705 MB | 1,760 MB | 557 MB | 0 MB | 706 MB |
## Our process to verify current install footprint
We created a quick virtual machine. We chose to use our fresh Windows 10 test virtual machines here.
### Empty disk details
### Install PowerToys to empty disk
### PowerToys installation directory size shown by File Explorer
As mentioned above, File Explorer shows size of PowerToys installation dir as every hard-link is a regular file for itself
### PowerToys size shown by App->Installed apps
### Disk usage with PowerToys installed
Real disk usage of PowerToys is shown by inspecting disk usage after installing PowerToys. Used space is now 695MB, comparing to ~35MB used space for empty disk gives us the size of ~660MB for PowerToys installation dir.
### PowerShell command calculating size of non-hardlinks files
Size of regular files (non-hard-links) and hard-links can also be obtained by running following PowerShell command in PowerToys installation dir:
```
Regular files:
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -ne HardLink | Measure-Object -Property Length -Sum
Hard-links
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -e HardLink | Measure-Object -Property Length -Sum
```
Running these commands for PowerToys v0.66 shows that size of regular files is way less than size of hard-links pointing to some of those regular files because PowerShell (same as File Explorer) also takes the size of hard-links as of regular files.
---
### Doc Devdocs Embedded Msix (`doc/devdocs/embedded-msix.md`)
# How to integrate new MSIX module with PowerToys Settings and WiX installer
[`issue_11705_with_example` branch](https://github.com/microsoft/PowerToys/tree/issue_11705_with_example) contains HelloWorld UWP C# MSIX application which reads its module settings and is installed along PowerToys.
## Steps
- uncomment everything near "TODO: Use to activate embedded MSIX" comments
- build PowerToys solution
- deploy HelloModule module and sign it with a self-signed certificate (don't forget to put it into a trusted store)
- build PowerToysSetup solution and install it
Type HelloModule into start search and observe that it was installed:
Open PowerToys settings and change the stub setting to something:
Open HelloModule:
First time you press "Load Settings", it'll detect that it doesn't have permissions to access local file system and open its system settings window, toggle it there:
(it's a known uwp limitation, see https://stackoverflow.com/a/53533414/657390)
HelloModule will close then, restart it, press "Load Settings" and you should see that the application was able to load the setting string which was set by the settings app:
---
### Doc Devdocs Events (`doc/devdocs/events.md`)
# Telemetry Events
PowerToys collects limited telemetry to understand feature usage, reliability, and product quality. When adding a new telemetry event, follow the steps below to ensure the event is properly declared, documented, and available after release.
**⚠️ Important**: Telemetry must never include personal information, file paths, or user‑generated content.
## Developer Effort Overview (What to Expect)
Adding a telemetry event is a **multi-step process** that typically spans several areas of the codebase and documentation.
At a high level, developers should expect to:
1. Within one PR:
1. Add a new telemetry event(s) to module
1. Add the new event(s) DATA_AND_PRIVACY.md
1. Reach out to @carlos-zamora or @chatasweetie so internal scripts can process new event(s)
### Privacy Guidelines
**NEVER** log:
- User data (text, files, emails, etc.)
- File paths or filenames
- Personal information
- Sensitive system information
- Anything that could identify a specific user
DO log:
- Feature usage (which features, how often)
- Success/failure status
- Timing/performance metrics
- Error types (not error messages with user data)
- Aggregate counts
### Event Naming Convention
Follow this pattern: `UtilityName_EventDescription`
Examples:
- `ColorPicker_Session`
- `FancyZones_LayoutApplied`
- `PowerRename_Rename`
- `AdvancedPaste_FormatClicked`
- `CmdPal_ExtensionInvoked`
## Adding Telemetry Events to PowerToys
PowerToys uses ETW (Event Tracing for Windows) for telemetry in both C++ and C# modules. The telemetry system is:
- Opt-in by default (disabled since v0.86)
- Privacy-focused - never logs personal info, file paths, or user-generated content
- Controlled by registry - HKEY_CURRENT_USER\Software\Classes\PowerToys\AllowDataDiagnostics
### C++ Telemetry Implementation
**Core Components**
| File | Purpose |
| ------------- |:-------------:|
| [ProjectTelemetry.h](../../src/common/Telemetry/ProjectTelemetry.h) | Declares the global ETW provider g_hProvider |
| [TraceBase.h](../../src/common/Telemetry/TraceBase.h) | Base class with RegisterProvider(), UnregisterProvider(), and IsDataDiagnosticsEnabled() check |
| [TraceLoggingDefines.h](../../src/common/Telemetry/TraceLoggingDefines.h) | Privacy tags and telemetry option group macros
#### Pattern for C++ Modules
1. Create a `Trace` class inheriting from `telemetry::TraceBase` (src/common/Telemetry/TraceBase.h):
```c
// trace.h
#pragma once
#include
class Trace : public telemetry::TraceBase
{
public:
static void MyEvent(/* parameters */);
};
```
2. Implement events using `TraceLoggingWriteWrapper`:
```cpp
// trace.cpp
#include "trace.h"
#include
TRACELOGGING_DEFINE_PROVIDER(
g_hProvider,
"Microsoft.PowerToys",
(0x38e8889b, 0x9731, 0x53f5, 0xe9, 0x01, 0xe8, 0xa7, 0xc1, 0x75, 0x30, 0x74),
TraceLoggingOptionProjectTelemetry());
void Trace::MyEvent(bool enabled)
{
TraceLoggingWriteWrapper(
g_hProvider,
"ModuleName_EventName", // Event name
TraceLoggingBoolean(enabled, "Enabled"), // Event data
ProjectTelemetryPrivacyDataTag(ProjectTelemetryTag_ProductAndServicePerformance),
TraceLoggingBoolean(TRUE, "UTCReplace_AppSessionGuid"),
TraceLoggingKeyword(PROJECT_KEYWORD_MEASURE));
}
```
**Key C++ Telemetry Macros**
| Macro | Purpose |
| ------------- |:-------------:|
| `TraceLoggingWriteWrapper` [CustomAction.cpp](../../installer/PowerToysSetupCustomActionsVNext/CustomAction.cpp) | Wraps `TraceLoggingWrite` with `IsDataDiagnosticsEnabled()` check |
| `ProjectTelemetryPrivacyDataTag(tag)` [TraceLoggingDefines.h](../../src/common/Telemetry/TraceLoggingDefines.h) | Sets privacy classification |
### C# Telemetry Implementation
**Core Components**
| File | Purpose |
| ------------- |:-------------:|
| [PowerToysTelemetry.cs](../../src/common/ManagedTelemetry/Telemetry/PowerToysTelemetry.cs) | Singleton `Log` instance with `WriteEvent()` method |
| [EventBase.cs](../../src/common/ManagedTelemetry/Telemetry/Events/EventBase.cs) | Base class for all events (provides `EventName`, `Version`) |
| [IEvent.cs](../../src/common/ManagedTelemetry/Telemetry/Events/IEvent.cs) | Interface requiring `PartA_PrivTags` property |
| [TelemetryBase.cs](../../src/common/Telemetry/TelemetryBase.cs) | Inherits from `EventSource`, defines ETW constants |
| [DataDiagnosticsSettings.cs](../../src/common/ManagedTelemetry/Telemetry/DataDiagnosticsSettings.cs) | Registry-based enable/disable check
#### Pattern for C# Modules
1. Create an event class inheriting from `EventBase` and implementing `IEvent`:
```csharp
using System.Diagnostics.CodeAnalysis;
using System.Diagnostics.Tracing;
using Microsoft.PowerToys.Telemetry;
using Microsoft.PowerToys.Telemetry.Events;
namespace MyModule.Telemetry
{
[EventData]
[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicProperties)]
public class MyModuleEvent : EventBase, IEvent
{
// Event properties (logged as telemetry data)
public string SomeProperty { get; set; }
public int SomeValue { get; set; }
// Required: Privacy tag
public PartA_PrivTags PartA_PrivTags => PartA_PrivTags.ProductAndServiceUsage;
// Optional: Set EventName in constructor (defaults to class name)
public MyModuleEvent(string prop, int val)
{
EventName = "MyModule_EventName";
SomeProperty = prop;
SomeValue = val;
}
}
}
```
2. Log the event:
```csharp
PowerToysTelemetry.Log.WriteEvent(new MyModuleEvent("value", 42));
```
**Privacy Tags (C#)**
| Tag | Use Case |
| ------------- |:-------------:|
| `PartA_PrivTags.ProductAndServiceUsage` [TelemetryBase.cs](../../src/common/Telemetry/TelemetryBase.cs) | Feature usage events
| `PartA_PrivTags.ProductAndServicePerformance` [TelemetryBase.cs](../../src/common/Telemetry/TelemetryBase.cs) | Performance/timing events
### Update DATA_AND_PRIVACY.md file
Add your new event(s) to [DATA_AND_PRIVACY.md](../../DATA_AND_PRIVACY.md).
## Launch Product Version Containing the new events
Events do not become active until they ship in a released PowerToys version. After your PRs are merged:
- The event will begin firing once users install the version that includes it
- In order for PowerToys to process these events, you must complete the next section
## Next Steps
Reach out to @carlos-zamora or @chatasweetie so internal scripts can process new event(s).
## Summary
Required steps:
1. In one PR:
- Add the event(s) in code
- Document event(s) in DATA_AND_PRIVACY.md
1. Ship the change in a PowerToys release
1. Reach out for next steps
---
### Doc Devdocs Guidance (`doc/devdocs/guidance.md`)
# Coding Guidance
## Working With Strings
In order to support localization **YOU SHOULD NOT** have hardcoded UI display strings in your code. Instead, use resource files to consume strings.
### For CPP
Use [`StringTable` resource][String Table] to store the strings and resource header file(`resource.h`) to store Id's linked to the UI display string. Add the strings with Id's referenced from the header file to the resource-definition script file. You can use [Visual Studio Resource Editor][VS Resource Editor] to create and manage resource files.
- `resource.h`:
XXX must be a unique int in the list (mostly the int ID of the last string id plus one):
```cpp
#define IDS_MODULE_DISPLAYNAME XXX
```
- `StringTable` in resource-definition script file `validmodulename.rc`:
```
STRINGTABLE
BEGIN
IDS_MODULE_DISPLAYNAME L"Module Name"
END
```
- Use the `GET_RESOURCE_STRING(UINT resource_id)` method to consume strings in your code.
```cpp
#include
std::wstring GET_RESOURCE_STRING(IDS_MODULE_DISPLAYNAME)
```
### For C#
Use [XML resource file(.resx)][Resx Files] to store the UI display strings and [`Resource Manager`][Resource Manager] to consume those strings in the code. You can use [Visual Studio][Resx Files VS] to create and manage XML resources files.
- `Resources.resx`
```xml
Description to be displayed on UI.This text is displayed when XYZ button clicked.
```
- Use [`Resource Manager`][Resource Manager] to consume strings in code.
```csharp
System.Resources.ResourceManager manager = new System.Resources.ResourceManager(baseName, assembly);
string validUIDisplayString = manager.GetString("ValidUIDisplayString", resourceCulture);
```
In case of Visual Studio is used to create the resource file. Simply use the `Resources` class in auto-generated `Resources.Designer.cs` file to access the strings which encapsulate the [`Resource Manager`][Resource Manager] logic.
```csharp
string validUIDisplayString = Resources.ValidUIDisplayString;
```
## More On Coding Guidance
Please review these brief docs below relating to our coding standards, etc.
* [Coding Style](development/style.md)
* [Code Organization](readme.md)
[VS Resource Editor]: https://learn.microsoft.com/cpp/windows/resource-editors?view=vs-2019
[String Table]: https://learn.microsoft.com/windows/win32/menurc/stringtable-resource
[Resx Files VS]: https://learn.microsoft.com/dotnet/framework/resources/creating-resource-files-for-desktop-apps#resource-files-in-visual-studio
[Resx Files]: https://learn.microsoft.com/dotnet/framework/resources/creating-resource-files-for-desktop-apps#resources-in-resx-files
[Resource Manager]: https://learn.microsoft.com/dotnet/api/system.resources.resourcemanager?view=netframework-4.8
---
### Doc Devdocs Logging (`doc/devdocs/logging.md`)
# Logging
Logging plays an important part in determining bugs in our code. It provides context for the developers about where and when errors occur.
## Where are the logs saved
* Most of the logs are saved under `%LOCALAPPDATA%/Microsoft/PowerToys`.
* For low-privilege processes (like preview handlers) the logs are saved under `%USERPROFILE%/AppData/LocalLow/Microsoft/PowerToys`.
Logs are normally in a subfolder with the module name as title.
The [BugReportTool](/tools/BugReportTool) will take logs from both locations when executed.
## Using a logger in a project
### Spdlog
In C++ projects we use the awesome [spdlog](https://github.com/gabime/spdlog) library for logging as a git submodule under the `deps` directory. To use it in your project, just include [spdlog.props](/deps/spdlog.props) in a .vcxproj like this:
```xml
```
It'll add the required include dirs and link the library binary itself.
### PowerToys Logger in ManagedCommon
For C# projects there is a static logger class in Managed Common called `Logger`.
To use it, add a project reference to `ManagedCommon` and add the following line of code to all the files using the logger:
```Csharp
using ManagedCommon;
```
In the `Main` function (or a function with a similar meaning (like `App` in a `App.xaml.cs` file)) you have to call `InitializeLogger` and specify the location where the logs will be saved (always use a path scheme similar to this example):
```Csharp
Logger.InitializeLogger("\\FancyZones\\Editor\\Logs");
```
For a low-privilege process you have to set the optional second parameter to `true`:
```Csharp
Logger.InitializeLogger("\\FileExplorer\\Monaco\\Logs", true);
```
The `Logger` class contains the following logging functions:
```Csharp
// Logs an error that the utility encountered
Logger.LogError(string message);
Logger.LogError(string message, Exception ex);
// Logs an error that isn't that grave
Logger.LogWarning(string message);
// Logs what the app is doing at the moment
Logger.LogInfo(string message);
// Like LogInfo just with infos important for debugging
Logger.LogDebug(string message);
// Logs the current state of the utility.
Logger.LogTrace();
```
---
### Doc Devdocs Run As Admin Detection (`doc/devdocs/run-as-admin-detection.md`)
# This file has been moved
[PowerToys and running as Administrator](https://aka.ms/powertoysDetectedElevatedHelp)
---
### Doc Devdocs Watson Queries (`doc/devdocs/watson-queries.md`)
# Watson queries [msft only]
## Catch all
- [Catch all](https://watsonportal.microsoft.com/CabSearch?=&DateTimeFormat=UTC&MaxRows=1000&AppScope_AppVersion=0.100.2.0&Process=*powertoys*)
> [!NOTE]
> Update the `AppScope_AppVersion` (and the installer file names below) to the current release version when triaging.
## EXE name
- [Machine installer (x64)](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppName=PowerToysSetup-0.100.2-x64.exe)
- [Machine installer (arm64)](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppName=PowerToysSetup-0.100.2-arm64.exe)
- [User installer (x64)](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppName=PowerToysUserSetup-0.100.2-x64.exe)
- [User installer (arm64)](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppName=PowerToysUserSetup-0.100.2-arm64.exe)
- [Main exe](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppVersion=0.100.2&AppScope_AppName=PowerToys.exe)
- [PT Run / example](https://watsonportal.microsoft.com/Application?DateRange=Last%2014%20Days&MaxRows=100&AppScope_AppVersion=0.100.2&AppScope_AppName=PowerToys.PowerLauncher.exe)
## DLL based
- [KBM](https://watsonportal.microsoft.com/Failure/ModuleSearch?AppScope_AppVersion=0.100.2.0&FailureSearchText=keyboardmanager.dll)
- [Power Preview](https://watsonportal.microsoft.com/Failure/ModuleSearch?AppScope_AppVersion=0.100.2.0&FailureSearchText=powerpreview.dll)
- [SVG Thumbnail](https://watsonportal.microsoft.com/Failure/ModuleSearch?AppScope_AppVersion=0.100.2.0&FailureSearchText=SvgThumbnailProvider.dll)
- [SVG Preview Pane](https://watsonportal.microsoft.com/Failure/ModuleSearch?AppScope_AppVersion=0.100.2.0&FailureSearchText=SvgPreviewHandler.dll)
- [Markdown Preview Pane](https://watsonportal.microsoft.com/Failure/ModuleSearch?AppScope_AppVersion=0.100.2.0&FailureSearchText=MarkdownPreviewHandler.dll)
---
### Doc Dsc Profile Resource (`doc/dsc/profile-resource.md`)
---
description: Reference for the PowerToys Keyboard Manager profile DSC resource
ms.date: 07/20/2026
ms.topic: reference
title: Keyboard Manager Profile Resource
---
# Keyboard Manager Profile Resource
## Synopsis
Manages the Keyboard Manager remapping profile — key remappings and shortcut
remappings — declaratively through DSC v3.
## Description
The `profile` resource deploys Keyboard Manager key and shortcut remappings.
While the [`settings` resource][01] manages a module's settings (for
KeyboardManager: the enabled state and editor options), the `profile`
resource manages the remapping profile itself, which Keyboard Manager stores
separately from its settings.
Keys are written with friendly names instead of virtual-key codes, so
configurations are easy to author and review:
```yaml
profile:
keys:
- { from: CapsLock, to: Esc }
shortcuts:
- { from: "Ctrl+Shift+A", to: "Ctrl+V" }
```
The only supported module is `KeyboardManager`. The DSC resource type is
`Microsoft.PowerToys/KeyboardManagerProfile`.
> **Important — replace semantics:** Applying the resource replaces the
> **whole** remapping profile with the declared state. Remappings created in
> the Keyboard Manager editor that are not part of the configuration are
> removed. Use `export` to capture the current remappings before switching a
> machine to declarative management.
When the profile is applied while PowerToys is running, the Keyboard Manager
engine reloads it immediately; otherwise the profile takes effect the next
time PowerToys starts. Note that the remappings are only active when the
Keyboard Manager utility is enabled (see the [KeyboardManager module][02]).
## Profile schema
The `profile` object is required and has two entry lists. An empty profile
(`profile: {}`) removes every remapping:
### `keys[]` — single-key remappings
| Property | Type | Required | Description |
| -------- | ------ | -------- | -------------------------------------------------------- |
| `from` | string | yes | The key being remapped, e.g. `CapsLock`. |
| `to` | string | one of | Target key or shortcut, e.g. `Esc`, `Ctrl+C`, `Disable`. |
| `toText` | string | one of | Text to type instead of the key. |
Exactly one of `to` or `toText` must be set.
### `shortcuts[]` — shortcut remappings
| Property | Type | Required | Description |
| ------------ | ------- | -------- | ----------------------------------------------------------------------- |
| `from` | string | yes | The shortcut being remapped, e.g. `Ctrl+Shift+A` or `Win+O, K` (chord). |
| `to` | string | one of | Target key or shortcut. |
| `toText` | string | one of | Text to type instead of the shortcut. |
| `runProgram` | object | one of | Program to start (see below). |
| `openUri` | string | one of | URI to open, e.g. `https://github.com` or `ms-settings:`. |
| `targetApp` | string | no | Process name the remap applies to, e.g. `notepad.exe`. Omit for global. |
| `exactMatch` | boolean | no | Only trigger when no other keys are pressed. Default `false`. |
Exactly one of `to`, `toText`, `runProgram`, or `openUri` must be set. A
shortcut `from` requires at least one modifier plus one action key, and may
add a chord second key after a comma (`"Win+O, K"`). `Win+L` and
`Ctrl+Alt+Delete` are handled by Windows before any application and are
rejected, as in the Keyboard Manager editor.
### `runProgram` object
| Property | Type | Required | Description |
| ------------- | ------ | -------- | ------------------------------------------------------------------------------------------- |
| `filePath` | string | yes | Program path; environment variables are expanded. |
| `args` | string | no | Command-line arguments. |
| `startInDir` | string | no | Working directory. |
| `elevation` | string | no | `normal` (default), `elevated`, or `differentUser`. |
| `ifRunning` | string | no | `showWindow` (default), `startAnother`, `doNothing`, `close`, `endTask`, `closeAndEndTask`. |
| `windowStyle` | string | no | `normal` (default), `hidden`, `minimized`, `maximized`. |
## Key names
Key names are case-insensitive and independent of the active keyboard
layout. Shortcut parts are joined with `+`; a chord second key follows after
a comma.
| Category | Names |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Letters/digits | `A`–`Z`, `0`–`9` |
| Function | `F1`–`F24` |
| Modifiers | `Ctrl`, `Alt`, `Shift`, `Win` (either side); `LCtrl`, `RCtrl`, `LAlt`, `RAlt`, `LShift`, `RShift`, `LWin`, `RWin` |
| Navigation | `Esc`, `Tab`, `CapsLock`, `Space`, `Enter`, `Backspace`, `Insert`, `Delete`, `Home`, `End`, `PgUp`, `PgDn`, `Up`, `Down`, `Left`, `Right`, `PrintScreen`, `ScrollLock`, `Pause`, `NumLock`, `Apps`, `Break`, `Clear`, `Sleep` |
| Numpad | `NumPad0`–`NumPad9`, `NumPadMultiply`, `NumPadAdd`, `NumPadSeparator`, `NumPadSubtract`, `NumPadDecimal`, `NumPadDivide`; numpad-origin variants: `NumPadEnter`, `NumPadHome`, `NumPadEnd`, `NumPadPgUp`, `NumPadPgDn`, `NumPadInsert`, `NumPadDelete`, `NumPadUp`, `NumPadDown`, `NumPadLeft`, `NumPadRight`, `NumPadSlash` |
| Punctuation | `Semicolon` (`;`), `Equals` (`=`), `Comma` (`,`), `Minus` (`-`), `Period` (`.`), `Slash` (`/`), `Backquote` (`` ` ``), `LBracket` (`[`), `Backslash` (`\`), `RBracket` (`]`), `Quote` (`'`), `OEM102` |
| Media/browser | `VolumeMute`, `VolumeDown`, `VolumeUp`, `MediaNext`, `MediaPrev`, `MediaStop`, `MediaPlayPause`, `BrowserBack`, `BrowserForward`, `BrowserRefresh`, `BrowserStop`, `BrowserSearch`, `BrowserFavorites`, `BrowserHome`, `LaunchMail`, `LaunchMediaSelect`, `LaunchApp1`, `LaunchApp2` |
| Special | `Disable` (disables the key or shortcut), `VK` or `0x` for any other virtual-key code |
> **Note:** Punctuation names refer to the key's physical position on a US
> layout (`Semicolon` is the `VK_OEM_1` key), so profiles behave identically
> regardless of the machine's keyboard layout.
## Common operations
```powershell
# Get or export the current remapping profile
PowerToys.DSC.exe get --resource 'profile' --module KeyboardManager
PowerToys.DSC.exe export --resource 'profile' --module KeyboardManager
# Apply a remapping profile
$input = '{"profile":{"keys":[{"from":"CapsLock","to":"Esc"}]}}'
PowerToys.DSC.exe set --resource 'profile' --module KeyboardManager --input $input
# Test whether the current remappings match the desired state
PowerToys.DSC.exe test --resource 'profile' --module KeyboardManager --input $input
# Get the JSON schema of the resource
PowerToys.DSC.exe schema --resource 'profile' --module KeyboardManager
```
## Examples
### Example 1 - Deploy remappings with DSC
```bash
dsc config set --file keyboardmanager-profile.dsc.yaml
```
```yaml
# keyboardmanager-profile.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Deploy key remappings
type: Microsoft.PowerToys/KeyboardManagerProfile
properties:
profile:
keys:
- { from: CapsLock, to: Esc }
- { from: Insert, to: Disable }
- { from: F2, toText: "you@example.com" }
shortcuts:
- { from: "Ctrl+Shift+A", to: "Ctrl+V" }
- { from: "Win+O, K", toText: "chord-triggered text" }
- { from: "Ctrl+Alt+N", to: "Ctrl+S", targetApp: "notepad.exe", exactMatch: true }
- from: "Ctrl+Alt+T"
runProgram:
filePath: "%WINDIR%\\System32\\cmd.exe"
args: "/k echo hello"
- { from: "Ctrl+Alt+B", openUri: "https://github.com/microsoft/PowerToys" }
```
### Example 2 - Install PowerToys and deploy remappings with WinGet
```bash
winget configure winget-kbm-profile.yaml
```
```yaml
# winget-kbm-profile.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
winget:
processor: dscv3
resources:
- name: Install PowerToys
type: Microsoft.WinGet.DSC/WinGetPackage
properties:
id: Microsoft.PowerToys
source: winget
- name: Enable Keyboard Manager
type: Microsoft.PowerToys/KeyboardManagerSettings
properties:
settings:
properties:
Enabled: true
name: KeyboardManager
version: 1.0
- name: Deploy key remappings
type: Microsoft.PowerToys/KeyboardManagerProfile
properties:
profile:
keys:
- { from: CapsLock, to: LCtrl }
shortcuts:
- { from: "Ctrl+Shift+V", toText: "Best regards,\nContoso IT" }
```
### Example 3 - Capture existing remappings
Export the current remappings on a reference machine, then reuse them in a
configuration document:
```powershell
PowerToys.DSC.exe export --resource 'profile' --module KeyboardManager
# {"profile":{"keys":[{"from":"CapsLock","to":"Esc"}],"shortcuts":[]}}
```
## See also
- [KeyboardManager Module][02]
- [Settings Resource Reference][01]
- [PowerToys DSC Overview][03]
[01]: ./settings-resource.md
[02]: ./modules/KeyboardManager.md
[03]: ./overview.md
---
### Doc Dsc Settings Resource (`doc/dsc/settings-resource.md`)
---
description: Reference for the PowerToys DSC settings resource
ms.date: 10/18/2025
ms.topic: reference
title: Settings Resource
---
# Settings Resource
## Synopsis
Manages configuration settings for PowerToys utilities (modules).
## Description
The `settings` resource provides Microsoft Desired State Configuration (DSC)
support for managing PowerToys configuration. It enables declarative
configuration of PowerToys utilities, allowing you to define, test, and
enforce desired states for each module.
Each PowerToys utility (module) has its own configurable properties that can
be managed through this resource. The settings resource supports standard DSC
operations: get, set, test, export, schema, and manifest generation.
## Supported modules
The settings resource supports the following PowerToys modules:
- **App** - General application settings (enable/disable utilities, run at
startup, theme, etc.).
- **AdvancedPaste** - Advanced clipboard and paste operations.
- **AlwaysOnTop** - Window pinning configuration.
- **Awake** - Keep-awake timer settings.
- **ColorPicker** - Color picker activation and format settings.
- **CropAndLock** - Window cropping settings.
- **EnvironmentVariables** - Environment variable editor settings.
- **FancyZones** - Window layout and zone configuration.
- **FileLocksmith** - File lock detection settings.
- **FindMyMouse** - Mouse locator settings.
- **Hosts** - Hosts file editor settings.
- **ImageResizer** - Image resize configuration.
- **KeyboardManager** - Key remapping and shortcut settings.
- **MeasureTool** - Screen measurement tool settings.
- **MouseButtonLock** - Hands-free mouse button drag-lock settings.
- **MouseHighlighter** - Mouse highlighting configuration.
- **MouseJump** - Mouse jump navigation settings.
- **MousePointerCrosshairs** - Crosshair display settings.
- **Peek** - File preview settings.
- **PowerAccent** - Accent character selection settings.
- **PowerOCR** - Text extraction settings.
- **PowerRename** - Bulk rename configuration.
- **RegistryPreview** - Registry file preview settings.
- **ShortcutGuide** - Keyboard shortcut overlay settings.
- **Workspaces** - Application workspace settings.
- **ZoomIt** - Screen zoom and annotation settings.
For detailed property information for each module, see the individual [module
documentation][01].
## Operations
### List supported modules
List all modules that can be configured with the settings resource.
**Direct execution:**
```powershell
# List all configurable modules.
PowerToys.DSC.exe modules --resource 'settings'
```
### Get current state
Retrieve the current configuration state for a module.
**Direct execution:**
```powershell
# Get current settings for a module.
PowerToys.DSC.exe get --resource 'settings' --module
```
**DSC configuration:**
```yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Get Awake settings
type: Microsoft.PowerToys/AwakeSettings
properties: {}
```
**WinGet configuration:**
```yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
winget:
processor: dscv3
resources:
- name: Get FancyZones settings
type: Microsoft.PowerToys/FancyZonesSettings
properties: {}
```
### Export current state
Export the current configuration state. The output is identical to the `get`
operation.
**Direct execution:**
```powershell
# Export current settings for a module.
PowerToys.DSC.exe export --resource 'settings' --module
```
### Set desired state
Apply a configuration to a module, updating only the properties that differ
from the desired state.
**Direct execution:**
```powershell
# Set desired configuration for a module.
$input = '{
"settings": {
"properties": {
"keepDisplayOn": true,
"mode": 1
},
"name": "Awake",
"version": "0.0.1"
}
}'
PowerToys.DSC.exe set --resource 'settings' --module Awake --input $input
```
**DSC configuration:**
```yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Configure Awake
type: Microsoft.PowerToys/AwakeSettings
properties:
settings:
properties:
keepDisplayOn: true
mode: 1
name: Awake
version: 0.0.1
```
**WinGet configuration:**
```yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
winget:
processor: dscv3
resources:
- name: Install and configure PowerToys
type: Microsoft.WinGet.DSC/WinGetPackage
properties:
id: Microsoft.PowerToys
source: winget
- name: Configure FancyZones
type: Microsoft.PowerToys/FancyZonesSettings
properties:
settings:
properties:
fancyzones_shiftDrag: true
fancyzones_mouseSwitch: true
fancyzones_displayOrWorkAreaChange_moveWindows: true
name: FancyZones
version: 1.0
```
### Test desired state
Verify whether the current configuration matches the desired state.
**Direct execution:**
```powershell
# Test if current state matches desired state.
$input = '{
"settings": {
"properties": {
"keepDisplayOn": true,
"mode": 1
},
"name": "Awake",
"version": "0.0.1"
}
}'
PowerToys.DSC.exe test --resource 'settings' --module Awake --input $input
```
The output includes an `_inDesiredState` property indicating whether the
configuration matches (`true`) or differs (`false`).
**DSC configuration:**
```yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Test Awake configuration
type: Microsoft.PowerToys/AwakeSettings
properties:
settings:
properties:
keepDisplayOn: true
mode: 1
name: Awake
version: 0.0.1
```
### Get schema
Generate the JSON schema for a module's settings, describing all configurable
properties and their types.
**Direct execution:**
```powershell
# Get JSON schema for a module.
PowerToys.DSC.exe schema --resource 'settings' --module Awake
# Format for readability.
PowerToys.DSC.exe schema --resource 'settings' --module Awake `
| ConvertFrom-Json | ConvertTo-Json -Depth 10
```
### Generate manifest
Create a DSC resource manifest file for one or all modules.
**Direct execution:**
```powershell
# Generate manifest for a specific module.
$outputDir = "C:\manifests"
PowerToys.DSC.exe manifest --resource 'settings' --module Awake `
--outputDir $outputDir
# Generate manifests for all modules.
PowerToys.DSC.exe manifest --resource 'settings' --outputDir $outputDir
# Print manifest to console (omit --outputDir).
PowerToys.DSC.exe manifest --resource 'settings' --module Awake
```
## Examples
### Example 1 - Enable and configure FancyZones
This example enables FancyZones and configures window dragging behavior using
direct execution.
```powershell
# Get current FancyZones settings.
$current = PowerToys.DSC.exe get --resource 'settings' --module FancyZones `
| ConvertFrom-Json
# Modify settings.
$desired = @{
settings = @{
properties = @{
fancyzones_shiftDrag = $true
fancyzones_mouseSwitch = $true
fancyzones_displayOrWorkAreaChange_moveWindows = $true
}
name = "FancyZones"
version = "1.0"
}
} | ConvertTo-Json -Depth 10 -Compress
# Apply configuration.
PowerToys.DSC.exe set --resource 'settings' --module FancyZones `
--input $desired
```
### Example 2 - Configure multiple utilities with DSC
This example configures multiple PowerToys utilities in a single DSC
configuration.
```yaml
# powertoys-multi.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Enable PowerToys utilities
type: Microsoft.PowerToys/AppSettings
properties:
settings:
properties:
Enabled:
Awake: true
FancyZones: true
PowerRename: true
ColorPicker: true
name: App
version: 1.0
- name: Configure Awake
type: Microsoft.PowerToys/AwakeSettings
properties:
settings:
properties:
keepDisplayOn: true
mode: 1
name: Awake
version: 0.0.1
- name: Configure ColorPicker
type: Microsoft.PowerToys/ColorPickerSettings
properties:
settings:
properties:
changecursor: true
copiedcolorrepresentation: "HEX"
name: ColorPicker
version: 1.0
```
### Example 3 - Install and configure with WinGet
This example installs PowerToys and applies configuration using WinGet.
```yaml
# winget-powertoys-setup.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
winget:
processor: dscv3
resources:
- name: Install PowerToys
type: Microsoft.WinGet.DSC/WinGetPackage
properties:
id: Microsoft.PowerToys
source: winget
ensure: Present
- name: Configure general settings
type: Microsoft.PowerToys/AppSettings
properties:
settings:
properties:
run_elevated: true
startup: true
theme: "dark"
name: App
version: 1.0
- name: Configure FancyZones
type: Microsoft.PowerToys/FancyZonesSettings
properties:
settings:
properties:
fancyzones_shiftDrag: true
fancyzones_zoneSetChange_moveWindows: true
name: FancyZones
version: 1.0
- name: Configure ImageResizer
type: Microsoft.PowerToys/ImageResizerSettings
properties:
settings:
properties:
ImageResizerSizes:
- Name: Small
Width: 854
Height: 480
Unit: Pixel
Fit: Fit
- Name: Medium
Width: 1920
Height: 1080
Unit: Pixel
Fit: Fit
name: ImageResizer
version: 1.0
```
Apply the configuration:
```powershell
winget configure winget-powertoys-setup.yaml
```
### Example 4 - Test configuration drift
This example tests whether the current configuration matches the desired
state.
```powershell
# Define desired state.
$desired = @{
settings = @{
properties = @{
keepDisplayOn = $true
mode = 1
}
name = "Awake"
version = "0.0.1"
}
} | ConvertTo-Json -Depth 10 -Compress
# Test for drift.
$result = PowerToys.DSC.exe test --resource 'settings' --module Awake `
--input $desired | ConvertFrom-Json
if ($result._inDesiredState) {
Write-Host "Configuration is in desired state"
} else {
Write-Host "Configuration has drifted from desired state"
# Apply configuration.
PowerToys.DSC.exe set --resource 'settings' --module Awake `
--input $desired
}
```
### Example 5 - Export all module configurations
This example exports configuration for all modules.
```powershell
# Get list of all modules.
$modules = PowerToys.DSC.exe modules --resource 'settings'
# Export each module's configuration.
$configurations = @{}
foreach ($module in $modules) {
$config = PowerToys.DSC.exe export --resource 'settings' `
--module $module | ConvertFrom-Json
$configurations[$module] = $config
}
# Save to file.
$configurations | ConvertTo-Json -Depth 10 `
| Out-File "powertoys-backup.json"
```
## See also
- [PowerToys DSC Overview][02]
- [Module Documentation][01]
- [WinGet Configuration][03]
[01]: ./modules/
[02]: ./overview.md
[03]: https://learn.microsoft.com/windows/package-manager/configuration/
---
### Doc Specs FancyZones DCR (`doc/specs/FancyZones-DCR.md`)
### FancyZones library brief overview
---
1. `Zone` - Class which is basically wrapper around rectangle structure, representing one zone inside applied zone layout. ZoneSet is holding array of these which represent zone layout.
2. `ZoneSet` - Class implementing actual zone layout applied. What this means is that ZoneSet is responsible for actual calculation of rectangle coordinates (whether is grid or canvas layout) and moving window through them. WorkArea holds ZoneSet structure which represents currently active zone set.
3. `WorkArea` - Class representing work area, which is defined by monitor and current virtual desktop. For an example, if You have two monitors connected and two virtual desktops, You have 4 work areas available, and each of them can have separate zone layout. WorkArea is describing single work area. As mentioned before it holds active ZoneSet.
4. `FancyZones` - Top level entity and entry point for all user actions (which goes through actual module interface). Some of the main responsibilities of FancyZones class:
1. Starting FancyZones Editor (C#) with appropriate command line arguments on user request.
2. Keeping track of WorkArea per monitor (currently active work area on each connected monitor).
3. Keeping track of active virtual desktops. This is performed in separate thread by polling VirtualDesktopIDs registry key and parsing its content.
4. Detecting every change in work environment, such as creating / destroying / switching between virtual desktops, closing FancyZones Editor, changing display settings and handling those changes.
### Proposal for modifications of handling described in 4.4:
Currently after each of the mentioned changes in work environment we are calling EnumDisplayMonitors windows API, and passing callback function to it. EnumDisplayMonitors works asynchronous and triggers that callback for each work area available (as mentioned in previous example, for two monitors and two virtual desktops, we have this callback triggered four times). As mentioned previously, we have WorkArea class as our representation of this work area. And what we do, every time this callback is triggered we destroy previous WorkArea object for that work area and create new one, even though that it is most likely that nothing has changed (e.g. just switching back and forth between virtual desktops). This constant creation and deletion of WorkArea has caused some problems in the past and it's not ideal for some other fixes we would like to make in the multi-monitor/multi-desktop scenario.
As mentioned in 4.3 we already have tracker of virtual desktops implemented. Idea is to use this functionality and to extend it bit more, so we can track if work area (WorkArea) is new one, or already processed and skip creating new WorkArea objects and deleting old ones every time, even if nothing changed in it. We will keep map, where virtual desktop id is the key, and values are already processed monitors (virtual desktop exists across all monitors). Once we receive callback from EnumDisplayMonitors, indicating work area (defined by virtual desktop id and monitor) we can check if it’s new or not, and act accordingly (create new WorkArea for it or not). Deleting virtual desktop (which is also registered in 4.3), will trigger updates in this map, and also updates in our JSON storage.
---
### Doc Specs SCOOBE (`doc/specs/SCOOBE.md`)
# PowerToys SCOOBE Dialog
- **What is it:** Post-upgrade prompted dialog that walks users through the latest additions to PowerToys utilities and functionalities
- **Author:** Deondre Davis
- **Spec Status:** Draft
## 1. Overview
### 1.1. Executive Summary
To expand on our end-user on-boarding efforts, we seek to resolve the critical issue of informing users of new additions and improvements to PowerToys during upgrade scenarios. We currently list release notes on the main repository, in addition to affiliated information on Microsoft Docs. However, neither of these mediums are internal to the application, and thus requires users to proactively seek out information on what's been updated, or merely notice by chance what's been changed from their regular usage. As these are not ideal experiences, this document describes the inclusion of a post-upgrade 'SCOOBE' prompt that launches the previously developed OOBE dialog loaded with new information related to upgrade improvements and additions.
### 1.2. Key-Definitions/Concepts
Here are definitions for words and acronyms found throughout this document to ensure clarity:
- **OOBE:** Out of box experience – The users' initial interactions with the product immediately after installing the product and/or launching the product for the first time.
- **SCOOBE:** Second chance out of box experience - The users' initial interactions with the product immediately after upgrading the product and/or launching the product for the first time after upgrading.
### 1.3. Goals and Non-Goals
Goals:
- Create a guided prompt that exposes the user to a brief overview of the new features and/or improvements included with the latest version of PowerToys.
Non-Goals:
- Present a copy-and-paste replica of the repository release notes. This information needs to be readily consumable, often requiring visual demonstrations of the new behavior and/or functionality that's either not possible or not necessary to depict on the repository release notes.
## 2. Definition of Success
**2.1. Customers**
The PowerToys SCOOBE is for existing and new power users and developers who are looking to tune and streamline their Windows experience for greater productivity and enhanced user experience. As the PowerToys customer base tends to be particularly biased against SCOOBE prompts in general, we need to present the PowerToys SCOOBE dialog in such a way that it provides immediate value to end-users to improve the likelihood of users discovering all the additions to PowerToys by making their way through the prompt.
**2.2. Expected Impact: Customer, and Technology Outcomes**
- **High Reliability** : Less than 0.1% crash rate.
- **Increased Activation** : 50% or more adoption rate of new feature/utilities among PowerToys users who already utilize associated tools.
- **High User Retention:** 25% or more active PowerToys users after 28 days of upgrade.
## 3. Requirements
The SCOOBE dialog builds off the currently implemented OOBE dialog originally drafted by [Niels's mock-up.](https://github.com/microsoft/PowerToys/issues/1285)
**3.1. Functional Requirements**
**3.1.1. Functional Requirements** **Overview**
| **No.** | **Requirement** | **Pri** |
| --- | --- | --- |
|1. | The SCOOBE dialog should launch immediately when PowerToys runs after having been updated. | P0 |
|2. | The SCOOBE dialog should be contained inside the existing OOBE Dialog under its own "What's New" page of the dialog window. See figure 5.1.1. | P0 |
|3. | The content for the SCOOBE dialog should be stored externally from the PowerToys application on the PowerToys GitHub in distinct wiki pages on for each release. **\*** | P0 |
|4. | When the "What's New" page is opened, the content displayed should be loaded from the information contained in the relevant wiki pages discussed in 3.1.1.3 above. Assumes the user's device is connected to the internet. | P0 |
|6. | The SCOOBE dialog should display information on updates that have occurred on the version of PowerToys the user has installed/updated to. | P0 |
|7. | If PowerToys was installed for the first time, the OOBE's "Welcome to PowerToys" page should display first, not the SCOOBE's "What's New" page. See figure 5.1.2. | P0 |
|8. | The structure of the SCOOBE dialog page's content should follow the guidelines described in section 3.1.2. | P0 |
|9. | After SCOOBE is initially viewed, the user should be able to re-access the SCOOBE dialog at any time by opening the OOBE window again and selecting the "What's New" page. | P1 |
**\*** - By storing the content for SCOOBE externally from the application, the PowerToys team can update/adjust information without being constrained to PowerToys' release cycles. This is critical in the event of errors or miscommunications that would otherwise be difficult, if not impossible, to correct if stored locally to the app and shipped with the version of PowerToys being released. The content will likely be stored in an archive maintained in the PowerToys GitHub Wiki.
**3.1.2. Page Content**
| **No.** | **Requirement** | **Pri** |
| --- | --- | --- |
|1. | The SCOOBE dialog should display the version of PowerToys the user has installed, as shown in figures 5.1.1. | P0 |
|2. | The SCOOBE dialog information should be grouped into two sections: "New Features & Improvements" and "Bug fixes Highlights". | P0 |
|3. | The "New Features & Improvements" section should contain information related to end user functionality that has been added or updated. | P0 |
|4. | The "New Features & Improvements" section should be subdivided by the relevant utilities updated (i.e. Color Picker, FancyZones, etc.). See figure 5.1.1 and section 5.1.3 for examples. | P1 |
|5. | The "Bug fixes Highlights" section should contain information related to noteworthy issues/errors that were corrected. | P0 |
|6. | If there are relevant visuals, they should be included with the information text. See figure 5.1.1. | P1 |
|8. | The SCOOBE dialog should be scrollable if needed to fit all the content. | P0 |
|10. | The bottom of the SCOOBE dialog should include a link to the PowerToys releases page for a complete list of versions and their release notes ([Releases · microsoft/PowerToys (github.com)](https://github.com/microsoft/PowerToys/releases)). | P1 |
## 4. Measure Requirements
| **No.** | **Requirement** | **Implication** | **Pri** |
| --- | --- | --- | --- |
|1. | Date/Time of first-run following upgrade | Helps to categorize usage and retention trends across users who've been exposed to SCOOBE. | P0 |
|2. | SCOOBE section viewed | Used to measure activation of the SCOOBE dialog. Should be 100% for the current version of PowerToys following SCOOBE's inclusion. | P0 |
|3. | Accesses to linked documentation | Used to gauge interest in user's desire to learn more about the PowerToys described. | P1 |
|4. | Access to linked settings pages | Used to gauge whether the settings presented to users in the dialog are sufficient for user needs. | P1 |
|5. | PowerToys launched while SCOOBE window is active | Used to track user engagement with the various PowerToys while exploring the content in the SCOOBE. | P1 |
|6. | Screen size | Gives crucial information for considerations related to minimal/maximum window size needed for displaying content. | P2 |
## 5. Appendix
### 5.1. Mock-ups
**5.1.1. SCOOBE Dialog Layout**
**5.1.2. OOBE Welcome Page**
**5.1.3. Example Textual Descriptions for Updates**
**v0.29 -> v0.31:**
- New Features & Improvements
- FancyZones
- Dark mode for the editor
- Certain settings (e.g. number of zones, spacing settings) can now be set on individual layouts.
- PowerToys Run
- Service management plugin (Start, stop, …)
- Registry key plugin
- System action plugin (Reboot, lock, ...)
- Bug fixes Highlights
- Fixed OneDrive SVG Bug (#9999)
- SVG are scaled appropriately when view box is provided (#9999)
**v0.31 -> v0.33:**
- New Features & Improvements
- General
- Added a 'First time load' experience. The hope is a quick, light way to learn about basic functionality
- FancyZones
- New options to change zone activation algorithm
- PowerToys Run
- Plugin Manager now is in settings. You can directly turn on / off, include items in general search, and change the action key
- Improved support for additional window managers by abstracting out shell process calls
- ~ will now act as the user home directory in Folder plugin
- Bug fixes Highlights
- Fix for PT Run registering the hotkey on non-supported OS versions (#9999)
**v0.33 -> v0.35:**
- New Features & Improvements
- Color Picker
- Esc can now be used to exit the editor
- FancyZones
- Added hotkeys and quick swap functionality for custom layouts! Users can now assign a hotkey in the editor and use it to quickly set a desktop's zones with Ctrl + Win + Alt + NUMBER key binding, or by pressing the hotkey while dragging a window.
- PowerToys Run
- Users can specify where to show the launcher window
- New plugin added to support opening previously used Visual Studio Code workspaces, remote machines (SSH or Codespaces), and containers! When enabled, use { to query for available workspaces. Please note, this plugin is off by default.
- Shell history now saves the raw command instead of the resolved command. A command like %appdata% would now save in the Shell history as is instead of C:\Users\YourUserName\AppData\Roaming.
- Bug fixes Highlights
- PowerToys will start requiring Windows 10 v1903 or greater after 0.35.x release. (#9999)
- Fixed FancyZones placement algorithm for when the Taskbar is vertical (#9999)
---
### Doc Specs WinGet Manifest Keyboard Shortcuts Schema (`doc/specs/WinGet Manifest Keyboard Shortcuts schema.md`)
# WinGet Manifest Keyboard Shortcuts schema
## 1 What this spec is about
This spec provides an extension to the existing [WinGet manifest schema](https://github.com/microsoft/winget-pkgs/blob/master/doc/manifest/README.md) in form of an additional yaml file, that describes keyboard shortcuts the application provides.
These yaml files are saved on a per-user base and so called manifest interpreters can then display these manifests in a human-friendly version.
### 1.1 What this spec is not about
This spec does not provide a way to back up or save user-defined keyboard shortcuts.
## 2 Save location of manifests
### 2.1 WinGet
These files are saved online along with the other manifest files in the [WinGet Package repository](https://github.com/microsoft/winget-pkgs).
### 2.2 Locally
All manifests and one index file are saved locally under `%LocalAppData%/Microsoft/WinGet/KeyboardShortcuts`. All apps are allowed to add their manifest files there. In addition Package Managers (like WinGet) and manifest interpreters (like PowerToys Shortcut Guide) can control and add other manifests themselves.
#### 2.2.1 Downloading manifests
When WinGet or other package managers download a package, they should also download the corresponding keyboard shortcuts manifest file and save it in the local directory, given such a file exists in the WinGet repository.
The downloader is also responsible for updating the local `index.yaml` file, which contains all the information about the different manifest files that are saved in the same directory.
#### 2.2.2 Updating manifests
When a manifest interpreter starts, it should download the latest version of the manifests from the WinGet repository and save them in the local directory. If a manifest interpreter is not able to download the manifests or they do not exist, it should use the locally saved manifests.
The updater is also responsible for updating the local `index.yaml` file, which contains all the information about the different manifest files that are saved in the same directory.
> Note: WinGet must provide a way to update the keyboard shortcuts manifests given a package id.
### 2.3 File names
The file name of a keyboard shortcuts file is the WinGet package identifier, plus the locale of the strings of the file and at last the `.KBSC.yaml` file extension.
For example the package "test.bar" saves its manifest with `en-US` strings in `test.bar.en-US.KBSC.yaml`.
#### 2.3.1 No winget package available
If an application has no corresponding WinGet package its name starts with a plus (`+`) symbol.
### 2.4 Reserved namespaces
Every name starting with `+WindowsNT` is reserved for the Windows OS and its components.
## 3 File syntax
All relevant files are written in [YAML](https://yaml.org/spec).
> Note: A JSON schema will be provided as soon as the spec reaches a further step
### 3.1 Manifest Schema vNext Keyboard Shortcuts File
```
PackageName: # The package unique identifier
WindowFilter: # The filter of window processes to which the shortcuts apply to
BackgroundProcess: # Optionally allows applying WindowFilter to background processes
Shortcuts: # List of sections with keyboard shortcuts
- SectionName: # Name of the category of shortcuts
Properties: # List of shortcuts in the category
- Name: # Name of the shortcut
Description: # Optional description of the shortcut
AdditionalInfo: # Optional additional information about the shortcut
Recommended: # Optionally determines if the shortcut is displayed in a designated recommended area
Shortcut: # An array of shortcuts that need to be pressed
- Win: # Determines if the Windows Key is part of the shortcut
Ctrl: # Determines if the Ctrl Key is part of the shortcut
Shift: # Determines if the Shift Key is part of the shortcut
Alt: # Determines if the Alt Key is part of the shortcut
Keys: # Array of keys that need to be pressed
```
Per Application/Package one or more Keyboard manifests can be declared. Every manifest must have a different locale and the same `PackageName`, `WindowFilter` and `BackgroundProcess` fields.
PackageName - The package unique identifier
Package identifier (see 2.1 for more information on the package identifier).
WindowFilter - The filter of window processes to which the shortcuts apply to
This field declares for which process name the shortcuts should be shown (To rephrase: For which processes the shortcut will have an effect if pressed). The value can be either an exact process executable name, for example `explorer.exe` or `chrome.exe`, or a single asterisk (`*`) to apply to any process. No other wildcard patterns are supported by this specification.
BackgroundProcess - Optionally allows applying WindowFilter to background processes.
**Optional field**
Defaults to `False`. Determines if WindowFilter should apply to background processes as well (Rephrased: When the process is running, the shortcuts will apply).
Shortcuts - List of sections with keyboard shortcuts
List of different section (also called categories) of shortcuts.
SectionName - Name of the category of shortcuts
Name of the section of shortcuts. Use sentence case, the same convention described under `Name` below.
**Special sections**:
Special sections start with an identifier enclosed between `<` and `>`. This declares the category as a special display. If the interpreter of the manifest file can't understand the content this section should be left out.
Properties - List of shortcuts in the categoryName - Name of the shortcut
Name of the shortcut. This is the name that will be displayed in the interpreter.
**Casing**:
By convention, shortcut names (and `SectionName` values) use **sentence case**: capitalize only the first word plus any proper nouns or product/feature names. For example, prefer `Reopen last closed tab` over `Reopen Last Closed Tab`, but keep `Open History`, `Quit Slack`, and `Show Quick Access` capitalized because those are application feature names. Match the casing the application uses for its own features rather than copying the title-case styling some apps apply to their entire shortcut list.
Description - Optional description of the shortcut
Optional description of the shortcut. This is the description that will be displayed by the interpreter.
AdditionalInfo - Optional additional information about the shortcut
Array of additional information about the shortcut. This is the additional information that will be displayed by the interpreter and are not part of this manifest.
**Example**:
For example, if the shortcut is only available on a certain Windows version, this information could be added here.
```yaml
AdditionalInfo:
- MinWindowsVersion: "10.0.19041.0"
```
Shortcut - An array of shortcuts that need to be pressed
An array of shortcuts that need to be pressed. This allows defining sequential shortcuts that need to be pressed in order to trigger the action.
Win - Determines if the Windows Key is part of the shortcut
Refers to the left Windows Key on the keyboard.
Ctrl - Determines if the Ctrl Key is part of the shortcut
Refers to the left Ctrl Key on the keyboard.
Shift - Determines if the Shift Key is part of the shortcut
Refers to the left Shift Key on the keyboard.
Alt - Determines if the Alt Key is part of the shortcut
Refers to the left Alt Key on the keyboard.
Recommended - Optionally determines if the shortcut is displayed in a designated recommended area
**Optional field**
Defaults to `False`. Determines if the shortcut should be displayed in a designated recommended area. This is a visual hint for the user that this shortcut is important.
Keys - Array of keys that need to be pressed
A string array of all the keys that need to be pressed. If a number is supplied, it should be read as a [KeyCode](https://learn.microsoft.com/windows/win32/inputdev/virtual-key-codes) and displayed accordingly (based on the Keyboard Layout of the user).
**Literal digit keys**:
Because a bare number is interpreted as a virtual-key code, a literal digit key must be authored using the `` notation (the digit enclosed between `<` and `>`), where `N` is `0`–`9`. For example, `<9>` represents the literal `9` key (as in the "switch to the last tab" shortcut), not the virtual-key code `9` (which is `Tab`). The interpreter strips the brackets and displays just the digit.
This applies only to a single literal digit. A range such as `1 - 8` is a free-form label, not a key, and is supplied verbatim (the brackets would only be trimmed from the ends, so `<1> - <8>` would not render as intended).
**Special keys**:
Special keys are enclosed between `<` and `>` and correspond to a key that should be displayed in a certain way. If the interpreter of the manifest file can't understand the content, the brackets should be left out.
By convention these tokens are written as double-quoted strings in the YAML (for example `""` and `"<9>"`), matching the quoting used for punctuation key values. YAML treats the quoted and unquoted forms identically, so quoting is for consistency rather than a strict requirement for bracketed tokens.
|Name|Description|
|----|-----------|
|``| Corresponds to the Office key on some Windows keyboards |
|``| Corresponds to the Copilot key on some Windows keyboards |
|``| Corresponds to the left arrow key |
|``| Corresponds to the right arrow key |
|``| Corresponds to the up arrow key |
|``| Corresponds to the down arrow key |
|``| Corresponds to the Enter key |
|``| Corresponds to the Space key |
|``| Corresponds to the Tab key |
|``| Corresponds to the Backspace key |
|``| Corresponds to the Delete key |
|``| Corresponds to the Insert key |
|``| Corresponds to the Home key |
|``| Corresponds to the End key |
|``| Corresponds to the Print Screen key |
|``| Corresponds to the pause key |
|``| Corresponds to the Page Up key |
|``| Corresponds to the Page Down key |
|``| Corresponds to the Escape key |
|``| Corresponds to either the left, right, up or down arrow key |
|``| Corresponds to either the left or right arrow key |
|``| Corresponds to either the up or down arrow key |
|``| Corresponds to the `<` key |
|``| Corresponds to the `>` key |
|``| Corresponds to any letter that is _underlined_ in the UI |
#### 3.2.2 Example
```yaml
PackageName: Microsoft.PowerToys
WindowFilter: "*"
BackgroundProcess: True
Shortcuts:
- SectionName: General
Properties:
- Name: Advanced Paste
Shortcut:
- Win: True
Ctrl: False
Alt: False
Shift: False
Keys:
- 86
Description: Open Advanced Paste window
- Name: Advanced Paste
Shortcut:
- Win: True
Ctrl: True
Alt: True
Shift: False
Keys:
- 86
Description: Paste as plain text directly
```
### 3.2 `index.yaml` file
The `index.yaml` file is a file that contains all the information about the different manifest files that are saved in the same directory. This file is only available locally and is not saved in the WinGet repository as it is specific to the user.
```yaml
DefaultShellName: # The package identifier of the default shell used in Windows
Index: # List of all manifest files
- WindowFilter: # The filter of window processes to which the shortcuts apply to
BackgroundProcess: # Optionally allows applying WindowFilter to background processes
Apps: # List of all manifest files for the filter
```
DefaultShellName - The package identifier of the default shell used in Windows
This declares the package identifier of the default shell used in Windows. Most commonly it is `+WindowsNT.Shell`. Although not enforced, only the shell declared in the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell` should be used here.
Index - List of all manifest filesWindowFilter - The filter of window processes to which the shortcuts apply to
See the `WindowFilter` field in the manifest file for more information.
BackgroundProcess - Optionally allows applying WindowFilter to background processes
**Optional field**
See the `BackgroundProcess` field in the manifest file for more information.
Apps - List of all the package identifiers applying for the filter
#### 3.2.1 Example
```yaml
DefaultShellName: "+WindowsNT.Shell"
Index:
- Filter: "*"
BackgroundProcess: True
Apps: ["+WindowsNT.Shell", "Microsoft.PowerToys"]
- Filter: "explorer.exe"
Apps: ["+WindowsNT.WindowsExplorer"]
- Filter: "taskmgr.exe"
Apps: ["+WindowsNT.TaskManager"]
- Filter: "msedge.exe"
Apps: ["+WindowsNT.Edge"]
```
---
### Doc Specs Power Display Adaptive Brightness (`doc/specs/power-display-adaptive-brightness.md`)
# Power Display – Ambient-Light (ALS) Adaptive Brightness for External Monitors
Tracking issue: microsoft/PowerToys#49038
Behaviour discussion: #49038 (with @moooyo)
Related: #47480 (schedule-based auto-brightness), #42566 (Light Switch ALS → theme), #35564 (manual multi-monitor brightness), #1052 (Quick Display adjustment umbrella, completed)
## 1. Overview
Windows can auto-adjust the **built-in laptop panel** from the device's ambient light sensor (ALS), but
**external monitors have no such capability** — they almost never carry an ALS, and Windows will not pipe the
laptop's ALS reading to an external display. Today's PowerToys covers the two halves separately:
* **Light Switch** already reads the device ALS (`Windows.Devices.Sensors.LightSensor` → `IlluminanceInLux`) to drive theme.
* **Power Display** already writes external-monitor brightness over **DDC/CI** (`SetMonitorBrightness`, VCP `0x10`).
This feature wires them together: a per-monitor **Adaptive (ambient light)** mode in Power Display that continuously
maps the device's ambient lux to each external monitor's brightness. It is the **continuous, sensor-driven** counterpart
to the **time/schedule-based** request tracked in #47480 — and it is what most users actually mean by "auto-brightness".
## 2. Goals / Non-goals
### Goals
* Per-external-monitor opt-in adaptive brightness driven by the device ALS.
* A per-monitor **calibration curve** (lux → %), so differently-behaving panels can be matched.
* A per-monitor **offset** for manual/CLI nudges that rides on top of the curve (iOS-style personalization).
* Correct, safe behaviour when the sensor can't be trusted (e.g. laptop lid closed).
* Smooth, flicker-free, DDC/CI-friendly updates (smoothing + hysteresis + rate limiting).
* Coexist cleanly with manual brightness changes and the existing schedule/profile features.
### Non-goals
* Driving the built-in laptop panel (Windows already does this).
* Bundling external/USB ambient sensors (possible future extension).
* Content-adaptive / gamma-overlay dimming (a different, software-only approach).
* Colour-temperature / Night-Light behaviour.
## 3. Scenarios
1. A laptop is docked to one or two external monitors. As the room darkens through the evening, the externals dim
automatically to track the room — today only the built-in panel does this.
2. A light-sensitive user wants externals to follow ambient light continuously, without manual sliders or rigid schedules.
3. Two different external panels are calibrated so they *look* equally bright across the whole ambient range.
4. Clamshell (lid closed): the sensor is blocked, so brightness holds steady instead of dimming to black.
5. A non-DDC/CI monitor: adaptive is greyed out for that monitor with a clear "not supported" reason.
## 4. Fit with existing modules
```
[ Device ALS ]
LightSensor.ReadingChanged (lux) <-- already consumed by Light Switch (#42566)
│
▼
[ Adaptive Brightness engine ] (new glue, lives in Power Display)
smoothing (EMA) → hysteresis/deadband → curve(lux) + offset (per monitor) → rate limit
│
▼
[ Power Display DDC/CI writer ] <-- already exists (SetMonitorBrightness, VCP 0x10)
per external monitor
```
No new module. The ALS reader can be refactored into a small shared helper so both Light Switch and Power Display
consume one sensor source (avoids two sensor subscriptions). On #47480 a maintainer noted Light Switch can already
link to a Power Display *profile* on a scheduler; this design adds an *ambient-light* trigger alongside the existing
*time/sun* trigger and addresses the "apply a Power Display profile without forcing a theme change" limitation raised there.
## 5. Core model — adaptive curve + per-monitor offset
The whole feature reduces to a single formula, applied **independently per external monitor**:
```
target%(lux) = clamp( curve(lux) + offset, minPercent, maxPercent )
```
### 5.1 The loop
Continuously: read device ALS (lux) → smooth → map through the monitor's **curve** → add the monitor's **offset** →
clamp → write via DDC/CI. One shared sensor subscription drives an independent engine per external monitor.
### 5.2 Per-monitor calibration curve — the multi-monitor sync mechanism
Each monitor has its own editable `lux → %` curve. This is what keeps multiple monitors *looking* equally bright:
panels differ in nits and have **non-linear** backlight response, so the same ambient lux should map to a *different*
percentage on different panels. A per-monitor curve corrects this across the **entire** ambient range — something a
single scalar value cannot do (a uniform shift would keep them matched at one light level but drift apart at others).
### 5.3 Per-monitor offset — live personalization
A signed per-monitor `offset%` added on top of the curve. Manual/CLI nudges adjust it, so the system learns the
user's preference (iOS-style) instead of overriding them. The **curve does calibration**; the **offset does live,
personal fine-tuning** (and is the quick way to nudge one screen to match the others without editing its curve).
### 5.4 Manual / CLI interaction while adaptive is ON
When the user changes brightness (slider or CLI increase/decrease) with adaptive on, per-monitor `manualBehavior`:
* **`offset` (default):** the delta becomes a persistent offset; adaptation keeps tracking ambient, just shifted.
A CLI "brightness +10" makes the monitor 10% brighter *than the curve would pick*, and tracking continues.
* **`pause`:** adaptation suspends for that monitor (hard manual override) until the user re-enables it.
## 6. UX / Settings design
Per-monitor (WinUI3 `SettingsCard`/`SettingsExpander`):
* **Brightness source:** `Manual` (default) | `Adaptive (ambient light)`. Adaptive is disabled with a reason string
when (a) no ALS is present, or (b) the monitor has no DDC/CI brightness control.
* **Default (zero-config):** on/off + a single **Responsiveness** slider (Calm ↔ Snappy). A sensible default curve
ships out of the box so most users touch nothing else.
* **Advanced (collapsible):** editable **calibration curve** (anchor points, e.g. `0 lx→20%, 50→40%, 300→70%, 1000→100%`
with a "Reset"), **min/max** clamps, and the `manualBehavior` choice.
* **Live slider:** when adaptive is on, the brightness slider becomes **live** — it reflects the current computed
target and moves on its own as ambient changes, with an **"Auto"** badge and a readout (`Ambient 240 lx → 65%`).
Dragging it applies the **offset** (§5.3); it does not silently disable adaptive.
Global: a module-level toggle and an enable/disable hotkey (consistent with other Power Display shortcuts, e.g. #48784).
## 7. Sensor trust & lifecycle
The ALS reading is used **only when it can be trusted**.
### 7.1 ALS / DDC-CI availability
`LightSensor.GetDefault()` null → adaptive unavailable everywhere (e.g. a desktop). Per monitor, if DDC/CI brightness
is unsupported → adaptive is disabled for that monitor with a reason.
### 7.2 Lid closed / clamshell (sensor blocked)
When the lid is closed the ALS faces the keyboard deck and reads ~darkness, so we must **not** drive brightness from it.
* **Detect:** lid state via `RegisterPowerSettingNotification(GUID_LIDSWITCH_STATE_CHANGE)` (0 = closed, 1 = open),
corroborated by `QueryDisplayConfig(QDC_ONLY_ACTIVE_PATHS)` for an active internal panel
(`DISPLAYCONFIG_OUTPUT_TECHNOLOGY_INTERNAL`). Lid *position* is the true determinant — a user may have the lid open
but the internal display disabled, and there the sensor still sees the room.
* **Behaviour:** on lid-close → pause adaptation and **hold the last known-good brightness** (never dim-to-black),
surface a status ("Adaptive paused — lid closed / ambient sensor blocked"), and **resume live on reopen**.
### 7.3 Honest boundary + fallbacks
Clamshell-docked is a *primary* scenario for this feature, yet it's exactly where the laptop ALS can't see the room.
Therefore:
* **v1:** full ALS adaptive when the lid is open; hold/pause when closed.
* **Optional fallback:** when the ALS is untrusted, fall back to **time/schedule-based** brightness (the #47480
mechanism) so clamshell users still get some automation.
* **Future:** an **external ambient sensor** (monitor-integrated or USB) for true clamshell tracking (deferred).
## 8. Technical design
### 8.1 ALS acquisition
* `LightSensor.GetDefault()`; subscribe to `ReadingChanged`; set `ReportInterval = max(minimumReportInterval, ~500ms)`
to limit churn/battery. Value: `LightSensorReading.IlluminanceInLux` (double).
### 8.2 Smoothing + hysteresis (anti-flicker, anti-wear)
* **EMA** on lux: `s_t = α·lux + (1−α)·s_{t−1}` (α from the Responsiveness slider).
* **Deadband:** ignore changes whose mapped target moves < ~2–3% from the last applied value.
* **Min update interval** per monitor (~1–2 s) and optional **ramping** (step toward target).
* Rationale: DDC/CI writes are slow (tens–hundreds of ms) and excessive writes can flicker or wear some panels.
### 8.3 Mapping
* Piecewise-linear interpolation over the anchor points; add `offset`; clamp to per-monitor min/max.
* Curve + offset stored per monitor (keyed by stable monitor id, as Power Display already does for profiles).
### 8.4 Brightness write
* Reuse Power Display's DDC/CI path (`GetPhysicalMonitorsFromHMONITOR` → `SetMonitorBrightness`, VCP `0x10`).
* Capability probe per monitor (`GetMonitorBrightness` / VCP support); if unsupported, disable adaptive for it.
### 8.5 Concurrency
* One engine per external monitor, one shared ALS subscription. Serialize DDC/CI writes per monitor on a worker;
**never block the sensor callback**. Handle monitor hotplug / dock connect-disconnect (Power Display already tracks add/remove).
## 9. Settings persistence
Extend Power Display's `settings.json` per-monitor entry, e.g.:
```jsonc
{
"monitors": [{
"id": "",
"brightnessSource": "adaptive", // "manual" | "adaptive"
"adaptive": {
"curve": [[0,20],[50,40],[300,70],[1000,100]], // [lux, percent] calibration, per monitor
"offsetPercent": 0, // signed live nudge added on top of the curve
"minPercent": 15,
"maxPercent": 100,
"responsiveness": 0.4, // 0..1 → EMA α / update cadence
"manualBehavior": "offset", // "offset" (default) | "pause"
"deadbandPercent": 3,
"minUpdateMs": 1500
}
}]
}
```
`target = clamp( interpolate(curve, lux) + offsetPercent, minPercent, maxPercent )`.
## 10. Telemetry
Per `doc/devdocs/development/logging.md`, emit (privacy-respecting, counts only):
* Adaptive mode enabled/disabled per monitor; ALS-present; DDC/CI-supported; `manualBehavior` chosen.
* Apply-rate (writes/min), deadband/clamp suppression counts, and lid-close pause events (to validate anti-wear tuning).
* No raw lux series or PII.
## 11. Performance & reliability
* Sensor at ~0.5–2 s cadence; writes throttled per §8.2 → negligible CPU and few DDC/CI writes.
* Worker isolates slow DDC/CI calls from the UI/sensor thread.
* Graceful degradation: no ALS → mode hidden/disabled; no DDC/CI → mode disabled per monitor with reason; lid closed → hold last-good.
## 12. Accessibility / Localization
* All new strings via `.resw` + `x:Uid` (and discoverable by the settings search index, settings-search.md).
* Curve editor keyboard-navigable; the live slider value, "Auto" badge, and ambient readout exposed to narrator.
## 13. Risks & open questions
* **Manual-vs-adaptive arbitration** — resolved: default **`offset`** (iOS-style), with **`pause`** opt-in (direction agreed in #49038).
* **ALS placement** — chassis lux ≠ panel-facing lux; mitigated by the per-monitor curve; documented as a limitation.
* **Clamshell** — laptop ALS is blind when the lid is closed; handled via hold/pause + optional time fallback; external sensor is future work.
* **DDC/CI variance** across docks/USB-C/adapters (cf. #47577) — robust capability probing + clear unsupported messaging.
* **Shared ALS source** — refactor Light Switch's reader into a shared helper (preferred) vs. two subscriptions.
* **Open (tune during implementation):** exact default curve values and the Responsiveness → (α, min-update-interval) mapping.
## 14. Phased delivery
1. Engine + per-monitor `adaptive` (curve + offset) + default curve + DDC/CI write reuse + sensor-trust gating (JSON-config; minimal UI).
2. Settings UX: source dropdown, live slider + "Auto" badge/readout, curve editor, responsiveness, clamps, `manualBehavior`.
3. Shared ALS helper refactor (Light Switch + Power Display); precedence with schedule/profile; optional time-based fallback.
4. Telemetry + docs (`doc/devdocs/modules/powerdisplay/…`) + tests.
---
### Doc Specs Settings Search (`doc/specs/settings-search.md`)
# PowerToys Settings – Search Index (Hard-sealed)
## 1. What to index
This section describes the current structure of the settings pages in PowerToys. All user-facing settings are contained in the content of . The logical and visual structure of settings follows a nested layout as shown below:
```css
SettingsPageControl
└─ SettingsGroup
└─ [SettingsExpander]
└─ SettingsCard
```
* Each SettingsGroup defines a functional section within a settings page.
* An optional SettingsExpander may be used to further organize related settings inside a group.
* Each actual setting is represented by a SettingsCard, which contains one user-tweakable control or a group of closely related controls.
>Note: Not all SettingsCard are necessarily wrapped in a SettingsExpander; they can exist directly under a SettingsGroup.
> For indexing purposes, we are specifically targeting all SettingsCard elements. These are the smallest units of user interaction and correspond to individual configurable settings.
> There could be setting item in expander, so we also need to index expander items as well.
### Module
Module is a primary type that needs to be indexed, for modules, we need to index the 'ModuleTitle' and the 'ModuleDescription'.
So these two should be passed in by x:Uid and binding with a key.
### SettingsCard/SettingsExpander
Each SettingsCard/SettingsExpander should have an x:Uid for localization and indexing. The associated display strings are defined in the .resw files:
{x:Uid}.Header – The visible label/title of the setting.
{x:Uid}.Description – (optional) The tooltip or explanatory text.
The index should be built around these SettingsCard elements and their x:Uid-bound resources, as they represent the actual settings users will search for.
---
## 2. How to Navigate
### Entry
```csharp
enum EntryType
{
SettingsPage,
SettingsCard,
SettingsExpander,
}
public class SearchableElementMetadata
{
public string PageName { get; set; } // Used to navigate to a specific page
public EntryType Type { get; set; } // Used to know how should we navigate(As a page, a settingscard or an expander?)
public string ParentElementName { get; set; }
public string ElementName { get; set; }
public string ElementUid { get; set; }
public string Icon { get; set; }
}
```
### Navigation
The steps for navigate to an item:
* Navigate among pages
* [optional] Expand the expander if setting entry is inside an expander
* [optional] Navigate within page
> Use page name for navigation:
```csharp
Type GetPageTypeFromPageName(string PageName)
{
var assembly = typeof(GeneralPage).Assembly;
return assembly.GetType($"Microsoft.PowerToys.Settings.UI.Views.{PageName}");
}
NavigationService.Navigate(PageType, ElementName，ParentElementName);
```
> Use ElementName and ParentElementName for in page navigation:
```csharp
Page.OnNavigateTo(ElementName， ParentElementName){
var element = this.FindName(name) as FrameworkElement;
var parentElement = this.FindName(ParentElementName) as FrameworkElement;
if(parentElement) {
expander = (Expander)parentElement;
if(expander){
expander.Expand();
}
// https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.startbringintoview?view=winrt-26100
element.StartBringIntoView();
}
}
```
## 3. Runtime Search
When user start typing for an entry, e.g. shortcut or 快捷键(cn version of shortcut),
we need to go through all the entries to see if an entry matches the search text.
A naive approach will be try to match all the localized text one by one and see if they match.
Total entry is within thousand(To fill in an exact number), performance is acceptable now.
```csharp
// Match
query = UserInput();
matched = {};
indexes = BuildIndex();
foreach(var entry in indexes) {
if(entry.Match(query)) {
matched.Add(entry);
}
}
```
And we don't intend to introduce complexity on the match algorithm discussion, so let's use powertoys FuzzMatch impl for now.
```csharp
MatchResult Match(this Entry entry, string query) {
return FuzzMatch(entry.DisplayedText, query);
}
struct MatchResult{
int Score;
bool Result;
}
```
## 4. Search Result Page
After we got matched items, map these items to a search result page according to spec.
```c#
ObservableCollection ModuleResult;
ObservableCollection GroupedSettingsResults;
public class SettingsGroup : INotifyPropertyChanged
{
private string _groupName;
private ObservableCollection _settings;
public string GroupName
{
get => _groupName;
set
{
_groupName = value;
OnPropertyChanged();
}
}
public ObservableCollection Settings
{
get => _settings;
set
{
_settings = value;
OnPropertyChanged();
}
}
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
}
```
## 5. How to do Index
### Runtime index or build time index?
Now We need to build all the entries in our settings.
Most of the entry properties are static, and in runtime, the `SettingsCard` is compiled into native winUI3 controls (I suppose, please correct here if it's wrong), it's hard to locate all the `SettingsCard`, and performance is terrible if we do search for all the pages' elements.
### Build time indexing
We can rely on xaml file parsing to get all the SettingsCard Entries.
And we don't want xaml file to be brought into production bundle.
Use a project for parsing and bring that index file into production bundle is a solution.
```csproj
$(MSBuildProjectDirectory)\..\Settings.UI.XamlIndexBuilder\bin\$(Configuration)\net8.0\XamlIndexBuilder.exe$(MSBuildProjectDirectory)\Views$(MSBuildProjectDirectory)\Services\searchable_elements.json
```
```csharp
for(xamlFile in xamlFiles){
var doc = Load(xamlFile);
var elements = doc.Descendants();
foreach(var element in elements){
if(element.Name == "SettingsCard") {
var entry = new Entry{
ElementName = element.Attribute["Name"],
PageName = FileName,
Type = "SettingsCard",
ElementUid = element.Attribute["Uid"],
DisplayedText = "",
}
var parent = element.GetParent();
if(parent.Name == "SettingsExpander"){
entry.ParentElementName = parent.Attribute["Name"];
}
}
}
}
```
Runtime index loading:
```
var entries = LoadEntriesFromFile();
foreach(var entry in entries){
entry.DisplayedText = ResourceLoader.GetString(entry.Uid);
}
```
So now we have all the entries and entry properties.
## Overall flow:
## 6. Corner cases - that have not addressed yet
1. CmdPal page is not in scope of this effort, that needs additional effort&design to launch and search within cmdpal settings page.
2. Go back button
3. Dynamic constructed settings page
- Shortcut guide, with visibility converter
- advanced paste dynamically configured setting items
- powertoys run's extensions
---
### Doc Devdocs Common FilePreviewCommon (`doc/devdocs/common/FilePreviewCommon.md`)
# [FilePreviewCommon](/src/common/FilePreviewCommon)
This project contains common code used for previewing and displaying files.
## Monaco preview
Monaco preview enables to display developer files. It is based on [Microsoft's Monaco Editor](https://microsoft.github.io/monaco-editor/) which is maintained by the Visual Studio Code team.
This previewer is used for the File Explorer Dev File Previewer, as well as PowerToys Peek.
For a general overview of how Monaco is used in PowerToys, see the [Monaco Editor documentation](monaco-editor.md).
### Update Monaco Editor
1. Download Monaco editor with [npm](https://www.npmjs.com/): Run `npm i monaco-editor` in the command prompt.
2. Delete everything except the `min` folder (the minimised code) from the downloaded files.
3. Copy the `min` folder into the `/src/Monaco/monacoSRC` folder of the PowerToys project.
4. Generate the JSON file as described in the generate [monaco_languages.json file](#monaco_languagesjson) section.
### Add a new language definition
As an example on how to add a new language definition you can look at the one for [registry files](/src/Monaco/customLanguages/reg.js).
1. Add the new language definition (written with [Monarch](https://microsoft.github.io/monaco-editor/monarch.html)) as a new file to the [folder containing Monaco custom languages](/src/Monaco/customLanguages/) (Remember the file name and the string you used for "idDefinition" as you need it later.). The file should be formatted like in the example below. (Please change `idDefinition` to the name of your language.)
```javascript
export function idDefinition() {
return {
...
}
}
```
2. Add the following line to the [`monacoSpecialLanguages.js`](/src/Monaco/monacoSpecialLanguages.js) file, after the other import statements:
```javascript
import { idDefinition } from './customLanguages/file.js';
```
> Replace file.js with the name of your definition file from step 1. Please replace idDefinition with the string you used in step 1.
3. In the [`monacoSpecialLanguages.js`](/src/Monaco/monacoSpecialLanguages.js) file add the following line into the `registerAdditionalLanguages` function:
```javascript
registerAdditionalNewLanguage("id", [".fileExtension"], idDefinition(), monaco)
```
> Replace id and idDefinition with your id and string used in step 1. Replace fileExtension with a set of file extensions you want the language to register to.
* The id can be anything. Recommended is one of the file extensions. For example "php" or "reg".
4. In case you wish to add a custom color for a token, you can do so by adding the following line to [`customTokenThemeRules.js`](/src/Monaco/customTokenThemeRules.js):
```javascript
{token: 'token-name', foreground: 'ff0000'}
```
> Replace `token-name` with the name of the token and `ff0000` with the hex code of the desired color.
> Note: you can also specify a `background` and a `fontStyle` attribute for your token.
* Keep in mind that these rules apply to all languages. Therefore, you should not change the colors of any default tokens. Instead, create new tokens specific to the language you are adding.
5. Execute the steps described in the [monaco_languages.json](#monaco_languagesjson) section.
### Add a new file extension to an existing language
1. In the [`monacoSpecialLanguages.js`](/src/Monaco/monacoSpecialLanguages.js) file add the following line to the `registerAdditionalLanguages` function. (`existingId` is the id of the language you want to add the extension to. You can find these id's in the [`monaco_languages.json`](/src/Monaco/monaco_languages.json) file):
```javascript
registerAdditionalLanguage("id", [".fileExtension"], "existingId", monaco)
```
* If for instance you want to add more extensions to the php language set the id to `phpExt` and the existingId to `php`.
2. Copy the existing language definition into the `languageDefinitions` function in the same file. You can find the existing definitions in the following folder: [`/src/Monaco/monacoSRC/min/vs/basic-languages/`](/src/Monaco/monacoSRC/min/vs/basic-languages/).
3. Execute the steps described in the [monaco_languages.json](#monaco_languagesjson) section.
### monaco_languages.json
[`monaco_languages.json`](/src/Monaco/monaco_languages.json) contains all extensions and IDs for the languages supported by Monaco. The [`MonacoHelper`](/src/common/FilePreviewCommon/MonacoHelper.cs) class and the installer are using this file to register preview handlers for the defined extensions.
After updating Monaco Editor and/or adding a new language you should update the [`monaco_languages.json`](/src/Monaco/monaco_languages.json) file.
1. Run the [`generateLanguagesJson.html`](/src/Monaco/generateLanguagesJson.html) file on a local webserver (as webbrowsers will block certain needed features when running the file locally.)
* This can for example be achieved by using the [Preview Server](https://marketplace.visualstudio.com/items?itemName=yuichinukiyama.vscode-preview-server) extension for Visual Studio Code: Open the file in Visual Studio Code, right click in the code editor and select `vscode-preview-server: Launch on browser`. The file will be opened in a browser.
2. The browser will download the new `monaco_languages.json` file
3. Replace the old file with the newly downloaded one in the source code folder.
---
### Doc Devdocs Common Common (`doc/devdocs/common/common.md`)
# Classes and structures
> This document is outdated and will soon be renewed.
#### class Animation: [header](/src/common/animation.h) [source](/src/common/animation.cpp)
Animation helper class with two easing-in animations: linear and exponential.
#### class AsyncMessageQueue: [header](/src/common/async_message_queue.h)
Header-only asynchronous message queue. Used by `TwoWayPipeMessageIPC`.
#### class TwoWayPipeMessageIPC: [header](/src/common/two_way_pipe_message_ipc.h)
Header-only asynchronous IPC messaging class. Used by the runner to communicate with the settings window.
#### class DPIAware: [header](/src/common/dpi_aware.h) [source](/src/common/dpi_aware.cpp)
Helper class for creating DPI-aware applications.
#### struct MonitorInfo: [header](/src/common/monitors.h) [source](/src/common/monitors.cpp)
Class for obtaining information about physical displays connected to the machine.
#### class Settings, class PowerToyValues, class CustomActionObject: [header](/src/common/settings_objects.h) [source](/src/common/settings_objects.cpp)
Classes used to define settings screens for the PowerToys modules.
#### class Tasklist: [header](/src/common/tasklist_positions.h) [source](/src/common/tasklist_positions.cpp)
Class that can detect the position of the windows buttons on the taskbar. It also detects which window will react to pressing `WinKey + number`.
#### struct WindowsColors: [header](/src/common/windows_colors.h) [source](/src/common/windows_colors.cpp)
Class for detecting the current Windows color scheme.
# Helpers
#### Common helpers: [header](/src/common/common.h) [source](/src/common/common.cpp)
Various helper functions.
#### Settings helpers: [header](/src/common/settings_helpers.h)
Helper methods for the settings.
#### Start visible helper: [header](/src/common/start_visible.h) [source](/src/common/start_visible.cpp)
Contains function to test if the Start menu is visible.
# Toast Notifications
#### Notifications API [header](/src/common/notifications.h) [source](/src/common/notifications.cpp)
To use UWP-style toast notifications, simply include the header and call one of these functions:
```cpp
void show_toast(std::wstring_view message); // #1
void show_toast_background_activated( // #2
std::wstring_view message,
std::wstring_view background_handler_id,
std::vector button_labels);
```
We might add more functions in the future if the need arises, e.g. `show_toast_xml` which will accept raw XML for rich customization.
Description:
- `#1` is for sending simple notifications without any callbacks or buttons
- `#2` is capable of showing a toast with multiple buttons and background activation
- `message` is a plain-text argument
Implement a toast activation handler/callback as a function in [handler_functions.cpp](/src/common/notifications_winrt/handler_functions.cpp) and register its `background_handler_id` via `handlers_map`, e.g.:
```cpp
// Your .cpp where you'd like to show a toast
#include
void some_func() {
// ...
notifications::show_toast_background_activated(
L"Toast message!", // text displayed in a toast
L"awesome_toast", // activation handler id
{L"Press me!", L"Also could press me!", L"I'm here to be pressed!"} // buttons in a toast
);
```
```cpp
// handler_functions.cpp
void awesome_toast_handler(IBackgroundTaskInstance, const size_t button_id)
{
switch(button_id)
{
case 0:
// handle "Press me!" button click
case 1:
// handle "Also could press me!" button click
case 2:
// handle "I'm here to be pressed!" button click
}
}
namespace
{
const std::unordered_map handlers_map = {
// ...other handlers...
{L"awesome_toast", awesome_toast_handler}
};}
```
Note: since _background activation_ implies that your toast handler will be invoked in a separate process, you can't share data directly from within a handler and your PT process. Also, since PT is currently a Desktop Bridge app, _foreground activation_ is [handled the same as background](https://learn.microsoft.com/windows/uwp/design/shell/tiles-and-notifications/send-local-toast-desktop-cpp-wrl#foreground-vs-background-activation), therefore we don't make a dedicated API for it. You can read more on the [rationale of the current design](https://github.com/microsoft/PowerToys/pull/1178#issue-368768337).
---
### Doc Devdocs Common Context Menus (`doc/devdocs/common/context-menus.md`)
# PowerToys Context Menu Handlers
This document describes how context menu handlers are implemented in PowerToys, covering both Windows 10 and Windows 11 approaches.
## Context Menu Implementation Types
PowerToys implements two types of context menu handlers:
1. **Old-Style Context Menu Handlers**
- Used for Windows 10 compatibility
- Registered via registry entries
- Implemented as COM objects exposing the `IContextMenu` interface
- Registered for specific file extensions
2. **Windows 11 Context Menu Handlers**
- Implemented as sparse MSIX packages
- Exposing the `IExplorerCommand` interface
- Located in `PowerToys\x64\Debug\modules\\.msix`
- Registered for all file types and filtered in code
- Requires signing to be installed
## Context Menu Handler Registration Approaches
PowerToys modules use two different approaches for registering context menu handlers:
### 1. Dual Registration (e.g., ImageResizer, PowerRename)
- Both old-style and Windows 11 context menu handlers are registered
- Results in duplicate entries in Windows 11's expanded context menu
- Ensures functionality even if Windows 11 handler fails to appear
- Old-style handlers appear in the "Show more options" expanded menu
### 2. Selective Registration (e.g., NewPlus)
- Windows 10: Uses old-style context menu handler
- Windows 11: Uses new MSIX-based context menu handler
- Avoids duplicates but can cause issues if Windows 11 handler fails to register
## Windows 11 Context Menu Handler Implementation
### Package Registration
- MSIX packages are defined in `AppManifest.xml` in each context menu project
- Registration happens in `DllMain` of the module interface DLL when the module is enabled
- Explorer restart may be required after registration for changes to take effect
- Registration can be verified with `Get-AppxPackage` PowerShell command:
```powershell
Get-AppxPackage -Name *PowerToys*
```
### Technical Implementation
- Handlers implement the `IExplorerCommand` interface
- Key methods:
- `GetState`: Determines visibility based on file type
- `Invoke`: Handles the action when the menu item is clicked
- `GetTitle`: Provides the text to display in the context menu
- For selective filtering (showing only for certain file types), the logic is implemented in the `GetState` method
### Example Implementation Flow
1. Build generates an MSIX package from the context menu project
2. When the module is enabled, PowerToys installs the package using `PackageManager.AddPackageAsync`
3. The package references the DLL that implements the actual context menu handler
4. When the user right-clicks, Explorer loads the DLL and calls into its methods
## Debugging Context Menu Handlers
### Debugging Old-Style (Windows 10) Handlers
1. Update the registry to point to your debug build
2. Restart Explorer
3. Attach the debugger to explorer.exe
4. Set breakpoints and test by right-clicking in File Explorer
### Debugging Windows 11 Handlers
1. Build PowerToys to get the MSIX packages
2. Sign the MSIX package with a self-signed certificate
3. Replace files in the PowerToys installation directory
4. Use PowerToys to install the package
5. Restart Explorer
6. Run Visual Studio as administrator
7. Set breakpoints in relevant code
8. Attach to DllHost.exe process when context menu is triggered
### Debugging Challenges
- Windows 11 handlers require signing and reinstalling for each code change
- DllHost loads the DLL only when context menu is triggered and unloads after
- For efficient development, use logging or message boxes instead of breakpoints
- Consider debugging the Windows 10 handler by removing OS version checks
## Common Issues
- Context menu entries not showing in Windows 11
- Usually due to package not being removed/updated properly on PowerToys update
- Fix: Uninstall and reinstall the package or restart Explorer
- Registering packages requires signing
- For local testing, create and install a signing certificate
- Duplicate entries in Windows 11 context menu
- By design for some modules to ensure availability if Windows 11 handler fails
---
### Doc Devdocs Common Monaco Editor (`doc/devdocs/common/monaco-editor.md`)
# Monaco Editor in PowerToys
## Overview
Monaco is the text editor that powers Visual Studio Code. In PowerToys, Monaco is integrated as a component to provide advanced text editing capabilities with features like syntax highlighting, line numbering, and intelligent code editing.
## Where Monaco is Used in PowerToys
Monaco is primarily used in:
- Registry Preview module - For editing registry files
- File Preview handlers - For syntax highlighting when previewing code files
- Peek module - For preview a file
## Technical Implementation
Monaco is embedded into PowerToys' WinUI 3 applications using WebView2. This integration allows PowerToys to leverage Monaco's web-based capabilities within desktop applications.
### Directory Structure
The Monaco editor files are located in the relevant module directories. For example, in Registry Preview, Monaco files are bundled with the application resources.
## Versioning and Updates
### Current Version
The current Monaco version can be found in the `loader.js` file, specifically in the variable named `versionMonaco`.
### Update Process
Updating Monaco requires several steps:
1. Download the latest version of Monaco
2. Replace/override the main folder with the new version
3. Generate the new Monaco language JSON file
4. Override the existing JSON file
For detailed step-by-step instructions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#update-monaco-editor).
#### Estimated Time for Update
The Monaco update process typically takes approximately 30 minutes.
#### Reference PRs
When updating Monaco, you can refer to previous Monaco update PRs as examples, as they mostly involve copy-pasting the Monaco source code with minor adjustments.
## Customizing Monaco
### Adding New Language Definitions
Monaco can be customized to support new language definitions for syntax highlighting:
1. Identify the language you want to add
2. Create or modify the appropriate language definition files
3. Update the Monaco configuration to recognize the new language
For detailed instructions on adding language definitions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#add-a-new-language-definition).
### Adding File Extensions to Existing Languages
To make Monaco handle additional file extensions using existing language definitions:
1. Locate the language mapping configuration
2. Add the new file extension to the appropriate language entry
3. Update the file extension registry
For detailed instructions on adding file extensions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#add-a-new-file-extension-to-an-existing-language).
Example: If Monaco processes TXT files and you want it to preview LOG files the same way, you can add LOG extensions to the TXT language definition.
## Installer Handling
Monaco source files are managed via a script (`Generate-Monaco-wxs.ps1`) that:
1. Automatically generates the installer manifest to include all Monaco files
2. Avoids manually listing all Monaco files in the installer configuration
This approach simplifies maintenance and updates of the Monaco editor within PowerToys.
---
### Doc Devdocs Core Architecture (`doc/devdocs/core/architecture.md`)
# PowerToys Architecture
## Module Interface Overview
Each PowerToys utility is defined by a module interface (DLL) that provides a standardized way for the PowerToys Runner to interact with it. The module interface defines:
- Structure for hotkeys
- Name and key for the utility
- Configuration management
- Enable/disable functionality
- Telemetry settings
- Group Policy Object (GPO) configuration
### Types of Modules
1. **Simple Modules** (like Mouse Pointer Crosshairs, Find My Mouse)
- Entirely contained in the module interface
- No external application
- Example: Mouse Pointer Crosshairs implements the module interface directly
2. **External Application Launchers** (like Color Picker)
- Start a separate application (e.g., WPF application in C#)
- Handle events when hotkeys are pressed
- Communication via named pipes or other IPC mechanisms
3. **Context Handler Modules** (like Power Rename)
- Shell extensions for File Explorer
- Add right-click context menu entries
- Windows 11 context menu integration through MSIX
4. **Registry-based Modules** (like Power Preview)
- Register preview handlers and thumbnail providers
- Modify registry keys during enable/disable operations
## Common Dependencies and Libraries
- SPD logs for C++ (centralized logging system)
- CPP Win RT (used by most utilities)
- Common utilities in `common` folder for reuse across modules
- Interop library for C++/C# communication (converted to C++ Win RT)
- Common.UI library has WPF and WinForms dependencies
## Resource Management
- For C++ applications and module interfaces:
- Resource files (.resx) need to be converted to .rc
- Use conversion tools before building
- Different resource approaches:
- WPF applications use .resx files
- WinUI 3 apps use .resw files
- PRI file naming requirements:
- Need to override default names to avoid conflicts during flattening
## Implementation details
### [`Runner`](runner.md)
The PowerToys Runner contains the project for the PowerToys.exe executable.
It's responsible for:
- Loading the individual PowerToys modules.
- Passing registered events to the PowerToys.
- Showing a system tray icon to manage the PowerToys.
- Bridging between the PowerToys modules and the Settings editor.
### [`Interface`](../modules/interface.md)
The definition of the interface used by the [`runner`](/src/runner) to manage the PowerToys. All PowerToys must implement this interface.
### [`Common`](../common.md)
The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. [json parsing](/src/common/utils/json.h) and [IPC primitives](/src/common/interop/two_way_pipe_message_ipc.h).
### [`Settings`](settings/readme.md)
Settings v2 is our current settings implementation. Please head over to the dev docs that describe the current settings system.
---
### Doc Devdocs Core Installer (`doc/devdocs/core/installer.md`)
# PowerToys Installer
## Installer Architecture (WiX 5)
- Uses a bootstrapper to check dependencies and close PowerToys
- MSI defined in product.wxs
- Custom actions in C++ for special operations:
- Getting install folder
- User impersonation
- PowerShell module path retrieval
- GPO checking
- Process termination
### Installer Components
- Separate builds for machine-wide and user-scope installation
- Supports x64 and ARM64
- Custom actions DLL must be signed separately before installer build
- WXS files generated during build process for file components
- Localization handling for resource DLLs
- Firewall exceptions for certain modules
### MSI Installer Build Process
- First builds `PowerToysSetupCustomActionsVNext` DLL and signs it
- Then builds the installer without cleaning, to reuse the signed DLL
- Uses PowerShell scripts to modify .wxs files before build
- Restores original .wxs files after build completes
- Scripts (`applyBuildInfo.ps1` and `generateFileList.ps1`) dynamically update files list for installer
- Helps manage all self-contained dependencies (.NET, WinAppSDK DLLs, etc.)
- Avoids manual maintenance of file lists
### Special Build Processes
- .NET applications need publishing for correct WebView2 DLL inclusion
- WXS files backed up and regenerated during build
- Monaco UI components (JavaScript/HTML) generated during build
- Localization files downloaded from server during CI release builds
## Per-User vs Per-Machine Installation
- Functionality is identical
- Differences:
- Per-User:
- Installed to `%LOCALAPPDATA%\PowerToys`
- Registry entries in HKCU
- Different users can have different installations/settings
- Per-Machine:
- Installed to `Program Files\PowerToys`
- Registry entries in HKLM
- Single installation shared by all users
- Default is now Per-User installation
- Guards prevent installing both types simultaneously
## MSIX Usage in PowerToys
- Context menu handlers for Windows 11 use sparse MSIX packages
- Previous attempts to create full MSIX installers were abandoned
- Command Palette will use MSIX when merged into PowerToys
- The main PowerToys application still uses MSI for installation
### MSIX Packaging and Extensions
- MSIX packages for extensions (like context menus) are included in the PowerToys installer
- The MSIX files are built as part of the PowerToys build process
- MSIX files are saved directly into the root folder with base application files
- The installer includes MSIX files but doesn't install them automatically
- Packages are registered when a module is enabled
- Code in `package.h` checks if a package is registered and verifies the version
- Packages will be installed if a version mismatch is detected
- When uninstalling PowerToys, the system checks for installed packages with matching display names and attempts to uninstall them
## GPO Files (Group Policy Objects)
- GPO files for x64 and ARM64 are identical
- Only one set is needed
- GPO files in pipeline are copies of files in source
## Installer Debugging
- Can only build installer in Release mode
- Typically debug using logs and message boxes
- Logs located in:
- `%LOCALAPPDATA%\Temp\PowerToys_bootstrapper_*.log` - MSI tool logs
- `%LOCALAPPDATA%\Temp\PowerToys_*.log` - Custom installer logs
- Logs in Bug Reports are useful for troubleshooting installation issues
### Building PowerToys Locally
#### One stop script for building installer
1. Open `Developer PowerShell for VS`.
2. Run tools\build\build-installer.ps1
> For the first-time setup, please run the installer as an administrator. This ensures that the Wix tool can move wix.target to the desired location and trust the certificate used to sign the MSIX packages.
The following manual steps will not install the MSIX apps (such as Command Palette) on your local installer.
#### Prerequisites for building the MSI installer
PowerToys uses WiX v5 for creating installers. The WiX v5 tools are automatically installed during the build process via dotnet tool.
For manual installation of WiX v5 tools:
```powershell
dotnet tool install --global wix --version 5.0.2
```
> **Note:** As of release 0.94, PowerToys has migrated from WiX v3 to WiX v5. The WiX v3 toolset is no longer required.
#### Building prerequisite projects
##### From the command line
1. From the start menu, open a `Developer Command Prompt for VS`
1. Ensure `nuget.exe` is in your `%path%`
1. In the repo root, run these commands:
```
nuget restore .\tools\BugReportTool\BugReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\BugReportTool\BugReportTool.sln
nuget restore .\tools\StylesReportTool\StylesReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\StylesReportTool\StylesReportTool.sln
```
##### From Visual Studio
If you prefer, you can alternatively build prerequisite projects for the installer using the Visual Studio UI.
1. Open `tools\BugReportTool\BugReportTool.sln`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu, choose `Build Solution`.
1. Open `tools\StylesReportTool\StylesReportTool.sln`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu, choose `Build Solution`.
#### Locally compiling the installer
1. Open `installer\PowerToysSetup.slnx`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu choose `Build Solution`.
The resulting installer will be available in the `installer\PowerToysSetupVNext\x64\Release\` folder.
To build the installer from the command line, run `Developer Command Prompt for VS` in admin mode and execute the following commands. The generated installer package will be located at `\installer\PowerToysSetupVNext\{platform}\Release\MachineSetup`.
```
git clean -xfd -e *exe -- .\installer\
MSBuild -t:restore .\installer\PowerToysSetup.slnx -p:RestorePackagesConfig=true /p:Platform="x64" /p:Configuration=Release
MSBuild -t:Restore -m .\installer\PowerToysSetup.slnx /t:PowerToysInstallerVNext /p:Configuration=Release /p:Platform="x64"
MSBuild -t:Restore -m .\installer\PowerToysSetup.slnx /t:PowerToysBootstrapperVNext /p:Configuration=Release /p:Platform="x64"
```
### Supported arguments for the .EXE Bootstrapper installer
Head over to the wiki to see the [full list of supported installer arguments][installerArgWiki].
[installerArgWiki]: https://github.com/microsoft/PowerToys/wiki/Installer-arguments
---
### Doc Devdocs Core Runner (`doc/devdocs/core/runner.md`)
# PowerToys Runner
The PowerToys Runner is the main executable (`PowerToys.exe`) that loads and manages all PowerToys modules.
## Runner Architecture
The Runner is responsible for:
- Managing the tray icon
- Loading and managing module interfaces
- Handling enabling/disabling modules
- Processing global hotkeys
- Managing updates and settings
### Key Components
- Main CPP file manages the tray icon and modules
- Creates a list of modules with DLL paths
- Special handling for WinUI 3 apps (separated in different folder)
- DLLs flattening for consistent versions
- Runs as part of the Windows message loop
- Creates a window handle with a specific class name
- Registers itself as the window handler for components requiring a window handler
### Process Flow
1. Initialize logger
2. Create single instance application mutex
3. Initialize common utility code
4. Parse command line arguments
5. Start the tray icon
6. Initialize low-level keyboard hooks
7. Load module interfaces from DLLs
8. Start enabled modules
9. Enter Windows message loop
10. On exit, stop modules and clean up resources
## System Tray Icon Implementation
The system tray icon is one of the first components that starts when calling the `render_main` function:
- Defined in `tray_icon.h` and `tray_icon.cpp`
- Creates a popup window and registers as window handler via `start_tray_icon()`
- Processes window messages through `tray_icon_window_proc()`
- Uses `WM_COMMAND` and tray icon notifications for handling menu options
- Handles left mouse clicks (distinguishes between single and double clicks)
- Monitors taskbar creation to re-register the icon if needed
- Uses `shell_notify_icon` to register with the system tray
### Tray Icon Initialization and Message Processing
- `start_tray_icon()` initializes the tray icon by:
- Creating a window with the specified class name
- Setting up the notification icon data structure (NOTIFYICONDATA)
- Registering for taskbar recreate messages
- Adding the icon to the system tray
- `tray_icon_window_proc()` processes window messages, including:
- Handling `wm_icon_notify` messages from tray icon interactions
- Distinguishing between left-click, double-click, and right-click actions
- Showing context menus or opening Settings windows based on interaction type
### Communication with Settings UI
When the tray icon is clicked or a menu option is selected, the Runner communicates with the Settings UI:
- For quick access flyout (left-click):
```cpp
current_settings_ipc->send(L"{\"ShowYourself\":\"flyout\"}");
```
- For the main dashboard (menu option or double-click):
```cpp
current_settings_ipc->send(L"{\"ShowYourself\":\"Dashboard\"}");
```
### IPC Communication Mechanism
- The Runner and Settings UI communicate through Windows Named Pipes
- A two-way pipe (TwoWayPipeMessageIPC) is established between processes
- JSON messages are sent through this pipe to control UI behavior
- The Settings UI initializes the pipe connection on startup:
```csharp
ipcmanager = new TwoWayPipeMessageIPCManaged(cmdArgs[(int)Arguments.SettingsPipeName],
cmdArgs[(int)Arguments.PTPipeName],
(string message) => {
if (IPCMessageReceivedCallback != null && message.Length > 0) {
IPCMessageReceivedCallback(message);
}
});
```
### Settings UI Message Processing
The Settings UI processes incoming IPC messages through a callback chain:
1. Messages from the Runner are received through the IPC callback
2. Messages are parsed as JSON objects
3. Registered handlers in `ShellPage.ShellHandler.IPCResponseHandleList` process the messages
4. The `ReceiveMessage` method in `ShellPage` interprets commands:
- For flyout display: `"ShowYourself": "flyout"`
- For main window: `"ShowYourself": "Dashboard"` or other page names
When showing the flyout, the tray icon can also send position coordinates to place the flyout near the tray icon:
```json
{
"ShowYourself": "flyout",
"x_position": 1234,
"y_position": 567
}
```
The flyout window is then activated and brought to the foreground using native Windows APIs to ensure visibility.
### Tray Icon Menu
- Menus are defined in `.RC` files (Resource files)
- `base.h` defines IDs
- `resources.resx` contains localized strings
- The tray icon window proc handles showing the popup menu
## Centralized Keyboard Hook
- Located in "centralized_kb_hook.cpp"
- Handles hotkeys for multiple modules to prevent performance issues
- Contains optimizations to exit early when possible:
- Ignores keystrokes generated by PowerToys itself
- Ignores when no keys are actually pressed
- Uses metadata to avoid re-processing modified inputs
- Performance consideration: handler must run very fast as it's called on every keystroke
## Module Loading Process
1. Scan module directory for DLLs
2. Create the module interface object for each module
3. Load settings for each module
4. Initialize each module
5. Check GPO policies to determine which modules can start
6. Start enabled modules that aren't disabled by policy
## Finding and Messaging the Tray Icon
The tray icon class is used when sending messages to the runner. For example, to close the runner:
```cpp
// Find the window with the PowerToys tray icon class and send it a close message
WM_CLOSE
```
## Key Files and Their Purposes
#### [`main.cpp`](/src/runner/main.cpp)
Contains the executable starting point, initialization code and the list of known PowerToys. All singletons are also initialized here at the start. Loads all the powertoys by scanning the `./modules` folder and `enable()`s those marked as enabled in `%LOCALAPPDATA%\Microsoft\PowerToys\settings.json` config. Then it runs [a message loop](https://learn.microsoft.com/windows/win32/winmsg/using-messages-and-message-queues) for the tray UI. Note that this message loop also [handles lowlevel_keyboard_hook events](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/lowlevel_keyboard_event.cpp#L24).
#### [`powertoy_module.h`](/src/runner/powertoy_module.h) and [`powertoy_module.cpp`](/src/runner/powertoy_module.cpp)
Contains code for initializing and managing the PowerToy modules. `PowertoyModule` is a RAII-style holder for the `PowertoyModuleIface` pointer, which we got by [invoking module DLL's `powertoy_create` function](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/powertoy_module.cpp#L13-L24).
#### [`tray_icon.cpp`](/src/runner/tray_icon.cpp)
Contains code for managing the PowerToys tray icon and its menu commands. Note that `dispatch_run_on_main_ui_thread` is used to
transfer received json message from the [Settings window](/doc/devdocs/settings.md) to the main thread, since we're communicating with it from [a dedicated thread](https://github.com/microsoft/PowerToys/blob/7357e40d3f54de51176efe54fda6d57028837b8c/src/runner/settings_window.cpp#L267-L271).
#### [`settings_window.cpp`](/src/runner/settings_window.cpp)
Contains code for starting the PowerToys settings window and communicating with it. Settings window is a separate process, so we're using [Windows pipes](https://learn.microsoft.com/windows/win32/ipc/pipes) as a transport for json messages.
#### [`general_settings.cpp`](/src/runner/general_settings.cpp)
Contains code for loading, saving and applying the general settings.
#### [`auto_start_helper.cpp`](/src/runner/auto_start_helper.cpp)
Contains helper code for registering and unregistering PowerToys to run when the user logs in.
#### [`unhandled_exception_handler.cpp`](/src/runner/unhandled_exception_handler.cpp)
Contains helper code to get stack traces in builds. Can be used by adding a call to `init_global_error_handlers` in [`WinMain`](./main.cpp).
#### [`trace.cpp`](/src/runner/trace.cpp)
Contains code for telemetry.
#### [`svgs`](/src/runner/svgs/)
Contains the SVG assets used by the PowerToys modules.
#### [`bug_report.cpp`](/src/runner/bug_report.cpp)
Contains logic to start bug report tool.
#### [`centralized_hotkeys.cpp`](/src/runner/centralized_hotkeys.cpp)
Contains hot key logic registration and un-registration.
#### [`centralized_kb_hook.cpp`](/src/runner/centralized_kb_hook.cpp)
Contains logic to handle PowerToys' keyboard shortcut functionality.
#### [`restart_elevated.cpp`](/src/runner/restart_elevated.cpp)
Contains logic for restarting the current process with different elevation levels.
#### [`RestartManagement.cpp`](/src/runner/RestartManagement.cpp)
Contains code for restarting a process.
#### [`settings_telemetry.cpp`](/src/runner/settings_telemetry.cpp)
Contains logic that periodically triggers module-specific setting's telemetry delivery and manages timing and error handling for the process.
#### [`UpdateUtils.cpp`](/src/runner/UpdateUtils.cpp)
Contains code to handle the automatic update checking, notification, and installation process for PowerToys.
---
### Doc Devdocs Development Debugging (`doc/devdocs/development/debugging.md`)
# Debugging PowerToys
This document covers techniques and tools for debugging PowerToys.
## Pre-Debugging Setup
Before you can start debugging PowerToys, you need to set up your development environment:
1. Fork the repository and clone it to your machine
2. Navigate to the repository root directory
3. Run `git submodule update --init --recursive` to initialize all submodules
4. Change directory to `.config` and run `winget configure .\configuration.vsEnterprise.winget` (pick the configuration file that matches your Visual Studio distribution)
### Optional: Building Outside Visual Studio
You can build the entire solution from the command line, which is sometimes faster than building within Visual Studio:
1. Open `Developer Command Prompt for VS`
2. Navigate to the repository root directory
3. Run the following command(don't forget to set the correct platform):
```pwsh
msbuild -restore -p:RestorePackagesConfig=true -p:Platform=ARM64 -m PowerToys.slnx /tl /p:NuGetInteractive="true"
```
4. This process should complete in approximately 13-14 minutes for a full build
## Debugging Techniques
### Visual Studio Debugging
To debug the PowerToys application in Visual Studio, set the `runner` project as your start-up project, then start the debugger.
Some PowerToys modules must be run with the highest permission level if the current user is a member of the Administrators group. The highest permission level is required to be able to perform some actions when an elevated application (e.g. Task Manager) is in the foreground or is the target of an action. Without elevated privileges some PowerToys modules will still work but with some limitations:
- The `FancyZones` module will not be able to move an elevated window to a zone.
- The `Shortcut Guide` module will not appear if the foreground window belongs to an elevated application.
Therefore, it is recommended to run Visual Studio with elevated privileges when debugging these scenarios. If you want to avoid running Visual Studio with elevated privileges and don't mind the limitations described above, you can do the following: open the `runner` project properties and navigate to the `Linker -> Manifest File` settings, edit the `UAC Execution Level` property and change it from `highestAvailable (level='highestAvailable')` to `asInvoker (/level='asInvoker').
### Shell Process Debugging Tool
The Shell Process Debugging Tool is a Visual Studio extension that helps debug multiple processes, which is especially useful for PowerToys modules started by the runner.
#### Debugging Setup Process
1. Install ["Debug Child Processes"](https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool2022) Visual Studio extension
2. Configure which processes to debug and what debugger to use for each
3. Start PowerToys from Visual Studio
4. The extension will automatically attach to specified child processes when launched
#### Debugging Color Picker Example
1. Set breakpoints in both ColorPicker and its module interface
2. Use Shell Process Debugging to attach to ColorPickerUI.exe
3. Debug .NET and native code together
4. Runner needs to be running to properly test activation
#### Debugging DLL Main/Module Interface
- Breakpoints in DLL code will be hit when loaded by runner
- No special setup needed as DLL is loaded into runner process
#### Debugging Short-Lived Processes
- For processes with short lifetimes (like in Workspaces)
- List all processes explicitly in debugging configuration
- Set correct debugger type (.NET debugger for C# code)
### Finding Registered Events
1. Run WinObj tool from SysInternals as administrator
2. Search for event name
3. Shows handles to the event (typically runner and module)
### Common Debugging Usage Patterns
#### Debugging with Bug Report
1. Check module-specific logs for exceptions/crashes
2. Copy user's settings to your AppData to reproduce their configuration
3. Check Event Viewer XML files if logs don't show crashes
4. Compare installation_folder_structure.txt to detect corrupted installations
5. Check installer logs for installation-related issues
6. Look at Windows version and language settings for patterns across users
#### Installer Debugging
- Can only build installer in Release mode
- Typically debug using logs and message boxes
- Logs located in:
- `%LOCALAPPDATA%\Temp\PowerToys_bootstrapper_*.log` - MSI tool logs
- `%LOCALAPPDATA%\Temp\PowerToys_*.log` - Custom installer logs
- Logs in Bug Reports are useful for troubleshooting installation issues
#### Settings UI Debugging
- Use shell process debugging to connect to newly created processes
- Debug the `PowerToys.Settings.exe` process
- Add breakpoints as needed for troubleshooting
- Logs are stored in the local app directory: `%LOCALAPPDATA%\Microsoft\PowerToys`
- Check Event Viewer for application crashes related to `PowerToys.Settings.exe`
- Crash dumps can be obtained from Event Viewer
### Debugging Command Palette
Command Palette can be easily debugged using the solution filter in `src/modules/cmdpal/Command Palette.slnf`. This will open Command Palette as its own Visual Studio solution that can be run and debugged directly in Visual Studio without the need for the Shell Process Debugging Tool.
## Troubleshooting Build Errors
### Missing Image Files or Corrupted Build State
If you encounter build errors about missing image files (e.g., `.png`, `.ico`, or other assets), this typically indicates a corrupted build state. To resolve:
1. **Clean the solution in Visual Studio**: Build > Clean Solution
Or from the command line (`Developer Command Prompt for VS`):
```pwsh
msbuild PowerToys.slnx /t:Clean /p:Platform=x64 /p:Configuration=Debug
```
2. **Delete build output and package folders** from the repository root:
- `x64/`
- `ARM64/`
- `Debug/`
- `Release/`
- `packages/`
3. **Rebuild the solution**
#### Helper Script
A PowerShell script is available to automate this cleanup:
```pwsh
.\tools\build\clean-artifacts.ps1
```
This script will run MSBuild Clean and remove the build folders listed above. Use `-SkipMSBuildClean` if you only want to delete the folders without running MSBuild Clean.
After cleaning, rebuild with:
```pwsh
msbuild -restore -p:RestorePackagesConfig=true -p:Platform=x64 -m PowerToys.slnx
```
---
### Doc Devdocs Development Dev With Vscode (`doc/devdocs/development/dev-with-vscode.md`)
## Developing PowerToys with Visual Studio Code
This guide shows how to build, debug, and contribute to PowerToys using VS Code instead of (or alongside) full Visual Studio. It focuses on common inner‑loop tasks for C++, .NET, and mixed scenarios present in the solution.
> PowerToys is a large mixed C++ / C# / WinAppSDK solution. VS Code works well for incremental development and quick module iterations, but occasionally you may still prefer full Visual Studio for designer tooling or specialized diagnostics.
---
VS Code extensions Needed:
| Area | Extension | Notes |
|------|-----------|-------|
| C++ | ms-vscode.cpptools | IntelliSense, debugging (cppvsdbg) |
| C# | ms-dotnettools.csdevkit (or C#) | Language service / test explorer |
---
## Building in VS Code
### Configure Developer PowerShell for VS for more convenient development experience in VS Code
1. Configure profile in settings, entry: `terminal.integrated.profiles.windows`
2. Add below config as entry (choose VS 2026 or VS 2022 based on your installation):
**For Visual Studio 2026 (recommended):**
```json
"Developer PowerShell for VS": {
// Configure based on your preference
"path": "C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.5.2.0_arm64__8wekyb3d8bbwe\\pwsh.exe",
"args": [
"-NoExit",
"-Command",
"& {",
"$orig = Get-Location;",
// Adjust path based on your edition (Community/Professional/Enterprise)
"& 'C:\\Program Files\\Microsoft Visual Studio\\18\\Enterprise\\Common7\\Tools\\Launch-VsDevShell.ps1';",
"Set-Location $orig",
"}"
]
},
```
**For Visual Studio 2022:**
```json
"Developer PowerShell for VS 2022": {
// Configure based on your preference
"path": "C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.5.2.0_arm64__8wekyb3d8bbwe\\pwsh.exe",
"args": [
"-NoExit",
"-Command",
"& {",
"$orig = Get-Location;",
// Adjust path based on your edition (Community/Professional/Enterprise)
"& 'C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\Common7\\Tools\\Launch-VsDevShell.ps1';",
"Set-Location $orig",
"}"
]
},
```
3. [Optional] Set your Developer PowerShell profile as the default, so that you can get a deep integration with vscode coding agent.
4. Now you can build with plain `msbuild` or configure tasks.json in below section.
Or reach out to "tools\build\BUILD-GUIDELINES.md"
### Sample plain msbuild command
```powershell
# Restore:
msbuild powertoys.slnx -t:restore -p:configuration=debug -p:platform=x64 -m
# Build powertoys slnx
msbuild powertoys.slnx -p:configuration=debug -p:platform=x64 -m
# dotnet project
msbuild src\settings-ui\Settings.UI\PowerToys.Settings.csproj -p:Platform=x64 -p:Configuration=Debug -m
# native project
msbuild "src\modules\MouseUtils\FindMyMouse\FindMyMouse.vcxproj" -p:Configuration=Debug -p:Platform=x64 -m
```
---
## Debugging
### Existing launch configuration
The repo provides `.vscode/launch.json` with:
- `Run PowerToys.exe (no build)`: Launches the already-built executable at `x64/Debug/PowerToys.exe` using `cppvsdbg`.
Build first, then press F5. To switch configuration (Release / ARM64) either edit the path or create additional launch entries.
### Attaching to a running instance
If PowerToys is already running, you can attach to that process:
2. VS Code command palette: “C/C++: (Windows) Attach to Process”.
3. Filter for `PowerToys.exe` / module-specific processes.
### Debugging managed components
Many modules have a managed component loaded into the PowerToys process. `cppvsdbg` can debug mixed mode, but if you need richer .NET inspection you can create a second configuration using `type: coreclr` and `processId` attachment after the native launch, or just attach separately:
Similar for attach to managed code.
> Note: In arm64 machine, can only debug arm64 code.
```jsonc
{
"version": "0.2.0",
"configurations": [
{
"name": "Run native executable (no build)",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceFolder}\\x64\\Debug\\PowerToys.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"console": "integratedTerminal"
},
{
"name": "C/C++ Attach to PowerToys Process (native)",
"type": "cppvsdbg",
"request": "attach",
"processId": "${command:pickProcess}",
"symbolSearchPath": "${workspaceFolder}\\x64\\Debug;${workspaceFolder}\\Debug;${workspaceFolder}\\symbols"
},
{
"name": "Run managed code (managed, no build)",
"type": "coreclr",
"request": "launch",
"program": "${workspaceFolder}\\arm64\\Debug\\WinUI3Apps\\PowerToys.Settings.exe",
"args": [],
"cwd": "${workspaceFolder}",
"env": {},
"console": "internalConsole",
"stopAtEntry": false
}
]
}
```
---
## 6. Common tasks & tips
| Task | Command / Action | Notes |
|------|------------------|-------|
| Clean | `git clean -xdf` (careful) or `msbuild /t:Clean PowerToys.slnx` | Deep clean removes packages & build outputs |
| Rebuild single project | `msbuild path\to\proj.vcxproj /t:Rebuild -p:Platform=x64 -p:Configuration=Debug` | Faster than whole solution |
| Generate installer (rare in inner loop) | See `tools\build\build-installer.ps1` | Usually not needed for local debug |
| Resource conversion errors | Re-run restore + build | Triggers custom PowerShell targets |
---
### Doc Devdocs Development Guidelines (`doc/devdocs/development/guidelines.md`)
# PowerToys Development Guidelines
## Using Open Source Packages and Libraries
### License Considerations
- MIT license is generally acceptable for inclusion in the project
- For any license other than MIT, double check with the PM team
- All external packages or projects must be mentioned in the `notice.md` file
- Even if a license permits free use, it's better to verify with the team
### Safety and Quality Considerations
- Ensure the code being included is safe to use
- Avoid repositories or packages that are not widely used
- Check for packages with significant downloads/usage and good ratings
- Important because our pipeline signs external DLLs with Microsoft certificate
- Unsafe code signed with Microsoft certificate can cause serious issues
## Code Signing
### Signing JSON File
- Modifications to the signing JSON file are typically done manually
- When adding new DLLs (internal PowerToys modules or external libraries)
- When the release pipeline fails with a list of unsigned DLLs/executables:
- For PowerToys DLLs, manually add them to the list
- For external DLLs, verify they're safe to sign before including
### File Signing Requirements
- All DLLs and executables must be signed
- New files need to be added to the signing configuration
- CI checks if all files are signed
- Even Microsoft-sourced dependencies are signed if they aren't already
## Performance Measurement
- Currently no built-in timers to measure PowerToys startup time
- Startup measurement could be added in the runner:
- At the start of the main method
- After all module interface DLLs are loaded
- Alternative: use profilers or Visual Studio profiler
- Startup currently takes some time due to:
- Approximately 20 module interface DLLs that need to be loaded
- Modules that are started during loading
- No dashboards or dedicated tools for performance measurement
- Uses System.Diagnostics.Stopwatch in code
- Performance data is logged to default PowerToys logs
- Can search logs for stopwatch-related messages to diagnose performance issues
- Some telemetry events contain performance information
## Dependency Management
### WinRT SDK and CS/WinRT
- Updates to WinRT SDK and CS/WinRT are done periodically
- WinRT SDK often requires higher versions of CS/WinRT or vice versa
- Check for new versions in NuGet.org or Visual Studio's NuGet Package Explorer
- Prefer stable versions over preview versions
- Best practice: Update early in the release cycle to catch potential regressions
### WebView2
- Used for components like monotone file preview
- WebView2 version is related to the WebView runtime in Windows
- Previous issues with Windows Update installing new WebView runtime versions
- WebView team now includes PowerToys testing in their release cycle
- When updating WebView2:
- Update the version
- Open a PR
- Perform sanity checks on components that use WebView2
### General Dependency Update Process
- When updating via Visual Studio, it will automatically update dependencies
- After updates, perform:
- Clean build
- Sanity check that all modules still work
- Open PR with changes
### C/C++ Runtime (Hybrid CRT)
- `Cpp.Build.props` links the VC++ runtime and STL statically (`/MT`) and the Universal CRT from the in-box `ucrtbase.dll`, so no VC++ redistributable is needed.
- Every module in a process shares that UCRT, including WinUI 3 and .NET. Don't change process-wide CRT state:
- No `setlocale`, `std::locale::global` or named `std::locale` objects; MSVC's STL calls `setlocale` while building them. Use `_wcreate_locale` with the `_l` functions, or NLS APIs such as `LCMapStringEx`.
- No `signal` or `_set_invalid_parameter_handler` from a DLL.
- Read environment variables with `GetEnvironmentVariableW`; the CRT's copy is a snapshot.
- If a project sets Link `IgnoreSpecificDefaultLibraries` or `AdditionalOptions`, keep the inherited `%(...)` value.
- A project that can't follow these rules sets `false` with a comment that says why. Today: PowerRename.exe and its tests (PowerRenameLib calls `std::locale::global`) and MeasureToolCore (installs a `SIGABRT` handler).
- Debug builds need `ucrtbased.dll`, which the Windows SDK installs. Use a Release build on machines without the SDK.
## Testing Requirements
### Multiple Computers
- **Mouse Without Borders**: Requires multiple physical computers for proper testing
- Testing with VMs is not recommended as it may cause confusion between host and guest mouse input
- At least 2 computers are needed, sometimes testing with 3 is done
- Testing is usually assigned to team members known to have multiple computers
### Multiple Monitors
- Some utilities require multiple monitors for testing
- At least 2 monitors are recommended
- One monitor should be able to use different DPI settings
### Fuzzing Testing
- Security team requires fuzzing testing for modules that handle file I/O or user input
- Helps identify vulnerabilities and bugs by feeding random, invalid, or unexpected data
- PowerToys integrates with Microsoft's OneFuzz service for automated testing
- Both .NET (C#) and C++ modules have different fuzzing implementation approaches
- New modules handling file I/O or user input should implement fuzzing tests
- For detailed setup instructions, see [Fuzzing Testing in PowerToys](../tools/fuzzingtesting.md)
### Testing Process
- For reporting bugs during the release candidate testing:
1. Discuss in team chat
2. Determine if it's a regression (check if bug exists in previous version)
3. Check if an issue is already open
4. Open a new issue if needed
5. Decide on criticality for the release (if regression)
### Release Testing
- Team follows a release checklist
- Includes testing for WinGet configuration
- Sign-off process:
- Teams sign off on modules independently
- Regressions found in first release candidates lead to PRs
- Second release candidate verified fixes
- Command Palette needs separate sign-off
- Final verification ensures modules don't crash with Command Palette integration
## PR Management and Release Process
### PR Review Process
- PM team typically tags PRs with "need review"
- Small fixes from community that don't change much are usually accepted
- PM team adds tags like "need review" to highlight PRs
- PMs set priorities (sometimes using "info.90" tags)
- PMs decide which PRs to prioritize
- Team members can help get PRs merged when there's flexibility
### PR Approval Requirements
- PRs need approval from code owners before merging
- New team members can approve PRs but final approval comes from code owners
### PR Priority Handling
- Old PRs sometimes "slip through the cracks" if not high priority
- PMs tag important PRs with "priority one" to indicate they should be included in release
- Draft PRs are generally not prioritized
### Specific PR Types
- CI-related PRs need review and code owner approval
- Feature additions (like GPO support) need PM decision on whether the feature is wanted
- Bug fixes related to Watson errors sometimes don't have corresponding issue links
- Command Palette is considered high priority for the upcoming release
## Project Management Notes
- Be careful about not merging incomplete features into main
- Feature branches should be used for work in progress
- PRs touching installer files should be carefully reviewed
- Incomplete features should not be merged into main
- Use feature branches (feature/name-of-feature) for work-in-progress features
- Only merge to main when complete or behind experimentation flags
---
### Doc Devdocs Development Localization (`doc/devdocs/development/localization.md`)
# Localization
## Table of Contents
1. [Localization on the pipeline (CDPX)](#localization-on-the-pipeline-cdpx)
1. [UWP Special case](#uwp-special-case)
2. [Enabling localization on a new project](#enabling-localization-on-a-new-project)
1. [C++](#c)
2. [C#](#c-1)
3. [UWP](#uwp)
3. [Lcl Files](#lcl-files)
4. [Possible Issues in localization PRs (LEGO)](#possible-issues-in-localization-prs-lego)
5. [Enabling localized MSI for a new project](#enabling-localized-msi-for-a-new-project)
## Localization on the pipeline (CDPX)
[The localization step](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L45-L52) is run on the pipeline before the solution is built. This step runs the [build-localization](https://github.com/microsoft/PowerToys/blob/main/.pipelines/build-localization.cmd) script, which generates resx files for all the projects with localization enabled using the `Localization.XLoc` package.
The [`Localization.XLoc`](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/build-localization.cmd#L24-L25) tool is run on the repo root, and it checks for all occurrences of `LocProject.json`. Each localized project has a `LocProject.json` file in the project root, which contains the location of the English resx file, list of languages for localization, and the output path where the localized resx files are to be copied to. In addition to this, some other parameters can be set, such as whether the language ID should be added as a folder in the file path or in the file name. When the CDPX pipeline is run, the localization team is notified of changes in the English resx files. For each project with localization enabled, a `loc` folder (see [the loc folder in the Microsoft.Launcher module](https://github.com/microsoft/PowerToys/tree/main/src/modules/launcher/Microsoft.Launcher/loc) for example) is created in the same directory as the `LocProject.json` file. The folder contains language specific folders which in turn have a nested folder path equivalent to `OutputPath` in the `LocProject.json`. Each of these folders contain one `lcl` file. The `lcl` files contain the English resources along with their translation for that language. These are described in more detail in the [Lcl files section](#lcl-files). Once the `.resx` files are generated, they will be used during the `Build PowerToys` step for localized versions of the modules.
Since the localization script requires certain nuget packages, the [`restore-localization`](https://github.com/microsoft/PowerToys/blob/main/.pipelines/restore-localization.cmd) script is run before running `build-localization` to install all the required packages. This script must [run in the `restore` step](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L37-L39) of pipeline because [the host is network isolated](https://onebranch.visualstudio.com/Pipeline/_wiki/wikis/Pipeline.wiki/2066/Consuming-Packages-in-a-CDPx-Pipeline?anchor=overview) at the `build` step. The [Toolset package source](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L23) is used for this.
The process and variables that can be tweaked on the pipeline are described in more detail on [onebranch (account required) under Localization](https://onebranch.visualstudio.com/Pipeline/_wiki/wikis/Pipeline.wiki/290/Localization).
The localized resource dlls for C# projects are added to the MSI only for build on the pipeline. This is done by checking if the [`IsPipeline` variable is defined](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L804-L805), which gets defined before [building the installer on the pipeline](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/.pipelines/build-installer.cmd#L4). This is done because the localized resx files are only present on the pipeline, and not having this check would result in the installer project failing to build locally.
## Enabling localization on a new project
To enable localization on a new project, the first step is to create a file `LocProject.json` in the project root.
For example, for a project in the folder `src\path` where the resx file is present in `resources\Resources.resx`, the LocProject.json file will contain the following:
```
{
"Projects": [
{
"LanguageSet": "Azure_Languages",
"LocItems": [
{
"SourceFile": "src\\path\\resources\\Resources.resx",
"CopyOption": "LangIDOnName",
"OutputPath": "src\\path\\resources"
}
]
}
]
}
```
The rest of the steps depend on the project type and are covered in the sections below. The steps to add the localized files to the MSI can be found in [Enabling localized MSI for a new project](#Enabling-localized-MSI-for-a-new-project).
### C++
C++ projects do not support `resx` files, and instead use `rc` files along with `resource.h` files. The CDPX pipeline however doesn't support localizing `rc` files and the other alternative they support is directly translating the resources from the binary which makes it harder to maintain resources. To avoid this, a custom script has been added which expects a resx file and converts the entries to an rc file with a string table and adds resource declarations to a resource.h file so that the resources can be compiled with the C++ project.
If you already have a .rc file, copy the string table to a separate txt file and run the [convert-stringtable-to-resx.ps1](https://github.com/microsoft/PowerToys/blob/main/tools/build/convert-stringtable-to-resx.ps1) script on it. This script is not very robust to input, and requires the data in a specific format, where `IDS_ResName L"ResourceValue"` and any number of spaces can be present in between. The script converts this file to the format expected by [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert), which will convert it to resx. The resource names are changed from all uppercase to title case, and the `IDS_` prefix is removed. Escape characters might have to be manually replaced, for example .rc files would have escaped double quotes as `""`, so this should be replaced with just `"` before converting to the resx files.
After generating the resx file, rename the existing rc and h files to ProjName.base.rc and resource.base.h. In the rc file remove the string table which is to be localized and in the .h file remove all `#define`s corresponding to localized resources. In the vcxproj of the C++ project, add the following build event:
```
```
This event runs a script which generates a resource.h and ProjName.rc in the `Generated Files` folder using the strings in all the resx files along with the existing information in resource.base.h and ProjName.base.rc. The script is [convert-resx-to-rc.ps1](https://github.com/microsoft/PowerToys/blob/main/tools/build/convert-resx-to-rc.ps1). The script uses [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert) to convert the resx file to a string table expected in the .rc file format. When the resources are added to the rc file the `IDS_` prefix is added and resource names are in uppercase (as it was originally). Any occurrences of `"` in the string resource is escaped as `""` to prevent build errors. The string tables are added to the rc file in the following format:
```
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
STRINGTABLE
BEGIN
strings
END
#endif
```
Since there is no API to identify the `AFX_TARG_*`, `LANG_*` or `SUBLANG_*` values from each langId from the pipeline, these are hardcoded in the script (for each language) as done in [lines 50-77 of `convert-resx-to-rc.ps1`](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/tools/build/convert-resx-to-rc.ps1#L50-L77). **If any other languages are added in the future, this script will have to be updated.** In order to determine what are the language codes, you can open the rc file in Resource View, right click the string table and press `Insert Copy` and choose the corresponding language. This autogenerates the required code and can be used to figure out the language codes. The files also add the resource declarations to a resource.h file, starting from 101 by default(this can be changed by an optional argument). Since the output files will be generated in `Generated Files`, any includes in these two files will require an additional `..\` and wherever resource.h is used, it will have to be included as `Generated Files\resource.h`. While adding `resource.base.h` and `ProjName.base.rc` to the vcxproj, these should be modified to not participate in the build to avoid build errors:
```
```
Some rc/resource.h files might be used in multiple projects (for example, KBM). To ensure the projects build for these cases, the build event can be added to the entire directory so that the rc files are generated before any project is built. See [Directory.Build.targets](https://github.com/microsoft/PowerToys/blob/main/src/modules/keyboardmanager/Directory.Build.targets) for an example.
Check [this PR](https://github.com/microsoft/PowerToys/pull/6104) for an example for making these changes for a C++ project.
### C#
Since C# projects natively support `resx` files, the only step required here is to include all the resx files in the build. For .NET Core projects this is done automatically and the .csproj does not need to be modified. For other projects, the following line needs to be added:
```
```
**Note:** Building with localized resources may cause a build warning `Referenced assembly 'mscorlib.dll' targets a different processor` which is a VS bug. More details can be found in [PowerToys issue #7269](https://github.com/microsoft/PowerToys/issues/7269).
**Note:** If a project needs to be migrated from XAML resources to resx, the easiest way to convert the resources would be to change to format to `=` separates resources by either manually (by Ctrl+H on a text editor), or by a script, and then running [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert) on `Developer Command Prompt for VS` to convert it to resx format.
```
CalculatorAllows to do mathematical calculations.(Try 5*3-2 in Wox)Not a number (NaN)
```
to
```
wox_plugin_calculator_plugin_name=Calculator
wox_plugin_calculator_plugin_description=Allows to do mathematical calculations.(Try 5*3-2 in Wox)
wox_plugin_calculator_not_a_number=Not a number (NaN)
```
After adding the resx file to the project along with the resource generator, references to the strings will have to be replaced with `Properties.Resources.resName` rather than the custom APIs. Check [this PR](https://github.com/microsoft/PowerToys/pull/6165) for an example of the changes required.
### UWP
UWP projects expect `resw` files rather than `resx` (the format is almost the same). Unlike other C# projects, the files are expected in the format `fullLangId\Resources.resw`. To include these files in the build, replace the following line in the csproj:
```
```
to
```
```
## Lcl Files
Lcl files contain all the resources that are present in the English resx file, along with a translation if it has been added.
For example, an entry for a resource in the lcl file looks like this:
```
```
The `` element would not be present in the initial commits of the lcl files, as only the English version of the string would be present.
**Note:** The CDPX Localization system has a fail-safe check on the lcl files, where if the English string value which is present inside `` does not match the value present in the English Resources.resx file then the translated value will not be copied to the localized resx file. This is present so that obsolete translations would not be loaded when the English resource has changed, and the English string will be used rather than the obsolete translation.
## Possible Issues in localization PRs (LEGO)
Since the LEGO PRs update some of the strings in LCL files at a time, there can be multiple PRs which modify the same files, leading to merge conflicts. In most cases this would show up on GitHub as a merge conflict, but sometimes a bad git merge may occur, and the file could end up with incorrect formatting, such as two `` elements for a single resource. These can be fixed by ensuring the elements follow the format described in [this section](#lcl-files). To catch such errors, the build farm should be run for every LEGO PR and if any error occurs in the localization step, we should check the corresponding resx/lcl files for conflicts.
## Enabling localized MSI for a new project
For C++ and UWP projects no additional files are generated with localization that need to be added to the MSI. For C++ projects all the resources are added to the dll/exe, while for UWP projects they are added to the `resources.pri` file (which is present even for an unlocalized project). To verify if the localized resources are added to the `resources.pri` file the following steps can be done:
- Open `Developer Command Prompt for VS`
- After navigating to the folder containing the pri file, run the following command:
makepri.exe dump /if .\resources.pri
- Check the contents of the `resources.pri.xml` file that is generated from the command. The last section of the file will contain the resources with the strings in all the languages:
```
Running as administratorRunning as administrator
```
For C# projects, satellite dlls are generated when the project is built. For a project named `ProjName`, files are created in the format `langId\ProjName.resources.dll` where `langId` is in the same format as the lcl files. The satellite dlls need to be included with the MSI, but they must be added only if the solution is built from the build farm, as the localized resx files will not be present on local machines (and that could cause local builds of the installer to fail).
This can be done by adding the directory name of the project to [Product.wxs near line 806](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L806) and a resource component for the project can be created in [Product.wxs near lines 845-847](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L845-L847) in this format:
```
```
We should also ensure the new dlls are signed by the pipeline. Currently all dlls of the form [`*.resources.dll` are signed](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/.pipelines/pipeline.user.windows.yml#L68).
**Note:** The resource dlls should be added to the MSI project only after the initial commit with the lcl files has been done by the Localization team. Otherwise, the pipeline will fail as there wouldn't be any resx files to generate the dlls.
## Working With Strings
In order to support localization **YOU SHOULD NOT** have hardcoded UI display strings in your code. Instead, use resource files to consume strings.
### For CPP
Use [`StringTable` resource][String Table] to store the strings and resource header file(`resource.h`) to store Id's linked to the UI display string. Add the strings with Id's referenced from the header file to the resource-definition script file. You can use [Visual Studio Resource Editor][VS Resource Editor] to create and manage resource files.
- `resource.h`:
XXX must be a unique int in the list (mostly the int ID of the last string id plus one):
```cpp
#define IDS_MODULE_DISPLAYNAME XXX
```
- `StringTable` in resource-definition script file `validmodulename.rc`:
```
STRINGTABLE
BEGIN
IDS_MODULE_DISPLAYNAME L"Module Name"
END
```
- Use the `GET_RESOURCE_STRING(UINT resource_id)` method to consume strings in your code.
```cpp
#include
std::wstring GET_RESOURCE_STRING(IDS_MODULE_DISPLAYNAME)
```
### For C#
Use [XML resource file(.resx)][Resx Files] to store the UI display strings and [`Resource Manager`][Resource Manager] to consume those strings in the code. You can use [Visual Studio][Resx Files VS] to create and manage XML resources files.
- `Resources.resx`
```xml
Description to be displayed on UI.This text is displayed when XYZ button clicked.
```
- Use [`Resource Manager`][Resource Manager] to consume strings in code.
```csharp
System.Resources.ResourceManager manager = new System.Resources.ResourceManager(baseName, assembly);
string validUIDisplayString = manager.GetString("ValidUIDisplayString", resourceCulture);
```
In case of Visual Studio is used to create the resource file. Simply use the `Resources` class in auto-generated `Resources.Designer.cs` file to access the strings which encapsulate the [`Resource Manager`][Resource Manager] logic.
```csharp
string validUIDisplayString = Resources.ValidUIDisplayString;
```
[VS Resource Editor]: https://learn.microsoft.com/cpp/windows/resource-editors?view=vs-2019
[String Table]: https://learn.microsoft.com/windows/win32/menurc/stringtable-resource
[Resx Files VS]: https://learn.microsoft.com/dotnet/framework/resources/creating-resource-files-for-desktop-apps#resource-files-in-visual-studio
[Resx Files]: https://learn.microsoft.com/dotnet/framework/resources/creating-resource-files-for-desktop-apps#resources-in-resx-files
[Resource Manager]: https://learn.microsoft.com/dotnet/api/system.resources.resourcemanager?view=netframework-4.8
---
### Doc Devdocs Development Logging (`doc/devdocs/development/logging.md`)
# Logging and Telemetry in PowerToys
## Logging Types in PowerToys
PowerToys has several types of logging mechanisms:
1. Text file logs (application writes logs to files)
2. Telemetry/diagnostic data (sent to Microsoft servers)
3. Event Viewer logs (used by some utilities like Mouse Without Borders)
4. Watson reports (crash reports sent to Microsoft)
## Log File Locations
### Regular Logs
- Located at: `%LOCALAPPDATA%\Microsoft\PowerToys\Logs`
- Organized by utility and sometimes by version
- Examples: PowerToys Run logs, module interface logs
- C# and C++ components both write logs to these locations
### Low-Privilege Logs
- Some components (like preview handlers and thumbnail providers) are started by Explorer and have low privileges
- These components write logs to: `%USERPROFILE%/AppData/LocalLow/Microsoft/PowerToys`
- Example: Monaco preview handler logs
### Module Logs
- Logs always stored in user's AppData regardless of installation type
- Each module creates its own log
- Even with machine-wide installation, logs are per-user
- Different users can have different logs even with a machine-wide installation
## Log Implementation
### C++ Logging
In C++ projects we use the awesome [spdlog](https://github.com/gabime/spdlog) library for logging as a git submodule under the `deps` directory. To use it in your project, just include [spdlog.props](/deps/spdlog.props) in a .vcxproj like this:
```xml
```
It'll add the required include dirs and link the library binary itself.
- Projects need to include the logging project as a dependency
- Uses a git submodule for the actual logging library
- Logs are initialized in the main file:
```cpp
init_logger();
```
- After initialization, any file can use the logger
- Logger settings contain constants like log file locations
### C# Logging
For C# projects there is a static logger class in Managed Common called `Logger`.
To use it, add a project reference to `ManagedCommon` and add the following line of code to all the files using the logger:
```Csharp
using ManagedCommon;
```
In the `Main` function (or a function with a similar meaning (like `App` in a `App.xaml.cs` file)) you have to call `InitializeLogger` and specify the location where the logs will be saved (always use a path scheme similar to this example):
```Csharp
Logger.InitializeLogger("\\FancyZones\\Editor\\Logs");
```
For a low-privilege process you have to set the optional second parameter to `true`:
```Csharp
Logger.InitializeLogger("\\FileExplorer\\Monaco\\Logs", true);
```
The `Logger` class contains the following logging functions:
```Csharp
// Logs an error that the utility encountered
Logger.LogError(string message);
Logger.LogError(string message, Exception ex);
// Logs an error that isn't that grave
Logger.LogWarning(string message);
// Logs what the app is doing at the moment
Logger.LogInfo(string message);
// Like LogInfo just with infos important for debugging
Logger.LogDebug(string message);
// Logs the current state of the utility.
Logger.LogTrace();
```
## Log File Management
- Currently, most logs are not automatically cleaned up
- Some modules have community contributions to clean old logs, but not universally implemented
- By default, all info-level logs are written
- Debug and trace logs may not be written by default
- Log settings can be found in settings.json, but not all APIs honor these settings
## Telemetry
### Implementation
- Uses Event Tracing for Windows (ETW) for telemetry
- Different from the text file logging system
- Keys required to send telemetry to the right server
- Keys are not stored in the repository
- Obfuscated in public code
- Replaced during the release process
- Stored in private NuGet packages for release builds
### C++ Telemetry
- Managed through trace_base.h which:
- Registers the provider
- Checks if user has disabled diagnostics
- Defines events
- Example from Always On Top:
```cpp
Trace::AlwaysOnTop::Enable(true);
```
### C# Telemetry
- Uses PowerToysTelemetry class
- WriteEvent method sends telemetry
- Projects add a reference to the PowerToys.Telemetry project
- Example:
```csharp
PowerToysTelemetry.Log.WriteEvent(new LauncherShowEvent(hotKey));
```
### User Controls
- Settings page allows users to:
- Turn off/on sending telemetry
- Enable viewing of telemetry data
### Viewing Telemetry Data
- When "Enable viewing" is turned on, PowerToys starts ETW tracing
- Saves ETL files for 28 days
- Located at: `%LOCALAPPDATA%\Microsoft\PowerToys\ETL` (for most utilities)
- Low-privilege components save to a different location
- Button in settings converts ETL to XML for user readability
- XML format chosen to follow approved compliance pattern from Windows Subsystem for Android
- Files older than 28 days are automatically deleted
## Bug Report Tool
The [BugReportTool](/tools/BugReportTool) can be triggered via:
- Right-click on PowerToys tray icon → Report Bug
- Left-click on tray icon → Open Settings → Bug Report Tool
It creates a zip file on desktop named "PowerToys_Report_[date]_[time].zip" containing logs and system information.
See [Bug Report Tool](../tools/bug-report-tool.md) for more detailed information about the tool.
---
### Doc Devdocs Development New Powertoy (`doc/devdocs/development/new-powertoy.md`)
# 🧭 Creating a new PowerToy: end-to-end developer guide
First of all, thank you for wanting to contribute to PowerToys. The work we do would not be possible without the support of community supporters like you.
This guide documents the process of building a new PowerToys utility from scratch, including architecture decisions, integration steps, and common pitfalls.
---
## 1. Overview and prerequisites
A PowerToy module is a self-contained utility integrated into the PowerToys ecosystem. It can be UI-based, service-based, or both.
### Requirements
Follow the [Getting Started](../readme.md#getting-started) guide to set up your development environment, then [validate that you are able to build and run](debugging.md) `PowerToys.slnx`.
Optional:
- [WiX v5 toolset](https://github.com/microsoft/PowerToys/tree/main) for the installer
### Folder structure
```
src/
modules/
your_module/
YourModule.sln
YourModuleInterface/
YourModuleUI/ (if needed)
YourModuleService/ (if needed)
```
---
## 2. Design and planning
### Decide the type of module
Think about how your module works and which existing modules behave similarly. You are going to want to think about the UI needed for the application, the lifecycle, whether it is a service that is always running or event based. Below are some basic scenarios with some modules to explore. You can write your application in C++ or C#.
- **UI-only:** e.g., ColorPicker
- **Background service:** e.g., LightSwitch, Awake
- **Hybrid (UI + background logic):** e.g., ShortcutGuide
- **C++/C# interop:** e.g., PowerRename
### Write your module interface
Begin by setting up the [PowerToy module template project](https://github.com/microsoft/PowerToys/tree/main/tools/project_template). This will generate boilerplate for you to begin your new module. Below are the key headers in the Module Interface (`dllmain.cpp`) and an explanation of their purpose:
1. This is where module settings are defined. These can be anything from strings, bools, ints, and even custom Enums.
```c++
struct ModuleSettings {};
```
2. This is the header for the full class. It inherits the PowerToyModuleIface
```c++
class ModuleInterface : public PowertoyModuleIface
{
private:
// the private members of the class
// Can include the enabled variable, logic for event handlers, or hotkeys.
public:
// the public members of the class
// Will include the constructor and initialization logic.
}
```
> [!NOTE]
> Many of the class functions are boilerplate and need simple string replacements with your module name. The rest of the functions below will require bigger changes.
3. GPO stands for "Group Policy Object" and allows for administrators to configure settings across a network of machines. It is required that your module is on this list of settings. You can right click the `powertoys_gpo` object to go to the definition and set up the `getConfiguredModuleEnabledValue` for your module.
```c++
virtual powertoys_gpo::gpo_rule_configured_t gpo_policy_enabled_configuration() override
{
return powertoys_gpo::getConfiguredModuleEnabledValue();
}
```
4. `init_settings()` initializes the settings for the interface. Will either pull from existing settings.json or use defaults.
```c++
void ModuleInterface::init_settings()
```
5. `get_config` retrieves the settings from the settings.json file.
```c++
virtual bool get_config(wchar_t* buffer, int* buffer_size) override
```
6. `set_config` sets the new settings to the settings.json file.
```c++
virtual void set_config(const wchar_t* config) override
```
7. `call_custom_action` allows custom actions to be called based on signals from the settings app.
```c++
void call_custom_action(const wchar_t* action) override
```
8. Lifecycle events control whether the module is enabled or not, as well as the default status of the module.
```c++
virtual void enable() // starts the module
virtual void disable() // terminates the module and performs any cleanup
virtual bool is_enabled() // returns if the module is currently enabled
virtual bool is_enabled_by_default() const override // allows the module to dictate whether it should be enabled by default in the PowerToys app.
```
9. Hotkey functions control the status of the hotkey.
```c++
// takes the hotkey from settings into a format that the interface can understand
void parse_hotkey(PowerToysSettings::PowerToyValues& settings)
// returns the hotkeys from settings
virtual size_t get_hotkeys(Hotkey* hotkeys, size_t buffer_size) override
// performs logic when the hotkey event is fired
virtual bool on_hotkey(size_t hotkeyId) override
```
### Notes
- Keep module logic isolated under `/modules/`
- Use shared utilities from [`common`](https://github.com/microsoft/PowerToys/tree/main/src/common) instead of cross-module dependencies
- init/set/get config use preset functions to access the settings. Check out the [`settings_objects.h`](https://github.com/microsoft/PowerToys/blob/main/src/common/SettingsAPI/settings_helpers.h) in `src\common\SettingsAPI`
---
## 3. Bootstrapping your module
1. Use the [template](https://github.com/microsoft/PowerToys/tree/main/tools/project_template) to generate the module interface starter code.
2. Update all projects and namespaces with your module name.
3. Update GUIDs in `.vcxproj` and solution files.
4. Update the functions mentioned in the above section with your custom logic.
5. In order for your module to be detected by the runner you are required to add references to various lists. In order to register your module, add the corresponding module reference to the lists that can be found in the following files. (Hint: search other modules names to find the lists quicker)
- `src/runner/modules.h`
- `src/runner/modules.cpp`
- `src/runner/resource.h`
- `src/runner/settings_window.h`
- `src/runner/settings_window.cpp`
- `src/runner/main.cpp`
- `src/common/logger.h` (for logging)
6. ModuleInterface should build your `ModuleInterface.dll`. This will allow the runner to interact with your service.
> [!TIP]
> Mismatched module IDs are one of the most common causes of load failures. Keep your ID consistent across manifest, registry, and service.
---
## 4. Write your service
This is going to look different for every PowerToy. It may be easier to develop the application independently, and then link in the PowerToys settings logic later. But you have to write the service first, before connecting it to the runner.
### Notes
- This is a separate project from the Module Interface.
- You can develop this project using C# or C++.
- Set the service icon using the `.rc` file.
- Set the service name in the `.vcxproj` by setting the ``
```
..\..\..\..\$(Platform)\$(Configuration)\$(MSBuildProjectName)\PowerToys.LightSwitchService
```
- To view the code of the `.vcxproj`, right click the item and select **Unload project**
- Use the following functions to interact with settings from your service
```
ModuleSettings::instance().InitFileWatcher();
ModuleSettings::instance().LoadSettings();
auto& settings = ModuleSettings::instance().settings();
```
These come from the `ModuleSettings.h` file that lives with the Service. You can copy this from another module (e.g., Light Switch) and adjust to fit your needs.
If your module has a user interface:
- Use the **WinUI Blank App** template when setting up your project
- Use [Windows design best practices](https://learn.microsoft.com/windows/apps/design/basics/)
- Use the [WinUI 3 Gallery](https://apps.microsoft.com/detail/9p3jfpwwdzrc) for help with your UI code, and additional guidance.
## 5. Settings integration
PowerToys settings are stored per-module as JSON under:
```
%LOCALAPPDATA%\Microsoft\PowerToys\\settings.json
```
### Implementation steps
- In `src\settings-ui\Settings.UI.Library\` create `Properties.cs` and `Settings.cs`
- `Properties.cs` is where you will define your defaults. Every setting needs to be represented here. This should match what was set in the Module Interface.
- `Settings.cs`is where your settings.json will be built from. The structure should match the following
```cs
public ModuleSettings()
{
Name = ModuleName;
Version = Assembly.GetExecutingAssembly().GetName().Version.ToString();
Properties = new ModuleProperties(); // settings properties you set above.
}
```
- In `src\settings-ui\Settings.UI\ViewModels` create `ViewModel.cs` this is where the interaction happens between your settings page in the PowerToys app and the settings file that is stored on the device. Changes here will trigger the settings watcher via a `NotifyPropertyChanged` event.
- Create a `SettingsPage.xaml` at `src\settings-ui\Settings.UI\SettingsXAML\Views`. This will be the page where the user interacts with the settings of your module.
- Be sure to use resource strings for user facing strings so they can be localized. (`x:Uid` connects to Resources.resw)
```xaml
// LightSwitch.xaml
// Resources.resw
Off
```
> [!IMPORTANT]
> In the above example we use `.Content` to target the content of the Combobox. This can change per UI element (e.g., `.Text`, `.Header`, etc.)
> **Reminder:** Manual changes via external editors (VS Code, Notepad) do **not** trigger the settings watcher. Only changes written through PowerToys trigger reloads.
---
### Gotchas:
- Only use the WinUI 3 framework, _not_ UWP.
- Use [`DispatcherQueue`](https://learn.microsoft.com/windows/apps/develop/dispatcherqueue) when updating UI from non-UI threads.
---
## 6. Building and debugging
### Debugging steps
1. If this is your first time debugging PowerToys, be sure to follow [these steps first](https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/development/debugging.md#pre-debugging-setup).
2. Set "runner" as the start up project and ensure your build configuration is set to match your system (ARM64/x64)
3. Select F5 or the **Local Windows Debugger** button to begin debugging. This should start the PowerToys runner.
4. To set breakpoints in your service, select Ctrl+Alt+P and search for your service to attach to the runner.
5. Use logs to document changes. The logs live at `%LOCALAPPDATA%\Microsoft\PowerToys\RunnerLogs` and `%LOCALAPPDATA%\Microsoft\PowerToys\Module\Service\` for the specific module.
> [!TIP]
> PowerToys caches `.nuget` artifacts aggressively. Use `git clean -xfd` when builds behave unexpectedly.
---
## 7. Installer and packaging (WiX)
### Add your module to installer
1. Install [`WixToolset.Heat`](https://www.nuget.org/packages/WixToolset.Heat/) for Wix5 via nuget
2. Inside `installer\PowerToysInstallerVNext` add a new file for your module: `Module.wxs`
3. Inside of this file you will need copy the format from another module (ie: Light Switch) and replace the strings and GUID values.
4. The key part will be `` which is a placeholder for code that will be generated by `generateFileComponents.ps1`.
5. Inside `Product.wxs` add a line item in the `` section. It will look like a list of ` ` items.
6. Inside `generateFileComponents.ps1` you will need to add an entry to the bottom for your new module. It will follow the following format. `-fileListName Files` will match the string you set in `Module.wxs`, `` will match the name of your exe.
```bash
# Module Name
Generate-FileList -fileDepsJson "" -fileListName Files -wxsFilePath $PSScriptRoot\.wxs -depsPath "$PSScriptRoot..\..\..\$platform\Release\"
Generate-FileComponents -fileListName "Files" -wxsFilePath $PSScriptRoot\.wxs -regroot $registryroot
```
---
## 8. Testing and validation
### UI tests
- Place under `/modules//Tests`
- Create a new [WinUI Unit Test App](https://learn.microsoft.com/windows/apps/winui/winui3/testing/create-winui-unit-test-project)
- Write unit tests following the format from previous modules (ie: Light Switch). This can be to test your standalone UI (if you're a module like Color Picker) or to verify that the Settings UI in the PowerToys app is controlling your service.
### Manual validation
- Enable/disable in PowerToys Settings
- Check initialization in logs
- Confirm icons, tooltips, and OOBE page appear correctly
### Pro tips
1. Validate wake/sleep and elevation states. Background modules often fail silently after resume if event handles aren’t recreated.
2. Use Windows Sandbox to simulate clean install environments
3. To simulate a "new user" you can delete the PowerToys folder from `%LOCALAPPDATA%\Microsoft`
### Shortcut conflict detection
If your module has a shortcut, ensure that it is properly registered following [the steps listed in the documentation](https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/core/settings/settings-implementation.md#shortcut-conflict-detection) for conflict detection.
---
## 9. The final touches
### Out-of-Box experience (OOBE) page
The OOBE page is a custom settings page that gives the user at a glance information about each module. This window opens before the Settings application for new users and after updates. Create `OOBE.xaml` at `src\settings-ui\Settings.UI\SettingsXAML\OOBE\Views`. You will also need to add your module name to the enum at `src\settings-ui\Settings.UI\OOBE\Enums\PowerToysModules.cs`.
### Module assets
Now that your PowerToy is _done_ you can start to think about the assets that will represent your module.
- Module Icon: This will be displayed in a number of places: OOBE page, in the README, on the home screen of PowerToys, on your individual module settings page, etc.
- Module Image: This is the image you see at the top of each individual settings page.
- OOBE Image: This is the header you see on the OOBE page for each module
> [!NOTE]
> This step is something that the Design team will handle internally to ensure consistency throughout the application. If you have ideas or recommendations on what the icon or screenshots should be for your module feel free to leave it in the "Additional Comments" section of the PR and the team will take it into consideration.
### Documentation
There are two types of documentation that will be required when submitting a new PowerToy:
1. Developer documentation: This will live in the [PowerToys repo](https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/modules) at `/doc/devdocs/modules/` and should tell a developer how to work on your app. It should outline the module architecture, key files, testing, and tips on debugging if necessary.
2. Microsoft Learn documentation: When your new Module is ready to be merged into the PowerToys repository, an internal team member will create Microsoft Learn documentation so that users will understand how to use your module. There is not much work on your end as the developer for this step, but keep an eye on your PR in case we need more information about your PowerToy for this step.
---
Thank you again for contributing! If you need help, feel free to [open an issue](https://github.com/microsoft/PowerToys/issues/new/choose) and use the `Needs-Team-Response` label so we know you need attention.
---
### Doc Devdocs Development Style (`doc/devdocs/development/style.md`)
# Coding Style
## Philosophy
1. If it's inserting something into the existing classes/functions, try to follow the existing style as closely as possible.
1. If it's brand new code or refactoring a complete class or area of the code, please follow as Modern C++ of a style as you can and reference the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines) as much as you possibly can.
## Formatting
- We use [XamlStyler](https://github.com/Xavalon/XamlStyler/) to format XAML files. You can use the [Visual Studio Extension](https://marketplace.visualstudio.com/items?itemName=TeamXavalon.XAMLStyler2022) or apply formatting executing `.\.pipelines\applyXamlStyling.ps1 -Main`.
- We use [`.clang-format`](https://github.com/microsoft/PowerToys/blob/main/src/.clang-format) style file to enable automatic code formatting. You can [easily format source files from Visual Studio](https://devblogs.microsoft.com/cppblog/clangformat-support-in-visual-studio-2017-15-7-preview-1/). For example, `CTRL+K CTRL+D` formats the current document.
- If you prefer another text editor or have ClangFormat disabled in Visual Studio, you could invoke [`format_sources`](https://github.com/microsoft/PowerToys/blob/main/src/codeAnalysis/format_sources.ps1) powershell script from command line. It gets a list of all currently modified files from `git` and invokes clang-format on them.
Please note that you should also have `clang-format.exe` in `%PATH%` for it to work. The script can infer the path of `clang-format.exe` version which is shipped with Visual Studio at `%VCINSTALLDIR%\Tools\Llvm\bin\`, if you launch it from the *Native Tools Command Prompt for VS*.
- CI doesn't enforce code formatting yet, since we're gradually applying code formatting to the codebase, but please adhere to our formatting style for any new code.
---
### Doc Devdocs Development Test Winget Install Locally (`doc/devdocs/development/test-winget-install-locally.md`)
## If for any reason, you'd like to test winget install scenario, you can follow this doc:
### Powertoys winget manifest definition:
[winget repository](https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/PowerToys)
### How to test a winget installation locally:
1. Get artifacts from release CI pipeline Pipelines - Runs for PowerToys Signed YAML Release Build, or you can build one yourself by execute the
'tools\build\build-installer.ps1' script
2. Get the artifact hash, this is required to define winget manifest
```powershell
cd /path/to/your/directory/contains/installer
Get-FileHash -Path ".\.exe" -Algorithm SHA256
```
3. Host your installer.exe - Attention: staged github release artifacts or artifacts in release pipeline is not OK in this step
You can self-host it or you can upload to a publicly available endpoint
**How to selfhost it** (A extremely simple way):
```powershell
python -m http.server 8000
```
4. Download a version folder from wingetpkgs like: [version 0.92.1](https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/PowerToys/0.92.1)
and you get **a folder contains 3 yml files**
>note: Do not put any files other than these three in this folder
5. Modify the yml files based on your version and the self hosted artifact link, and modify the sha256 hash for the installer you'd like to use
6. Start winget install:
```powershell
#execute as admin
winget settings --enable LocalManifestFiles
winget install --manifest "" --architecture x64 --scope user
```
---
### Doc Devdocs Development Ui Tests (`doc/devdocs/development/ui-tests.md`)
# UI tests framework
PowerToys provides UI-test frameworks for modules and Settings. New tests should use
`Microsoft.PowerToys.UITest.Next`, which drives Windows UI Automation through `winappcli` and runs as
a Microsoft.Testing.Platform executable. The legacy `Microsoft.PowerToys.UITest` framework uses
WinAppDriver/Selenium and remains documented for existing suites and migration baselines.
## Agent-assisted workflows
Two repository skills cover the complete implementation and validation loop:
- [UI-tests migration skill](../../../.github/skills/ui-tests-migration/SKILL.md): create new
`.Next` test projects, port legacy WinAppDriver tests, design stable selectors/waits/lifecycle, and
prepare tests for CI.
- [Local-VM UI-tests skill](../../../.github/skills/ui-tests-local-vm/SKILL.md): create persistent
Windows 10 and Windows 11 Hyper-V guests, stage current build/test artifacts, execute tests in a
standard-user interactive desktop, and collect durable TRX/log/screenshot/video evidence.
For new or migrated tests, use both skills. Build first, then use the local VMs as the default live
agentic loop: run one deterministic test, diagnose and fix it, and finally widen to the complete
module suite on both supported Windows versions.
Module-specific constraints are documented with the module; for example, see the
[PowerRename UI-test notes](../modules/powerrename.md#ui-tests) for command-line selection, Boost
engine lifetime, and signed shell-extension requirements.
Read the [Environment Variables safety notes](../modules/environmentvariables.md#ui-tests) before
running that suite: it temporarily replaces the real User PATH and must run only in a disposable VM,
not on a working machine.
## Before running tests
### `.Next` tests
- Build the PowerToys runtime and `.UITests.Next` test executable.
- Install the pinned `winappcli` runtime or set `WINAPP_CLI_PATH`. The pipeline helper is
`.pipelines/InstallWinAppCli.ps1`.
- Use a live interactive desktop. UIA, foreground input, Explorer, hotkeys, and rendering do not work
in session 0.
- Exit an existing PowerToys instance before a host-desktop run. The harness owns the runner and
module lifecycle.
### Legacy tests
- Install Windows Application Driver v1.2.1 from https://github.com/microsoft/WinAppDriver/releases/tag/v1.2.1 to the default directory (`C:\Program Files (x86)\Windows Application Driver`)
- Enable Developer Mode in Windows settings
## Running tests
### `.Next` tests
Build the focused project with the repository script, then run the produced Microsoft.Testing.Platform
executable directly:
```pwsh
tools\build\build.cmd `
-Path src\modules\\Tests\.UITests.Next `
-Platform x64 `
-Configuration Debug
$exe = 'x64\Debug\tests\.UITests.Next\net10.0-windows10.0.26100.0\.UITests.Next.exe'
& $exe `
--filter 'TestCategory=' `
--report-trx `
--report-trx-filename module.trx `
--results-directory .\TestResults\ `
--timeout 7m
```
Use explicit filter properties such as `Name=`, `Name~`, `FullyQualifiedName~`, or `TestCategory=`.
A bare display name can select zero tests. The `7m` timeout above is a focused-filter example; choose
a larger value for a module or project-wide run.
### Legacy tests
- Exit PowerToys if it's running.
- Open `PowerToys.slnx` in Visual Studio and build the solution.
- Run tests in the Test Explorer (`Test > Test Explorer` or `Ctrl+E, T`).
## Running `.Next` tests in persistent local VMs
The supported local backend is a pair of persistent Hyper-V guests driven through PowerShell Direct:
Windows 10 and Windows 11, each with an already logged-on standard-user desktop. The VMs reveal
first-run, profile, Explorer, WebView2, foreground, and lifecycle assumptions without modifying the
host profile, while retaining staged payloads for a fast edit/build/rerun loop.
### One-time host setup
Scaffold a VM root outside the repository, then follow the generated next steps to create the
untracked configuration:
```pwsh
pwsh .github\skills\ui-tests-local-vm\scripts\Initialize-LocalVm.ps1 `
-DestinationRoot C:\PowerToysUiTestVm
pwsh .github\skills\ui-tests-local-vm\scripts\Initialize-LocalVmHost.ps1 `
-VmRoot C:\PowerToysUiTestVm `
-CheckOnly
```
If `-CheckOnly` reports `IsReady=false`, a human must run the elevated setup command it prints.
Hyper-V group membership, the DPAPI-protected guest administrator credential, and guest creation
cannot be completed by an agent. See the [setup reference](../../../.github/skills/ui-tests-local-vm/references/setup.md)
for install media, `vm.config.psd1`, Windows 10/11 guest creation, and baseline checkpoints.
### Run the agentic loop
Create a module exchange containing `ui-tests.zip`, `powertoys-runtime.zip`, `winappcli.zip`, and
`dotnet-runtime.zip` as described in the
[agentic-loop reference](../../../.github/skills/ui-tests-local-vm/references/agentic-loop.md). Payloads
are extracted to guest-local storage; tests are never run directly from a host share.
```pwsh
$vmRoot = 'C:\PowerToysUiTestVm'
$exchange = "$vmRoot\shared\PowerToysUiTests\"
pwsh .github\skills\ui-tests-local-vm\scripts\Invoke-LocalVmUiTest.ps1 `
-VmName PowerToysUiTest-Win11 `
-ConfigurationPath "$vmRoot\vm.config.psd1" `
-VmRoot $vmRoot `
-ExchangeRoot $exchange `
-TestExecutable '.UITests.Next.exe' `
-Filter 'Name=.FocusedTest' `
-Platform x64Win11 `
-BuildLabel (git rev-parse HEAD) `
-SuiteTimeout 15m `
-TimeoutMinutes 25 `
-ReuseStagedPayload
```
The controller starts the guest if needed, validates the standard-user token, Explorer session, and
desktop size, then runs the test through a limited interactive scheduled task. It streams progress
and returns `status.json`, TRX counters, per-test failures, logs, screenshots, and retained failure
recordings under `\LocalVmResults\`.
After each source change, rebuild and replace only the changed archive, then rerun the same focused
filter with `-ReuseStagedPayload`. Widen only after that behavior is understood. A module is complete
only after the full category filter passes with `executed == total` on both Windows 10 and Windows 11;
restore the baseline checkpoint for the final clean-profile confirmation. See the local-VM
[troubleshooting guide](../../../.github/skills/ui-tests-local-vm/references/troubleshooting.md) for
desktop, PowerShell Direct, payload, shell-extension signing, and evidence failures.
## Running tests in pipeline
The PowerToys UI test pipeline provides flexible options for building and testing:
### Pipeline Options
- **buildSource**: Select the build type for testing:
- `latestMainOfficialBuild`: Downloads and uses the latest official PowerToys build from main branch
- `buildNow`: Builds PowerToys from current source code and uses it for testing
- `specificBuildId`: Downloads a specific PowerToys build using the build ID specified in `specificBuildId` parameter
**Default value**: `latestMainOfficialBuild`
- **specificBuildId**: When `buildSource` is set to `specificBuildId`, specify the exact PowerToys build ID to download and test against.
**Default value**: `"xxxx"` (placeholder, enter actual build ID when using specificBuildId option)
**When to use this**:
- Testing against a specific known build for reproducibility
- Regression testing against a particular build version
- Validating fixes in a specific build before release
**Usage**: Enter the build ID number (e.g., `12345`) to download that specific build. Only used when `buildSource` is set to `specificBuildId`.
- **uiTestModules**: Specify which UI test modules to build and run. This parameter controls both the `.csproj` projects to build and the `.dll` test assemblies to execute. Examples:
- `['UITests-FancyZones']` - Only FancyZones UI tests
- `['MouseUtils.UITests']` - Only MouseUtils UI tests
- `['UITests-FancyZones', 'MouseUtils.UITests']` - Multiple specific modules
- Leave empty to build and run all UI test modules
**Important**: The `uiTestModules` parameter values must match both the test project names (for `.csproj` selection during build) and the test assembly names (for `.dll` execution during testing).
### Build Modes
1. **Official Build Testing** (`buildSource = latestMainOfficialBuild` or `specificBuildId`)
- Downloads and installs official PowerToys build (latest from main or specific build ID)
- Builds only UI test projects (all or specific based on `uiTestModules`)
- Runs UI tests against installed PowerToys
- Tests both machine-level and per-user installation modes automatically
2. **Current Source Build Testing** (`buildSource = buildNow`)
- Builds entire PowerToys solution from current source code
- Builds UI test projects (all or specific based on `uiTestModules`)
- Runs UI tests against freshly built PowerToys
- Uses artifacts from current pipeline build
> **Note**: All modes support the `uiTestModules` parameter to control which specific UI test modules to build and run. Both machine-level and per-user installation modes are tested automatically when using official builds.
### Pipeline Access
- Pipeline: https://microsoft.visualstudio.com/Dart/_build?definitionId=161438&_a=summary
## How to add the first UI tests for your modules
Use the [UI-tests migration skill](../../../.github/skills/ui-tests-migration/SKILL.md) for new
`.Next` projects and ports. It contains the current executable project scaffold, API mapping, naming,
CI-stability checklist, and validated examples.
The project sample below describes the **legacy WinAppDriver framework** and is retained for existing
legacy suites. Do not use it as the starting point for a new `.Next` project.
- Follow the naming convention:
- Create a new project and add the following references to the project file. Change the OutputPath to your own module's path.
```
{4E0AE3A4-2EE0-44D7-A2D0-8769977254A0}PowerToys.Hosts.UITestsPowerToys.Hosts.UITestsfalsetrueenableLibraryfalse$(SolutionDir)$(Platform)\$(Configuration)\tests\Hosts.UITests\
```
- Inherit your test class from UITestBase.
>Set Scope: The default scope starts from the PowerToys settings UI. If you want to start from your own module, set the constructor as shown below:
>Specify Scope:
```
[TestClass]
public class HostModuleTests : UITestBase
{
public HostModuleTests()
: base(PowerToysModule.Hosts, WindowSize.Small_Vertical)
{
}
}
```
- Then you can start performing the UI operations.
**Example**
```
[TestMethod("Hosts.Basic.EmptyViewShouldWork")]
[TestCategory("Hosts File Editor #4")]
public void TestEmptyView()
{
this.CloseWarningDialog();
this.RemoveAllEntries();
// 'Add an entry' button (only show-up when list is empty) should be visible
Assert.IsTrue(this.HasOne("Add an entry"), "'Add an entry' button should be visible in the empty view");
VisualAssert.AreEqual(this.TestContext, this.Find("Entries"), "EmptyView");
// Click 'Add an entry' from empty-view for adding Host override rule
this.Find("Add an entry").Click();
this.AddEntry("192.168.0.1", "localhost", false, false);
// Should have one row now and not more empty view
Assert.IsTrue(this.Has
Advanced Paste](https://aka.ms/PowerToysOverview_AdvancedPaste) | [
Always on Top](https://aka.ms/PowerToysOverview_AoT) | [
Awake](https://aka.ms/PowerToysOverview_Awake) |
| [
Color Picker](https://aka.ms/PowerToysOverview_ColorPicker) | [
Command Not Found](https://aka.ms/PowerToysOverview_CmdNotFound) | [
Command Palette](https://aka.ms/PowerToysOverview_CmdPal) |
| [
Crop And Lock](https://aka.ms/PowerToysOverview_CropAndLock) | [
Environment Variables](https://aka.ms/PowerToysOverview_EnvironmentVariables) | [
FancyZones](https://aka.ms/PowerToysOverview_FancyZones) |
| [
File Explorer Add-ons](https://aka.ms/PowerToysOverview_FileExplorerAddOns) | [
File Locksmith](https://aka.ms/PowerToysOverview_FileLocksmith) | [
Grab And Move](https://aka.ms/PowerToysOverview_GrabAndMove) |
| [
Hosts File Editor](https://aka.ms/PowerToysOverview_HostsFileEditor) | [
Image Resizer](https://aka.ms/PowerToysOverview_ImageResizer) | [
Keyboard Manager](https://aka.ms/PowerToysOverview_KeyboardManager) |
| [
Light Switch](https://aka.ms/PowerToysOverview_LightSwitch) | [
Mouse Utilities](https://aka.ms/PowerToysOverview_MouseUtilities) | [
Mouse Without Borders](https://aka.ms/PowerToysOverview_MouseWithoutBorders) |
| [
New+](https://aka.ms/PowerToysOverview_NewPlus) | [
Peek](https://aka.ms/PowerToysOverview_Peek) | [
PowerDisplay](https://aka.ms/PowerToysOverview_PowerDisplay) |
| [
PowerRename](https://aka.ms/PowerToysOverview_PowerRename) | [
PowerToys Run](https://aka.ms/PowerToysOverview_PowerToysRun) | [
Quick Accent](https://aka.ms/PowerToysOverview_QuickAccent) |
| [
Registry Preview](https://aka.ms/PowerToysOverview_RegistryPreview) | [
Screen Ruler](https://aka.ms/PowerToysOverview_ScreenRuler) | [
Shortcut Guide](https://aka.ms/PowerToysOverview_ShortcutGuide) |
| [
Text Extractor](https://aka.ms/PowerToysOverview_TextExtractor) | [
Window Hopper](https://aka.ms/PowerToysOverview_WindowHopper) | [
Workspaces](https://aka.ms/PowerToysOverview_Workspaces) |
| [
ZoomIt](https://aka.ms/PowerToysOverview_ZoomIt) | | |
## 📦 Installation
For detailed installation instructions and system requirements, visit the [installation docs](https://learn.microsoft.com/windows/powertoys/install).
But to get started quickly, choose one of the installation methods below:
### Install PowerToys to empty disk
### PowerToys installation directory size shown by File Explorer
As mentioned above, File Explorer shows size of PowerToys installation dir as every hard-link is a regular file for itself
### PowerToys size shown by App->Installed apps
### Disk usage with PowerToys installed
Real disk usage of PowerToys is shown by inspecting disk usage after installing PowerToys. Used space is now 695MB, comparing to ~35MB used space for empty disk gives us the size of ~660MB for PowerToys installation dir.
### PowerShell command calculating size of non-hardlinks files
Size of regular files (non-hard-links) and hard-links can also be obtained by running following PowerShell command in PowerToys installation dir:
```
Regular files:
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -ne HardLink | Measure-Object -Property Length -Sum
Hard-links
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -e HardLink | Measure-Object -Property Length -Sum
```
Running these commands for PowerToys v0.66 shows that size of regular files is way less than size of hard-links pointing to some of those regular files because PowerShell (same as File Explorer) also takes the size of hard-links as of regular files.
---
### Doc Devdocs Embedded Msix (`doc/devdocs/embedded-msix.md`)
# How to integrate new MSIX module with PowerToys Settings and WiX installer
[`issue_11705_with_example` branch](https://github.com/microsoft/PowerToys/tree/issue_11705_with_example) contains HelloWorld UWP C# MSIX application which reads its module settings and is installed along PowerToys.
## Steps
- uncomment everything near "TODO: Use to activate embedded MSIX" comments
- build PowerToys solution
- deploy HelloModule module and sign it with a self-signed certificate (don't forget to put it into a trusted store)
- build PowerToysSetup solution and install it
Type HelloModule into start search and observe that it was installed:
Open PowerToys settings and change the stub setting to something:
Open HelloModule:
First time you press "Load Settings", it'll detect that it doesn't have permissions to access local file system and open its system settings window, toggle it there:
(it's a known uwp limitation, see https://stackoverflow.com/a/53533414/657390)
HelloModule will close then, restart it, press "Load Settings" and you should see that the application was able to load the setting string which was set by the settings app:
---
### Doc Devdocs Events (`doc/devdocs/events.md`)
# Telemetry Events
PowerToys collects limited telemetry to understand feature usage, reliability, and product quality. When adding a new telemetry event, follow the steps below to ensure the event is properly declared, documented, and available after release.
**⚠️ Important**: Telemetry must never include personal information, file paths, or user‑generated content.
## Developer Effort Overview (What to Expect)
Adding a telemetry event is a **multi-step process** that typically spans several areas of the codebase and documentation.
At a high level, developers should expect to:
1. Within one PR:
1. Add a new telemetry event(s) to module
1. Add the new event(s) DATA_AND_PRIVACY.md
1. Reach out to @carlos-zamora or @chatasweetie so internal scripts can process new event(s)
### Privacy Guidelines
**NEVER** log:
- User data (text, files, emails, etc.)
- File paths or filenames
- Personal information
- Sensitive system information
- Anything that could identify a specific user
DO log:
- Feature usage (which features, how often)
- Success/failure status
- Timing/performance metrics
- Error types (not error messages with user data)
- Aggregate counts
### Event Naming Convention
Follow this pattern: `UtilityName_EventDescription`
Examples:
- `ColorPicker_Session`
- `FancyZones_LayoutApplied`
- `PowerRename_Rename`
- `AdvancedPaste_FormatClicked`
- `CmdPal_ExtensionInvoked`
## Adding Telemetry Events to PowerToys
PowerToys uses ETW (Event Tracing for Windows) for telemetry in both C++ and C# modules. The telemetry system is:
- Opt-in by default (disabled since v0.86)
- Privacy-focused - never logs personal info, file paths, or user-generated content
- Controlled by registry - HKEY_CURRENT_USER\Software\Classes\PowerToys\AllowDataDiagnostics
### C++ Telemetry Implementation
**Core Components**
| File | Purpose |
| ------------- |:-------------:|
| [ProjectTelemetry.h](../../src/common/Telemetry/ProjectTelemetry.h) | Declares the global ETW provider g_hProvider |
| [TraceBase.h](../../src/common/Telemetry/TraceBase.h) | Base class with RegisterProvider(), UnregisterProvider(), and IsDataDiagnosticsEnabled() check |
| [TraceLoggingDefines.h](../../src/common/Telemetry/TraceLoggingDefines.h) | Privacy tags and telemetry option group macros
#### Pattern for C++ Modules
1. Create a `Trace` class inheriting from `telemetry::TraceBase` (src/common/Telemetry/TraceBase.h):
```c
// trace.h
#pragma once
#include