PowerToys — Engineering Performance

feat(powerdisplay): add CLI for monitor control (#48632) ## Summary of the Pull Request Adds `PowerToys.PowerDisplay.Cli.exe`, a scriptable interface for controlling monitors through the running PowerDisplay process. It supports `list`, `get`, `set`, `up`, `down`, `capabilities`, `profiles`, and `apply-profile`. The CLI communicates over an authenticated, per-session named pipe; PowerDisplay remains responsible for DDC/CI and WMI access. ## PR Checklist - [x] Closes: #48713 - [x] **Communication:** Discussed with core contributors - [x] **Tests:** Added/updated and all pass - [x] **Localization:** Core errors are localizable; some help and output text remains English-only - [ ] **Dev docs:** N/A; built-in CLI help is the command reference - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetupVNext/Resources.wxs) - [x] **YML for CI pipeline:** N/A; test assemblies are auto-discovered - [x] **YML for signed pipeline:** N/A; signing is driven by `ESRPSigning_core.json` - [ ] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments - Adds an AOT-compatible CLI and shared request/response contracts. - Uses a secured named-pipe server in PowerDisplay, with stable exit codes and a bounded request timeout. - Supports saved profiles by their existing stable profile IDs. - Adds solution, signing, installer, and unit-test project integration. ## Validation Steps Performed - PowerDisplay Lib, Contracts, CLI, and IPC unit-test suites pass. - Native AOT publish completes without analyzer warnings. - Manually validated the CLI on two DDC/CI monitors, including the PowerDisplay-unavailable path. - Rebuilt the PowerDisplay GUI after the shared-library changes. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

UT: Add ut to protect common utils codes (#45290) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request As title <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Tests should be picked up and run and pass

[PowerOCR] migrate PowerOCR to WinUI 3 (#49431) ## Summary of the Pull Request Migrates Text Extractor (`PowerOCR`) from WPF to WinUI 3 while preserving its Runner integration, settings contract, activation behavior, telemetry, and UI Automation identifiers. - Replaces the WPF overlay with native WinUI 3 `WindowEx` overlays, one per display, with mixed-DPI and negative-origin coordinate handling. - Extracts OCR, bitmap preparation, text formatting, table analysis, and selection geometry into the UI-independent `PowerOCR.Core` library. - Migrates localization from `.resx` to `.resw`/`x:Uid`, and updates process lifetime, Named Event dispatch, clipboard handling, and deterministic resource cleanup. - Moves managed Text Extractor outputs into `WinUI3Apps` and updates the native launcher, signing manifest, installer resources, and installation verification list. - Adds Core unit tests and updates the existing PowerOCR UI automation/checklist for the WinUI controls. https://github.com/user-attachments/assets/16bbef72-fa5e-4c2b-8bd2-b1871a3e0e4c ## PR Checklist - [x] Closes: #49656 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass — Core tests pass, but interactive UI tests and several visual/multi-monitor checks remain environment-blocked as detailed below - [x] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for `PowerToys.PowerOCR.Core.dll` and the WinUI3Apps paths - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) — handled by the existing WinUI3Apps component generator; removed the obsolete PowerOCR satellite-resource component from `installer/PowerToysSetupVNext/Resources.wxs` - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) — N/A; the new test project is included in `PowerToys.slnx` and uses existing test discovery - [x] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) — N/A; no per-module pipeline entry is required - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx — N/A; no end-user behavior change ## Detailed Description of the Pull Request / Additional comments ### Core and project structure - Adds `src/modules/PowerOCR/PowerOCR.Core/` and `PowerOCR.Core.UnitTests/`. - Removes production `UseWPF`, `System.Windows`, WPF imaging types, MEF construction, and the WPF-only `Common.UI` dependency. - Converts `src/modules/PowerOCR/PowerOCR/PowerOCR.csproj` to an unpackaged, self-contained WinUI 3 application with XAML under `PowerOCRXAML/`. ### Overlay and OCR flow - Captures every display before showing overlays, then creates one borderless topmost overlay per `DisplayArea`. - Uses cached physical-pixel screenshots for clicked-word, region, single-line, and table OCR modes. - Converts WinUI DIP pointer coordinates through each window's rasterization scale and supports displays with negative virtual-desktop origins. - Replaces the WPF `CombinedGeometry` selection clip with four mask rectangles plus a selection `Border`. - Synchronizes language and formatting state across all overlay windows and preserves Escape, S, T, and D1-D9 keyboard behavior. ### Lifetime and compatibility - Preserves the existing process name, mutex, Runner PID argument, GPO behavior, Named Events, standalone keyboard hook, settings JSON, telemetry events, and existing AutomationIds. - Adds cancellation-aware Named Event handling and deterministic disposal for windows, screenshots, WinRT image sources, OCR crops, pointer capture, and cursor clipping. - Keeps `PowerOCRModuleInterface.dll` in the install root and launches `WinUI3Apps\PowerToys.PowerOCR.exe`. ## Validation Steps Performed - Built `PowerOCR.Core.UnitTests` for x64 Debug and ran all tests with `vstest.console.exe`: **23/23 passed**. - Built `PowerOCR-UITests` for x64 Debug successfully. - Built `PowerOCR` for x64 Release and ARM64 Release successfully. - Built `PowerOCRModuleInterface` for x64 Release and ARM64 Release successfully. - Ran XAML Styler against the branch: 3 PowerOCR XAML files processed with no changes. - Confirmed the required x64/ARM64 outputs, including `PowerToys.PowerOCR.Core.dll` and `PowerToys.PowerOCR.pri`, are generated in the expected locations. - Ran build+sideload checklist validation against the local WinUI 3 bits: **15 PASS, 0 FAIL, 16 BLOCKED**. - Blocked items require an attached interactive desktop, WinAppDriver v1.2.1, multiple displays/mixed DPI, real pointer drag/input, or visual theme inspection. - No product defects were observed in the checks that could be executed. - The legacy UI test runtime remains blocked because WinAppDriver is unavailable and the current RDP input desktop is detached; the tests compile successfully. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Niels Laute <nielslaute@microsoft.com> Copilot-Session: 64307790-5118-4071-9308-5e9ee9836310 Copilot-Session: e5ba1f54-e354-456c-bd2a-c716a143eb97

CmdPal: Icons (12/n) - Share Shell icons by identity and display file-type previews (#50192) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Part 12 of 12 in the CmdPal icon-loading series. Depends on #50191. This PR resolves Shell identity before materialization so different item paths can share one cached icon, and adds a quick file-type preview before exact refinement. - Routes explicit Shell requests and eligible legacy paths through shared location aliases and canonical cache/in-flight entries. - Adds generation-safe invalidation, bounded retries, safe fallbacks, and direct HICON conversion without a PNG round trip. - Keeps resolution/extraction and cold arbitration off the STA, coalesces preview updates, and skips misleading shortcut previews. - Integrates Indexer, Bookmarks, and Shell requests and adds diagnostics plus separate System32 semantic/legacy samples. Motivation: thousands of files often share a small set of icons. Avoid repeating extraction/materialization, while giving the user a useful preview during per-item resolution. Note: A dear reviewer will observe that both System32 samples are still slow as a drunk crippled squirrel and icons are loading slowly anyway. The reason for that is that the list items are initialized in order, and before it is initialized, list item view model doesn't know anything about its icon at all. The follow-up PR #50469 tackles this issue. ### Examples Using `Microsoft.CommandPalette.Extensions.Toolkit`: ```csharp new IconInfo(ShellItemIconProtocol.Create(@"C:\Docs\a.txt")); new IconInfo(ShellItemIconProtocol.CreateJumbo(@"C:\Docs\a.txt")); new IconInfo(ShellItemIconProtocol.Create(@"C:\Windows\System32\shell32.dll")); ``` The first two serialize as: ```text |ShellItemIcon|v1;13:C:\Docs\a.txt |JumboShellItemIcon|v1;13:C:\Docs\a.txt ``` The last example requests the DLL file's Shell icon. It does not mean “extract icon resource 1,” which remains a different request: ```csharp new IconInfo(@"C:\Windows\System32\shell32.dll,1"); ``` ### Evidence These are Shell-specific characterizations, not an accepted comparison with the preceding PR. - Historical System32 cold runs: 8565, 8564, and 8564 Shell requests; exactly 174 extractions and 4769 location resolutions in each run. Many requests share materialized icons, but per-path resolution still costs work. - The three warm passes performed 0, 0, and 171 extractions; location resolutions were 0, 0, and 4769. A zero median must not be presented as guaranteed warm reuse. - A later two-phase smoke run recorded 171 extractions for 8565 requests. Its workload gate passed, but there was only one run per side. - The earlier legacy-page versus semantic-page comparison failed its cross-page workload gate. Its headline latency percentages are not accepted comparative evidence. - Provider/resolver tests cover canonical joins, invalidation races, fallback poisoning, progressive replacement, and off-caller-thread cold arbitration. The counts demonstrate sharing, not instantaneous visible icons. Repeat a matched-page cold/warm comparison on the final build and explain the warm re-extraction run before claiming a reliable latency improvement. All apps/Home scenarios do not substitute for a Shell workload. ### Technical notes - Path aliases remain case-sensitive; canonical Shell identity is where different paths converge. Index generations participate in the key. After bounded invalidation retries, resolution falls back to a path-specific identity instead of relabeling a possibly stale image-list index. - `SHGFI_USEFILEATTRIBUTES` supplies only the provisional type icon, not proof of the exact item's identity. Exact lookup still corrects custom icons. Extensionless items and shortcuts skip this phase; a dotted directory can briefly receive a file-type preview rather than forcing a filesystem check on the STA. - Requests joining a canonical load keep their original request binding. The shared load is conservatively held demanded rather than reattaching an already-bound requester. Actual worker release is measured separately from the later shared-task completion. - Null extraction results/shared generic fallbacks must not poison a canonical type-wide cache entry. Fallback and real extraction success are distinct outcomes. - Thread-local Shell error-mode suppression prevents modal error boxes; it does not impose a timeout on Shell handlers. Direct image paths retain their image behavior, and explicit Shell-file requests remain distinct from embedded binary-icon references. - Canonical caching reduces extraction/materialization, not every per-path Shell query or earlier view-model initialization. Realized-item initializer priority is outside these 12 PRs. Implementation: `src/modules/cmdpal/Microsoft.CmdPal.UI/Helpers/Icons/ShellIconLocationResolver.cs`. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #50131 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Rebase validation (2026-09-08): - Rebased onto `dev/jpolasek/f/49944-cmdpal-svg-icons` at `89973610cbd28b77317a007dec554d236818b380`. - `git range-diff` confirmed both Shell-icon commits are unchanged. The item-initialization change is reviewed independently against `main` in #50469. - Release x64 build of `Microsoft.CmdPal.UI` passed using `tools/build/build.ps1` with serial MSBuild execution and package generation disabled. - All 351 UI unit tests passed through `vstest.console.exe`. - `git diff --check` passed. - Live UI behavior was not exercised in this validation run.

[ColorPicker] Migrate from WPF to WinUI 3 (#49174) ## Summary of the Pull Request Migrates the **ColorPicker** module from WPF to WinUI 3 (Windows App SDK). The whole module — the picking overlay, the color editor, settings, the zoom magnifier, telemetry, and the Win32 input hooks — is ported off `System.Windows` onto `Microsoft.UI.Xaml`, MEF is replaced by `Microsoft.Extensions.DependencyInjection`, and the legacy WPF sources are removed once each piece is ported. > **Draft / WIP:** opened early for visibility and incremental review. The checklist below is intentionally left unchecked until the migration is finalized and fully validated on real hardware/DPI configurations. demo: https://github.com/user-attachments/assets/465f2a21-1760-4bcf-9d33-253fd6b06f64 ## PR Checklist - [x] Closes: #49000 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments High-level areas ported (see the commit history for the step-by-step breakdown): - **App shell & DI** — WinUI 3 entry point / `App` / `MainWindow`, a `Microsoft.Extensions.DependencyInjection` container replacing MEF, with direct WinUI view composition replacing the implicit WPF `DataTemplate` mapping. - **Picking overlay & editor** — a `TransparentWindow`-based overlay (cursor-following tooltip) plus `ColorEditorView` / `ColorPickerControl` / `ColorFormatControl` ported off WPF (`ContextMenu` → `MenuFlyout`, Visual State Manager, native WinUI styles merged into `App.xaml`). - **Zoom magnifier** — a Win2D `CanvasControl` that redraws the captured region with a brightness-adaptive pixel grid + center highlight (replacing the WPF `ShaderEffect`), plus a WinUI Storyboard resize that matches the WPF zoom-step timing and easing. - **Core & helpers** — color math + value converters on `Windows.UI.Color`, `MonitorResolutionHelper` on `Windows.Foundation.Rect`, `ThrottledActionInvoker` on `DispatcherQueueTimer`, the shared `ManagedCommon.ClipboardHelper`, and the Win32 mouse/keyboard hooks off WPF input types. - **Resources** — a `.resw` scaffold + `ResourceLoaderInstance` replacing the old `.resx` designer. - **Build & installer** — `ColorPickerUI` flipped to WinUI 3, launched from `WinUI3Apps\`; installer satellite + signing paths updated; leftover WPF sources removed. **Zoom parity fixes in this branch:** the magnifier is centered on the cursor once when the zoom session starts and stays anchored while the wheel changes levels. The resize now also matches the WPF behavior: 200 ms `SineEase/EaseOut` growth and `QuadraticEase/EaseIn` shrink, animation of the image only (fixed border chrome), and rapid/reversing wheel input handed off from the current rendered size instead of jumping back to the previous level. The 8x host was corrected from 430 to 432 DIP so its border is not clipped. ## Validation Steps Performed - `ColorPickerUI.UnitTests.csproj` and `ColorPicker.UITests.csproj` build clean (x64 Debug, exit code 0, using the configured host NuGet source). - `ColorPickerUI.UnitTests`: 482/482 passed, including the presentation-value resize plan, exact WPF easing selection, 200 ms duration, animated grid threshold, RGB byte-range validation, and export extension handling. - Real UI E2E: Settings enable/disable, activation hotkey, overlay HEX, 1x/4x/8x zoom, a 50 ms 4x → 8x → 4x → 8x reversal, pointer movement, clipboard capture, and editor display all passed. - Runtime frame trace at 150% DPI confirmed continuous handoff during rapid reversal (`214.0 → 213.33 DIP`, then a second handoff from `211.33 DIP` to 8x) with no jump to a nominal level; final frames landed within the 200 ms animation plus display-refresh quantization. - Manual UI validation at 150% DPI passed both activation modes, shortcut rebinding, mouse/keyboard actions, color-name and clipboard formats, history selection/removal/multiselect, format toggle/reorder/customization, adjust-color flows, screen edges, dark theme, corrupt-history recovery, named events, single-instance behavior, and 100-cycle lifecycle stress. - TXT/JSON export, cancel, single/multi-selection, Unicode paths, overwrite/truncation, and unsupported-extension preservation passed using the real Windows App SDK Save As dialog; no unexpected errors were added to the final-run log. - Supporting suites passed: ManagedCommon clipboard 30/30, Settings ColorPicker/navigation 5/5, DSC ColorPicker 6/6, and ColorPicker E2E 1/1 (524/524 automated tests total). - Environment-dependent validation across an elevated runner, multiple physical/mixed-DPI monitors, native ARM64, and installer upgrade/uninstall remains pending (draft). --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Copilot-Session: ed45e5c8-72b0-4fdf-9de3-ae10be595428 Copilot-Session: 364bf5dd-eac3-42bc-901b-59194c8df71a Copilot-Session: f7c58bff-df3f-41ee-b2e2-8af47508cd19 Copilot-Session: 99a6c348-a4d6-4cd3-9909-b2cb92695e90 Copilot-Session: 90411037-22d3-4fbb-bb74-bff7a69467a9 Copilot-Session: 0dcbe1a4-e4fd-4f19-bbdb-19781d2fb693 Copilot-Session: 17f1d101-a06a-452d-ad18-e1d164791dd5 Copilot-Session: b272ded1-04fe-441d-bf0c-a94979844399 Copilot-Session: d5afc36b-3356-46af-b8cb-071b87a64532

CmdPal: Add support for multiple clocks and refactor the Time and Date module (#49288) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR refactors Time and date extension and adds support for multiple clocks with different time zone and/or display format. - Adds a new page for viewing and managing custom clocks, each with its own time zone, title, and subtitle display format. - Adds per-clock settings. - Adds a relative date format based on the current date, for cases where a time zone difference changes the displayed date. - Makes custom clocks pinnable. - Dynamically adapts "Copy time" and "Copy date" context menu items names to actual format being copied. - Adds a new optional "Copy XXX" context menu item, to allow copy a user-selected format that doesn't match the displayed one. - Removes the fallback switch from the options (we now have a toggle for that built-in to fallback command managment). - Replaces the dock-wide seconds setting with per-clock customization. - Introduces a centralized service that updates all clocks. - Dynamically enables or disables updates for pages and bands based on whether they are currently in use. - Adds new option to select now dock band action (Open notification center or show All clock page). ## Pictures? Pictures! <img width="1298" height="530" alt="image" src="https://github.com/user-attachments/assets/0b07fc91-7823-4252-b7d9-07a95e4a2578" /> <img width="1434" height="1354" alt="image" src="https://github.com/user-attachments/assets/63e4b340-520f-404f-8252-3318b0dce0de" /> <img width="1294" height="702" alt="image" src="https://github.com/user-attachments/assets/3794d948-0eab-46ec-a1bd-baef503940ed" /> <img width="1288" height="1096" alt="image" src="https://github.com/user-attachments/assets/1e7f7299-31e7-4d06-bc07-fb1211fc799c" /> <img width="610" height="300" alt="image" src="https://github.com/user-attachments/assets/44d70270-5d0b-4534-9a6b-b94474c4d36b" /> <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49284 - [x] Closes: #48940 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed

CmdPal: Add command deep links (#49793) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR builds the foundation for deep linking everything in Command Palette. Some mandatory reading: [👀 src/modules/cmdpal/doc/command-links.md](https://github.com/microsoft/PowerToys/blob/dev/jpolasek/f/49775-cmdpal-deeplink-everything/src/modules/cmdpal/doc/command-links.md) - Extends x-cmdpal:// with command routes and list-page options. - Adds dialog for explicit user consent. - Adds copy-link actions to top-level commands. - Adds permission management UI. - Adds tech-design document draft. - As a flyby fixes Pin to Dock dialog being clipped by a small compact window. ## Pictures? Pictures! We also have moving pictures, see... https://github.com/user-attachments/assets/3399e064-f64a-441b-9e9c-0410e5124eb8 Hello user <img width="722" height="420" alt="image" src="https://github.com/user-attachments/assets/f79ed015-a087-4839-a7c5-23aced7a0a55" /> I love toggles and buttons <img width="1330" height="754" alt="image" src="https://github.com/user-attachments/assets/136c7261-3444-4400-b8b2-331897df13fe" /> Because what everyone really wanted was more context menu items... <img width="723" height="455" alt="image" src="https://github.com/user-attachments/assets/904d8648-80e5-490b-92b5-45b1226b7bb9" /> <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49775 - [x] Closes: #49283 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed

Harden IPC pipe ownership and shutdown lifecycle (#48902) ## Summary of the Pull Request The two-way named-pipe IPC server (`TwoWayPipeMessageIPC`, shared by the runner, Settings, and Quick Access host) created every pipe instance without `FILE_FLAG_FIRST_PIPE_INSTANCE`. If a pipe with the same name already existed — for example a leftover instance from a previous run or another process — `CreateNamedPipe` would quietly create an *additional* instance and share the name instead of owning it. This makes `start_named_pipe_server` create the **first** instance with `FILE_FLAG_FIRST_PIPE_INSTANCE`, so `CreateNamedPipe` fails fast on a name collision and the server is the authoritative owner of its pipe name. ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized (N/A — no user-facing strings) - [x] **Dev docs:** Added/updated (N/A) - [x] **New binaries:** Added on the required places (N/A — no new binaries) ## Detailed Description of the Pull Request / Additional comments - The flag is applied **only** to the first instance. Subsequent instances continue to omit it, so the existing `PIPE_UNLIMITED_INSTANCES` behavior is fully preserved. - The change is contained to a single function in `src/common/interop/two_way_pipe_message_ipc.cpp`. Public signatures and the `PowerToys.Interop` ABI are unchanged, so the runner, Settings, and Quick Access host all benefit without any code changes on their side. ## Validation Steps Performed - The existing `Common.Interop.UnitTests` `TestSend` exercises the modified first-instance code path (`Start()` → `start_named_pipe_server`) and continues to pass — a full IPC round-trip still works. - Verified the updated `CreateNamedPipe` open-mode logic compiles cleanly. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 49797c8c-784d-47e6-bc0f-53464eecec4b

[PowerRename] Support using photo metadata to replace in the PowerRename (#41728) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request 1. Introduce WIC for power rename and add new class WICMetadataExtractor to use WIC to extract metadata. 2. Add some patterns for metadata extract. 3. Support XMP and EXIF metadata extract. 4. Add test data for xmp and exif extractor 5. Add attribution for the test data uploader. UI: <img width="2052" height="1415" alt="image" src="https://github.com/user-attachments/assets/9051b12e-4e66-4fdc-a4d4-3bada661c235" /> <img width="284" height="170" alt="image" src="https://github.com/user-attachments/assets/2fd67193-77a7-48f0-a5ac-08a69fe64e55" /> <img width="715" height="1160" alt="image" src="https://github.com/user-attachments/assets/5fa68a8c-d129-44dd-b747-099dfbcded12" /> demo: https://github.com/user-attachments/assets/e90bc206-62e5-4101-ada2-3187ee7e2039 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #5612 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com>

CmdPal: Icons (4/n) - Prioritize live icon requests and load glyphs directly (#50184) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Part 4 of 12 in the CmdPal icon-loading series. Depends on #50183. Next: #50185. This PR gives live requests precedence and removes unnecessary queueing for glyph cache misses. - Keeps caching/in-flight sharing, but constructs eligible glyph sources directly on the UI thread. - Sends demand changes through a lock-free command queue to a dedicated coordinator. - Keeps the extraction-worker count unchanged and reserves capacity from speculative work. Motivation: inexpensive list/context-menu glyphs should not wait behind image work, and off-screen work should not occupy every slot. ### Evidence Historical adjacent-stage comparison (2026-08-18); shared method and limitations: the diagnostics foundation PR #50181. - B cold-ish applied average: 19.951 → 4.978 ms (−14.973 ms, −75.0%); all three pairs improved. - B cold-ish new-load glyph latency: 30.575 → 0.402 ms; p99 bound ≤500 → ≤1 ms. - A cold-ish queued dispatcher callbacks: 3504 → 673 (2831 fewer); all three pairs decreased. - A cold-ish demanded queue-wait average: 2.285 → 13.544 ms. Cheap glyphs have left this population, so the aggregate is no longer like-for-like; remaining image delays still need their own assessment. - Queue tests cover demand transitions, capacity limits, and scheduler faults. The evidence supports removing glyph queueing and reducing dispatcher traffic, rather than a universal improvement for every remaining icon type. ### Technical notes - Direct glyph loading still uses the cache. “Cheap to construct” does not mean “free to construct repeatedly,” and XAML objects still require the correct STA. - The coordinator is a control thread, not an additional extraction worker. The STA publishes notifications without acquiring the scheduler's state lock. - Losing demand does not cancel a shared load. Speculative work may still populate the cache, but is allowed to starve while live demand continues. - Queue order follows the current continuous demand period. Losing every requester relinquishes that position; returning demand does not keep an old place indefinitely. Implementation: `src/modules/cmdpal/Microsoft.CmdPal.UI/Helpers/Icons/IconLoadQueue.cs`. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #49936 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed