[DevDocs] More content and restructure (#40165)

## Summary of the Pull Request
Accumulated information from internal transition about the modules
development, and reworked it to be added in dev docs. Also the dev docs
intself was restructured to be more organized. New pages was
verified by transition team.

## PR Checklist
- [x] **Dev docs:** Added/updated

---------

Co-authored-by: Zhaopeng Wang (from Dev Box) <zhaopengwang@microsoft.com>
Co-authored-by: Hao Liu <liuhao3418@gmail.com>
Co-authored-by: Peiyao Zhao <105847726+zhaopy536@users.noreply.github.com>
Co-authored-by: Mengyuan <162882040+chenmy77@users.noreply.github.com>
Co-authored-by: zhaopeng wang <33367956+wang563681252@users.noreply.github.com>
Co-authored-by: Jaylyn Barbee <51131738+Jaylyn-Barbee@users.noreply.github.com>

doc/Fuzzing/CppFuzzingGuide.md

@@ -1,117 +0,0 @@
-# 🧪 C++ Project Fuzzing Test Guide
-
-This guide walks you through setting up a **fuzzing test** project for a C++ module using [libFuzzer](https://llvm.org/docs/LibFuzzer.html).
-.
-
----
-
-## 🏗️ Step-by-Step Setup
-
-### 1. Create a New C++ Project
-
-- Use **Empty Project** template.
-- Name it `<ModuleName>.FuzzingTest`.
-
----
-
-### 2. Update Build Configuration
-
-- In **Configuration Manager**, Uncheck Build for both Release|ARM64, Debug|ARM64 and Debug|x64 configurations.
-- Note: ARM64 is not supported in this case, so leave ARM64 configurations build disabled.
----
-
-### 3. Enable ASan and libFuzzer in `.vcxproj`
-
-Edit the project file to enable fuzzing:
-
-```xml
-<PropertyGroup>
-  <EnableASAN>true</EnableASAN>
-  <EnableFuzzer>true</EnableFuzzer>
-</PropertyGroup>
-```
-
----
-
-### 4. Add Fuzzing Compiler Flags
-
-Add this to `AdditionalOptions` under the `Fuzzing` configuration:
-
-```xml
-/fsanitize=address
-/fsanitize-coverage=inline-8bit-counters
-/fsanitize-coverage=edge
-/fsanitize-coverage=trace-cmp
-/fsanitize-coverage=trace-div
-%(AdditionalOptions)
-```
-
----
-
-### 5. Link the Sanitizer Coverage Runtime
-
-In `Linker → Input → Additional Dependencies`, add:
-
-```text
-$(VCToolsInstallDir)lib\$(Platform)\libsancov.lib
-```
-
----
-
-### 6. Copy Required Runtime DLL
-
-Add a `PostBuildEvent` to copy the ASAN DLL:
-
-```xml
-<Command>
-  xcopy /y "$(VCToolsInstallDir)bin\Hostx64\x64\clang_rt.asan_dynamic-x86_64.dll" "$(OutDir)"
-</Command>
-```
-
----
-
-### 7. Add Preprocessor Definitions
-
-To avoid annotation issues, add these to the `Preprocessor Definitions`:
-
-```text
-_DISABLE_VECTOR_ANNOTATION;_DISABLE_STRING_ANNOTATION
-```
-
----
-
-## 🧬 Required Code
-
-### `LLVMFuzzerTestOneInput` Entry Point
-
-Every fuzzing project must expose this function:
-
-```cpp
-extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
-{
-    std::string input(reinterpret_cast<const char*>(data), size);
-
-    try
-    {
-        // Call your module with the input here.
-    }
-    catch (...) {}
-
-    return 0;
-}
-```
-
----
-
-## ⚙️ [Test run in the cloud](https://eng.ms/docs/cloud-ai-platform/azure-edge-platform-aep/aep-security/epsf-edge-and-platform-security-fundamentals/the-onefuzz-service/onefuzz/faq/notwindows/walkthrough)
-
-To submit a job to the cloud you can run with this command:
-
-```
-oip submit --config .\OneFuzzConfig.json --drop-path <your_submission_directory> --platform windows --do-not-file-bugs --duration 1
-```
-You want to run with --do-not-file-bugs because if there is an issue with running the parser in the cloud (which is very possible), you don't want bugs to be created if there is an issue. The --duration task is the number of hours you want the task to run. I recommend just running for 1 hour to make sure things work initially. If you don't specify this parameter, it will default to 48 hours. You can find more about submitting a test job here. 
-
-OneFuzz will send you an email when the job has started.
-
----

doc/devdocs/common/FilePreviewCommon.md

@@ -8,6 +8,8 @@ Monaco preview enables to display developer files. It is based on [Microsoft's M
 
 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.

doc/devdocs/common/context-menus.md

@@ -0,0 +1,102 @@
+# 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\<module>\<module>.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.md

@@ -0,0 +1,77 @@
+# 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.md

@@ -0,0 +1,78 @@
+# 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.md

@@ -0,0 +1,135 @@
+# PowerToys Installer
+
+## Installer Architecture (WiX 3)
+
+- 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 `PowerToysSetupCustomActions` 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
+
+#### Prerequisites for building the MSI installer
+
+1. Install the [WiX Toolset Visual Studio 2022 Extension](https://marketplace.visualstudio.com/items?itemName=WixToolset.WixToolsetVisualStudio2022Extension).
+1. Install the [WiX Toolset build tools](https://github.com/wixtoolset/wix3/releases/tag/wix3141rtm). (installer [direct link](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314.exe))
+1. Download [WiX binaries](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314-binaries.zip) and extract `wix.targets` to `C:\Program Files (x86)\WiX Toolset v3.14`.
+
+#### Building prerequisite projects
+
+##### From the command line
+
+1. From the start menu, open a `Developer Command Prompt for VS 2022`
+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.sln`
+1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
+1. From the `Build` menu choose `Build Solution`.
+
+The resulting `PowerToysSetup.msi` installer will be available in the `installer\PowerToysSetup\x64\Release\` folder.
+
+### 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.md

@@ -0,0 +1,197 @@
+# 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_keyboard_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/core/settings/gpo-integration.md

@@ -0,0 +1,64 @@
+# Group Policy Integration
+
+PowerToys settings can be controlled and enforced via Group Policy. This document describes how Group Policy integration is implemented in the settings system.
+
+## Overview
+
+Group Policy settings for PowerToys allow administrators to:
+
+- Enable or disable PowerToys entirely
+- Control which modules are available
+- Configure specific settings for individual modules
+- Enforce settings across an organization
+
+## Implementation Details
+
+When a setting is controlled by Group Policy:
+
+1. The UI shows the setting as locked (disabled)
+2. The module checks GPO settings before applying user settings
+3. GPO settings take precedence over user settings
+
+## Group Policy Settings Detection
+
+The settings UI checks for Group Policy settings during initialization:
+
+```csharp
+// Example code for checking if a setting is controlled by GPO
+bool isControlledByPolicy = RegistryHelper.GetGPOValue("PolicyKeyPath", "PolicyValueName", out object value);
+if (isControlledByPolicy)
+{
+    // Use the policy value and disable UI controls
+    setting.IsEnabled = false;
+    setting.Value = (bool)value;
+}
+```
+
+## UI Indication for Managed Settings
+
+When a setting is managed by Group Policy, the UI indicates this to the user:
+
+- Controls are disabled (grayed out)
+- A tooltip indicates the setting is managed by policy
+- The actual policy value is displayed
+
+## Testing Group Policy Settings
+
+To test Group Policy integration:
+
+1. Create a test GPO using the PowerToys ADMX template
+2. Apply settings in the Group Policy Editor
+3. Verify that the settings UI correctly reflects the policy settings
+4. Verify that the modules honor the policy settings
+
+## GPO Settings vs. User Settings
+
+The precedence order for settings is:
+
+1. Group Policy settings (highest priority)
+2. User settings (lower priority)
+3. Default settings (lowest priority)
+
+When a setting is controlled by Group Policy, attempts to modify it through the settings UI or programmatically will not persist, as the policy value will always take precedence.
+
+For more information on PowerToys Group Policy implementation, see the [GPO Implementation](/doc/devdocs/processes/gpo.md) documentation.

doc/devdocs/core/settings/readme.md

@@ -0,0 +1,19 @@
+# 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/core/settings/settings-implementation.md

@@ -0,0 +1,158 @@
+# Settings Implementation
+
+This document describes how settings are implemented in PowerToys modules, including code examples for C++ and C# modules, and details on debugging settings issues.
+
+## C++ Settings Implementation
+
+For C++ modules, the settings system is implemented in the following files:
+
+- `settings_objects.h` and `settings_objects.cpp`: Define the basic settings objects
+- `settings_helpers.h` and `settings_helpers.cpp`: Helper functions for reading/writing settings
+- `settings_manager.h` and `settings_manager.cpp`: Main interface for managing settings
+
+### Reading Settings in C++
+
+```cpp
+#include <common/settings_objects.h>
+#include <common/settings_helpers.h>
+
+auto settings = PowerToysSettings::Settings::LoadSettings(L"ModuleName");
+bool enabled = settings.GetValue(L"enabled", true);
+```
+
+### Writing Settings in C++
+
+```cpp
+PowerToysSettings::Settings settings(L"ModuleName");
+settings.SetValue(L"setting_name", true);
+settings.Save();
+```
+
+## C# Settings Implementation
+
+For C# modules, the settings are accessed through the `SettingsUtils` class in the `Microsoft.PowerToys.Settings.UI.Library` namespace:
+
+### Reading Settings in C#
+
+```csharp
+using Microsoft.PowerToys.Settings.UI.Library;
+
+// Read settings
+var settings = SettingsUtils.GetSettings<ModuleSettings>("ModuleName");
+bool enabled = settings.Enabled;
+```
+
+### Writing Settings in C#
+
+```csharp
+using Microsoft.PowerToys.Settings.UI.Library;
+
+// Write settings
+settings.Enabled = true;
+SettingsUtils.SaveSettings(settings.ToJsonString(), "ModuleName");
+```
+
+## Settings Handling in Modules
+
+Each PowerToys module must implement settings-related functions in its module interface:
+
+```cpp
+// Get the module's settings
+virtual PowertoyModuleSettings get_settings() = 0;
+
+// Called when settings are changed
+virtual void set_config(const wchar_t* config_string) = 0;
+```
+
+When the user changes settings in the UI:
+
+1. The settings UI serializes the settings to JSON
+2. The JSON is sent to the PowerToys runner via IPC
+3. The runner calls the `set_config` function on the appropriate module
+4. The module parses the JSON and applies the new settings
+
+## Debugging Settings
+
+To debug settings issues:
+
+1. Check the settings files in `%LOCALAPPDATA%\Microsoft\PowerToys\`
+2. Ensure JSON is well-formed
+3. Monitor IPC communication between settings UI and runner using debugger breakpoints at key points:
+   - In the Settings UI when sending configuration changes
+   - In the Runner when receiving and dispatching changes
+   - In the Module when applying changes
+4. Look for log messages related to settings changes in the PowerToys logs
+
+### Common Issues
+
+- **Settings not saving**: Check file permissions or conflicts with other processes accessing the file
+- **Settings not applied**: Verify IPC communication is working and the module is properly handling the configuration
+- **Incorrect settings values**: Check JSON parsing and type conversion in the module code
+
+## Adding a New Module with Settings
+
+Adding a new module with settings requires changes across multiple projects. Here's a step-by-step guide with references to real implementation examples:
+
+### 1. Settings UI Library (Data Models)
+
+Define the data models for your module's settings in the Settings UI Library project. These data models will be serialized to JSON configuration files stored in `%LOCALAPPDATA%\Microsoft\PowerToys\`.
+
+Example: [Settings UI Library implementation](https://github.com/shuaiyuanxx/PowerToys/pull/3/files#diff-9be1cb88a52ce119e5ff990811e5fbb476c15d0d6b7d5de4877b1fd51d9241c3)
+
+### 2. Settings UI (User Interface)
+
+#### 2.1 Add a navigation item in ShellPage.xaml
+
+The ShellPage.xaml is the entry point for the PowerToys settings, providing a navigation view of all modules. Add a navigation item for your new module.
+
+Example: [Adding navigation item](https://github.com/shuaiyuanxx/PowerToys/pull/3/files#diff-5a06e6e7a5c99ae327c350c9dcc10036b49a2d66d66eac79a8364b4c99719c6b)
+
+#### 2.2 Create a settings page for your module
+
+Create a new XAML page that contains all the settings controls for your module.
+
+Example: [New settings page](https://github.com/shuaiyuanxx/PowerToys/pull/3/files#diff-310fd49eba464ddf6a876dcf61f06a6f000ca6744f3a1f915c48c58384d7bacb)
+
+#### 2.3 Implement the ViewModel
+
+Create a ViewModel class that handles the settings data and operations for your module.
+
+Example: [ViewModel implementation](https://github.com/shuaiyuanxx/PowerToys/pull/3/files#diff-409472a53326f2288c5b76b87c7ea8b5527c43ede12214a15b6caabe0403c1d0)
+
+### 3. Module Implementation
+
+#### 3.1 Implement PowertoyModuleIface in dllmain.cpp
+
+The module interface must implement the PowertoyModuleIface to allow the runner to interact with it.
+
+Reference: [PowertoyModuleIface definition](https://github.com/microsoft/PowerToys/blob/cc644b19982d09fcd2122fe7590c77496c4973b9/src/modules/interface/powertoy_module_interface.h#L6C1-L35C4)
+
+#### 3.2 Implement Module UI
+
+Create a UI for your module using either WPF (like ColorPicker) or WinUI3 (like Advanced Paste).
+
+### 4. Runner Integration
+
+Add your module to the known modules list in the runner so it can be brought up and initialized.
+
+Example: [Runner integration](https://github.com/shuaiyuanxx/PowerToys/pull/3/files#diff-c07e4e5e9ce3c371d4c47f496b5f66734978a3c4f355c7e446c1ef19e086a4d6)
+
+### 5. Testing and Debugging
+
+1. Test each component individually:
+   - Verify settings serialization/deserialization
+   - Test module activation/deactivation
+   - Test IPC communication
+
+2. For signal-related issues, ensure all modules work correctly before debugging signal handling.
+
+3. You can debug each module directly in Visual Studio or by attaching to running processes.
+
+### Recommended Implementation Order
+
+1. Module/ModuleUI implementation
+2. Module interface (dllmain.cpp)
+3. Runner integration
+4. Settings UI implementation
+5. OOBE (Out of Box Experience) integration
+6. Other components

doc/devdocs/development/debugging.md

@@ -0,0 +1,98 @@
+# 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 2022
+2. Navigate to the repository root directory
+3. Run the following command(don't forget to set the correct platform):
+   ```
+   msbuild -restore -p:RestorePackagesConfig=true -p:Platform=ARM64 -m PowerToys.sln
+   ```
+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

doc/devdocs/development/guidelines.md

@@ -0,0 +1,146 @@
+# 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
+
+## 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.md

@@ -0,0 +1,223 @@
+# 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 [this](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:
+```
+<Target Name="GenerateResourceFiles" BeforeTargets="PrepareForBuild">
+    <Exec Command="powershell -NonInteractive -executionpolicy Unrestricted $(SolutionDir)tools\build\convert-resx-to-rc.ps1 $(MSBuildThisFileDirectory) resource.base.h resource.h ProjName.base.rc ProjName.rc" />
+</Target>
+```
+
+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 upper case (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:
+```
+<None Include="Resources.resx" />
+```
+
+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:
+```
+<EmbeddedResource Include="Properties\Resources.*.resx" />
+```
+
+**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.
+```
+<system:String x:Key="wox_plugin_calculator_plugin_name">Calculator</system:String>
+<system:String x:Key="wox_plugin_calculator_plugin_description">Allows to do mathematical calculations.(Try 5*3-2 in Wox)</system:String>
+<system:String x:Key="wox_plugin_calculator_not_a_number">Not a number (NaN)</system:String>
+```
+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:
+```
+<PRIResource Include="Strings\en-us\Resources.resw" />
+```
+to
+```
+<PRIResource Include="Strings\*\Resources.resw" />
+```
+
+## 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:
+```
+<Item ItemId=";EditKeyboard_WindowName" ItemType="0;.resx" PsrId="211" Leaf="true">
+    <Str Cat="Text">
+        <Val><![CDATA[Remap keys]]></Val>
+        <Tgt Cat="Text" Stat="Loc" Orig="New">
+            <Val><![CDATA[Remapper des touches]]></Val>
+        </Tgt>
+    </Str>
+    <Disp Icon="Str" />
+</Item>
+```
+The `<Tgt>` 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 `<Val><![CDATA[*]]></Val>` 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 `<Tgt>` 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:
+```
+<NamedResource name="GeneralSettings_RunningAsAdminText" uri="ms-resource://f4f787a5-f0ae-47a9-be89-5408b1dd2b47/Resources/GeneralSettings_RunningAsAdminText">
+    <Candidate qualifiers="Language-FR" type="String">
+        <Value>Running as administrator</Value>
+    </Candidate>
+    <Candidate qualifiers="Language-EN-US" isDefault="true" type="String">
+        <Value>Running as administrator</Value>
+    </Candidate>
+</NamedResource>
+```
+
+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:
+```
+<Component Id="ProjName_$(var.IdSafeLanguage)_Component" Directory="Resource$(var.IdSafeLanguage)ProjNameInstallFolder">
+    <File Id="ProjName_$(var.IdSafeLanguage)_File" Source="$(var.BinX64Dir)modules\ProjName\$(var.Language)\ProjName.resources.dll" />
+</Component>
+```
+
+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 <common.h>
+
+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
+  <data name="ValidUIDisplayString" xml:space="preserve">
+    <value>Description to be displayed on UI.</value>
+    <comment>This text is displayed when XYZ button clicked.</comment>
+  </data>
+```
+
+- 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.md

@@ -0,0 +1,147 @@
+# 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
+<Import Project="..\..\..\deps\spdlog.props" />
+```
+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/modules/advancedpaste.md

@@ -0,0 +1,31 @@
+# Advanced Paste
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/advanced-paste)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Advanced%20Paste%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Advanced%20Paste%22%20label%3AIssue-Bug)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen++label%3A%22Product-Advanced+Paste%22)
+
+## Overview
+
+Advanced Paste is a PowerToys module that provides enhanced clipboard pasting with formatting options and additional functionality.
+
+## Implementation Details
+
+[Source code](/src/modules/AdvancedPaste)
+
+TODO: Add implementation details
+
+## Debugging
+
+TODO: Add debugging information
+
+## Settings
+
+TODO: Add settings documentation
+
+## Future Improvements
+
+TODO: Add potential future improvements

doc/devdocs/modules/alwaysontop.md

@@ -0,0 +1,98 @@
+# Always on Top
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/always-on-top)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Always%20On%20Top%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20%20label%3A%22Product-Always%20On%20Top%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen++label%3A%22Product-Always+On+Top%22+)
+
+## Overview
+
+The Always on Top module allows users to pin windows on top of others, ensuring they remain visible even when switching between applications. The module provides visual indicators (customizable borders) to identify which windows are pinned.
+
+## Features
+
+- Pin any window to stay on top of other windows
+- Customizable border color, opacity, and thickness around pinned windows
+- User-defined keyboard shortcut for toggling window pinning
+- Visual indicators to identify pinned windows
+
+## Architecture
+
+### Main Components
+
+- **Hotkey Listener**: Detects the user-defined hotkey to toggle the Always on Top state
+- **AlwaysOnTop**: Manages the state of windows, ensuring the selected window stays on top
+- **Settings**: Stores user preferences and configurations
+- **WindowHook**: Hooks all window events
+
+### Data Flow
+
+1. The Hotkey Listener detects the hotkey press and notifies the AlwaysOnTop
+2. The AlwaysOnTop updates the window state and interacts with the operating system to keep the window on top
+3. User preferences are saved and loaded from the Settings
+
+## Code Structure
+
+### Key Files
+
+- **AlwaysOnTop.cpp**: Contains the core logic for the module, including initialization and event handling
+- **Settings.cpp**: Defines the settings structure and provides methods to load and save settings
+- **main.cpp**: Starts thread and initializes AlwaysOnTop
+
+### Initialization
+
+The module is initialized in the AlwaysOnTop class. During initialization, the following steps are performed:
+
+1. **LoadSettings**: The module loads user settings from a configuration file
+2. **RegisterHotkey**: The HotkeyManager registers the keyboard shortcut for pinning/unpinning windows
+3. **SubscribeToEvents**: Event handlers are attached to respond to user actions, such as pressing the hotkey
+
+### Pinning and Unpinning Windows
+
+The AlwaysOnTop class handles the pinning and unpinning of windows. Key methods include:
+
+- **PinTopmostWindow**: Pins the specified window on top of others and applies visual indicators
+- **UnpinTopmostWindowss**: Removes the pinning status and visual indicators from the specified window
+- **AssignBorder**: Applies a colored border around the pinned window based on user settings
+
+### Settings Management
+
+The Settings class manages the module's settings. Key methods include:
+
+- **LoadSettings**: Loads settings from a configuration file
+- **NotifyObservers**: Distributes the data for the settings
+- **GetDefaultSettings**: Returns the default settings for the module
+
+## User Interface
+
+The module provides a user interface for configuring settings in the PowerToys Settings UI. This interface is implemented using XAML and includes options for customizing the:
+
+- Border color
+- Border opacity
+- Border thickness
+- Keyboard shortcut
+
+## Development Environment Setup
+
+### Prerequisites
+
+- Visual Studio 2019 or later
+- Windows 10 SDK
+- PowerToys repository cloned from GitHub
+
+### Building and Testing
+
+1. Clone the repository: `git clone https://github.com/microsoft/PowerToys.git`
+2. Open PowerToys.sln in Visual Studio
+3. Select the Release configuration and build the solution
+4. Run PowerToys.exe from the output directory to test the module
+
+### Debug
+1. build the entire project
+2. launch the built Powertoys
+3. select AlwaysOnTop as the startup project in VS
+4. In the debug button, choose "Attach to process". ![image](https://github.com/user-attachments/assets/a7624ec2-63f1-4720-9540-a916b0ada282)
+5. Attach to AlwaysOnTop.![image](https://github.com/user-attachments/assets/815c0f89-8fd1-48d6-b7fd-0e4a92e222d0)

doc/devdocs/modules/awake.md

@@ -0,0 +1,44 @@
+# Awake
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/awake)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-Awake)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20%20label%3AProduct-Awake)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen++label%3A%22Product-Awake%22+)
+
+## Overview
+Awake is a PowerToys utility designed to keep your computer awake without permanently modifying system power settings. It prevents the computer from sleeping and can keep the monitor on, providing a convenient alternative to changing system power configurations.
+
+## Key Features
+- Temporarily override system sleep settings
+- Keep monitor on (prevent display from turning off)
+- Set time intervals for keeping the system awake
+- One-time setup with no need to revert power settings afterward
+
+## Advantages Over System Power Settings
+- **Convenience**: Easy UI for quick toggling of sleep prevention
+- **Flexibility**: Support for different time intervals (indefinitely, for specific duration)
+- **Non-persistent**: Changes are temporary and don't require manual reversion
+- **Quick Access**: Available directly from the system tray
+
+## Architecture
+
+### Components
+- **System Tray UI**: Provides user interface for controlling Awake settings
+- **Backend Threads**: Manages the power state prevention functionality
+- **Command Line Interface**: Supports various commands for controlling Awake functionality programmatically
+
+## Technical Implementation
+Awake works by preventing system sleep through Windows power management APIs. The module runs as a background process that interfaces with the Windows power management system to keep the device awake according to user preferences.
+
+## User Experience
+Users can access Awake through the PowerToys system tray icon. From there, they can:
+1. Toggle Awake on/off
+2. Set a specific duration for keeping the system awake
+3. Choose whether to keep the display on or allow it to turn off
+4. Access additional configuration options
+
+## Command Line Support
+Awake includes command-line functionality for power users and automation scenarios, allowing programmatic control of the utility's features.

doc/devdocs/modules/colorpicker.md

@@ -0,0 +1,49 @@
+# Color Picker
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/color-picker)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Color%20Picker%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Color%20Picker%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen++label%3A%22Product-Color+Picker%22)
+
+## Overview
+Color Picker is a system-wide color picking utility for Windows that allows users to pick colors from any screen and copy them to the clipboard in a configurable format.
+
+## Implementation Details
+
+### Color Capturing Mechanism
+The Color Picker works by following these steps to capture the color at the current mouse position:
+
+1. Obtain the position of the mouse
+2. Create a 1x1 size rectangle at that position
+3. Create a Bitmap class and use it to initiate a Graphics object
+4. Create an image associated with the Graphics object by leveraging the CopyFromScreen function, which captures the pixel information from the specified location
+
+### Core Color Picking Function
+The following code snippet demonstrates the core functionality of how a color is picked from the screen:
+
+```csharp
+private static Color GetPixelColor(System.Windows.Point mousePosition)
+{
+    var rect = new Rectangle((int)mousePosition.X, (int)mousePosition.Y, 1, 1);
+    using (var bmp = new Bitmap(rect.Width, rect.Height, PixelFormat.Format32bppArgb))
+    {
+        var g = Graphics.FromImage(bmp);
+        g.CopyFromScreen(rect.Left, rect.Top, 0, 0, bmp.Size, CopyPixelOperation.SourceCopy);
+
+        return bmp.GetPixel(0, 0);
+    }
+}
+```
+
+## Features
+- Pick colors from any pixel on the screen
+- View color information in various formats (RGB, HEX, HSL, etc.)
+- Copy color values to clipboard in configurable formats
+- Color history for quick access to previously selected colors
+- Keyboard shortcuts for quick activation and operation
+
+## User Experience
+When activated, Color Picker displays a magnified view of the area around the cursor to allow for precise color selection. Once a color is selected, it can be copied to the clipboard in the user's preferred format for use in design tools, development environments, or other applications.

doc/devdocs/modules/commandnotfound.md

@@ -0,0 +1,43 @@
+# Command Not Found
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/cmd-not-found)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-CommandNotFound)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-CommandNotFound)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-CommandNotFound)
+
+## Overview
+Command Not Found is a PowerToys module that suggests package installations when you attempt to run a command that isn't available on your system. It integrates with the Windows command line to provide helpful suggestions for installing missing commands through package managers.
+
+## How it Works
+When you attempt to execute a command in the terminal that isn't found, the Command Not Found module intercepts this error and checks if the command is available in known package repositories. If a match is found, it suggests the appropriate installation command.
+
+## Installation
+The Command Not Found module requires the Microsoft.WinGet.CommandNotFound PowerShell module to function properly. When enabling the module through PowerToys, it automatically attempts to install this dependency.
+
+The installation is handled by the following script:
+```powershell
+# Located in PowerToys\src\settings-ui\Settings.UI\Assets\Settings\Scripts\EnableModule.ps1
+Install-Module -Name Microsoft.WinGet.CommandNotFound -Force
+```
+
+## Usage
+1. Enable the Command Not Found module in PowerToys settings.
+2. Open a terminal and try to run a command that isn't installed on your system.
+3. If the command is available in a package, you'll see a suggestion for how to install it.
+
+Example:
+```
+C:\> kubectl
+'kubectl' is not recognized as an internal or external command, operable program, or batch file.
+
+Command 'kubectl' not found, but can be installed with:
+    winget install -e --id Kubernetes.kubectl
+```
+
+## Technical Details
+The Command Not Found module leverages the Microsoft.WinGet.CommandNotFound PowerShell module, which is maintained in a separate repository: https://github.com/microsoft/winget-command-not-found
+
+The module works by registering a command-not-found handler that intercepts command execution failures and provides installation suggestions based on available packages in the WinGet repository.

doc/devdocs/modules/cropandlock.md

@@ -0,0 +1,45 @@
+# Crop and Lock
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/crop-and-lock)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-CropAndLock)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-CropAndLock)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-CropAndLock)
+
+## Overview
+
+The Crop and Lock module in PowerToys allows users to crop a current application into a smaller window or create a thumbnail. This utility enhances productivity by enabling users to focus on specific parts of an application window.
+
+## Features
+
+### Thumbnail Mode
+Creates a window showing the selected area of the original window. Changes in the original window are reflected in the thumbnail.
+
+### Reparent Mode
+Creates a window that replaces the original window, showing only the selected area. The application is controlled through the cropped window.
+
+## Code Structure
+
+### Project Layout
+The Crop and Lock module is part of the PowerToys solution. All the logic-related settings are in the main.cpp. The main implementations are in ThumbnailCropAndLockWindow and ReparentCropAndLockWindow. ChildWindow and OverlayWindow distinguish the two different modes of windows implementations.
+
+### Key Files
+- **ThumbnailCropAndLockWindow.cpp**: Defines the UI for the thumbnail mode.
+- **OverlayWindow.cpp**: Thumbnail module type's window concrete implementation.
+- **ReparentCropAndLockWindow.cpp**: Defines the UI for the reparent mode.
+- **ChildWindow.cpp**: Reparent module type's window concrete implementation.
+
+## Known Issues
+
+- Cropping maximized or full-screen windows in "Reparent" mode might not work properly.
+- Some UWP apps may not respond well to being cropped in "Reparent" mode.
+- Applications with sub-windows or tabs can have compatibility issues in "Reparent" mode.
+
+## Debug
+1. build the entire project
+2. launch the built Powertoys
+3. select CropAndLock as the startup project in VS
+4. In the debug button, choose "Attach to process". ![image](https://github.com/user-attachments/assets/a7624ec2-63f1-4720-9540-a916b0ada282)
+5. Attach to CropAndLock.![image](https://github.com/user-attachments/assets/08aa0465-596c-4494-9daa-e96b234f9997)

doc/devdocs/modules/environmentvariables.md

@@ -0,0 +1,71 @@
+# Environment Variables
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/environment-variables)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Environment%20Variables%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Environment%20Variables%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Environment+Variables%22)
+[Checklist](https://github.com/microsoft/PowerToys/blob/releaseChecklist/doc/releases/tests-checklist-template.md?plain=1#L744)
+
+## Overview
+
+Environment Variables is a PowerToys module that provides an easy and convenient way to manage Windows environment variables. It offers a modern user interface for viewing, editing, and managing both user and system environment variables.
+
+## Features
+
+- View and edit user and system environment variables in a unified interface
+- Create profiles to group and manage sets of variables together
+- Profile-based variable management with on/off toggles
+- Automatic backup of existing variables when overridden by a profile
+- Restoration of original values when profiles are disabled
+
+## How It Works
+
+### Profiles
+
+Profiles are collections of environment variables that can be enabled or disabled together. When a profile is enabled:
+
+1. Variables in the profile override existing User variables with the same name
+2. Original values are automatically backed up for restoration when the profile is disabled
+3. Only one profile can be active at a time
+
+### Variable Precedence
+
+The module follows this precedence order for environment variables:
+1. Active profile variables (highest precedence)
+2. User variables
+3. System variables (lowest precedence)
+
+## Architecture
+
+The Environment Variables module is structured into three main components:
+
+### Project Structure
+
+```
+EnvironmentVariables/               # Contains assets, main windows, and telemetry
+EnvironmentVariablesModuleInterface # Interface definitions and package configurations
+EnvironmentVariableUILib            # Abstracted UI methods and implementations
+```
+
+### Key Components
+
+- **Main Window Framework**: Builds the modern Windows desktop UI, handles Windows messages, resource loading, and window closing operations
+- **Project Configuration**: Defines settings and configurations for the module
+- **UI Implementation**: Contains the user interface components and the backend logic
+
+## Implementation Details
+
+### Key Functions
+
+- **OpenEnvironmentKeyIfExists**: Accesses environment information through registry keys
+- **SetEnvironmentVariableFromRegistryWithoutNotify**: Sets variables directly to registry instead of using Environment API, avoiding the 1-second timeout for settings change notifications
+- **GetVariables**: Reads variables directly from registry instead of using Environment API to prevent automatic variable expansion
+
+### Technical Notes
+
+- The module reads and writes variables directly to the registry instead of using the Environment API
+- This direct registry access approach is used because the Environment API automatically expands variables and has a timeout for notifications
+- When a profile variable has the same name as an existing User variable, a backup is created with a naming pattern: `VARIABLE_NAME_powertoys_PROFILE_NAME`

doc/devdocs/modules/fancyzones-tools.md

@@ -0,0 +1,131 @@
+# FancyZones Debugging Tools
+
+## Overview
+
+FancyZones has several specialized debugging tools to help diagnose issues with window management, zone detection, and rendering. These tools are designed to isolate and test specific components of the FancyZones functionality.
+
+## Tools Summary
+
+| Tool | Purpose | Key Functionality |
+|------|---------|-------------------|
+| FancyZones_HitTest | Tests zone hit detection | Shows which zone is under cursor with detailed metrics |
+| FancyZones_DrawLayoutTest | Tests layout drawing | Renders zone layouts to debug display issues |
+| FancyZones_zonable_tester | Tests window zonability | Determines if windows can be placed in zones |
+| StylesReportTool | Analyzes window properties | Generates window style reports for debugging |
+
+## FancyZones_HitTest
+
+![Image of the FancyZones hit test tool](/doc/images/tools/fancyzones-hit-test.png)
+
+### Purpose
+Tests the FancyZones layout selection logic by displaying a window with zones and highlighting the zone under the mouse cursor.
+
+### Functionality
+- Displays a window with 5 sample zones
+- Highlights the zone under the mouse cursor
+- Shows metrics used for zone detection in a sidebar
+- Helps diagnose issues with zone positioning and hit testing
+
+### Usage
+- Run the tool and move your mouse over the zones
+- The currently detected zone will be highlighted
+- The sidebar displays metrics used for determining the active zone
+- Useful for debugging hit detection, positioning, and DPI issues
+
+## FancyZones_DrawLayoutTest
+
+### Purpose
+Debug issues related to the drawing of zone layouts on screen.
+
+### Functionality
+- Simulates zone layouts (currently only column layout supported)
+- Tests rendering of zones with different configurations
+- Helps diagnose display issues across monitor configurations
+
+### Usage
+- Run the tool
+- Press **W** key to toggle zone appearance on the primary screen
+- Press **Q** key to exit the application
+- The number of zones can be modified in the source code
+
+### Technical Notes
+The application is DPI unaware, meaning it doesn't scale for DPI changes and always assumes a scale factor of 100% (96 DPI). Scaling is automatically performed by the system.
+
+## FancyZones_zonable_tester
+
+![Image of the FancyZones zonable tester](/doc/images/tools/fancyzones-zonable-tester.png)
+
+### Purpose
+Tests if the window under the mouse cursor is "zonable" (can be placed in a FancyZones zone).
+
+### Functionality
+- Analyzes the window under the cursor
+- Provides detailed window information:
+  * HWND (window handle)
+  * Process ID
+  * HWND of foreground window
+  * Window style flags
+  * Extended style flags
+  * Window class
+  * Process path
+
+### Usage
+- Run the command-line application
+- Hover the mouse over a window to test
+- Review the console output for detailed window information
+- Check if the window is considered zonable by FancyZones
+
+### Limitations
+Note that this tool may not be fully up-to-date with the latest zonable logic in the main FancyZones codebase.
+
+## StylesReportTool
+
+### Purpose
+Generates detailed reports about window styles that affect zonability.
+
+### Functionality
+- Creates comprehensive window style reports
+- Focuses on style flags that determine if windows can be placed in zones
+- Outputs report to "WindowStyles.txt" on the desktop
+
+### Usage
+- Run the tool
+- Focus the window you want to analyze
+- Press **Ctrl+Alt+S** to generate a report
+- Review WindowStyles.txt to understand why a window might not be zonable
+
+## Debugging Workflow
+
+For most effective debugging of FancyZones issues:
+
+1. Use **StylesReportTool** to analyze window properties of problematic windows
+2. Use **FancyZones_zonable_tester** to check if specific windows can be zoned
+3. Use **FancyZones_draw** for layout rendering issues on different monitors
+4. Use **FancyZones_HitTest** for diagnosing zone detection problems
+
+## Testing Considerations
+
+When testing FancyZones with these tools, consider:
+
+- Testing on different Windows versions
+- Testing with multiple monitors with different:
+  * Resolutions
+  * Scaling settings
+  * Physical arrangements
+- Testing with various window types:
+  * Standard applications
+  * Legacy applications
+  * UWP/WinUI applications
+  * Administrative windows
+  * Special windows (like Task Manager)
+- Testing various layouts:
+  * Grid layouts
+  * Custom layouts
+  * Overlapping zones
+
+## Initial Setup Issues
+
+If encountering JSON token errors on first run:
+1. Launch FancyZones Editor through PowerToys Settings UI
+2. This initializes required configuration files
+3. Direct project execution won't initialize configs properly

doc/devdocs/modules/fancyzones.md

@@ -1,13 +1,246 @@
-# FancyZones UI tests
+# FancyZones
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/fancyzones)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-FancyZones)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-FancyZones)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-FancyZones)
+
+## Overview
+
+FancyZones is a window manager utility that allows users to create custom layouts for organizing windows on their screen.
+
+## Architecture Overview
+
+FancyZones consists of several interconnected components:
+
+### Directory Structure
+- **src**: Contains the source code for FancyZones.
+  - **Editor**: Code for the zone editor.
+  - **Runner**: Code for the zone management and window snapping.
+  - **Settings**: Code for managing user settings.
+- **tests**: Contains unit and integration tests for FancyZones and UI test code.
+
+### Project Structure
+FancyZones is divided into several projects:
+
+- **FancyZones**: Used for thread starting and module initialization.
+- **FancyZonesLib**: Contains the main backend logic, called by FancyZones (via COM).
+  - **FancyZonesData** folder: Contains classes and utilities for managing FancyZones data.
+- **FancyZonesEditor**: Main UI implementation for creating and editing layouts.
+- **FancyZonesEditorCommon**: Stores editor's data and provides shared functionality.
+- **FancyZonesModuleInterface**: Interface layer between FancyZones and the PowerToys Runner.
+
+### Interface Layer: FancyZonesModuleInterface
+- Exposes interface between FancyZones and the Runner
+- Handles communication and configuration exchange
+- Contains minimal code, most logic implemented in other modules
+
+### UI Layer: FancyZonesEditor and FancyZonesEditorCommon
+- **FancyZonesEditor**: Main UI implementation with MainWindow.xaml as entry point
+- **FancyZonesEditorCommon**: Provides data structures and I/O helpers for the Editor
+- Acts as a visual config editor for layout configuration
+
+![Editor Code Map](../images/fancyzones/editor_map.png)
+![Editor Common Code Map](../images/fancyzones/editor_common_map.png)
+
+### Backend Implementation: FancyZones and FancyZonesLib
+- **FancyZonesLib**: Core logic implementation
+  - All drag-and-drop behavior
+  - Layout UI during dragging (generated in C++ via WorkArea.cpp, NewZonesOverlayWindow function)
+  - Core data structures
+- **FancyZones**: Wrapper around FancyZonesLib
+
+### Data Flow
+- User interactions with the Editor are saved in the Settings
+- The Runner reads the Settings to apply the zones and manage window positions
+- Editor sends update events, which trigger FancyZones to refresh memory data
+
+## Key Files
+
+### FancyZones and FancyZonesLib Projects
+
+- **FancyZonesApp.h/cpp**:
+  - **FancyZonesApp Class**: Initializes and manages the FancyZones application.
+  - **Constructor**: Initializes DPI awareness, sets up event hooks, creates the FancyZones instance.
+  - **Destructor**: Cleans up resources, destroys the FancyZones instance, unhooks event hooks.
+  - **Run Method**: Starts the FancyZones application.
+  - **InitHooks Method**: Sets up Windows event hooks to monitor system events.
+  - **DisableModule Method**: Posts a quit message to the main thread.
+  - **HandleWinHookEvent/HandleKeyboardHookEvent Methods**: Handle Windows event hooks.
+
+- **Data Management Files**:
+  - **AppliedLayouts.h/cpp**: Manages applied layouts for different monitors and virtual desktops.
+  - **AppZoneHistory.h/cpp**: Tracks history of app zones.
+  - **CustomLayouts.h/cpp**: Handles user-created layouts.
+  - **DefaultLayouts.h/cpp**: Manages default layouts for different monitor configurations.
+  - **LayoutHotkeys.h/cpp**: Manages hotkeys for switching layouts.
+  - **LayoutTemplates.h/cpp**: Handles layout templates.
+
+- **Core Functionality**:
+  - **FancyZonesDataTypes.h**: Defines data types used throughout FancyZones.
+  - **FancyZonesWindowProcessing.h/cpp**: Processes window events like moving and resizing.
+  - **FancyZonesWindowProperties.h/cpp**: Manages window properties like assigned zones.
+  - **JsonHelpers.h/cpp**: Utilities for JSON serialization/deserialization.
+  - **Layout.h/cpp**: Defines the Layout class for zone layout management.
+  - **LayoutConfigurator.h/cpp**: Configures different layout types (grid, rows, columns).
+  - **Settings.h/cpp**: Manages FancyZones module settings.
+
+### FancyZonesEditor and FancyZonesEditorCommon Projects
+
+- **UI Components**:
+  - **MainWindow.xaml/cs**: Main window of the FancyZones Editor.
+  - **EditorOverlay.xaml/cs**: Overlay window for editing zones.
+  - **EditorSettings.xaml/cs**: Settings window for the FancyZones Editor.
+  - **LayoutPreview.xaml/cs**: Provides layout preview.
+  - **ZoneSettings.xaml/cs**: Manages individual zone settings.
+
+- **Data Components**:
+  - **EditorParameters.cs**: Parameters used by the FancyZones Editor.
+  - **LayoutData.cs**: Manages data for individual layouts.
+  - **LayoutHotkeys.cs**: Manages hotkeys for switching layouts.
+  - **LayoutTemplates.cs**: Manages layout templates.
+  - **Zone.cs**: Represents an individual zone.
+  - **ZoneSet.cs**: Manages sets of zones within a layout.
+
+## Configuration Management
+
+### Configuration Files Location
+- Path: `C:\Users\[username]\AppData\Local\Microsoft\PowerToys\FancyZones`
+- Files:
+  - EditorParameters
+  - AppliedLayouts
+  - CustomLayouts
+  - DefaultLayouts
+  - LayoutHotkeys
+  - LayoutTemplates
+  - AppZoneHistory
+
+### Configuration Handling
+- No central configuration handler
+- Editor: Read/write handlers in FancyZonesEditorCommon project
+- FancyZones: Read/write handlers in FancyZonesLib project
+- Data synchronization: Editor sends update events, FancyZones refreshes memory data
+
+## Window Management
+
+### Monitor Detection and DPI Scaling
+- Monitor detection handled in `FancyZones::MoveSizeUpdate` function
+- DPI scaling: FancyZones retrieves window position without needing mouse DPI scaling info
+- Window scaling uses system interface via `WindowMouseSnap::MoveSizeEnd()` function
+
+### Zone Tracking
+- Window-to-zone tracking implemented in `FancyZones::MoveSizeUpdate` function
+- Maintains history of which windows belong to which zones
+
+## Development History
+
+- FancyZones was originally developed as a proof of concept
+- Many configuration options were added based on community feedback after initial development
+- Some options were added to address specific issues:
+  - Options for child windows or pop-up windows
+  - Some options were removed later
+  - Community feedback led to more interactions being implemented
+
+## Admin Mode Considerations
+
+- FancyZones can't move admin windows unless running as admin
+- By default, all utilities run as admin if PowerToys is running as admin
+
+## Development Environment Setup
+
+### Prerequisites
+- Visual Studio 2022: Required for building and debugging
+- Windows 10 SDK: Ensure the latest version is installed
+- PowerToys Repository: Clone from GitHub
+
+### Setup Steps
+1. Clone the Repository:
+   ```
+   git clone https://github.com/microsoft/PowerToys.git
+   ```
+2. Open `PowerToys.sln` in Visual Studio
+3. Select the Release configuration and build the solution
+4. If you encounter build errors, try deleting the x64 output folder and rebuild
+
+## Getting Started with FancyZones Development
+
+### Step 1: Familiarize with the Feature
+- Use the feature to understand its functionality
+- Read the official documentation: [PowerToys FancyZones utility for Windows](https://learn.microsoft.com/en-us/windows/powertoys/fancyzones)
+
+### Step 2: Build and Debug
+- Ensure you can successfully compile and debug the module
+- First-time setup may require running the Editor through PowerToys Settings UI to initialize configuration files
+
+### Step 3: Learn through Bug Fixes
+- Examine existing bugs and feature requests to understand code structure
+- Use debugging to trace code execution for specific features
+- Examine UI test code to understand how features are tested
+
+## Debugging
+
+### Setup for Debugging
+1. In Visual Studio 2022, set FancyZonesEditor as the startup project
+2. Set breakpoints in the code where needed
+3. Click Run to start debugging
+
+### During Active Development
+- You can perform breakpoint debugging to troubleshoot issues
+- Attach to running processes if needed to debug the module in context
+
+### Common Debugging Issues
+- If encountering JSON errors on first run, launch the FancyZones Editor once through PowerToys Settings UI to initialize required configuration files
+- For UI-related issues, use tools like AccessibilityInsights to inspect element properties
+
+## Deployment and Release Process
+
+### Deployment
+
+#### Local Testing
+1. Build the solution in Visual Studio
+2. Run PowerToys.exe from the output directory
+
+#### Packaging
+- Use the MSIX packaging tool to create an installer
+- Ensure all dependencies are included
+
+### Release
+
+#### Versioning
+- Follow semantic versioning for releases
+
+#### Release Notes
+- Document all changes, fixes, and new features
+
+#### Publishing
+1. Create a new release on GitHub
+2. Upload the installer and release notes
+
+## Troubleshooting
+
+### First Run JSON Error
+**Error**: "The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. Path: $ | LineNumber: 0 | BytePositionInLine: 0."
+
+**Solution**: Launch the FancyZones Editor once through PowerToys Settings UI. Running the Editor directly within the project will not initialize the required configuration files.
+
+### Known Issues
+- Potential undiscovered bugs related to data updates in the Editor
+- Some automated tests pass in CI but fail on specific machines
+- Complex testing requirements across different monitor configurations
+
+## FancyZones UI Testing
 
 UI tests are implemented using [Windows Application Driver](https://github.com/microsoft/WinAppDriver).
 
-## Before running tests
+### Before running tests
 
   - Install Windows Application Driver v1.2.1 from https://github.com/microsoft/WinAppDriver/releases/tag/v1.2.1. 
   - Enable Developer Mode in Windows settings
 
-## Running tests
+### Running tests
   
   - Exit PowerToys if it's running
   - Run WinAppDriver.exe from the installation directory. Skip this step if installed in the default directory (`C:\Program Files (x86)\Windows Application Driver`); in this case, it'll be launched automatically during tests.
@@ -16,11 +249,239 @@ UI tests are implemented using [Windows Application Driver](https://github.com/m
 
 >Note: notifications or other application windows, that are shown above the window under test, can disrupt the testing process.
 
+### UI Test Automation
 
-## Extra tools and information
+FancyZones is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
+
+[FancyZones UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/fancyzones/UITests-FancyZonesEditor/release-test-checklist.md)
+
+### Testing Strategy
+
+#### Unit Tests
+- Build the unit test project
+- Run using the Visual Studio Test Explorer (`Test > Test Explorer` or `Ctrl+E, T`)
+
+#### Integration Tests
+- Ensure the entire FancyZones module works as expected
+- Test different window layouts and snapping behaviors
+
+### Test Framework Structure
+
+#### UI Test Requirements
+All test cases require pre-configured user data and must reset this data before each test.
+
+**Required User Data Files**:
+- EditorParameters
+- AppliedLayouts
+- CustomLayouts
+- DefaultLayouts
+- LayoutHotkeys
+- LayoutTemplates
+- AppZoneHistory
+
+#### Editor Test Suite
+
+**ApplyLayoutTest.cs**
+- Verifies layout application and selection per monitor
+- Tests file updates and behavior under display switching
+- Validates virtual desktop changes
+
+**CopyLayoutTests.cs**
+- Tests copying various layout types
+- Validates UI and file correctness
+
+**CreateLayoutTests.cs**
+- Tests layout creation and cancellation
+- Focuses on file correctness validation
+
+**CustomLayoutsTests.cs**
+- Tests user-created layout operations
+- Covers renaming, highlight line changes, zone count changes
+
+**DefaultLayoutsTest.cs**
+- Validates default and user layout files
+
+**DeleteLayoutTests.cs**
+- Tests layout deletion across types
+- Checks both UI and file updates
+
+**EditLayoutTests.cs**
+- Tests zone operations: add/delete/move/reset/split/merge
+
+**FirstLaunchTest.cs**
+- Verifies Editor launches correctly on first run
+
+**LayoutHotkeysTests.cs**
+- Tests hotkey configuration file correctness
+- Note: Actual hotkey behavior tested in FancyZones backend
+
+**TemplateLayoutsTests.cs**
+- Tests operations on built-in layouts
+- Covers renaming, highlight changes, zone count changes
+
+#### FancyZones Backend Tests
+
+**LayoutApplyHotKeyTests.cs**
+- Focuses on hotkey-related functionality
+- Tests actual hotkey behavior implementation
+
+### UI Testing Tools
+
+While working on tests, you may need tools to view element accessibility data:
+- [AccessibilityInsights](https://accessibilityinsights.io/docs/windows/overview)
+- [WinAppDriver UI Recorder](https://github.com/microsoft/WinAppDriver/wiki/WinAppDriver-UI-Recorder)
+
+>Note: Close helper tools while running tests. Overlapping windows can affect test results.
+2. FancyZones might have implemented certain screen resolution limits in the code that do not support such wide screens
+3. User error — it can be seen that no layout has been applied to the screen, so it's normal that the far right is not displayed, as the user hasn't used the FancyZones feature
+4. From the image, it appears the user is trying to maximize a game window, but some games may not support rendering windows at such high resolutions due to internal implementation
+
+The **optimal solution** for this bug is to first comment on the user's usage issue. Let them correctly use the FancyZones feature before making further judgments. If the issue persists after proper usage, then investigate whether it's a code issue or a problem with the game itself.
+
+To demonstrate a debugging example, I will assume it's a code issue, specifically an issue with the Editor. Please see the following debug process.
+
+  
+
+Let's first locate the corresponding code. Since the error is in the Editor, we'll start by checking the FancyZonesEditor shown in the image.
+
+![Debug Step Image](../images/fancyzones/1.png)
+
+However, I currently don't know where the code for this specific UI element in the Editor is located.
+![Debug Step Image](../images/fancyzones/2.png)
+
+We now have two approaches to find the exact code location.
+
+**First approach:**
+
+The main XAML page is usually named `App.xaml` or `MainWindow.xaml`. Let's start by locating these two files in the FancyZones Editor. Upon reviewing their contents, we find that `App.xaml` is primarily a wrapper file and doesn't contain much UI code. Therefore, it's highly likely that the UI code is located in `MainWindow.xaml`. In the preview of `MainWindow.xaml`, we can also see a rough outline of the UI elements.![Debug Step Image](../images/fancyzones/3.png)
+
+By searching for "monitor", we found that only lines 82 and 338 contain the string "monitor".![Debug Step Image](../images/fancyzones/4.png)
+
+Then, upon reviewing the code, we found that the line at 82 is part of a template. The UI element we're looking for is located within the code block around line 338.
+
+**Second approach:**
+
+We can use the **AccessibilityInsights** tool to inspect the specific information of the corresponding UI element.
+![Debug Step Image](../images/fancyzones/5.png)
+
+However, the current UI element does not have an AutomationId. Let's check whether its parent or child nodes have an AutomationId value. (In fact, using ClassName could also help locate it, but elements with the same ClassName might be numerous, making AutomationId a more accurate option.)
+![Debug Step Image](../images/fancyzones/6.png)
+We found that the parent node "List View" has an AutomationId value. Copy this value and search for it in the code.
+![Debug Step Image](../images/fancyzones/7.png)
+
+**Accurately located at line 338.**
+
+Now that we've found the code for the UI element, let's look at where the size data for this UI element comes from. First, the text of this `Text` element is bound within the `MonitorItemTemplate`. The name of this `Text` element is `ResolutionText`, and it binds to a data property named `Dimensions`.
+
+![Debug Step Image](../images/fancyzones/8.png)
+
+Search for code related to `Dimensions` across all projects in FancyZones.
+
+![Debug Step Image](../images/fancyzones/9.png)
+
+We found that this string corresponds to a variable. However, the return value differs in Debug mode, so let's first examine the logic in Release mode.
+
+We found that the variable `ScreenBoundsWidth` is located in the constructor of `MonitorInfoModel`.
+
+![Debug Step Image](../images/fancyzones/10.png)
+
+Then, by searching for `MonitorInfoModel`, we found that this class is instantiated in the constructor of the `MonitorViewModel` class.
+
+![Debug Step Image](../images/fancyzones/11.png)
+
+The width and height of the monitor, which are crucial, are also assigned at this point. Let's continue by checking where the data in `App.Overlay.Monitors` is initialized.
+
+My idea is to examine all references to the `Monitors` variable and identify the initialization point based on those references.
+
+![Debug Step Image](../images/fancyzones/12.png)
+
+Finally, by tracing the `Add` function of `Monitors`, we found the `AddMonitor()` method. This method is only called by `ParseParams()`, which confirms that the data originates from there.
+ However, by examining the context around the `AddMonitor()` function, we can see that the data comes from the `editor-parameters.json` file. Next, we will continue to investigate how this file is initialized and modified.
+
+![Debug Step Image](../images/fancyzones/13.png)
+
+By searching, we found that the `editor-parameters.json` file has write functions in both the Editor and FancyZones projects.
+
+![Debug Step Image](../images/fancyzones/14.png)
+
+**The display information is retrieved through the following call stack:**
+ `UpdateWorkAreas()` → `IdentifyMonitors()` → `GetDisplays()` → `EnumDisplayDevicesW()`.
+
+**How was the `UpdateWorkAreas()` function identified?**
+ It was discovered by searching for `EditorParameters` and noticing that when the `save` function is called on `EditorParameters`, the parameter passed is `m_workAreaConfiguration`.
+
+![Debug Step Image](../images/fancyzones/15.png)
+
+**Then, by checking the initialization location of the `m_workAreaConfiguration` variable, we found that it is initialized inside `UpdateWorkAreas`.**
+ With this, we have successfully identified the source of the monitor resolution data displayed in the Editor's `Monitors` section.
+
+
+
+### Step Four：
+
+Familiarize yourself with the module code through the current tasks at hand.
+
+Bug：[Issues · microsoftPowerToys](https://github.com/microsoft/PowerToys/issues?q=is%3Aissue%20state%3Aopen%20type%3ABug%20label%3AProduct-FancyZones)
+
+UITest Code：
+
+[Task 57329836: PowerToys UI Test FancyZone UI Test Override Windows Snap-1 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329836/)
+
+[Task 57329843: PowerToys UI Test FancyZone UI Test Override Windows Snap-2 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329843/)
+
+[Task 57329845: PowerToys UI Test FancyZone UI Test Override Windows Snap-3 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329845/)
+
+[Task 56940387: PowerToys UI Test FancyZone UI Test Override Windows Snap-4 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/56940387/)
+
+UI Test Check List:
+
+PowerToys/doc/releases/tests-checklist-template.md at releaseChecklist · microsoft/PowerToys](https://github.com/microsoft/PowerToys/blob/releaseChecklist/doc/releases/tests-checklist-template.md)
+
+
+
+## Q&A
+
+- ### First Run FancyZones error
+![Debug Step Image](../images/fancyzones/16.png)
+
+If you encounter this situation, you need to launch the FancyZones Editor once in the powertoys settings UI (Refer to the image below). The reason is that running the Editor directly within the project will not initialize various configuration files.
+
+![Debug Step Image](../images/fancyzones/17.png)
+
+- ### How are layouts stored and loaded? Is there a central configuration handler?
+
+There is no central configuration handler. 
+
+Editor read/write config data handler is in FancyZonesEditorCommon project.
+
+![Debug Step Image](../images/fancyzones/18.png)
+
+FancyZones cpp project read/write config data handler is in FancyZonesLib project.
+
+![Debug Step Image](../images/fancyzones/19.png)
+However, the files write and read those are C:\Users\“xxxxxx”\AppData\Local\Microsoft\PowerToys\FancyZones
+
+You can think of the editor as a visual config editor, which is most of its functionality. Another feature is used to set the layout for the monitor displays.
+
+When the Editor starts, it will load the config data, and when FancyZones starts, it will also load the config data. After the Editor updates the config data, it will send a data update event, and FancyZones will refresh the current data in memory upon receiving the event.
+
+![Debug Step Image](../images/fancyzones/20.png)
+
+- ### Which parts of the code are responsible for monitor detection and DPI scaling?
+
+About monitor detection you can find "FancyZones::MoveSizeUpdate" function. 
+
+I believe that in the case without DPI scaling, FancyZones retrieves the window's position and does not need to know what the mouse's DPI scaling is like. If you are referring to window scaling, it is called through the system interface, and you can see the detailed code in "WindowMouseSnap::MoveSizeEnd()" fucntion.
+
+- ### How does FancyZones track which windows belong to which zones?
+
+In "FancyZones::MoveSizeUpdate" function.
+
+### Extra tools and information
 
 **Test samples**: https://github.com/microsoft/WinAppDriver/tree/master/Samples
 
 While working on tests, you may need a tool that helps you to view the element's accessibility data, e.g. for finding the button to click. For this purpose, you could use [AccessibilityInsights](https://accessibilityinsights.io/docs/windows/overview) or [WinAppDriver UI Recorder](https://github.com/microsoft/WinAppDriver/wiki/WinAppDriver-UI-Recorder).
 
 >Note: close helper tools while running tests. Overlapping windows can affect test results.
+

doc/devdocs/modules/fileexploreraddons.md

@@ -0,0 +1,34 @@
+# File Explorer Add-ons
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/file-explorer)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-File%20Explorer%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-File%20Explorer%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-File+Explorer%22)
+
+## Overview
+
+File Explorer Add-ons are extensions that enhance Windows File Explorer functionality with additional features and context menu options.
+
+## Links
+
+- [Source code folder](https://github.com/microsoft/PowerToys/tree/main/src/modules/fileexplorerpreview)
+- [Issue tracker](https://github.com/microsoft/PowerToys/issues?q=is%3Aissue+label%3A%22File+Explorer%22)
+
+## Implementation Details
+
+TODO: Add implementation details
+
+## Debugging
+
+TODO: Add debugging information
+
+## Settings
+
+TODO: Add settings documentation
+
+## Future Improvements
+
+TODO: Add potential future improvements

doc/devdocs/modules/filelocksmith.md

@@ -0,0 +1,202 @@
+# File Locksmith
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/file-locksmith)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-File%20Locksmith%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-File%20Locksmith%22%20label%3AIssue-Bug)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-File+Locksmith%22)
+
+## Overview
+
+File Locksmith is a utility in PowerToys that shows which processes are locking or using a specific file. This helps users identify what's preventing them from deleting, moving, or modifying files by revealing the processes that have handles to those files.
+
+## Architecture
+
+![Diagram](../images/filelocksmith/diagram.png)
+
+File Locksmith follows a similar architecture to the ImageResizer and NewPlus modules. It consists of:
+
+1. **Shell Extensions**:
+   - `FileLocksmithExt` - COM-based shell extension for Windows 10 and below
+   - `FileLocksmithContextMenu` - Shell extension for Windows 11 context menu
+
+2. **Core Components**:
+   - `FileLocksmithLib` - Handles IPC between shell extensions and UI
+   - `FileLocksmithLibInterop` - Core functionality for finding processes locking files
+   - `FileLocksmithUI` - WinUI 3 user interface component
+
+3. **Settings Integration**:
+   - Settings integration in the PowerToys settings application
+
+## Implementation Details
+
+### Shell Extensions
+
+The module adds "Unlock with File Locksmith" to the context menu in File Explorer:
+
+- For Windows 11, a context menu command is registered as a MSIX sparse package (compiled via appxmanifest.xml)
+- For Windows 10 and below, a traditional shell extension is registered through registry keys during installation
+
+### Process Communication Flow
+
+1. User enables File Locksmith in PowerToys settings
+2. User right-clicks on a file and selects "Unlock with File Locksmith"
+3. The shell extension writes the selected file path to a temporary file (file-based IPC)
+4. The shell extension launches `PowerToys.FileLocksmithUI.exe`
+5. The UI reads the file path from the temporary file
+6. The UI uses `FileLocksmithLibInterop` to scan for processes with handles to the file
+7. Results are displayed in the UI, showing process information and allowing user action
+
+### Core Functionality
+
+The core functionality to find processes locking files is implemented in [FileLocksmith.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/FileLocksmith.cpp), which:
+
+- Uses low-level Windows APIs via `NtdllExtensions` to iterate through file handles
+- Examines all running processes to find handles to the specified files
+- Maps process IDs to the files they're locking
+- Retrieves process information such as name, user context, and file paths
+
+### User Interface
+
+The UI is built with WinUI 3 and uses MVVM architecture:
+- View models handle process data and user interactions
+- Converters transform raw data into UI-friendly formats
+- The interface shows which processes are locking files, along with icons and process details
+
+## Code Structure
+
+### Shell Extensions
+- [ClassFactory.cpp](/src/modules/FileLocksmith/FileLocksmithExt/ClassFactory.cpp): COM class factory that creates instances of shell extension objects
+- [ExplorerCommand.cpp](/src/modules/FileLocksmith/FileLocksmithExt/ExplorerCommand.cpp): Implements Windows Explorer context menu command for Windows 10 and below
+- [PowerToysModule.cpp](/src/modules/FileLocksmith/FileLocksmithExt/PowerToysModule.cpp): PowerToys module interface implementation with settings management
+- [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithExt/dllmain.cpp): DLL entry point for Windows 10 shell extension
+- [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithContextMenu/dllmain.cpp): Windows 11 context menu integration through MSIX package
+
+### Core Libraries
+- [IPC.cpp](/src/modules/FileLocksmith/FileLocksmithLib/IPC.cpp): File-based inter-process communication between shell extensions and UI
+- [Settings.cpp](/src/modules/FileLocksmith/FileLocksmithLib/Settings.cpp): Settings management for File Locksmith module
+- [FileLocksmith.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/FileLocksmith.cpp): Core process scanning implementation to find processes locking files
+- [NativeMethods.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NativeMethods.cpp): Interop layer bridging native C++ with WinRT-based UI
+- [NtdllBase.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NtdllBase.cpp): Interface to native Windows NT APIs
+- [NtdllExtensions.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NtdllExtensions.cpp): Process and handle querying utilities using NtQuerySystemInformation
+- [ProcessResult.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/ProcessResult.cpp): Class for storing process information (name, PID, user, file list)
+
+### UI Components
+- [FileCountConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/FileCountConverter.cs): Converts file counts for UI display
+- [FileListToDescriptionConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/FileListToDescriptionConverter.cs): Formats file lists for display
+- [PidToIconConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/PidToIconConverter.cs): Extracts icons for processes
+- [UserToSystemWarningVisibilityConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/UserToSystemWarningVisibilityConverter.cs): Shows warnings for system processes
+- [MainWindow.xaml.cs](/src/modules/FileLocksmith/FileLocksmithUI/FileLocksmithXAML/MainWindow.xaml.cs): Main application window implementation
+- [App.xaml.cs](/src/modules/FileLocksmith/FileLocksmithUI/FileLocksmithXAML/App.xaml.cs): Application entry point
+- [ResourceLoaderInstance.cs](/src/modules/FileLocksmith/FileLocksmithUI/Helpers/ResourceLoaderInstance.cs): Localization resource helper
+- [MainViewModel.cs](/src/modules/FileLocksmith/FileLocksmithUI/ViewModels/MainViewModel.cs): Main view model that handles loading processes asynchronously
+
+### Settings Integration
+- [FileLocksmithViewModel.cs](/src/settings-ui/Settings.UI/ViewModels/FileLocksmithViewModel.cs): ViewModel for File Locksmith in PowerToys settings
+- [FileLocksmithLocalProperties.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithLocalProperties.cs): Machine-level settings storage
+- [FileLocksmithProperties.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithProperties.cs): User-level settings storage
+- [FileLocksmithSettings.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithSettings.cs): Module settings definitions
+
+## Debugging
+
+To build and debug the File Locksmith module:
+
+0. **Build FileLocksmith module**
+   - Shutdown the existing release builds of PowerToys
+   - Open the solution in Visual Studio
+   - Build the entire solution
+   - Build the `FileLocksmith` project
+
+1. **Create certificate and import to Root (if you don't already have)**
+   ```powershell
+   New-SelfSignedCertificate -Subject "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" `
+    -KeyUsage DigitalSignature `
+    -Type CodeSigningCert `
+    -FriendlyName "PowerToys SelfCodeSigning" `
+    -CertStoreLocation "Cert:\CurrentUser\My"
+
+   $cert = Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.FriendlyName -like "*PowerToys*" }
+
+   Export-Certificate -Cert $cert -FilePath "$env:TEMP\PowerToysCodeSigning.cer"
+
+   # under admin Terminal:
+   Import-Certificate -FilePath "$env:TEMP\PowerToysCodeSigning.cer" -CertStoreLocation Cert:\LocalMachine\Root
+
+   # get Thumbprint
+   Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.FriendlyName -like "*PowerToys*" }
+    ```
+
+2. **Sign the MSIX package**
+   ```
+   SignTool sign /fd SHA256 /sha1 <CERTIFICATE THUMBPRINT> "C:\Users\$env:USERNAME\source\repos\PowerToys\x64\Debug\WinUI3Apps\FileLocksmithContextMenuPackage.msix"
+   ```
+   SignTool might be not in your PATH, so you may need to specify the full path to it, e.g., `C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64\signtool.exe`.
+
+   **commands example**:
+   ```powershell
+      PS C:\Users\developer> New-SelfSignedCertificate -Subject "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" `
+      >>     -KeyUsage DigitalSignature `
+      >>     -Type CodeSigningCert `
+      >>     -FriendlyName "PowerToys SelfSigned" `
+      >>     -CertStoreLocation "Cert:\CurrentUser\My"
+
+         PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
+
+      Thumbprint                                Subject              EnhancedKeyUsageList
+      ----------                                -------              --------------------
+      1AA018C2B06B60EAFEE452ADE403306F39058FF5  CN=Microsoft Corpor… Code Signing
+
+      PS C:\Users\developer> Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.FriendlyName -like "*PowerToys*" }
+
+         PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
+
+      Thumbprint                                Subject              EnhancedKeyUsageList
+      ----------                                -------              --------------------
+      1AA018C2B06B60EAFEE452ADE403306F39058FF5  CN=Microsoft Corpor… Code Signing
+
+      PS C:\Users\developer> & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\signtool.exe" sign /fd SHA256 /sha1 1AA018C2B06B60EAFEE452ADE403306F39058FF5 "%REPO_PATH%\PowerToys\x64\Debug\WinUI3Apps\FileLocksmithContextMenuPackage.msix"
+      Done Adding Additional Store
+      Successfully signed: C:\Users\developer\Develop\GitHub\PowerToys\x64\Debug\WinUI3Apps\FileLocksmithContextMenuPackage.msix
+   ```
+
+3. **Remove old version**
+   ```powershell
+   Get-AppxPackage -Name Microsoft.PowerToys.FileLocksmithContextMenu*
+   Remove-AppxPackage Microsoft.PowerToys.FileLocksmithContextMenu_1.0.0.0_neutral__8wekyb3d8bbwe
+   ```
+
+4. **Install new signed MSIX**
+   ```powershell
+   Add-AppxPackage -Path "%REPO_PATH%\PowerToys\x64\Debug\WinUI3Apps\FileLocksmithContextMenuPackage.msix" -ExternalLocation "%REPO_PATH%\PowerToys\x64\Debug\WinUI3Apps"
+   ```
+
+5. **Restart Explorer**
+   - Go to Task Manager and restart explorer.exe
+
+6. **Debug Process**
+   - Set the breakpoint in [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithContextMenu/dllmain.cpp#L116)
+   - Open the **Attach to Process** dialog in Visual Studio
+   - Right-click a file in File Explorer
+   - Attach the debugger to `dllhost.exe` with **FileLocksmith** Title to debug the shell extension
+   ![Attach to Process](../images/filelocksmith/debug.png)
+   - Right-click (fast) a file again and select *"Unlock with File Locksmith"*
+   - Attach the debugger to `PowerToys.FileLocksmithUI.exe` to debug the UI
+
+7. **Alternative Debugging Method**
+   - You can set the `FileLocksmithUI` as startup project directly in Visual Studio, which will launch the UI without needing to go through the shell extension. This is useful for debugging the UI logic without the shell extension overhead.
+
+## Known Issues
+
+There is an open PR to change the IPC mechanism from file-based to pipe-based, but it has blockers:
+- When restarting as admin, the context menu extension doesn't show
+- The "Unlock with File Locksmith" option doesn't work when launched as admin
+
+## Settings Integration
+
+File Locksmith integrates with the PowerToys settings through:
+- [FileLocksmithViewModel.cs](/src/settings-ui/Settings.UI/ViewModels/FileLocksmithViewModel.cs)
+- [FileLocksmithLocalProperties.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithLocalProperties.cs)
+- [FileLocksmithProperties.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithProperties.cs)
+- [FileLocksmithSettings.cs](/src/settings-ui/Settings.UI.Library/FileLocksmithSettings.cs)

doc/devdocs/modules/hostsfileeditor.md

@@ -0,0 +1,114 @@
+# Hosts File Editor
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/hosts-file-editor)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Hosts%20File%20Editor%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Hosts%20File%20Editor%22%20label%3AIssue-Bug)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Hosts+File+Editor%22)
+
+## Overview
+
+The Hosts File Editor module provides a convenient way to edit the system's hosts file. The hosts file is a plain text file used by the operating system to map hostnames to IP addresses, allowing users to override DNS for specific domain names.
+
+## Code Structure
+
+![Diagram](../images/hostsfileeditor/diagram.png)
+
+The Hosts File Editor module is structured into three primary components:
+
+1. **Hosts** - Entry point for the Hosts File Editor. Manages core services and settings through helper utilities.
+2. **HostsModuleInterface** - Interface for integrating the Hosts module with the PowerToys system.
+3. **HostsUILib** - Implements the UI layer using WinUI 3.
+
+This structure is similar to the Environment Variables for Windows module.
+
+## Key Components
+
+### Main Entry Points
+
+- **Module Entry**: [Program.cs](/src/modules/Hosts/Program.cs) → [App.xaml.cs](/src/modules/Hosts/HostsXAML/App.xaml.cs)
+- **Settings UI**: 
+  - Main Window: [MainWindow.xaml.cs](/src/modules/Hosts/Hosts/HostsXAML/MainWindow.xaml.cs)
+  - View: [HostsMainPage.xaml](/src/modules/Hosts/HostsUILib/HostsMainPage.xaml)
+  - ViewModel: [HostsMainPage.xaml.cs](/src/modules/Hosts/HostsUILib/HostsMainPage.xaml.cs)
+- **Runner Integration**: [HostsModuleInterface](/src/modules/Hosts/HostsModuleInterface)
+
+### Runner Integration
+
+The module is loaded by the PowerToys runner from:
+- [main.cpp](/src/runner/main.cpp) (Lines 183-184): Loads Hosts Module using `L"WinUI3Apps/PowerToys.HostsModuleInterface.dll"`
+
+### Settings Management
+
+- [HostsViewModel.cs](/src/settings-ui/Settings.UI/ViewModels/HostsViewModel.cs): Hosts UI in PowerToys settings
+- [HostsProperties.cs](/src/settings-ui/Settings.UI.Library/HostsProperties.cs): In settings UI
+- [HostsSettings.cs](/src/settings-ui/Settings.UI.Library/HostsSettings.cs): Wrapper with HostsProperties
+
+### Module Components
+
+#### HostsModuleInterface
+
+- Defines the interface for integrating the Hosts module with the PowerToys system.
+
+#### Hosts (Main Project)
+
+- [Program.cs](/src/modules/Hosts/Hosts/Program.cs): Launch app
+- [HostsXAML](/src/modules/Hosts/Hosts/HostsXAML): Initialize service and loads the main window
+- [Host.cs](/src/modules/Hosts/Hosts/Helpers/Host.cs): Access to services register
+- [NativeEventWaiter.cs](/src/modules/Hosts/Hosts/Helpers/NativeEventWaiter.cs): Gets the dispatcher queue for posting UI updates from a background thread
+- [UserSettings.cs](/src/modules/Hosts/Hosts/Settings/UserSettings.cs): Manages reading, tracking, and updating user settings from settings.json
+
+#### HostsUILib
+
+- [HostsMainPage.xaml.cs](/src/modules/Hosts/HostsUILib/HostsMainPage.xaml.cs): Main page
+- [ViewModels](/src/modules/Hosts/HostsUILib/ViewModels): Contains view models that manage state and logic
+- [Models](/src/modules/Hosts/HostsUILib/Models): Models for managing host entries
+  - [AddressType.cs](/src/modules/Hosts/HostsUILib/Models/AddressType.cs): Specifies whether an address is IPv4, IPv6, or Invalid
+  - [Entry.cs](/src/modules/Hosts/HostsUILib/Models/Entry.cs): Represents a single hosts file entry (IP address, hostnames, comment, flags)
+  - [HostsData.cs](/src/modules/Hosts/HostsUILib/Models/HostsData.cs): Converts the list of entries into a read-only collection
+- [Settings](/src/modules/Hosts/HostsUILib/Settings): Settings configuration
+- [Consts.cs](/src/modules/Hosts/HostsUILib/Consts.cs): Defines constants like max hosts IP length
+- [Helpers](/src/modules/Hosts/HostsUILib/Helpers): Utilities for dealing with hosts IP, filter features, and file loading
+
+## Call Flow
+
+1. **Enable app**: runner/main.cpp → settings.ui/settings.ui.library
+2. **Start app**: Program.cs → HostsXAML → HostsMainPage
+3. **Load hosts data**: ViewModel → HostsData → Helpers (load and parse file)
+4. **User edits**: UI bound to ViewModel updates entries
+5. **Save changes**: ViewModel triggers file write through Helpers
+6. **Settings management**: UserSettings.cs persists user preferences
+
+## Key Features
+
+| Feature | Key Function |
+|---------|--------------|
+| Adding a new entry | `Add(Entry entry)` |
+| Filtering host file entries | `ApplyFilters()` |
+| Open Hosts File | `ReadHosts()` |
+| Additional Lines | `UpdateAdditionalLines(string lines)` |
+
+## Settings
+
+| Setting | Implementation |
+|---------|---------------|
+| Open as administrator | `UserSettings()` |
+| Additional lines position | `UserSettings()->AdditionalLinesPosition` |
+| Consider loopback addresses as duplicates | `UserSettings()->LoopbackDuplicates` |
+| Encoding Setting | `UserSettings()->Encoding` |
+
+## UI Test Automation
+
+Hosts File Editor is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
+
+[Hosts File Editor UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/Hosts/Hosts.UITests/Release-Test-Checklist-Migration-Progress.md)
+
+## How to Build and Debug
+
+1. Build PowerToys Project in debug mode
+2. Set Hosts as the startup project
+3. Launch Hosts File Editor in debug mode
+4. Attach the debugger to PowerToys.Hosts.dll
+5. Add breakpoints in the Hosts code

doc/devdocs/modules/imageresizer.md

@@ -0,0 +1,132 @@
+# Image Resizer
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/image-resizer)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Image%20Resizer%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Image%20Resizer%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Image+Resizer%22)
+
+Image Resizer is a Windows shell extension that enables batch resizing of images directly from File Explorer.
+
+## Overview
+
+Image Resizer provides a convenient way to resize images without opening a dedicated image editing application. It is accessible through the Windows context menu and allows users to:
+- Resize single or multiple images at once
+- Choose from predefined sizing presets or enter custom dimensions
+- Maintain or modify aspect ratios
+- Create copies or overwrite original files
+- Apply custom filename formats to resized images
+- Select different encoding quality settings
+
+## Architecture
+
+Image Resizer consists of multiple components:
+- Shell Extension DLL (context menu integration)
+- WinUI 3 UI application
+- Core image processing library
+
+### Technology Stack
+- C++/WinRT
+- WPF (UI components)
+- Windows Imaging Component (WIC) for image processing
+- COM for shell integration
+
+## Context Menu Integration
+
+Image Resizer integrates with the Windows context menu following the [PowerToys Context Menu Handlers](../common/context-menus.md) pattern. It uses a dual registration approach to ensure compatibility with both Windows 10 and Windows 11.
+
+### Registration Process
+
+The context menu integration follows the same pattern as PowerRename, using:
+- A traditional shell extension for Windows 10
+- A sparse MSIX package for Windows 11 context menus
+
+For more details on the implementation approach, see the [Dual Registration section](../common/context-menus.md#1-dual-registration-eg-imageresizer-powerrename) in the context menu documentation.
+
+### Context Menu Appearance Logic
+
+Image Resizer dynamically determines when to show the context menu option:
+- `AppxManifest.xml` registers the extension for all file types (`Type="*"`)
+- The shell extension checks if the selected files are images using `AssocGetPerceivedType()`
+- The menu appears only for image files (returns `ECS_ENABLED`), otherwise it remains hidden (returns `ECS_HIDDEN`)
+
+This approach provides flexibility to support additional file types by modifying only the detection logic without changing the system-level registration.
+
+## UI Implementation
+
+Image Resizer uses WPF for its user interface, as evidenced by the App.xaml.cs file. The UI allows users to:
+- Select from predefined size presets or enter custom dimensions
+- Configure filename format for the resized images
+- Set encoding quality and format options
+- Choose whether to replace or create copies of the original files
+
+From the App.xaml.cs file, we can see that the application:
+- Supports localization through `LanguageHelper.LoadLanguage()`
+- Processes command line arguments via `ResizeBatch.FromCommandLine()`
+- Uses a view model pattern with `MainViewModel`
+- Respects Group Policy settings via `GPOWrapper.GetConfiguredImageResizerEnabledValue()`
+
+## Debugging
+
+### Debugging the Context Menu
+
+See the [Debugging Context Menu Handlers](../common/context-menus.md#debugging-context-menu-handlers) section for general guidance on debugging PowerToys context menu extensions.
+
+For Image Resizer specifically, there are several approaches:
+
+#### Option 1: Manual Registration via Registry
+
+1. Create a registry file (e.g., `register.reg`) with the following content:
+```
+Windows Registry Editor Version 5.00
+
+[HKEY_CLASSES_ROOT\CLSID\{51B4D7E5-7568-4234-B4BB-47FB3C016A69}]
+@="PowerToys Image Resizer Extension"
+
+[HKEY_CLASSES_ROOT\CLSID\{51B4D7E5-7568-4234-B4BB-47FB3C016A69}\InprocServer32]
+@="D:\\PowerToys\\x64\\Debug\\PowerToys.ImageResizerExt.dll"
+"ThreadingModel"="Apartment"
+
+[HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations\.png\ShellEx\ContextMenuHandlers\ImageResizer]
+@="{51B4D7E5-7568-4234-B4BB-47FB3C016A69}"
+```
+
+2. Import the registry file:
+```
+reg import register.reg
+```
+
+3. Restart Explorer to apply changes:
+```
+taskkill /f /im explorer.exe && start explorer.exe
+```
+
+4. Attach the debugger to `explorer.exe`
+
+5. Add breakpoints to relevant code in the Image Resizer shell extension
+
+#### Option 2: Using regsvr32
+
+1. Register the shell extension DLL:
+```
+regsvr32 "D:\PowerToys\x64\Debug\PowerToys.ImageResizerExt.dll"
+```
+
+2. Restart Explorer and attach the debugger as in Option 1
+
+### Common Issues
+
+- Context menu not appearing: 
+  - Ensure the extension is properly registered
+  - Verify you're right-clicking on supported image files
+  - Restart Explorer to clear context menu cache
+  
+- For Windows 11, check AppX package registration:
+  - Use `get-appxpackage -Name *imageresizer*` to verify installation
+  - Use `Remove-AppxPackage` to remove problematic registrations
+
+- Missing UI or processing failures:
+  - Check Event Viewer for application errors
+  - Verify file permissions for both source and destination folders

doc/devdocs/modules/keyboardmanager/README.md

@@ -1,6 +1,17 @@
 # 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)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Keyboard%20Shortcut%20Manager%22)<br>
+[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/keyboardmanager/debug.md

@@ -0,0 +1,94 @@
+# Keyboard Manager Debugging Guide
+
+This document provides guidance on debugging the Keyboard Manager module in PowerToys.
+
+## Module Overview
+
+Keyboard Manager consists of two main components:
+- **Keyboard Manager Editor**: UI application for configuring key and shortcut remappings
+- **Keyboard Manager Engine**: Background process that intercepts and handles keyboard events
+
+## Development Environment Setup
+
+1. Clone the PowerToys repository
+2. Open `PowerToys.sln` in Visual Studio
+3. Ensure all NuGet packages are restored
+4. Build the entire solution in Debug configuration
+
+## Debugging the Editor (UI)
+
+### Setup
+
+1. In Visual Studio, right-click on the `KeyboardManagerEditor` project
+2. Select "Set as Startup Project"
+
+### Common Debugging Scenarios
+
+#### UI Rendering Issues
+
+Breakpoints to consider:
+- `EditKeyboardWindow.cpp`: `CreateWindow()` method 
+- `EditShortcutsWindow.cpp`: `CreateWindow()` method
+
+#### Configuration Changes
+
+When debugging configuration changes:
+1. Set breakpoints in `KeyboardManagerState.cpp` around the `SetRemappedKeys()` or `SetRemappedShortcuts()` methods
+2. Monitor the JSON serialization process in the save functions
+
+### Testing UI Behavior
+
+The `KeyboardManagerEditorTest` project contains tests for the UI functionality. Run these tests to validate UI changes.
+
+## Debugging the Engine (Remapping Logic)
+
+### Setup
+
+1. In Visual Studio, right-click on the `KeyboardManagerEngine` project
+2. Select "Set as Startup Project"
+3. Press F5 to start debugging
+
+### Key Event Flow
+
+The keyboard event processing follows this sequence:
+1. Low-level keyboard hook captures an event
+2. `KeyboardEventHandlers.cpp` processes the event
+3. `KeyboardManager.cpp` applies remapping logic
+4. Event is either suppressed, modified, or passed through
+
+### Breakpoints to Consider
+
+- `main.cpp`: `StartLowlevelKeyboardHook()` - Hook initialization
+- `KeyboardEventHandlers.cpp`: `HandleKeyboardEvent()` - Entry point for each keyboard event
+- `KeyboardManager.cpp`: `HandleKeyEvent()` - Processing individual key events
+- `KeyboardManager.cpp`: `HandleShortcutRemapEvent()` - Processing shortcut remapping
+
+### Logging and Trace
+
+Enable detailed logging by setting the `_DEBUG` and `KBM_VERBOSE_LOGGING` preprocessor definitions.
+
+## Common Issues and Troubleshooting
+
+### Multiple Instances
+
+If you encounter issues with multiple instances, check the mutex logic in `KeyboardManagerEditor.cpp`. The editor uses `PowerToys_KBMEditor_InstanceMutex` to ensure single instance.
+
+### Key Events Not Being Intercepted
+
+1. Verify the hook is properly installed by setting a breakpoint in the hook procedure
+2. Check if any other application is capturing keyboard events at a lower level
+3. Ensure the correct configuration is being loaded from the settings JSON
+
+### UI Freezes or Crashes
+
+1. Check XAML Islands initialization in the Editor
+2. Verify UI thread is not being blocked by IO operations
+3. Look for exceptions in the event handling code
+
+## Advanced Debugging
+
+### Debugging Both Components Simultaneously
+
+To debug both the Editor and Engine:
+1. Launch the Engine first in debug mode
+2. Attach the debugger to the Editor process when it starts

doc/devdocs/modules/mouseutils/findmymouse.md

@@ -0,0 +1,95 @@
+# Find My Mouse
+
+Find My Mouse is a utility that helps users locate their mouse pointer by creating a spotlight effect when activated. It is based on Raymond Chen's SuperSonar utility.
+
+## Implementation
+
+Find My Mouse displays a spotlight effect centered on the cursor location when activated via a keyboard shortcut (typically a double-press of the Ctrl key).
+
+### Key Files
+- `src/modules/MouseUtils/FindMyMouse/FindMyMouse.cpp` - Contains the main implementation
+- Key function: `s_WndProc` - Handles window messages for the utility
+
+### Enabling Process
+
+When the utility is enabled:
+
+1. A background thread is created to run the Find My Mouse logic asynchronously:
+   ```cpp
+   // Enable the PowerToy
+   virtual void enable()
+   {
+       m_enabled = true;  // Mark the module as enabled
+       Trace::EnableFindMyMouse(true);  // Enable telemetry
+       std::thread([=]() { FindMyMouseMain(m_hModule, m_findMyMouseSettings); }).detach();  // Run main logic in background
+   }
+   ```
+
+2. The `CompositionSpotlight` instance is initialized with user settings:
+   ```cpp
+   CompositionSpotlight sonar;
+   sonar.ApplySettings(settings, false);  // Apply settings
+   if (!sonar.Initialize(hinst))
+   {
+       Logger::error("Couldn't initialize a sonar instance.");
+       return 0;
+   }
+
+   m_sonar = &sonar;
+   ```
+
+3. The utility listens for raw input events using `WM_INPUT`, which provides more precise and responsive input detection than standard mouse events.
+
+### Activation Process
+
+The activation process works as follows:
+
+1. **Keyboard Hook Detects Shortcut**
+   - A global low-level keyboard hook is set up during initialization
+   - The hook monitors for the specific activation pattern (double Ctrl press)
+   - Once matched, it sends a `WM_PRIV_SHORTCUT` message to the sonar window:
+     ```cpp
+     virtual void OnHotkeyEx() override
+     {
+         Logger::trace("OnHotkeyEx()");
+         HWND hwnd = GetSonarHwnd();
+         if (hwnd != nullptr)
+         {
+             PostMessageW(hwnd, WM_PRIV_SHORTCUT, NULL, NULL);
+         }
+     }
+     ```
+
+2. **Message Handler Triggers Action**
+   - The custom message is routed to `BaseWndProc()`
+   - The handler toggles the sonar animation:
+     ```cpp
+     if (message == WM_PRIV_SHORTCUT)
+     {
+         if (m_sonarStart == NoSonar)
+             StartSonar();  // Trigger sonar animation
+         else
+             StopSonar();   // Cancel if already running
+     }
+     ```
+
+3. **Sonar Animation**
+   - `StartSonar()` uses `CompositionSpotlight` to display a highlight (ripple/pulse) centered on the mouse pointer
+   - The animation is temporary and fades automatically or can be cancelled by user input
+
+### Event Handling
+
+The Find My Mouse utility handles several types of events:
+
+- **Mouse Events**: Trigger sonar animations (e.g., after a shake or shortcut)
+- **Keyboard Events**: May cancel or toggle the effect
+- **Custom Shortcut Messages**: Handled to allow toggling Find My Mouse using a user-defined hotkey
+
+When the main window receives a `WM_DESTROY` message (on shutdown or disable), the sonar instance is properly cleaned up, and the message loop ends gracefully.
+
+## Debugging
+
+To debug Find My Mouse:
+- Attach to the PowerToys Runner process directly
+- Set breakpoints in the `FindMyMouse.cpp` file
+- When debugging the spotlight effect, visual artifacts may occur due to the debugger's overhead

doc/devdocs/modules/mouseutils/mousehighlighter.md

@@ -0,0 +1,92 @@
+# Mouse Highlighter
+
+Mouse Highlighter is a utility that visualizes mouse clicks by displaying a highlight effect around the cursor when clicked.
+
+## Implementation
+
+Mouse Highlighter runs within the PowerToys Runner process and draws visual indicators (typically circles) around the mouse cursor when the user clicks.
+
+### Key Files
+- `src/modules/MouseUtils/MouseHighlighter/MouseHighlighter.cpp` - Contains the main implementation
+- Key function: `WndProc` - Handles window messages and mouse events
+
+### Enabling Process
+
+When the utility is enabled:
+
+1. A background thread is created to run the mouse highlighter logic asynchronously:
+   ```cpp
+   std::thread([=]() { MouseHighlighterMain(m_hModule, m_highlightSettings); }).detach();
+   ```
+
+2. The Highlighter instance is initialized and configured with user settings:
+   ```cpp
+   Highlighter highlighter;
+   Highlighter::instance = &highlighter;
+   highlighter.ApplySettings(settings);
+   highlighter.MyRegisterClass(hInstance);
+   ```
+
+3. A highlighter window is created:
+   ```cpp
+   instance->CreateHighlighter();
+   ```
+
+4. The utility:
+   - Registers a custom window class 
+   - Creates a transparent window for drawing visuals
+   - Handles the `WM_CREATE` message to initialize the Windows Composition API (Compositor, visuals, and target)
+
+### Activation Process
+
+The activation process works as follows:
+
+1. **Shortcut Detection**
+   - The system detects when the activation shortcut is pressed
+   - A global hotkey listener (registered with `RegisterHotKey` or similar hook) detects the shortcut
+
+2. **Message Transmission**
+   - A message (like `WM_SWITCH_ACTIVATION_MODE`) is sent to the highlighter window via `PostMessage()` or `SendMessage()`
+
+3. **Window Procedure Handling**
+   - The `WndProc` of the highlighter window receives the message and toggles between start and stop drawing modes:
+     ```cpp
+     case WM_SWITCH_ACTIVATION_MODE:
+         if (instance->m_visible)
+             instance->StopDrawing();
+         else
+             instance->StartDrawing();
+     ```
+
+4. **Drawing Activation**
+   - If turning ON, `StartDrawing()` is called, which:
+     - Moves the highlighter window to the topmost position
+     - Slightly offsets the size to avoid transparency bugs
+     - Shows the transparent drawing window
+     - Hooks into global mouse events
+     - Starts drawing visual feedback around the mouse
+
+   - If turning OFF, `StopDrawing()` is called, which:
+     - Hides the drawing window
+     - Removes the mouse hook
+     - Stops rendering highlighter visuals
+
+### Drawing Process
+
+When the mouse highlighter is active:
+1. A low-level mouse hook detects mouse button events
+2. On click, the highlighter draws a circle (or other configured visual) at the cursor position
+3. The visual effect fades over time according to user settings
+4. Each click can be configured to show different colors based on the mouse button used
+
+## Debugging
+
+To debug Mouse Highlighter:
+- Attach to the PowerToys Runner process directly
+- Set breakpoints in the `MouseHighlighter.cpp` file
+- Be aware that visual effects may appear different or stuttery during debugging due to the debugger's overhead
+
+## Known Issues
+
+- There is a reported bug where the highlight color stays on after toggling opacity to 0
+- This issue has been present for more than six months and can still be reproduced in recent PowerToys releases

doc/devdocs/modules/mouseutils/mousejump.md

@@ -0,0 +1,90 @@
+# Mouse Jump
+
+Mouse Jump is a utility that allows users to quickly move their cursor to any location on screen using a grid-based overlay interface.
+
+## Implementation
+
+Unlike the other Mouse Utilities that run within the PowerToys Runner process, Mouse Jump operates as a separate process that communicates with the Runner via events.
+
+### Key Files
+- `src/modules/MouseUtils/MouseJump` - Contains the Runner interface for Mouse Jump
+- `src/modules/MouseUtils/MouseJumpUI` - Contains the UI implementation
+- `src/modules/MouseUtils/MouseJumpUI/MainForm.cs` - Main UI form implementation
+- `src/modules/MouseUtils/MouseJump.Common` - Shared code between the Runner and UI components
+
+### Enabling Process
+
+When the utility is enabled:
+
+1. A separate UI process is launched for Mouse Jump:
+   ```cpp
+   void launch_process()
+   {
+       Logger::trace(L"Starting MouseJump process");
+       unsigned long powertoys_pid = GetCurrentProcessId();
+
+       std::wstring executable_args = L"";
+       executable_args.append(std::to_wstring(powertoys_pid));
+
+       SHELLEXECUTEINFOW sei{ sizeof(sei) };
+       sei.fMask = { SEE_MASK_NOCLOSEPROCESS | SEE_MASK_FLAG_NO_UI };
+       sei.lpFile = L"PowerToys.MouseJumpUI.exe";
+       sei.nShow = SW_SHOWNORMAL;
+       sei.lpParameters = executable_args.data();
+       if (ShellExecuteExW(&sei))
+       {
+           Logger::trace("Successfully started the Mouse Jump process");
+       }
+       else
+       {
+           Logger::error(L"Mouse Jump failed to start. {}", get_last_error_or_default(GetLastError()));
+       }
+
+       m_hProcess = sei.hProcess;
+   }
+   ```
+
+2. The Runner creates shared events for communication with the UI process:
+   ```cpp
+   m_hInvokeEvent = CreateDefaultEvent(CommonSharedConstants::MOUSE_JUMP_SHOW_PREVIEW_EVENT);
+   m_hTerminateEvent = CreateDefaultEvent(CommonSharedConstants::TERMINATE_MOUSE_JUMP_SHARED_EVENT);
+   ```
+
+### Activation Process
+
+The activation process works as follows:
+
+1. **Shortcut Detection**
+   - When the activation shortcut is pressed, the Runner signals the shared event `MOUSE_JUMP_SHOW_PREVIEW_EVENT`
+
+2. **UI Display**
+   - The MouseJumpUI process listens for this event and displays a screen overlay when triggered
+   - The overlay shows a grid or other visual aid to help select a destination point
+
+3. **Mouse Movement**
+   - User selects a destination point on the overlay
+   - The UI process moves the mouse cursor to the selected position
+
+4. **Termination**
+   - When the utility needs to be disabled or PowerToys is shutting down, the Runner signals the `TERMINATE_MOUSE_JUMP_SHARED_EVENT`
+   - The UI process responds by cleaning up and exiting
+
+### User Interface
+
+The Mouse Jump UI is implemented in C# using Windows Forms:
+- Displays a semi-transparent overlay over the entire screen
+- May include grid lines, quadrant divisions, or other visual aids to help with precision selection
+- Captures mouse and keyboard input to allow for selection and cancellation
+- Moves the mouse cursor to the selected location upon confirmation
+
+## Debugging
+
+To debug Mouse Jump:
+
+1. Start by debugging the Runner process directly
+2. Then attach the debugger to the MouseJumpUI process when it launches
+3. Note: Debugging MouseJumpUI directly is challenging because it requires the Runner's process ID to be passed as a parameter at launch
+
+## Community Contributions
+
+Mouse Jump was initially contributed by Michael Clayton (@mikeclayton) and is based on his FancyMouse utility.

doc/devdocs/modules/mouseutils/mousepointer.md

@@ -0,0 +1,114 @@
+# Mouse Pointer Crosshairs
+
+Mouse Pointer Crosshairs is a utility that displays horizontal and vertical lines that intersect at the mouse cursor position, making it easier to track the cursor location on screen.
+
+## Implementation
+
+Mouse Pointer Crosshairs runs within the PowerToys Runner process and draws crosshair lines that follow the cursor in real-time.
+
+### Key Files
+- `src/modules/MouseUtils/MousePointerCrosshairs/InclusiveCrosshairs.cpp` - Contains the main implementation
+- Key function: `WndProc` - Handles window messages and mouse events
+
+### Enabling Process
+
+When the utility is enabled:
+
+1. A background thread is created to run the crosshairs logic asynchronously:
+   ```cpp
+   std::thread([=]() { InclusiveCrosshairsMain(hInstance, settings); }).detach();
+   ```
+
+2. The InclusiveCrosshairs instance is initialized and configured with user settings:
+   ```cpp
+   InclusiveCrosshairs crosshairs;
+   InclusiveCrosshairs::instance = &crosshairs;
+   crosshairs.ApplySettings(settings, false);
+   crosshairs.MyRegisterClass(hInstance);
+   ```
+
+3. The utility:
+   - Creates the crosshairs visuals using Windows Composition API inside `CreateInclusiveCrosshairs()`
+   - Handles the `WM_CREATE` message to initialize the Windows Composition API (Compositor, visuals, and target)
+   - Creates a transparent, layered window for drawing the crosshairs with specific extended window styles (e.g., `WS_EX_LAYERED`, `WS_EX_TRANSPARENT`)
+
+### Activation Process
+
+The activation process works as follows:
+
+1. **Shortcut Detection**
+   - When the activation shortcut is pressed, the window procedure (`WndProc`) receives a custom message `WM_SWITCH_ACTIVATION_MODE`
+
+2. **Toggle Drawing State**
+   ```cpp
+   case WM_SWITCH_ACTIVATION_MODE:
+       if (instance->m_drawing)
+       {
+           instance->StopDrawing();
+       }
+       else
+       {
+           instance->StartDrawing();
+       }
+       break;
+   ```
+
+3. **Start Drawing Function**
+   - The `StartDrawing()` function is called to:
+     - Log the start of drawing
+     - Update the crosshairs position
+     - Check if the cursor should be auto-hidden, and set a timer for auto-hide if enabled
+     - Show the crosshairs window if the cursor is visible
+     - Set a low-level mouse hook to track mouse movements asynchronously
+
+   ```cpp
+   void InclusiveCrosshairs::StartDrawing()
+   {
+       Logger::info("Start drawing crosshairs.");
+       UpdateCrosshairsPosition();
+
+       m_hiddenCursor = false;
+       if (m_crosshairs_auto_hide)
+       {
+           CURSORINFO cursorInfo{};
+           cursorInfo.cbSize = sizeof(cursorInfo);
+           if (GetCursorInfo(&cursorInfo))
+           {
+               m_hiddenCursor = !(cursorInfo.flags & CURSOR_SHOWING);
+           }
+
+           SetAutoHideTimer();
+       }
+
+       if (!m_hiddenCursor)
+       {
+           ShowWindow(m_hwnd, SW_SHOWNOACTIVATE);
+       }
+
+       m_drawing = true;
+       m_mouseHook = SetWindowsHookEx(WH_MOUSE_LL, MouseHookProc, m_hinstance, 0);
+   }
+   ```
+
+4. **Stop Drawing Function**
+   - The `StopDrawing()` function is called to:
+     - Remove the mouse hook
+     - Kill the auto-hide timer
+     - Hide the crosshairs window
+     - Log the stop of drawing
+
+### Cursor Tracking
+
+While active, the utility:
+1. Uses a low-level mouse hook (`WH_MOUSE_LL`) to track cursor movement
+2. Updates crosshair positions in real-time as the mouse moves
+3. Supports auto-hiding functionality when the cursor is inactive for a specified period
+
+## Debugging
+
+To debug Mouse Pointer Crosshairs:
+- Attach to the PowerToys Runner process directly
+- Set breakpoints in the `InclusiveCrosshairs.cpp` file
+- Be aware that during debugging, moving the mouse may cause unexpected or "strange" visual behavior because:
+  - The mouse hook (`MouseHookProc`) updates the crosshairs position on every `WM_MOUSEMOVE` event
+  - This frequent update combined with the debugger's overhead or breakpoints can cause visual glitches or stutters

doc/devdocs/modules/mouseutils/readme.md

@@ -0,0 +1,129 @@
+# 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)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Mouse%20Utilities%22)<br>
+[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 four 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
+
+## Architecture
+
+Most of the sub-modules (Find My Mouse, Mouse Highlighter, and Mouse Pointer Crosshairs) 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)
+
+## 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/mousewithoutborders.md

@@ -1,4 +1,13 @@
 # Mouse Without Borders module
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/mouse-without-borders)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Mouse%20Without%20Borders%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Mouse%20Without%20Borders%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Mouse+Without+Borders%22)
+
 This file contains the documentation for the Mouse Without Borders PowerToy module.
 ## Table of Contents:
 - [Mouse Without Borders module](#mouse-without-borders-module)

doc/devdocs/modules/newplus.md

@@ -0,0 +1,143 @@
+# NewPlus Module
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/newplus)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-New%2B)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-New%2B)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-New%2B+)
+
+## Overview
+
+NewPlus is a PowerToys module that provides a context menu entry for creating new files directly from File Explorer. Unlike some other modules, NewPlus implements a different approach to context menu registration to avoid duplication issues in Windows 11.
+
+## Context Menu Implementation
+
+NewPlus implements two separate context menu handlers:
+
+1. **Windows 10 Handler** (`NewPlus.ShellExtension.win10.dll`)
+   - Implements "old-style" context menu handler for Windows 10 compatibility
+   - Not shown in Windows 11 (this is intentional and controlled by a condition in `QueryContextMenu`)
+   - Registered via registry keys
+
+2. **Windows 11 Handler** (`NewPlus.ShellExtension.dll`)
+   - Implemented as a sparse MSIX package for Windows 11's modern context menu
+   - Only registered and used on Windows 11
+
+This implementation differs from some other modules like ImageResizer which register both handlers on Windows 11, resulting in duplicate menu entries. NewPlus uses selective registration to provide a cleaner user experience, though it can occasionally lead to issues if the Windows 11 handler fails to register properly.
+
+## Project Structure
+
+- **NewPlus.ShellExtension** - Windows 11 context menu handler implementation
+- **NewPlus.ShellExtension.win10** - Windows 10 "old-style" context menu handler implementation
+
+## Debugging NewPlus Context Menu Handlers
+
+### Debugging the Windows 10 Handler
+
+1. Update the registry to point to your debug build:
+   ```
+   Windows Registry Editor Version 5.00
+
+   [HKEY_CLASSES_ROOT\CLSID\{<NewPlus-CLSID>}]
+   @="PowerToys NewPlus Extension"
+
+   [HKEY_CLASSES_ROOT\CLSID\{<NewPlus-CLSID>}\InprocServer32]
+   @="x:\GitHub\PowerToys\x64\Debug\PowerToys.NewPlusExt.win10.dll"
+   "ThreadingModel"="Apartment"
+
+   [HKEY_CURRENT_USER\Software\Classes\Directory\Background\shellex\ContextMenuHandlers\NewPlus]
+   @="{<NewPlus-CLSID>}"
+   ```
+
+2. Restart Explorer:
+   ```
+   taskkill /f /im explorer.exe && start explorer.exe
+   ```
+
+3. Attach the debugger to explorer.exe
+4. Add breakpoints in the NewPlus code
+5. Right-click in File Explorer to trigger the context menu handler
+
+### Debugging the Windows 11 Handler
+
+Debugging the Windows 11 handler requires signing the MSIX package:
+
+1. Build PowerToys to get the MSIX packages
+
+2. **Create certificate** (if you don't already have one):
+   ```powershell
+   New-SelfSignedCertificate -Subject "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" `
+    -KeyUsage DigitalSignature `
+    -Type CodeSigningCert `
+    -FriendlyName "PowerToys SelfCodeSigning" `
+    -CertStoreLocation "Cert:\CurrentUser\My"
+   ```
+
+3. **Get the certificate thumbprint**:
+   ```powershell
+   $cert = Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.FriendlyName -like "*PowerToys*" }
+   $cert.Thumbprint
+   ```
+
+4. **Install the certificate in the Trusted Root** (requires admin Terminal):
+   ```powershell
+   Export-Certificate -Cert $cert -FilePath "$env:TEMP\PowerToysCodeSigning.cer"
+   Import-Certificate -FilePath "$env:TEMP\PowerToysCodeSigning.cer" -CertStoreLocation Cert:\LocalMachine\Root
+   ```
+
+   Alternatively, you can manually install the certificate using the Certificate Import Wizard:
+
+   ![wizard 1](../images/newplus/wizard1.png)
+   ![wizard 2](../images/newplus/wizard2.png)
+   ![wizard 3](../images/newplus/wizard3.png)
+   ![wizard 4](../images/newplus/wizard4.png)
+
+5. Sign the MSIX package:
+   ```powershell
+   SignTool sign /fd SHA256 /sha1 <THUMBPRINT> "x:\GitHub\PowerToys\x64\Debug\WinUI3Apps\NewPlusPackage.msix"
+   ```
+   
+   Note: SignTool might not be in your PATH, so you may need to specify the full path, e.g.:
+   ```powershell
+   & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\signtool.exe" sign /fd SHA256 /sha1 <THUMBPRINT> "x:\GitHub\PowerToys\x64\Debug\WinUI3Apps\NewPlusPackage.msix"
+   ```
+
+6. Check if the NewPlus package is already installed and remove it if necessary:
+   ```powershell
+   Get-AppxPackage -Name Microsoft.PowerToys.NewPlusContextMenu
+   Remove-AppxPackage Microsoft.PowerToys.NewPlusContextMenu_<VERSION>_neutral__8wekyb3d8bbwe
+   ```
+
+7. Install the new signed MSIX package (optional if launching PowerToys settings first):
+   ```powershell
+   Add-AppxPackage -Path "x:\GitHub\PowerToys\x64\Debug\WinUI3Apps\NewPlusPackage.msix" -ExternalLocation "x:\GitHub\PowerToys\x64\Debug\WinUI3Apps"
+   ```
+   
+   Note: If you prefer, you can simply launch PowerToys settings and enable the NewPlus module, which will install the MSIX package for you.
+
+8. Restart Explorer to ensure the new context menu handler is loaded:
+   ```powershell
+   taskkill /f /im explorer.exe && start explorer.exe
+   ```
+
+9. Run Visual Studio as administrator (optional)
+
+10. Set breakpoints in the code (e.g., in [shell_context_menu.cpp#L45](/src/modules/NewPlus/NewShellExtensionContextMenu/shell_context_menu.cpp#L45))
+
+11. Right-click in File Explorer and attach the debugger to the `DllHost.exe` process (with NewPlus title) that loads when the context menu is invoked
+![alt text](../images/newplus/debug.png)
+
+12. Right-click again (quickly) after attaching the debugger to trigger the breakpoint
+
+Note: The DllHost process loads the DLL only when the context menu is triggered and unloads after, making debugging challenging. For easier development, consider using logging or message boxes instead of breakpoints.
+
+## Common Issues
+
+- If the Windows 11 context menu entry doesn't appear, it may be due to:
+  - The package not being properly registered
+  - Explorer not being restarted after registration
+  - A signature issue with the MSIX package
+  
+- For development and testing, using the Windows 10 handler can be easier since it doesn't require signing.

doc/devdocs/modules/peek/readme.md

@@ -1,5 +1,14 @@
 # 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)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-Peek)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-Peek)
+
+
 > Documentation is currently under construction
 
 ## Dev file previewer

doc/devdocs/modules/powerrename.md

@@ -1,23 +1,108 @@
-#### [`dllmain.cpp`](/src/modules/powerrename/dll/dllmain.cpp)
-TODO
+# PowerRename
 
-#### [`PowerRenameExt.cpp`](/src/modules/powerrename/dll/PowerRenameExt.cpp)
-TODO
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/powerrename)
 
-#### [`Helpers.cpp`](/src/modules/powerrename/lib/Helpers.cpp)
-TODO
+## Quick Links
 
-#### [`PowerRenameItem.cpp`](/src/modules/powerrename/lib/PowerRenameItem.cpp)
-TODO
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-PowerRename)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-PowerRename)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-PowerRename)
 
-#### [`PowerRenameManager.cpp`](/src/modules/powerrename/lib/PowerRenameManager.cpp)
-TODO
+PowerRename is a Windows shell extension that enables batch renaming of files using search and replace or regular expressions.
 
-#### [`PowerRenameRegEx.cpp`](/src/modules/powerrename/lib/PowerRenameRegEx.cpp)
-TODO
+## Overview
 
-#### [`Settings.cpp`](/src/modules/powerrename/lib/Settings.cpp)
-TODO
+PowerRename provides a powerful and flexible way to rename files in File Explorer. It is accessible through the Windows context menu and allows users to:
+- Preview changes before applying them
+- Use search and replace with regular expressions
+- Filter items by type (files or folders)
+- Apply case-sensitive or case-insensitive matching
+- Save and reuse recent search/replace patterns
 
-#### [`trace.cpp`](/src/modules/powerrename/lib/trace.cpp)
-TODO
+## Architecture
+
+PowerRename consists of multiple components:
+- Shell Extension DLL (context menu integration)
+- WinUI 3 UI application
+- Core renaming library
+
+### Technology Stack
+- C++/WinRT
+- WinUI 3
+- COM for shell integration
+
+## Context Menu Integration
+
+PowerRename integrates with the Windows context menu following the [PowerToys Context Menu Handlers](../common/context-menus.md) pattern. It uses a dual registration approach to ensure compatibility with both Windows 10 and Windows 11.
+
+### Registration Process
+
+The context menu registration entry point is in `PowerRenameExt/dllmain.cpp::enable`, which registers:
+- A traditional shell extension for Windows 10
+- A sparse MSIX package for Windows 11 context menus
+
+For more details on the implementation approach, see the [Dual Registration section](../common/context-menus.md#1-dual-registration-eg-imageresizer-powerrename) in the context menu documentation.
+
+## Code Components
+
+### [`dllmain.cpp`](/src/modules/powerrename/dll/dllmain.cpp)
+Contains the DLL entry point and module activation/deactivation code. The key function `RunPowerRename` is called when the context menu option is invoked, which launches the PowerRenameUI.
+
+### [`PowerRenameExt.cpp`](/src/modules/powerrename/dll/PowerRenameExt.cpp)
+Implements the shell extension COM interfaces required for context menu integration, including:
+- `IShellExtInit` for initialization 
+- `IContextMenu` for traditional context menu support
+- `IExplorerCommand` for Windows 11 context menu support
+
+### [`Helpers.cpp`](/src/modules/powerrename/lib/Helpers.cpp)
+Utility functions used throughout the PowerRename module, including file system operations and string manipulation.
+
+### [`PowerRenameItem.cpp`](/src/modules/powerrename/lib/PowerRenameItem.cpp)
+Represents a single item (file or folder) to be renamed. Tracks original and new names and maintains state.
+
+### [`PowerRenameManager.cpp`](/src/modules/powerrename/lib/PowerRenameManager.cpp)
+Manages the collection of items to be renamed and coordinates the rename operation.
+
+### [`PowerRenameRegEx.cpp`](/src/modules/powerrename/lib/PowerRenameRegEx.cpp)
+Implements the regular expression search and replace functionality used for renaming.
+
+### [`Settings.cpp`](/src/modules/powerrename/lib/Settings.cpp)
+Manages user preferences and settings for the PowerRename module.
+
+### [`trace.cpp`](/src/modules/powerrename/lib/trace.cpp)
+Implements telemetry and logging functionality.
+
+## UI Implementation
+
+PowerRename uses WinUI 3 for its user interface. The UI allows users to:
+- Enter search and replace patterns
+- Preview rename results in real-time
+- Access previous search/replace patterns via MRU (Most Recently Used) lists
+- Configure various options
+
+### Key UI Components
+
+- Search/Replace input fields with x:Bind to `SearchMRU`/`ReplaceMRU` collections
+- Preview list showing original and new filenames
+- Settings panel for configuring rename options
+- Event handling for `SearchReplaceChanged` to update the preview in real-time
+
+## Debugging
+
+### Debugging the Context Menu
+
+See the [Debugging Context Menu Handlers](../common/context-menus.md#debugging-context-menu-handlers) section for general guidance on debugging PowerToys context menu extensions.
+
+### Debugging the UI
+
+To debug the PowerRename UI:
+
+1. Add file paths manually in `\src\modules\powerrename\PowerRenameUILib\PowerRenameXAML\App.xaml.cpp`
+2. Set the PowerRenameUI project as the startup project
+3. Run in debug mode to test with the manually specified files
+
+### Common Issues
+
+- Context menu not appearing: Ensure the extension is properly registered and Explorer has been restarted
+- UI not launching: Check Event Viewer for errors related to WinUI 3 application activation
+- Rename operations failing: Verify file permissions and check for locked files

doc/devdocs/modules/quickaccent.md

@@ -0,0 +1,119 @@
+# Quick Accent
+
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/quick-accent)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Quick%20Accent%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Quick%20Accent%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Quick+Accent%22)
+
+## Overview
+
+Quick Accent (formerly known as Power Accent) is a PowerToys module that allows users to quickly insert accented characters by holding a key and pressing an activation key (like the Space key or arrow keys). For example, holding 'a' might display options like 'à', 'á', 'â', etc. This tool enhances productivity by streamlining the input of special characters without the need to memorize keyboard shortcuts.
+
+## Architecture
+
+The Quick Accent module consists of four main components:
+
+```
+poweraccent/
+├── PowerAccent.Core/               # Core component containing Language Sets
+├── PowerAccent.UI/                 # The character selector UI
+├── PowerAccentKeyboardService/     # Keyboard Hook
+└── PowerAccentModuleInterface/     # DLL interface
+```
+
+### Module Interface (PowerAccentModuleInterface)
+
+The Module Interface, implemented in `PowerAccentModuleInterface/dllmain.cpp`, is responsible for:
+- Handling communication between PowerToys Runner and the PowerAccent process
+- Managing module lifecycle (enable/disable/settings)
+- Launching and terminating the PowerToys.PowerAccent.exe process
+
+### Core Logic (PowerAccent.Core)
+
+The Core component contains:
+- Main accent character logic
+- Keyboard input detection
+- Character mappings for different languages
+- Management of language sets and special characters (currency, math symbols, etc.)
+- Usage statistics for frequently used characters
+
+### UI Layer (PowerAccent.UI)
+
+The UI component is responsible for:
+- Displaying the toolbar with accent options
+- Handling user selection of accented characters
+- Managing the visual positioning of the toolbar
+
+### Keyboard Service (PowerAccentKeyboardService)
+
+This component:
+- Implements keyboard hooks to detect key presses
+- Manages the trigger mechanism for displaying the accent toolbar
+- Handles keyboard input processing
+
+## Implementation Details
+
+### Activation Mechanism
+
+The Quick Accent is activated when:
+1. A user presses and holds a character key (e.g., 'a')
+2. User presses the trigger key
+3. After a brief delay (around 300ms per setting), the accent toolbar appears
+4. The user can select an accented variant using the trigger key
+5. Upon releasing the keys, the selected accented character is inserted
+
+### Character Sets
+
+The module includes multiple language-specific character sets and special character sets:
+- Various language sets for different alphabets and writing systems
+- Special character sets (currency symbols, mathematical notations, etc.)
+- These sets are defined in the core component and can be extended
+
+### Known Behaviors
+
+- The module has a specific timing mechanism for activation that users have become accustomed to. Initially, this was considered a bug (where the toolbar would still appear even after quickly tapping and releasing keys), but it has been maintained as expected behavior since users rely on it.
+- Multiple rapid key presses can trigger multiple background tasks.
+
+## Future Considerations
+
+- Potential refinements to the activation timing mechanism
+- Additional language and special character sets
+- Improved UI positioning in different application contexts
+
+## Debugging
+
+To debug the Quick Accent module via **runner** approach, follow these steps:
+
+0. Get familiar with the overall [Debugging Process](../development/debugging.md) for PowerToys.
+1. **Build** the entire PowerToys solution in Visual Studio
+2. Navigate to the **PowerAccent** folder in Solution Explorer
+3. Open the file you want to debug and set **breakpoints** at the relevant locations
+4. Find the **runner** project in the root of the solution
+5. Right-click on the **runner** project and select "*Set as Startup Project*"
+6. Start debugging by pressing `F5` or clicking the "*Start*" button
+7. When the PowerToys Runner launches, **enable** the Quick Accent module in the UI
+8. Use the Visual Studio Debug menu or press `Ctrl+Alt+P` to open "*Reattach to Process*"
+9. Find and select "**PowerToys.PowerAccent.exe**" in the process list
+10. Trigger the action in Quick Accent that should hit your breakpoint
+11. Verify that the debugger breaks at your breakpoint and you can inspect variables and step through code
+
+This process allows you to debug the Quick Accent module while it's running as part of the full PowerToys application.
+
+### Alternative Debugging Approach
+
+To directly debug the Quick Accent UI component:
+
+0. Get familiar with the overall [Debugging Process](../development/debugging.md) for PowerToys.
+1. **Build** the entire PowerToys solution in Visual Studio
+2. Navigate to the **PowerAccent** folder in Solution Explorer
+3. Open the file you want to debug and set **breakpoints** at the relevant locations
+4. Right-click on the **PowerAccent.UI** project and select "*Set as Startup Project*"
+5. Start debugging by pressing `F5` or clicking the "*Start*" button
+6. Verify that the debugger breaks at your breakpoint and you can inspect variables and step through code
+
+**Known issue**: You may encounter approximately 78 errors during the start of debugging.<br>
+**Solution**: If you encounter errors, right-click on the **PowerAccent** folder in Solution Explorer and select "*Rebuild*". After rebuilding, start debugging again.

doc/devdocs/modules/readme.md

@@ -0,0 +1,43 @@
+# 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/modules/registrypreview.md

@@ -0,0 +1,85 @@
+# Registry Preview Module
+
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/registry-preview)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Registry%20Preview%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Registry%20Preview%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Registry+Preview%22)
+[CheckList](https://github.com/microsoft/PowerToys/blob/releaseChecklist/doc/releases/tests-checklist-template.md?plain=1#L641)
+
+## Overview
+
+Registry Preview simplifies the process of visualizing and editing complex Windows Registry files. It provides a powerful interface to preview, edit, and write changes to the Windows Registry. The module leverages the [Monaco Editor](../common/monaco-editor.md) to provide features like syntax highlighting and line numbering for registry files.
+
+## Technical Architecture
+
+Registry Preview is built using WinUI 3 with the [Monaco Editor](../common/monaco-editor.md) embedded for text editing capabilities. Monaco was originally designed for web environments but has been integrated into this desktop application to leverage its powerful editing features.
+
+The module consists of several key components:
+
+1. **Main Windows Interface** - Handles the UI interactions, window messaging, and resource loading
+2. **Monaco Editor Integration** - Embeds the Monaco web-based editor into WinUI 3 (see [Monaco Editor documentation](../common/monaco-editor.md) for details)
+3. **Registry Parser** - Parses registry files and builds a tree structure for visualization
+4. **Editor Control** - Manages the editing capabilities and syntax highlighting
+
+## Code Structure
+
+The Registry Preview module is organized into the following projects:
+
+- **RegistryPreview** - Main window implementation, including Windows message handling, resource loading, and service injection
+- **RegistryPreviewUILib** - UI implementation details and backend logic
+- **RegistryPreviewExt** - Project configuration and setup
+- **RegistryPreview.FuzzTests** - Fuzzing tests for the module
+
+Key files and components:
+
+1. **MonacoEditorControl** - Handles the embedding of [Monaco](../common/monaco-editor.md) into WinUI 3 and sets up the WebView container
+2. **MainWindow** - Manages all event handling in one place
+3. **Utilities** - Contains shared helper methods and utility classes
+
+## Main Functions
+
+- **MonacoEditorControl**: Controls editing in Monaco
+- **GetRuntimeMonacoDirectory**: Gets the current directory path
+- **OpenRegistryFile**: Opens and processes a registry file (first-time open)
+- **RefreshRegistryFile**: Re-opens and processes an already opened file
+- **ParseRegistryFile**: Parses text from the editor
+- **AddTextToTree**: Creates TreeView nodes from registry keys
+- **ShowMessageBox**: Wrapper method for displaying message boxes
+
+## Debugging Registry Preview
+
+### Setup Debugging Environment
+
+1. Set the PowerToys Runner as the parent process
+2. Set the RegistryPreviewUILib project as the child process for debugging
+3. Use the PowerToys Development Utility tool to configure debugging
+
+### Debugging Tips
+
+1. The main application logic is in the RegistryPreviewUILib project
+2. Monaco-related issues may require debugging the WebView component (see [Monaco Editor documentation](../common/monaco-editor.md) for details)
+3. For parsing issues, add breakpoints in the ParseRegistryFile method
+4. UI issues are typically handled in the main RegistryPreview project
+
+## UI Automation
+
+Currently, Registry Preview does not have UI automation tests implemented. This is a potential area for future development.
+
+## Recent Updates
+
+Registry Preview has received community contributions, including:
+- UI improvements
+- New buttons and functionality
+- Data preview enhancements
+- Save button improvements
+
+## Future Considerations
+
+- Adding UI automation tests
+- Further [Monaco editor](../common/monaco-editor.md) updates
+- Enhanced registry parsing capabilities
+- Improved visualization options

doc/devdocs/modules/screenruler.md

@@ -0,0 +1,68 @@
+# Screen Ruler
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/screen-ruler)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Screen%20Ruler%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Screen%20Ruler%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Screen+Ruler%22)
+
+## Overview
+
+Screen Ruler (project name: MeasureTool or Measure 2) is a PowerToys module that allows users to measure pixel distances and detect color boundaries on the screen. The tool renders an overlay UI using DirectX and provides several measurement utilities.
+
+## Features
+
+- **Bounce Utility**: Measure a rectangular zone by dragging with a left click
+- **Spacing Tool**: Measure the length of a line with the same color with the same pixel value both horizontally and vertically
+- **Horizontal Spacing**: Measure the line with the same color in the horizontal direction
+- **Vertical Spacing**: Measure the line with the same color in the vertical direction
+
+## Architecture & Implementation
+
+The Screen Ruler module consists of several components:
+
+### MeasureToolModuleInterface
+
+- **Dllmain.cpp**: Provides functionality to start and stop the Measure Tool process based on hotkey events, manage settings, and handle events.
+
+### MeasureToolUI
+
+- **App.xaml.cs**: Main entrance of the app. Initializes MeasureToolCore and activates a new main window.
+- **MainWindow.xaml.cs**: Sets properties and behaviors for the window, and handles user click interactions.
+- **NativeMethods.cs**: Interacts with the Windows API to manipulate window properties, such as positioning and sizing.
+- **Settings.cs**: Gets the default measure style from settings.
+
+### PowerToys.MeasureToolCore
+
+- **PowerToys.MeasureToolCore**: Handles initialization, state management, and starts the measure tool and bounds tool.
+- **BGRATextureView.h**: Manages and interacts with BGRA textures in a Direct3D 11 context.
+- **Measurement.cpp**: Defines a Measurement struct that represents a rectangular measurement area, including methods for converting and printing measurement details in various units.
+- **Clipboard.cpp**: Copies measurement data to the clipboard.
+- **D2DState.cpp**: Manages Direct2D rendering state and draws text boxes.
+- **DxgiAPI.cpp**: Creates and manages Direct3D and Direct2D devices.
+- **EdgeDetection.cpp**: Detects edges in a BGRA texture.
+- **OverlayUI.cpp**: Creates and manages overlay windows for tools like MeasureTool and BoundsTool.
+- **BoundsToolOverlayUI.cpp**: UI implementation for bounds feature. Handles mouse and touch events to draw measurement rectangles on the screen and display their pixels.
+- **MeasureToolOverlayUI.cpp**: UI implementation for measure feature. Draws measurement lines on the screen and displays their pixels.
+- **ScreenCapturing.cpp**: Continuously captures the screen, detects edges, and updates the measurement state for real-time drawing of measurement lines.
+- **PerGlyphOpacityTextRender.cpp**: Renders text with varying opacity on a Direct2D render target.
+
+## Building & Debugging
+
+### Building
+
+1. Open PowerToys.sln in Visual Studio
+2. In the Solutions Configuration drop-down menu, select Release or Debug
+3. From the Build menu, choose Build Solution
+4. The executable app for Screen Ruler is named PowerToys.MeasureToolUI.exe
+
+### Debugging
+
+1. Right-click the project MeasureToolUI and click 'Set as Startup Project'
+2. Right-click the project MeasureToolUI and click 'Debug'
+
+## Known Issues
+
+There are several open bugs for the Screen Ruler module, most of which are related to crashing issues. These can be found in the [PowerToys issues list](https://github.com/microsoft/PowerToys/issues?q=is%3Aissue%20state%3Aopen%20Screen%20ruler%20type%3ABug).

doc/devdocs/modules/shortcut_guide.md

@@ -1,17 +1,91 @@
+# Shortcut Guide
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/shortcut-guide)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Shortcut%20Guide%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Shortcut%20Guide%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Shortcut+Guide%22+)
+
+## Overview
+Shortcut Guide is a PowerToy that displays an overlay of available keyboard shortcuts when the Windows key is pressed and held. It provides a visual reference for Windows key combinations, helping users discover and utilize built-in Windows shortcuts.
+
+## Usage
+- Press and hold the Windows key to display the overlay of available shortcuts
+- Press the hotkey again to dismiss the overlay
+- The overlay displays Windows shortcuts with their corresponding actions
+
+## Build and Debug Instructions
+
+### Build
+1. Open PowerToys.sln in Visual Studio
+2. Select Release or Debug in the Solutions Configuration drop-down menu
+3. From the Build menu, choose Build Solution
+4. The executable is named PowerToys.ShortcutGuide.exe
+
+### Debug
+1. Right-click the ShortcutGuide project and select 'Set as Startup Project'
+2. Right-click the project again and select 'Debug'
+
+## Code Structure
+
+![Diagram](../images/shortcutguide/diagram.png)
+
+### Core Files
+
 #### [`dllmain.cpp`](/src/modules/shortcut_guide/dllmain.cpp)
-Contains DLL boilerplate code.
+Contains DLL boilerplate code. Implements the PowertoyModuleIface, including enable/disable functionality and GPO policy handling. Captures hotkey events and starts the PowerToys.ShortcutGuide.exe process to display the shortcut guide window.
 
 #### [`shortcut_guide.cpp`](/src/modules/shortcut_guide/shortcut_guide.cpp)
-Contains the module interface code. It initializes the settings values and the keyboard event listener.
+Contains the module interface code. It initializes the settings values and the keyboard event listener. Defines the OverlayWindow class, which manages the overall logic and event handling for the PowerToys Shortcut Guide.
 
 #### [`overlay_window.cpp`](/src/modules/shortcut_guide/overlay_window.cpp)
-Contains the code for loading the SVGs, creating and rendering of the overlay window.
+Contains the code for loading the SVGs, creating and rendering of the overlay window. Manages and displays overlay windows with SVG graphics through two main classes:
+- D2DOverlaySVG: Handles loading, resizing, and manipulation of SVG graphics
+- D2DOverlayWindow: Manages the display and behavior of the overlay window
 
 #### [`keyboard_state.cpp`](/src/modules/shortcut_guide/keyboard_state.cpp)
 Contains helper methods for checking the current state of the keyboard.
 
 #### [`target_state.cpp`](/src/modules/shortcut_guide/target_state.cpp)
-State machine that handles the keyboard events. It’s responsible for deciding when to show the overlay, when to suppress the Start menu (if the overlay is displayed long enough), etc.
+State machine that handles the keyboard events. It's responsible for deciding when to show the overlay, when to suppress the Start menu (if the overlay is displayed long enough), etc. Handles state transitions and synchronization to ensure the overlay is shown or hidden appropriately based on user interactions.
 
 #### [`trace.cpp`](/src/modules/shortcut_guide/trace.cpp)
 Contains code for telemetry.
+
+### Supporting Files
+
+#### [`animation.cpp`](/src/modules/shortcut_guide/animation.cpp)
+Handles the timing and interpolation of animations. Calculates the current value of an animation based on elapsed time and a specified easing function.
+
+#### [`d2d_svg.cpp`](/src/modules/shortcut_guide/d2d_svg.cpp)
+Provides functionality for loading, resizing, recoloring, rendering, and manipulating SVG images using Direct2D.
+
+#### [`d2d_text.cpp`](/src/modules/shortcut_guide/d2d_text.cpp)
+Handles creation, resizing, alignment, and rendering of text using Direct2D and DirectWrite.
+
+#### [`d2d_window.cpp`](/src/modules/shortcut_guide/d2d_window.cpp)
+Manages a window using Direct2D and Direct3D for rendering. Handles window creation, resizing, rendering, and destruction.
+
+#### [`native_event_waiter.cpp`](/src/modules/shortcut_guide/native_event_waiter.cpp)
+Waits for a named event and executes a specified action when the event is triggered. Uses a separate thread to handle event waiting and action execution.
+
+#### [`tasklist_positions.cpp`](/src/modules/shortcut_guide/tasklist_positions.cpp)
+Handles retrieving and updating the positions and information of taskbar buttons in Windows.
+
+#### [`main.cpp`](/src/modules/shortcut_guide/main.cpp)
+The entry point for the PowerToys Shortcut Guide application. Handles initialization, ensures single instance execution, manages parent process termination, creates and displays the overlay window, and runs the main event loop.
+
+## Features and Limitations
+
+- The overlay displays Windows shortcuts (Windows key combinations)
+- The module supports localization, but only for the Windows controls on the left side of the overlay
+- It's currently rated as a P3 (lower priority) module
+
+## Future Development
+
+A community-contributed version 2 is in development that will support:
+- Application-specific shortcuts based on the active application
+- Additional shortcuts beyond Windows key combinations
+- PowerToys shortcuts

doc/devdocs/modules/textextractor.md

@@ -0,0 +1,34 @@
+# Text Extractor
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/text-extractor)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3A%22Product-Text%20Extractor%22)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3A%22Product-Text%20Extractor%22)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3A%22Product-Text+Extractor%22)
+
+## Overview
+Text Extractor is a PowerToys utility that enables users to extract and copy text from anywhere on the screen, including inside images and videos. The module uses Optical Character Recognition (OCR) technology to recognize text in visual content. This module is based on Joe Finney's Text Grab.
+
+## How it works
+Text Extractor captures the screen content and uses OCR to identify and extract text from the selected area. Users can select a region of the screen, and Text Extractor will convert any visible text in that region into copyable text.
+
+## Architecture
+
+### Components
+- **EventMonitor**: Handles the `ShowPowerOCRSharedEvent` which triggers the OCR functionality
+- **OCROverlay**: The main UI component that provides:
+  - Language selection for OCR processing
+  - Canvas for selecting the screen area to extract text from
+- **Screen Capture**: Uses `CopyFromScreen` to capture the screen content as the overlay background image
+
+### Activation Methods
+- **Global Shortcut**: Activates Text Extractor through a keyboard shortcut
+- **LaunchOCROverlayOnEveryScreen**: Functionality to display the OCR overlay across multiple monitors
+
+## Technical Implementation
+Text Extractor is implemented using Windows Presentation Foundation (WPF) technology, which provides the UI framework for the selection canvas and other interface elements.
+
+## User Experience
+When activated, Text Extractor displays an overlay on the screen that allows users to select an area containing text. Once selected, the OCR engine processes the image and extracts any text found, which can then be copied to the clipboard.

doc/devdocs/modules/workspaces.md

@@ -0,0 +1,34 @@
+# Workspaces
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/workspaces)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-Workspaces)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AIssue-Bug%20label%3AProduct-Workspaces)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-Workspaces)
+
+## Overview
+
+Workspaces is a PowerToys module that allows users to save and restore window layouts for different projects or workflows.
+
+## Links
+
+- [Source code folder](https://github.com/microsoft/PowerToys/tree/main/src/modules/Workspaces)
+- [Issue tracker](https://github.com/microsoft/PowerToys/issues?q=is%3Aissue+label%3AWorkspaces)
+
+## Implementation Details
+
+TODO: Add implementation details
+
+## Debugging
+
+TODO: Add debugging information
+
+## Settings
+
+TODO: Add settings documentation
+
+## Future Improvements
+
+TODO: Add potential future improvements

doc/devdocs/modules/zoomit.md

@@ -0,0 +1,194 @@
+# ZoomIt Module
+
+[Public overview - Microsoft Learn](https://learn.microsoft.com/en-us/windows/powertoys/zoomit)
+
+## Quick Links
+
+[All Issues](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-ZoomIt)<br>
+[Bugs](https://github.com/microsoft/PowerToys/issues?q=is%3Aopen%20label%3AProduct-ZoomIt%20label%3AIssue-Bug%20)<br>
+[Pull Requests](https://github.com/microsoft/PowerToys/pulls?q=is%3Apr+is%3Aopen+label%3AProduct-ZoomIt)
+
+## Overview
+
+ZoomIt is a screen zoom and annotation tool originally from Microsoft's Sysinternals suite. It allows users to:
+
+- Zoom in on specific areas of the screen
+- Draw and annotate on the screen while zoomed in
+- Use a timer for presentations or breaks
+- Pan and move while zoomed in
+- Record screen activity with audio
+
+ZoomIt runs in the background and is activated via customizable hotkeys.
+
+## Special Integration Considerations
+
+Unlike other PowerToys modules, ZoomIt has some unique integration aspects:
+
+1. **Registry-based Settings**: ZoomIt uses registry settings instead of JSON files (which is the standard for other PowerToys modules). This was required to maintain compatibility with the standalone Sysinternals version.
+
+2. **Dual Source of Truth**: The PowerToys repository serves as the source of truth for both the PowerToys version and the standalone Sysinternals version, with build flags to differentiate between them.
+
+3. **Settings Integration**: A special WinRT/C++ interop library was developed to bridge between PowerToys' JSON-based settings system and ZoomIt's registry-based settings.
+
+## Technical Architecture
+
+The ZoomIt module consists of the following components:
+
+1. **ZoomIt Executable** (`PowerToys.ZoomIt.exe`): The main ZoomIt application that provides the zooming and annotation functionality.
+
+2. **Module Interface** (`PowerToys.ZoomItModuleInterface.dll`): Implements the PowerToys module interface to integrate with the PowerToys runner.
+
+3. **Settings Interop** (`ZoomItSettingsInterop`): A WinRT/C++ interop library that enables communication between PowerToys settings and ZoomIt's registry settings.
+
+![key functions](../images/zoomit/functions.png)
+
+### Directory Structure
+
+```
+src/
+├── modules/
+│   └── ZoomIt/
+│       ├── ZoomIt/             # Main ZoomIt application code
+│       ├── ZoomItModuleInterface/  # PowerToys module interface implementation
+│       └── ZoomItSettingsInterop/  # WinRT/C++ interop for settings
+├── settings-ui/
+│   └── Settings.UI/
+│       ├── SettingsXAML/
+│       │   └── Views/
+│       │       └── ZoomItPage.xaml  # ZoomIt settings page UI
+│       └── ViewModels/
+│           └── ZoomItViewModel.cs   # ZoomIt settings view model
+└── common/
+    └── sysinternals/          # Common code from Sysinternals
+```
+
+
+## Settings Management
+
+ZoomIt's settings are stored in the Windows registry instead of JSON files to maintain compatibility with the standalone version. The settings include:
+
+- Hotkey combinations for different modes (zoom, draw, etc.)
+- Drawing options (colors, line thickness, etc.)
+- Font settings for text annotations
+- Microphone selection for recording
+- Custom file paths for demo mode and break backgrounds
+
+The `ZoomItSettingsInterop` library handles:
+1. Loading settings from registry and converting to JSON for PowerToys settings UI
+2. Saving changes from the settings UI back to the registry
+3. Notifying the ZoomIt application when settings change
+
+![interop](../images/zoomit/interop.png)
+
+## Integration Steps
+
+The integration of ZoomIt into PowerToys involved these key steps:
+
+1. **Code Migration**:
+   - Moving code from the Sysinternals ZoomIt repository to `src/modules/ZoomIt/ZoomIt`
+   - Adding required common libraries to `src/common/sysinternals`
+   - Sanitizing code for open source (removing private APIs, undocumented details, etc.)
+   - Ensuring no private APIs (validated through APIScan)
+   - Removing references to undocumented implementation details, constants, and names
+   - Standardizing dependencies with other PowerToys utilities
+
+2. **Module Interface Implementation**:
+   - Creating the PowerToys module interface
+   - Adding process management (start/terminate)
+   - Implementing event-based communication for settings updates
+   - Adding named events for communication between PowerToys and ZoomIt
+
+3. **Settings Integration**:
+   - Extracting ZoomIt settings code to a shareable component
+   - Creating a WinRT/C++ interop library for registry-JSON conversion
+   - Implementing all settings UI controls in PowerToys settings
+   - Building `ZoomItSettingsInterop` as a bridge between registry and JSON settings
+
+4. **PowerToys Integration**:
+   - Adding ZoomIt to the PowerToys runner
+   - Adding GPO rules for ZoomIt
+   - Implementing telemetry and logging
+   - Creating OOBE (out-of-box experience) page with animated tutorial
+   - Adding ZoomIt to process termination list for proper cleanup
+   - Adding telemetry events documentation
+
+5. **UI/UX Adjustments**:
+   - Redirecting ZoomIt's settings UI to PowerToys settings
+   - Handling hotkey conflicts with warning notifications
+   - Modifying tray icon behavior
+   - Removing original ZoomIt options menu entries
+   - Adding Sysinternals attribution on the settings page
+
+6. **Build System Updates**:
+   - Adding ZoomIt to the PowerToys solution
+   - Implementing build flags for standalone vs. PowerToys versions
+   - Adding signing for new binaries
+   - Fixing analyzer errors and code quality issues
+
+## Debug Instructions
+1. Build the entire PowerToys solution at least once.
+2. Set `runner` as the startup project and start debugging.
+3. Once the PowerToys Settings app is running and ensure ZoomIt is activated.
+4. Set `ZoomIt` as the startup project in Visual Studio.
+5. Press `Ctrl + Alt + P` and attach ZoomIt to the process.
+6. You should now be able to set breakpoints and step through the code.
+
+## Special Implementation Details
+
+### Font Selection
+
+ZoomIt requires storing font information as a binary LOGFONT structure in the registry. This required special handling:
+
+- Creating P/Invoke declarations for Windows font APIs
+- Base64 encoding the binary data for transfer through JSON
+- Using native Windows dialogs for font selection
+
+### Hotkey Management
+
+ZoomIt registers hotkeys through the Windows RegisterHotKey API. Special handling was needed to:
+
+- Detect and notify about hotkey conflicts
+- Update hotkeys when settings change
+- Support modifier keys
+
+### Process Communication
+
+Communication between PowerToys and ZoomIt uses:
+- Command-line arguments to pass PowerToys process ID
+- Named events for signaling settings changes and exit requests
+- Windows messages for internal ZoomIt state management
+
+## Implementation Challenges
+
+Several challenges were encountered during ZoomIt integration:
+
+1. **First-Run Behavior**:
+   - Font loading crashed when no ZoomIt data existed in registry
+   - Hotkeys weren't registered on first run with no existing data
+   - Implemented safeguards to handle missing registry data
+
+2. **Settings Synchronization**:
+   - Modifier keys for shortcuts weren't correctly updated when settings changed
+   - Implemented proper event notification for settings changes
+   - Added hotkey conflict detection and warnings
+
+3. **File Interaction**:
+   - ZoomIt file pickers changed the working directory of the Settings project
+   - Fixed to maintain proper directory context
+
+4. **Drawing Issues**:
+   - Color settings lacking opacity caused drawing functionality to fail
+   - Removed internal state settings that weren't truly editable
+
+5. **Dual-Build Support**:
+   - Added build flags to support both PowerToys and standalone Sysinternals versions
+   - Implemented different executable properties based on build target
+
+## Source Code Management
+
+The PowerToys repository serves as the source of truth for both PowerToys and Sysinternals standalone versions of ZoomIt. Key repositories involved:
+
+- Utility repo: `https://dev.azure.com/sysinternals/Tools/_git/ZoomIt`
+- Common library repo: `https://dev.azure.com/sysinternals/Tools/_git/Common`
+
+The integration process can be tracked through [PR #35880](https://github.com/microsoft/PowerToys/pull/35880) which contains the complete history of changes required to properly integrate ZoomIt.

doc/devdocs/processes/gpo.md

@@ -0,0 +1,125 @@
+# PowerToys GPO (Group Policy Objects) Implementation
+
+Group Policy Objects (GPOs) allow system administrators to control PowerToys settings across an organization. This document describes how GPOs are implemented in PowerToys.
+
+## GPO Overview
+
+GPO policies allow system administrators to control PowerToys settings. PowerToys ships GPO files as part of the release zip, not installed directly.
+
+## GPO File Structure
+
+### ADMX File
+- Contains policy definitions
+- Defines which versions support each policy
+- Sets up folder structure
+- Defines each policy with:
+  - Name
+  - Class (user scope or machine scope)
+  - Description
+  - Registry location where policy is stored
+  - Enabled/disabled values
+
+### ADML File
+- Contains localized strings for the ADMX file
+- Contains revision number that must be updated when changes are made
+- Stores strings for:
+  - Folder names
+  - Version definitions
+  - Policy descriptions and titles
+- Currently only ships English US version (no localization story yet)
+
+## Installation Process
+
+- Files need to be placed in: `C:\Windows\PolicyDefinitions\`
+- ADMX file goes in the root folder
+- ADML file goes in the language subfolder (e.g., en-US)
+- After installation, policies appear in the Group Policy Editor (gpedit.msc)
+
+## Registry Implementation
+
+- Policies are stored as registry values
+- Location: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerToys` or `HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerToys`
+- Machine scope takes precedence over user scope
+- Policy states:
+  - Enabled: Registry value set to 1
+  - Disabled: Registry value set to 0
+  - Not Configured: Registry value does not exist
+
+## Code Integration
+
+### Common Files
+- Policy keys defined in `common\utils\GPO.h`
+- Contains functions to read registry values and get configured values
+- WinRT C++ adapter created for C# applications to access GPO settings
+
+### WPF Applications
+- WPF applications cannot directly load WinRT C++ projects
+- Additional library created to allow WPF applications to access GPO values
+
+### Module Interface
+- Each module must implement policy checking in its interface
+- Runner checks this to determine if module should be started or not
+
+## UI Implementation
+
+- When a policy disables a utility:
+  - UI is locked (cannot be enabled)
+  - Settings page shows a lock icon
+  - Dashboard hides the module button
+  - If user tries to start the executable directly, it exits and logs a message
+
+## Types of GPO Policies
+
+### Basic Module Enable/Disable Policy
+- Most common type
+- Controls whether a module can be enabled or disabled
+- Shared description text for these policies
+
+### Configuration Policies
+- Example: Run at startup setting
+- Controls specific settings rather than enabling/disabling modules
+- Custom description text explaining what happens when enabled/disabled/not configured
+
+### Machine-Scope Only Policies
+- Example: Mouse Without Borders service mode
+- Only makes sense at machine level (not user level)
+- Restricts functionality that requires elevated permissions
+
+## Steps to Add a New Policy
+
+1. Update ADMX file:
+   - Increase revision number
+   - Add supported version definition
+   - Define the policy with registry location
+
+2. Update ADML file:
+   - Increase revision number
+   - Add strings for version, title, description
+
+3. Update code:
+   - Add to GPO.h
+   - Add to GPO wrapper for C# access
+   - Update module interface
+   - Modify settings UI to show lock when policy applied
+   - Add checks in executable to prevent direct launching
+   - Update dashboard helper to respect policy
+
+4. Add to bug report tool to capture policy state
+
+## Update-Related GPO Settings
+
+- `disable automatic update download` - Prevents automatic downloading
+- `disable new update toast` - Controls if toast notifications are shown
+- `suspend new update toast` - Suspends toast notifications for 2 minor releases
+
+## Testing GPO Settings
+
+To test GPO settings locally:
+
+1. Run `regedit` as administrator
+2. Navigate to `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerToys`
+3. Create a new DWORD value with the name of the policy
+4. Set the value to 0 (disabled) or 1 (enabled)
+5. Restart PowerToys to see the effect
+
+For user-scope policies, use `HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerToys` instead.

doc/devdocs/processes/release-process.md

@@ -0,0 +1,183 @@
+# PowerToys Release Process
+
+This document outlines the process for preparing and publishing PowerToys releases.
+
+## Release Preparation
+
+### Branch Management
+1. Sync commits from main branch to stable branch
+   - Usually sync current main to stable
+   - For hotfixes: might need to cherry-pick specific commits
+
+2. Start release build from the stable branch
+   - Use pipelines to build
+   - Set version number (e.g., 0.89.0)
+   - Build for both x64 and ARM64
+   - Build time: ~1-2 hours (signing can take extra time)
+   - Build can be flaky, might need multiple attempts
+
+3. Artifacts from the build:
+   - ARM64 release files
+     - PowerToys setup for ARM64 (machine setup)
+     - User setup
+   - X64 release files
+     - PowerToys setup for x64 (machine setup)
+     - User setup
+   - GPO files (same for both architectures)
+   - Hash files for verification
+   - Symbols that are shipped with every release
+
+### Versioning
+- Uses semantic versioning: `MAJOR.MINOR.PATCH`
+- MINOR version increases with regular releases (e.g., 0.89.0)
+- PATCH version increases for hotfixes (e.g., 0.87.0 → 0.87.1)
+- Each release version must be higher than the previous one for proper updating
+
+## Testing Process
+
+### Release Candidate Testing
+1. Fully test the builds using a checklist
+   - Manual tests for each release
+   - Each test item should be verified by at least 2 people
+   - Test on both x64 and ARM64 machines
+   - Every module is tested by at least two people
+   - New team members typically take 2 days for complete testing
+   - Experienced team members complete testing in less than a day (~2 hours for 1/3 of tests)
+
+2. For subsequent Release Candidates:
+   - Full retesting of modules with changes
+   - Verifying specific fixes
+   - Sanity checking all utilities (ensuring no startup crashes)
+
+3. If regressions found:
+   - Fix issues
+   - Return to step 1 (sync fixes to stable and build again)
+
+### Testing Workflow
+1. Team divides the test checklist among members
+2. Each member performs assigned tests
+3. Members report any issues found
+4. Team assesses if issues are release blockers
+5. Team confirms testing completion before proceeding
+
+### Reporting Bugs During 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)
+
+### Sign-off Process
+- Teams sign off on modules independently
+- Regressions found in first release candidates lead to PRs
+- Second release candidate verified fixes
+- Final verification ensures modules don't crash with new features
+
+## Documentation and Changelog
+
+### README Updates
+1. Create PR with README updates for the release:
+   - Add new utilities to the list if applicable
+   - Update milestones
+   - Update expected download links
+   - Upload new hashes
+   - Update version and month
+   - Write highlights of important changes
+   - Thank open source contributors
+     - Don't thank internal team members or Microsoft employees assigned to the project
+     - Exception: thank external helpers like Niels (UI contributions)
+
+### Changelog Creation
+- Changelog PR should be created several days before release
+- Community members need time to comment and request changes
+- Project managers need time to review and clean up
+- When team testing is set, either tests are done or changelog is created right away
+
+### Changelog Structure
+- **General section**: 
+  - Issues/fixes not related to specific modules
+  - User-visible changes
+  - Important package updates (like .NET packages)
+  - Fixes that affect end users
+
+- **Development section**:
+  - CI-related changes
+  - Changes not visible to end users
+  - Performance improvements internal to the system
+  - Refactoring changes
+  - Logger updates and other developer-focused improvements
+
+### Formatting Notes
+- Special attention needed for "highlights" section
+- Different format is required for highlights in README versus release notes
+- Must follow the exact same pattern/format for proper processing
+- PowerToys pulls "What's New" information from the GitHub API
+  - Gets changelog from the latest 5 releases
+  - Format must be consistent for the PowerToys code to properly process it
+  - Code behind will delete everything between certain markers (installer hashes and highlights)
+
+### Documentation Changes
+- Public docs appear on the web
+- Changes happen in the Microsoft Docs repo: microsoft/windows-dev-docs
+- For help with docs, contact Alvin Ashcraft from Microsoft
+- Content automatically appears on learn.microsoft.com when PR is merged
+
+## GitHub Release Process
+
+### Creating the Release
+1. Ask the project management team to start a GitHub release draft
+   - Draft should target stable branch
+   - Use proper version format (e.g., V 0.89.0)
+   - Set title using same format (e.g., "Release V 0.89.0")
+
+2. After testing is complete:
+   - Pick up the hashes from artifacts
+   - Apply changelog
+   - Fill in release notes
+   - Upload binaries
+     - GPO files
+     - Setup files
+     - ZIP files with symbols
+   - Only press "Save Draft", don't publish yet
+
+3. Final verification:
+   - Download every file from the draft
+   - Check that ZIPs can be unzipped
+   - Verify hashes match expectations
+   - Tell the project management team the release is good to go
+   - They will handle the actual publishing
+
+### Post-Release Actions
+- GitHub Actions automatically trigger:
+  - Store submission
+  - WinGet submission
+- Monitor these actions to ensure they complete successfully
+- If something fails, action may need to be taken
+
+## Release Decision Making
+
+### Timing Considerations
+- Release owner should coordinate with project managers
+- Project managers have high-level view of what should be included in the release
+- Use the "in for .XX" tag to identify PRs that should be included
+- If a key feature isn't ready, discuss with PMs whether to delay the release
+
+### Release Coordination
+- Release coordination requires good communication with domain feature owners
+- Coordination needed with project managers and key feature developers
+- Release candidate can only be done once key features have been merged
+- Need to ensure all critical fixes are included before the release candidate
+
+## Special Cases
+
+### Hotfix Process
+- For critical issues found after release
+- Create a hotfix branch from the stable branch
+- Cherry-pick only essential fixes
+- Increment the PATCH version (e.g., 0.87.0 → 0.87.1)
+- Follow the standard release process but with limited testing scope
+
+### Community Testing
+- Community members generally don't have access to draft builds
+- Exception: Some Microsoft MVPs sometimes test ARM64 builds
+- If providing builds to community members, use a different version number (e.g., 0.1.x) to avoid installer conflicts

doc/devdocs/processes/update-process.md

@@ -0,0 +1,111 @@
+# PowerToys Update Process
+
+This document describes how the PowerToys update mechanism works.
+
+## Key Files
+
+- `updating.h` and `updating.cpp` in common - Contains code for handling updates and helper functions
+- `update_state.h` and `update_state.cpp` - Handles loading and saving of update state
+
+## Update Process
+
+### Version Detection
+- Uses GitHub API to get the latest version information
+- API returns JSON with release information including version and assets
+- Checks asset names to find the correct installer based on:
+  - Architecture (ARM64 or X64)
+  - Installation scope (user or machine)
+
+### Installation Scope
+- Differentiates between user installer and machine installer
+- Different patterns are defined to distinguish between the two scopes
+- Both have different upgrade codes
+
+### Update State
+- State is stored in a local file
+- Contains information like:
+  - Current update state
+  - Release page URL
+  - Last time check was performed
+  - Whether a new version is available
+  - Whether installer is already downloaded
+
+### Update Checking
+- Manual check: When user clicks "Check for Updates" in settings
+- Automatic check: Periodic update worker runs periodically to check for updates
+- Update state is saved to: `%LOCALAPPDATA%\Microsoft\PowerToys\update_state.json`
+
+### Update Process Flow
+1. Check current version against latest version from GitHub
+2. If newer version exists:
+   - Check metered connection settings
+   - Check if automatic updates are enabled
+   - Check GPO settings
+3. Process new version:
+   - Check if installer is already downloaded
+   - Clean up old installer files
+   - Download new installer if needed
+4. Notify user via toast notification
+
+### PowerToys Updater
+- `PowerToysUpdate.exe` - Executable shipped with installer
+- Handles downloading and running the installer
+- Called when user clicks the update toast notification
+- Downloads the installer if not already downloaded
+
+### Version Numbering
+- Semantic versioning: `MAJOR.MINOR.PATCH`
+- MINOR version increases with regular releases (e.g., 0.89.0)
+- PATCH version increases for hotfixes (e.g., 0.87.0 → 0.87.1)
+
+### Installer Details
+- Uses WiX bootstrapper
+- Defines upgrade codes for per-user and per-machine installations
+- These codes must remain consistent for proper updating
+
+## GPO Update Settings
+
+PowerToys respects Group Policy settings for controlling updates:
+
+- `disable automatic update download` - Prevents automatic downloading
+- `disable new update toast` - Controls if toast notifications are shown
+- `suspend new update toast` - Suspends toast notifications for 2 minor releases
+
+## User Settings
+
+Users can control update behavior through the PowerToys settings:
+
+- Automatic update downloads can be enabled/disabled
+- Download and install updates automatically on metered connections
+
+## Update Notification
+
+When a new update is available:
+1. Toast notification appears in the Windows Action Center
+2. Clicking the notification starts the update process
+3. The updater downloads the installer (if not already downloaded)
+4. The installer runs with appropriate command-line arguments
+
+## Debugging Tips
+
+### Testing Update Detection
+- To force an update check, modify the timestamp in the update state file to an earlier date
+- Exit PowerToys, modify the file, then restart PowerToys
+
+### Common Issues
+- Permission issues can prevent downloading updates
+- Network connectivity problems may interrupt downloads
+- Group Policy settings may block updates
+- Installer may fail if the application is running
+
+### Update Logs
+- Check PowerToys logs for update-related messages
+- `%LOCALAPPDATA%\Microsoft\PowerToys\Logs\PowerToys-*.log`
+- Look for entries related to update checking and downloading
+
+## Rollout Considerations
+
+- Updates are made available to all users simultaneously
+- No staged rollout mechanism is currently implemented
+- Critical issues discovered after release require a hotfix
+- See [Release Process](release-process.md) for details on creating hotfixes

doc/devdocs/readme.md

@@ -1,4 +1,42 @@
-# Dev Documentation
+# 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.
+
+## 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
+- [Logging and Telemetry](development/logging.md) - How to use logging and telemetry
+- [Localization](development/localization.md) - How to support multiple languages
+
+## Development Guidelines
+
+- [Coding Guidelines](development/guidelines.md) - Development guidelines and best practices
+- [Coding Style](development/style.md) - Code formatting and style conventions
+- [UI Testing](development/ui-tests.md) - How to write UI tests for PowerToys
+- [Debugging](development/debugging.md) - Techniques for debugging PowerToys
+
+## 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
 
 ## Fork, Clone, Branch and Create your PR
 
@@ -14,7 +52,7 @@ Once you've discussed your proposed feature/fix/etc. with a team member, and an
 ## Rules
 
 - **Follow the pattern of what you already see in the code.**
-- [Coding style](style.md).
+- [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.
@@ -76,89 +114,9 @@ The installer can only be compiled in `Release` mode; steps 1 and 2 must be perf
 1. Compile `StylesReportTool.sln` tool. Path from root: `tools\StylesReportTool\StylesReportTool.sln` (details listed below)
 1. Compile `PowerToysSetup.sln` Path from root: `installer\PowerToysSetup.sln` (details listed below)
 
-### Prerequisites for building the MSI installer
-
-1. Install the [WiX Toolset Visual Studio 2022 Extension](https://marketplace.visualstudio.com/items?itemName=WixToolset.WixToolsetVisualStudio2022Extension).
-1. Install the [WiX Toolset build tools](https://github.com/wixtoolset/wix3/releases/tag/wix3141rtm). (installer [direct link](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314.exe))
-1. Download [WiX binaries](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314-binaries.zip) and extract `wix.targets` to `C:\Program Files (x86)\WiX Toolset v3.14`.
-
-### Building prerequisite projects
-
-#### From the command line
-
-1. From the start menu, open a `Developer Command Prompt for VS 2022`
-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.sln`
-1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
-1. From the `Build` menu choose `Build Solution`.
-
-The resulting `PowerToysSetup.msi` installer will be available in the `installer\PowerToysSetup\x64\Release\` folder.
-
-#### Supported arguments for the .EXE Bootstrapper installer
-
-Head over to the wiki to see the [full list of supported installer arguments][installerArgWiki].
-
-## 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').
+See [Installer](core/installer.md) for more details on building and debugging the installer.
 
 ## How to create new PowerToys
 
 See the instructions on [how to install the PowerToys Module project template](/tools/project_template). <br />
-Specifications for the [PowerToys settings API](settingsv2/readme.md).
-
-## 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.
-
-![Image of the tray icon](/doc/images/runner/tray.png)
-
-### [`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`](settingsv2/)
-
-Settings v2 is our current settings implementation.  Please head over to the dev docs that describe the current settings system.
+Specifications for the [PowerToys settings API](core/settings/readme.md).

doc/devdocs/runner.md

@@ -1,48 +0,0 @@
-#### [`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/settingsv2/readme.md

@@ -1,12 +0,0 @@
-# Table of Contents
-1. [Settings overview](/doc/devdocs/settingsv2/project-overview.md)
-2. [UI Architecture](/doc/devdocs/settingsv2/ui-architecture.md)
-3. [ViewModels](/doc/devdocs/settingsv2/viewmodels.md)
-4. Data flow
-    - [Inter-Process Communication with runner](/doc/devdocs/settingsv2/runner-ipc.md)
-    - [Communication with modules](/doc/devdocs/settingsv2/communication-with-modules.md)
-5. [Settings Utilities](/doc/devdocs/settingsv2/settings-utilities.md)
-6. [Custom Hotkey control and keyboard hook handling](hotkeycontrol.md)
-7. [Compatibility with legacy settings and runner](/doc/devdocs/settingsv2/compatibility-legacy-settings.md)
-8. [XAML Island tweaks](/doc/devdocs/settingsv2/xaml-island-tweaks.md)
-9. [Telemetry](/doc/devdocs/settingsv2/telemetry.md)

doc/devdocs/tools/bug-report-tool.md

@@ -1,24 +1,56 @@
-# [Bug report tool](/tools/BugReportTool/)
+# Bug Report Tool
 
-This tool is used to collect logs and system information for bug reports. The bug report is then saved as a zip file on the desktop.
+The Bug Report Tool is a utility that collects logs and system information to help diagnose issues with PowerToys. It creates a comprehensive report that can be shared with developers to help troubleshoot problems.
 
-## Launching
+## Location and Access
 
-It can launch from the PowerToys tray icon by clicking "Report Bug", by clicking the bug report icon in the PowerToys flyout  or by running the executable directly.
+- Source code: `/tools/BugReportTool/`
+- Users can trigger the tool via:
+  - Right-click on PowerToys tray icon → Report Bug
+  - Left-click on tray icon → Open Settings → Bug Report Tool
 
-## Included files
+## What It Does
 
-The bug report includes the following files:
+The Bug Report Tool creates a zip file on the desktop named "PowerToys_Report_[date]_[time].zip" containing logs and system information. It:
+
+1. Copies logs from PowerToys application directories
+2. Collects system information relevant to PowerToys functionality
+3. Redacts sensitive information
+4. Packages everything into a single zip file for easy sharing
+
+## Information Collected
+
+### Logs
+- Copies logs from:
+  - `%LOCALAPPDATA%\Microsoft\PowerToys\Logs` - Regular logs
+  - `%USERPROFILE%\AppData\LocalLow\Microsoft\PowerToys` - Low-privilege logs
+
+### System Information
+- Windows version and build information
+- Language and locale settings
+- Monitor information (crucial for FancyZones and multi-monitor scenarios)
+- .NET installation details
+- PowerToys registry entries
+- Group Policy Object (GPO) settings
+- Application compatibility mode settings
+- Event Viewer logs related to PowerToys executables
+- PowerToys installer logs
+- Windows 11 context menu package information
+
+### PowerToys Configuration
+- Settings files
+- Module configurations
+- Installation details
+- File structure and integrity (with hashes)
+
+## Key Files in the Report
 
-* Settings files of the modules.
-* Logs of the modules and the runner.
-* Update log files.
 * `compatibility-tab-info.txt` - Information about [compatibility settings](https://support.microsoft.com/windows/make-older-apps-or-programs-compatible-with-windows-783d6dd7-b439-bdb0-0490-54eea0f45938) set for certain PowerToys executables both in the user and system scope.
 * `context-menu-packages.txt` - Information about the packages that are registered for the new Windows 11 context menu.
 * `dotnet-installation-info.txt` - Information about the installed .NET versions.
 * `EventViewer-*.xml` - These files contain event logs from the Windows Event Viewer for the executable specified in the file name.
 * `EventViewer-Microsoft-Windows-AppXDeploymentServer/Operational.xml` - Contains event logs from the AppXDeployment-Server which are useful for diagnosing MSIX installation issues.
-* `gpo-configuration-info.txt` - Information about the configured [GPO](/doc/gpo/README.md).
+* `gpo-configuration-info.txt` - Information about the configured [GPO](doc/devdocs/processes/gpo.md).
 * `installationFolderStructure.txt` - Information about the folder structure of the installation. All lines with files have the following structure: `FileName Version MD5Hash`.
 * `last_version_run.json` - Information about the last version of PowerToys that was run.
 * `log_settings.json` - Information about the log level settings.
@@ -30,3 +62,58 @@ The bug report includes the following files:
 * `UpdateState.json` - Information about the last update check and the current status of the update download.
 * `windows-settings.txt` - Information about the Windows language settings.
 * `windows-version.txt` - Information about the Windows version.
+
+## Privacy Considerations
+
+The tool redacts certain types of private information:
+- Mouse Without Borders security keys
+- FancyZones app zone history
+- User-specific paths
+- Machine names
+
+## Implementation Details
+
+The tool is implemented as a C# console application that:
+1. Creates a temporary directory
+2. Copies logs and configuration files to this directory
+3. Runs commands to collect system information
+4. Redacts sensitive information
+5. Compresses everything into a zip file
+6. Cleans up the temporary directory
+
+### Core Components
+
+- `BugReportTool.exe` - Main executable
+- Helper classes for collecting specific types of information
+- Redaction logic to remove sensitive data
+
+## Extending the Bug Report Tool
+
+When adding new PowerToys features, the Bug Report Tool may need to be updated to collect relevant information. Areas to consider:
+
+1. New log locations to include
+2. Additional registry keys to examine
+3. New GPO values to report
+4. Process names to include in Event Viewer data collection
+5. New configuration files to include
+
+## Build Process
+
+The Bug Report Tool is built separately from the main PowerToys solution:
+
+1. Path from root: `tools\BugReportTool\BugReportTool.sln`
+2. Must be built before building the installer
+3. Built version is included in the PowerToys installer
+
+### Building from the Command Line
+
+```
+nuget restore .\tools\BugReportTool\BugReportTool.sln
+msbuild -p:Platform=x64 -p:Configuration=Release .\tools\BugReportTool\BugReportTool.sln
+```
+
+### Building from Visual Studio
+
+1. Open `tools\BugReportTool\BugReportTool.sln`
+2. Set the Solution Configuration to `Release`
+3. Build the solution

doc/devdocs/tools/debugging-tools.md

@@ -0,0 +1,111 @@
+# PowerToys Debugging Tools
+
+PowerToys includes several specialized tools to help with debugging and troubleshooting. These tools are designed to make it easier to diagnose issues with PowerToys features.
+
+## FancyZones Debugging Tools
+
+### FancyZones Hit Test Tool
+
+- Location: `/tools/FancyZonesHitTest/`
+- Purpose: Tests FancyZones layout selection logic
+- Functionality:
+  - Simulates mouse cursor positions
+  - Highlights which zone would be selected
+  - Helps debug zone detection issues
+
+### FancyZones Draw Layout Test
+
+- Location: `/tools/FancyZonesDrawLayoutTest/`
+- Purpose: Tests FancyZones layout drawing logic
+- Functionality:
+  - Visualizes how layouts are drawn
+  - Helps debug rendering issues
+  - Tests different monitor configurations
+
+### FancyZones Zonable Tester
+
+- Location: `/tools/FancyZonesZonableTester/`
+- Purpose: Tests if a window is "zonable" (can be moved to zones)
+- Functionality:
+  - Checks if windows match criteria for zone placement
+  - Helps debug why certain windows can't be zoned
+
+## Monitor Information Tools
+
+### Monitor Info Report
+
+- Location: `/tools/MonitorPickerTool/`
+- Purpose: Diagnostic tool for identifying WinAPI bugs related to physical monitor detection
+- Functionality:
+  - Lists all connected monitors
+  - Shows detailed monitor information
+  - Helps debug multi-monitor scenarios
+
+## Window Information Tools
+
+### Styles Report Tool
+
+- Location: `/tools/StylesReportTool/`
+- Purpose: Collect information about an open window
+- Functionality:
+  - Reports window styles
+  - Shows window class information
+  - Helps debug window-related issues in modules like FancyZones
+
+### Build Process
+
+The Styles Report Tool is built separately from the main PowerToys solution:
+
+```
+nuget restore .\tools\StylesReportTool\StylesReportTool.sln
+msbuild -p:Platform=x64 -p:Configuration=Release .\tools\StylesReportTool\StylesReportTool.sln
+```
+
+## Shell-Related Debugging Tools
+
+### PowerRenameContextMenu Test
+
+- Location: `/tools/PowerRenameContextMenuTest/`
+- Purpose: Tests PowerRename context menu integration
+- Functionality:
+  - Simulates right-click context menu
+  - Helps debug shell extension issues
+
+## Verification Tools
+
+### Verification Scripts
+
+- Location: `/tools/verification-scripts/`
+- Purpose: Scripts to verify PowerToys installation and functionality
+- Functionality:
+  - Verify binary integrity
+  - Check registry entries
+  - Test module loading
+
+## Other Debugging Tools
+
+### Clean Up Tool
+
+- Location: `/tools/CleanUp/`
+- Purpose: Clean up PowerToys installation artifacts
+- Functionality:
+  - Removes registry entries
+  - Deletes settings files
+  - Helps with clean reinstallation
+
+### Using Debugging Tools
+
+1. Most tools can be run directly from the command line
+2. Some tools require administrator privileges
+3. Tools are typically used during development or for advanced troubleshooting
+4. Bug Report Tool can collect and package the output from several of these tools
+
+## Adding New Debugging Tools
+
+When creating new debugging tools:
+
+1. Place the tool in the `/tools/` directory
+2. Follow existing naming conventions
+3. Document the tool in this file
+4. Include a README.md in the tool's directory
+5. Consider adding the tool's output to the Bug Report Tool if appropriate

doc/devdocs/tools/fancyzones-draw-layout-test.md

@@ -1,7 +0,0 @@
-# [FancyZones_DrawLayoutTest](/tools/FancyZones_DrawLayoutTest/)
-
-This test tool is created in order to debug issues related to the drawing of zone layout on screen.
-
-Currently, only column layout is supported with modifiable number of zones. Pressing **w** key toggles zone appearance on primary screen (multi monitor support not yet in place). Pressing **q** key exits application.
-
-Application is DPI unaware which means that application does not scale for DPI changes and it always assumes to have a scale factor of 100% (96 DPI). Scaling will be automatically performed by the system.

doc/devdocs/tools/fancyzones-hit-test.md

@@ -1,5 +0,0 @@
-# [FancyZone hit test tool](/tools/FancyZone_HitTest/)
-
-![Image of the FancyZones hit test tool](/doc/images/tools/fancyzones-hit-test.png)
-
-This tool tests the FancyZones layout selection logic. It displays a window with 5 zones. By hovering the mouse over the zones, the zone under the mouse cursor is highlighted. The sidebar shows different metrics that are used to determine which zone is under the mouse cursor.

doc/devdocs/tools/fancyzones-zonable-tester.md

@@ -1,13 +0,0 @@
-# [FancyZones_zonable_tester](/tools/FancyZones_zonable_tester/)
-
-![Image of the FancyZones zonable tester](/doc/images/tools/fancyzones-zonable-tester.png)
-
-This command line application tests if the window where the mouse cursor is located is zonable. It also adds additional information about the window to the console output:
-
-* The HWND (window handle) of the window
-* The process ID of the window
-* The HWND of the window in the foreground
-* The style of the window
-* The exStyle of the window
-* The window class
-* The path of the process that created the window