mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
9ecbc9ab8a69203149701532603a083103eafe31
9674 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Copilot
|
b329b3f243 |
Shortcut Guide: Add keyboard shortcut manifest for new Outlook (olk.exe) (#48821)
## Summary of the Pull Request Shortcut Guide had no manifest for the new Outlook for Windows app, so it showed no shortcuts when `olk.exe` was the foreground process. Adds a new YAML manifest (`Microsoft.OutlookForWindows.en-US.yml`) with `WindowFilter: "olk.exe"` covering email, navigation, text editing, formatting, and calendar shortcuts. ## PR Checklist - [ ] Closes: #48798 - [ ] **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 New file: `src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/Microsoft.OutlookForWindows.en-US.yml` - **PackageName:** `Microsoft.OutlookForWindows` (WinGet package ID) - **WindowFilter:** `olk.exe` — process name for the new Outlook app (distinct from classic `outlook.exe`) - **Display name:** `Outlook (new)` - **Shortcut categories:** Frequently used · Navigate Outlook · Text editing · Format text · Calendar The `.csproj` already globs `Assets\ShortcutGuide\Manifests\*.yml`, so no project file changes are needed. ## Validation Steps Performed - Verified the YAML structure matches existing manifests (e.g., `Microsoft.Outlook.en-US.yml`). - Confirmed `olk.exe` is the correct process name for new Outlook for Windows. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Copilot
|
b6f0a7ae91 |
Add Shortcut Guide manifest for the Godot editor (#48959)
## Summary of the Pull Request
Adds bundled Shortcut Guide support for the Godot editor so Godot
shortcuts can appear when `Godot.exe` is the active app.
- **Shortcut Guide manifest**
- Added `+Godot.Godot.en-US.yml` under the bundled Shortcut Guide
manifests
- Uses the no-WinGet-package Godot editor identity expected by Shortcut
Guide:
```yml
PackageName: +Godot.Godot
WindowFilter: "Godot.exe"
```
- **Shortcut coverage**
- Includes the reporter-provided Godot editor mappings across core
editor workflows, panels, 2D/3D editors, text editor, and project
manager
- **Schema compliance**
- Uses spec-compliant bracketed literal digit tokens such as `"<0>"`
- Uses spec-compliant bracketed special key tokens such as `"<Tab>"`,
`"<Space>"`, `"<Insert>"`, `"<Delete>"`, `"<Escape>"`, `"<PageUp>"`, and
`"<PageDown>"`
## PR Checklist
- [ ] **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
- [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
## Detailed Description of the Pull Request / Additional comments
Shortcut Guide already copies all bundled manifest assets at startup and
builds its app index from those files. This change only extends that
manifest set with a Godot definition and aligns the manifest data with
the keyboard shortcuts schema; no runtime logic changed.
## Validation Steps Performed
- Parsed the new `+Godot.Godot.en-US.yml` file to verify YAML validity
and required top-level fields
- Confirmed the manifest targets `Godot.exe` and contains the expected
`+Godot.Godot` package identity
- Confirmed literal digit shortcuts use bracketed tokens like `"<0>"`
- Confirmed special keys use bracketed schema-compliant tokens where
applicable
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
|
||
|
Copilot
|
3df0535473 |
Add Obsidian manifest for Shortcut Guide (#48960)
## Summary of the Pull Request Adds built-in Shortcut Guide support for Obsidian by shipping an app manifest keyed to `Obsidian.exe`. This lets Shortcut Guide recognize Obsidian as the foreground app and show a curated set of common Obsidian shortcuts. Closes: #48596 ## PR Checklist - [ ] **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 - **Shortcut Guide manifest** - Adds `src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/Obsidian.Obsidian.en-US.yml` - Uses `PackageName: Obsidian.Obsidian` - Matches the app via `WindowFilter: "Obsidian.exe"` - **Curated Obsidian shortcuts** - Adds common shortcuts across: - Navigation - Tabs - Editing - Includes key Obsidian actions such as command palette, quick switcher, tab navigation, reading/editing mode toggle, and core editing commands - **No code-path changes** - This is a data-only addition that plugs into the existing manifest-driven Shortcut Guide app support ```yml PackageName: Obsidian.Obsidian Name: Obsidian WindowFilter: "Obsidian.exe" BackgroundProcess: false ``` ## Validation Steps Performed - Verified the new manifest is the only repository change - Parsed the new manifest structure successfully - Confirmed the manifest follows existing Shortcut Guide key/token conventions used by other bundled app manifests --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Alex Mihaiuc
|
23a26428d3 |
Grab And Move mod click passthrough (#49121)
This lets Alt/Win + click/rclick (no drag) go through if no mouse movement is recorded. Now the target window goes either into the "all clicks go through" or "all clicks are considered resizes/moves" based on whether the first mouse action after the modifier is pressed is a click or the beginning of a mouse drag action. <!-- 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 <!-- 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 |
||
|
Jiří Polášek
|
6da052247f |
CmdPal: Prevent stealing focus from other apps (#49087)
## Summary of the Pull Request
Gate search bar focus updates so they only run when the window is
visible.
The search bar can update its focus after context changes, but that
update may be dispatched after the window has already been hidden. In
that case, focusing the search box can bring the window back into focus
and steal focus from another app.
This change prevents the focus update from running when the owning
window is no longer visible.
Also as a flyby, `FocusSearchBoxMessage` is now handled by the ShellPage
instead of SearchBar, and goes through the same gate.
Regressed with the new token based params
(
|
||
|
Alex Mihaiuc
|
cccd2b7510 |
GrabAndMove drag maximized windows relative to the click point (#49118)
This aligns the behavior with resize. <!-- 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 When grabbing and moving a maximized icon, the old behavior was to first restore the window with its title bar under the cursor, then proceed with the move. Now the window is restored and moved proportionally around the cursor, exactly like in the case of the grab and resize behavior. <!-- 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 Ensure the window geometry/coordinates change exactly the same as for grab and resize on it, when starting from a maximized state. |
||
|
Renn
|
e4ef90d168 |
[Peek] Options for AlwaysOnTop and ShowOnTaskbar (#44645)
<!-- 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 * Add the option for Peek to allow the window to be always on top * Add the option for Peek to allow to not show its icon on the taskbar <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #26274 - [x] Closes: #43093 <!-- - [ ] 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 - [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) - [x] **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: https://github.com/MicrosoftDocs/windows-dev-docs/pull/5824 <!-- 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 AlwaysOnTop defaults to `false`, and ShowOnTaskbar defaults to `true` to match the current behavior. Peek settings after the change: <img width="1642" height="714" alt="image" src="https://github.com/user-attachments/assets/e9c8b390-8a8b-40aa-8990-c671b1fffd96" /> Peek window behavior with AlwaysOnTop set to `true` and ShowOnTaskbar set to `false`: <img width="1813" height="1161" alt="image" src="https://github.com/user-attachments/assets/e5fbda14-0ba8-4a70-840c-2e8493b7d920" /> <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. Start PowerToys with Peek enabled 2. In settings, turn off close window on focus loss for ease of validation 3. Peek something 4. Turn on always on top, observe the window is now always on top 5. Turn off always on top, observe the window is no longer always on top 6. Turn off show icon on taskbar, observe the icon disappeared immediately from the taskbar 7. Turn on show icon on taskbar, observe the icon re-appeared on the taskbar |
||
|
Jiří Polášek
|
e0fe3c48cf |
CmdPal: Stretch main window card vertically when in expanded mode (#49109)
## Summary of the Pull Request This PR updates the behavior of CmdPal's main window in expanded (non-compact) mode to match the previous behavior. The page content now stretches across the entire window instead of collapsing to the actual content height. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48872 <!-- - [ ] 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 |
||
|
Jiří Polášek
|
029dd04ce4 |
CmdPal: Fix compact mode not toggling the list/command bar at runtime (#49111)
<!-- 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 hooks `ShellPage` to `ISettingsService` and triggers update of expanded state when the Compact mode settings is changed. Toggling the compact-mode setting while the palette was open neverre-evaluated `ShellPage.ExpandedMode`, so disabling compact mode left the palette collapsed (only the search box visible). <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48933 <!-- - [ ] 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 |
||
|
Copilot
|
3d3cef73da |
Add Zoom Workspace keyboard shortcut manifest for Shortcut Guide (#49062)
## Summary of the Pull Request Adds a new Shortcut Guide manifest for Zoom Workspace so Zoom-specific shortcuts are available in the overlay when `zoom.exe` is active. The manifest follows existing in-repo schema and naming conventions for app-specific keyboard shortcut files. ## PR Checklist - [ ] **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 - **Manifest addition** - Added `src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/Zoom.Zoom.en-US.yml`. - Targets `WindowFilter: "zoom.exe"` with `PackageName: Zoom.Zoom`. - **Shortcut coverage** - Added high-value Zoom shortcuts grouped by section: - `General` - `View` - `Meeting controls` - Includes core actions such as mute/unmute, start/stop video, share, full-screen, and meeting exit. - **Schema alignment** - Uses existing Shortcut Guide manifest structure (`SectionName` / `Properties` / `Shortcut`) and key token conventions already used in adjacent manifests. ```yaml PackageName: Zoom.Zoom Name: Zoom Workspace WindowFilter: "zoom.exe" BackgroundProcess: false ``` ## Validation Steps Performed - Manifest content was kept within existing Shortcut Guide manifest schema and repository conventions for built-in app manifests. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Bryce Cindrich
|
03e5f3e837 |
feat(shortcut-guide): add 1Password manifest (#48793)
## Summary of the Pull Request Adds a Shortcut Guide manifest for the **1Password** desktop app. - **New manifest:** `src/modules/ShortcutGuide/ShortcutGuide.Ui/Assets/ShortcutGuide/Manifests/AgileBits.1Password.en-US.yml`: 26 shortcuts for `1Password.exe`, grouped into the same four sections 1Password uses in its in-app Keyboard Shortcuts reference: - **Basics:** View keyboard shortcuts, Show Quick Access, Lock 1Password - **Navigation:** Find, Switch to all accounts, Switch accounts & collections, Back, Forward, Focus next/previous row, Focus right/left section - **Selected item:** Copy primary field / password / one-time password, Open & fill in web browser, Open item in new window, Edit item, Save item, Reveal concealed fields, Archive item, Delete item - **View:** Show/hide sidebar, Zoom in, Zoom out, Actual size - **No code changes.** The manifest is auto-included via the existing `Manifests/*.yml` glob in `ShortcutGuide.Ui.csproj`, exactly like the existing Postman, Slack, Discord, and browser manifests. - The two literal-digit shortcuts (`Ctrl+1` switch to all accounts, `Ctrl+0` actual size) use the `<N>` token (`<1>` / `<0>`) per the manifest spec, and the "Switch accounts & collections" range renders as `2 - 9`. - **Documentation:** Added a note in `doc/specs/WinGet Manifest Keyboard Shortcuts schema.md` documenting the existing **sentence-case** naming convention for `Name` and `SectionName` (capitalize only the first word plus proper nouns / product feature names), so future contributors do not copy an application's title-case shortcut-list styling. The 1Password names in this PR follow that convention, keeping only feature/product names capitalized (Show Quick Access, Lock 1Password). ## PR Checklist - [x] Closes: #48792 - [ ] **Communication:** I've discussed this with core contributors already. <!-- Filed #48792; the v0.100 announcement invites app-shortcut contributions via PR. Follows the precedent set by #48461 (Postman). --> - [ ] **Tests:** Added/updated and all pass <!-- N/A: data-only change, no new code paths. The manifest was validated by deserializing it with YamlDotNet (the same `Deserializer` used by `ManifestInterpreter`), confirming all 26 entries and key tokens parse into `ShortcutFile`. --> - [x] **Localization:** All end-user-facing strings can be localized <!-- Shortcut names live in the per-language manifest (`*.en-US.yml`); other locales fall back to en-US, consistent with every existing manifest. --> - [x] **Dev docs:** Added/updated <!-- Documented the sentence-case naming convention for Name / SectionName in doc/specs/WinGet Manifest Keyboard Shortcuts schema.md. --> - [ ] **New binaries:** Added on the required places <!-- N/A: the new manifest is a data asset under an already-shipped, globbed folder. No new binaries or test projects. --> - [ ] **Documentation updated:** <!-- N/A: user-facing docs unchanged. --> - [x] **Local run:** Built the Shortcut Guide projects and ran the Debug build with 1Password focused (`Win+Shift+/`); screenshot of the rendered guide is attached below. ## Detailed Description of the Pull Request / Additional comments The Shortcut Guide displays per-app shortcuts from YAML manifests, matched to the foreground window via `WindowFilter`. Adding support for an app is purely additive: drop a `<PackageName>.<locale>.yml` file in the `Manifests` folder and it is picked up by the existing build glob and the index generator. - `PackageName: AgileBits.1Password` (the WinGet package identifier) and `WindowFilter: "1Password.exe"` (the desktop app process). - `Name: 1Password` is the display name shown in the Shortcut Guide app picker. - Shortcut names follow the repo's sentence-case convention (now documented in the schema spec). Recommended is set on the five highest-frequency / signature actions: Show Quick Access, Lock 1Password, Copy primary field, Copy password, Copy one-time password. ## Validation Steps Performed - **Schema/parse:** Deserialized the manifest with `YamlDotNet.Serialization.Deserializer` (the same path `ManifestInterpreter.YamlToShortcutList` uses). All four sections and 26 entries parse, with 5 marked Recommended. No parse errors. - **Key rendering:** Verified every key token against `KeyVisual` and `ShortcutDescriptionToKeysConverter`: `<Space>`/`<Delete>` strip to their labels, `<Left>`/`<Right>`/`<Up>`/`<Down>` map to arrow glyphs, `<1>`/`<0>` strip to the literal digit (matching the merged Postman `<9>`/`<0>` handling), `2 - 9` renders verbatim, and `+` / `-` render as the literal symbols (as in the bundled Windows Explorer and Shell manifests). - **Source fidelity:** The section grouping and every shortcut/modifier combination match 1Password's in-app Keyboard Shortcuts reference one-to-one. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <img width="1462" height="2260" alt="image" src="https://github.com/user-attachments/assets/e7824a38-cb56-4242-9a6a-31c7a93c03c9" /> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
moooyo
|
9039451e2f |
[Quick Accent] Migrate UI to WinUI 3 (#48891)
## Summary of the Pull Request Migrates the **Quick Accent (PowerAccent)** module's UI from WPF (`System.Windows.*`) to **WinUI 3 (Windows App SDK)**, following the pattern used by other migrated modules (ImageResizer, PowerDisplay). The accent selector is now a self-contained WinUI 3 app (`PowerToys.PowerAccent.exe`) shipped under `WinUI3Apps`, and `PowerAccent.Core` is UI-framework-agnostic. demo: https://github.com/user-attachments/assets/400c33ee-0fc0-491e-841b-a546438edf91 ## PR Checklist - [x] Closes: #48889 - [x] **Communication:** Tracked task (#48889) agreed with core contributors - [x] **Tests:** Added/updated and all pass — new `PowerAccent.Core.UnitTests` (21 tests for the positioning / DPI math); existing `PowerAccent.Common.UnitTests` unaffected - [x] **Localization:** No new localizable end-user strings — new accessibility metadata uses non-localized `AutomationProperties.AutomationId`, and the window title is the brand name `"Quick Accent"` (literal, matching ColorPicker) - [x] **Dev docs:** Updated `doc/devdocs/modules/quickaccent.md` - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json): the `WinUI3Apps\` PowerAccent payloads are listed in `ESRPSigning_core.json` - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs): no manual `Product.wxs` entry — the self-contained `WinUI3Apps` output (exe + `.pri` + Windows App SDK runtime) is harvested by the `WinUI3ApplicationsFiles` glob (same as ImageResizer) - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml): no change needed — `PowerAccent.Core.UnitTests` is discovered by the existing `**\*UnitTest*.dll` VSTest glob - [x] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml): covered by `ESRPSigning_core.json`; no `release.yml` change needed - [ ] **Documentation updated:** N/A — internal UI-framework migration with no user-facing behavior change ## Detailed Description of the Pull Request / Additional comments The migration spans three areas (tracked in #48889): **UI (WPF → WinUI 3)** - `PowerAccent.UI` is now a WinUI 3 app shell (custom `Program.Main`, `WindowsPackageType=None`, `WindowsAppSDKSelfContained=true`). - The accent selector is a non-activating `TransparentWindow` overlay shown with `SW_SHOWNA` (never steals focus). It is made always-on-top only while shown — the WinUIEx `WindowEx.IsAlwaysOnTop` property is toggled `true` on show / `false` on hide in `OnChangeDisplay` (matching the WPF original's `Topmost = isActive`), so the dormant, never-destroyed overlay does not pin a discrete GPU awake on hybrid-graphics laptops (issue #34849 / PR #41044). - The accent "pill" selection visual is reproduced with `VisualStateManager` (WinUI 3 has no `Style.Triggers`). - **WinUI 3 gotcha:** x:Bind on a Window-rooted XAML initializes only on `Window.Activated`, which never fires for this `SW_SHOWNA` overlay — so the selector calls `Bindings.Update()` after `InitializeComponent()`; without it the `ListView` renders empty. - **Theme:** the long-lived, never-activated process follows the system app theme automatically — `App.xaml` leaves `Application.RequestedTheme` unset, so WinUI re-resolves the `{ThemeResource}` brushes (and retints the acrylic) on a live light/dark switch with no manual `ThemeListener` needed. - **Layout parity with the WPF original:** the bar width hugs its content (`itemCount × 48`, clamped to the monitor width — computed, not measured, to avoid a racy `ListView` measure), and each cell pins `MinWidth=48` (WinUI's `ListViewItem` defaults to 88, which would otherwise leave wide gaps). - **Accessibility:** UIA window name + `AutomationId`s on the character list and description. **Dependency** - `PowerAccent.Core` no longer depends on WPF — it raises events and takes an injected UI-thread marshaller. - WinForms `SendKeys` → `SendInput` (CsWin32 P/Invoke); WPF-UI (Lepo) removed; language data moved to the UI-/WinRT-agnostic `PowerAccent.Common`. - MVVM via CommunityToolkit.Mvvm with `[ObservableProperty]` **partial properties** (WinRT-correct, clears MVVMTK0045). **CI / Build / Installer** - Signing config, WinUI3Apps glob harvest, and the new unit-test project — see the checklist above. ## Validation Steps Performed - **Build:** `x64 Debug` builds with **0 warnings / 0 errors**. - **Unit tests:** `PowerAccent.Core.UnitTests` — **21/21 pass** (9 anchor positions × DPI 1.0/1.5/2.0, the offset and negative-origin monitors, caret centering + edge clamping + flip-below). - **XamlStyler:** `PowerAccentXAML/MainWindow.xaml` passes the passive format check (CI mode). - **Manual (single monitor, Top-center, light theme):** - Accent popup appears with the full accent list rendered. - Bar hugs the characters and is centered; cell spacing matches the WPF original. - Switching the system theme (light/dark) is followed live by the popup. - With `show_description` enabled, the description row is wide (≥600px) and readable, with the accent bar centered above it. - **Remaining manual validation** (tracked in #48889): multi-monitor, per-monitor DPI, all 9 `toolbar_position` values, and high-contrast theme. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
af45c3ec7c |
Add press-and-hold activation mode to Quick Accent (#48937)
## Summary of the Pull Request Adds an opt-in **press-and-hold** activation mode to Quick Accent, like iOS / macOS: hold an accent-capable letter (e.g. `a`) and after a short, configurable delay the accent picker opens automatically — no separate trigger key (Space/arrows) required. This is purely additive. The existing trigger-key modes (`Left/Right arrow`, `Space`, `Both`) and all serialized settings values are unchanged. https://github.com/user-attachments/assets/faec298c-e42c-4fd1-84bd-6e74d1b481a0 ### What it does - Holding a letter types the base letter immediately, then arms the picker. After the **Hold duration** (default **500 ms**) the toolbar appears. - Navigate the options with the arrow keys / Space, then **release the letter** to insert the selected accent (it replaces the base letter). - A quick tap types just the letter. Holding and releasing without selecting leaves the base letter as-is. - `Ctrl` / `Alt` / `AltGr` / `Win` + letter combinations are left untouched, so shortcuts like `Ctrl+A` still work. ## PR Checklist - [ ] **Closes:** N/A — feature enhancement (happy to link a tracking issue if one is preferred) - [x] **Communication:** Discussed direction with maintainers; coordinated with #48891 (see below) - [ ] **Tests:** No automated tests added — the activation decision lives in the C++ low-level keyboard hook and isn't reachable from the existing managed unit-test project. Validated manually (steps below). Open to guidance on the preferred test surface. - [x] **Localization:** All new end-user strings are in `Settings.UI/Strings/en-us/Resources.resw` with translator comments. - [x] **Dev docs:** `doc/devdocs/modules/quickaccent.md` updated with the new mode. - [x] **New binaries:** None. - [x] **Documentation updated:** Dev docs updated; public Learn docs can follow once shipped. ## Detailed Description of the Pull Request / Additional comments - **`PowerAccentKeyboardService` (C++ hook):** - Append `PressAndHold` to the internal `PowerAccentActivationKey` enum (value `3`, appended to preserve serialized `0/1/2`). - Add a `holdDuration` setting and `UpdateHoldDuration(Int32)` to the WinRT projection (`.idl`). - In `OnKeyDown`, arm the picker on the held letter itself; the base letter still types on first press and auto-repeat is swallowed (reuses the existing `m_toolbarVisible` repeat guard from #36853). - In `OnKeyUp`, use the hold duration as the minimum-hold release threshold for this mode (trigger modes keep using `inputTime`). - Modifier guard: Ctrl/Alt/AltGr/Win do not arm the mode. - **Settings model (`Settings.UI.Library`):** append `PressAndHold` to `PowerAccentActivationKey`; add `hold_duration_ms` (`IntProperty`, default 500). Existing `settings.json` without the field falls back to the 500 ms default. - **`PowerAccent.Core`:** read and forward the hold duration to the hook, and use it as the popup delay when `PressAndHold` is active. - **Settings UI:** add the **"Press and hold the letter"** activation option and a **"Hold duration (ms)"** control that is shown only when that mode is selected. ### Enum sync note `PowerAccentActivationKey` exists in both the C++ hook and the managed settings library and is kept in sync by integer value. `PressAndHold` was **appended** (never reordered) so existing serialized settings (`0/1/2`) keep their meaning. ### Coordination with #48891 (Quick Accent WinUI migration) This lands as its own atomic change on `main`. The overlap with the in-progress WinUI migration (#48891) is tiny: only `PowerAccent.cs`'s mode-aware popup delay (a single `Task.Delay` line). The C++ hook, settings enum/model, and Settings UI are not touched by #48891, so it can rebase onto this with minimal effort. ## Validation Steps Performed - Built the full chain in `Debug|x64`: - `PowerAccent.UI.csproj` → rebuilds the C++ `PowerAccentKeyboardService` projection (incl. `UpdateHoldDuration`) + `PowerAccent.Core` + `Settings.UI.Library`. **0 errors.** - `PowerToys.Settings.csproj` → Settings UI XAML / ViewModel / `.resw` (XamlIndexBuilder search index regenerated). **0 errors.** - Manual trial of the running module (`PowerToys.PowerAccent.exe`) with `activation_key = 3`: - Hold `a` → base letter types immediately; picker opens after ~500 ms; arrows/Space navigate; releasing inserts the accent (replacing the base letter). - Quick tap → base letter only. Hold + release without selecting → base letter remains. - `Ctrl+A` / `Alt`+letter unaffected. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
de4859454c |
[PowerToys] Guard TitleBar windows against an empty window title (startup fault) (#49069)
## Summary Guard PowerToys' WinUI windows against an empty native window title, so the WinUI `TitleBar` control can't read an empty title during startup and fault the process. This fixes a class of bugs like https://github.com/microsoft/PowerToys/issues/48547 ## Background Spotted while reading through the Environment Variables `MainWindow` startup path. The WinUI `TitleBar` control (used with `ExtendsContentIntoTitleBar`) reads the owning window's `AppWindow.Title` during a deferred layout pass (`OnApplyTemplate` → `UpdateTitle`). When the native window title is empty at that instant, the windowing layer can fault while resolving the title and terminate the process during startup. The native title ends up empty in two ways: 1. The title is computed from `ResourceLoader.GetString(...)`, which returns an **empty string** (it doesn't throw) when the resource map can't be resolved at runtime. 2. The window sets `AppWindow.Title` only *later*, not before the title bar's first layout. ## Windows fixed Every PowerToys window that hosts the `TitleBar` control: | Window | Fix | |---|---| | Environment Variables | Non-empty fallback for the resource-based title | | Hosts | Non-empty fallback for the resource-based title | | File Locksmith | Non-empty fallback for the resource-based title | | Shortcut Guide | Non-empty fallback for the resource-based title | | Settings — shortcut-conflict window | Non-empty fallback for the resource-based title | | Registry Preview | Set `AppWindow.Title` to the app name in the constructor (previously only set later in `UpdateWindowTitle`) | | Keyboard Manager Editor | No change — already sets a hardcoded non-empty `Title` | ## Risk Very low. The only behavior change is that a previously-empty title becomes a non-empty fallback; the normal (resource-resolved) paths are unchanged. ## Validation Each affected project builds clean (`x64 | Release`): EnvironmentVariables, Hosts, FileLocksmithUI, ShortcutGuide.Ui, RegistryPreview, PowerToys.Settings. ## Related Root cause write-up (windowing/WinUI side): microsoft/microsoft-ui-xaml#11214. --- ADO: https://microsoft.visualstudio.com/DefaultCollection/OS/_workitems/edit/62685601/ --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Niels Laute
|
93669df118 |
TransparentWindow: opt-in Esc / focus-lost dismiss + multi-surface docs (#48950)
## Summary Hardens the shared `TransparentWindow` (in `src/common/Common.UI.Controls/`) with two **opt-in** dismissal behaviors and documents multi-surface hosting. No consumer changes; everything defaults off. ### 1. `DismissOnEscape` (default `false`) Pressing <kbd>Esc</kbd> while the window content has keyboard focus calls `Hide()`. Input is hooked lazily at show time because `Content` is assigned by the consumer after construction. ### 2. `DismissOnFocusLost` (default `false`) Light dismiss: hides when the window is deactivated. Guarded by a "seen activated" flag (reset on each `Show()`) so the transient deactivation that can occur during the show sequence doesn't dismiss prematurely. This mirrors the guards that **PowerDisplay** (`_isShowingWindow`) and **Quick Access** (`_hasSeenInteractiveActivation`) currently hand-roll — they can drop their bespoke logic once they derive from `TransparentWindow`. > Both properties are no-ops unless the consumer activates the window (it shows no-activate / `SW_SHOWNA`). ### 3. Multi-surface hosting (docs only — already works) Added class `<remarks>` documenting that multiple `TransientSurface`s can `SubscribeTo` one window: `HidingEventArgs` aggregates deferrals so the window hides only after **all** surfaces finish animating out, and plain `Show()` lets each surface play its own configured transition. ## Why no DWM "full-bleed" hardening here The extra DWM hardening Shortcut Guide uses (NCRENDERING disabled, `DwmExtendFrameIntoClientArea(-1)`, etc.) is only needed for **full-monitor, edge-to-edge** overlays. Content-sized surfaces (Quick Accent, CmdPal Toast) inset their acrylic card behind transparent padding, so any phantom border sits in the transparent margin and is invisible. Applying it universally would add compositing risk for zero benefit, so it's deferred to the Shortcut Guide refactor (where it's actually exercised) as an opt-in. ## Testing - `Common.UI.Controls` builds clean (Debug/x64). - Behavior is opt-in and off by default, so existing consumers are unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Noraa Junker
|
56fabda79c |
[Chore] Remove outdated clean up tool (#48992)
<!-- 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 Remove outdated clean up tool and script <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48991 <!-- - [ ] 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] **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 |
||
|
Clint Rutkas
|
70555459ab |
[AlwaysOnTop] Guard m_frameDrawer in WindowBorder::UpdateBorderPosition (#48412)
## Summary
`WindowBorder::UpdateBorderPosition()` dereferences `m_frameDrawer`
without a null check when `GetFrameRect` fails on the tracked window:
```cpp
auto rectOpt = GetFrameRect(m_trackingWindow);
if (!rectOpt.has_value())
{
m_frameDrawer->Hide(); // <-- AV if m_frameDrawer == nullptr
return;
}
```
The sibling routine `WindowBorder::UpdateBorderProperties()` already
guards both `m_trackingWindow` and `m_frameDrawer` before doing any
work:
```cpp
if (!m_trackingWindow || !m_frameDrawer)
{
return;
}
```
`UpdateBorderPosition` was the only call site that didn't match that
pattern. This PR brings it in line, and also adds a guard for `m_window`
for symmetry (the subsequent `SetWindowPos(m_window, ...)` would
otherwise fail silently with `ERROR_INVALID_WINDOW_HANDLE` but it's
cleaner to early-return).
## Why `m_frameDrawer` can be null when `UpdateBorderPosition` runs
`WindowBorder` registers itself as a `SettingsObserver` in its
base-class constructor — *before* `Init()` finishes. `Init()` is what
actually allocates `m_frameDrawer` (via `FrameDrawer::Create`). So
between those two steps there is a window where the object is alive and
observable but `m_frameDrawer == nullptr`.
The destructor has a similar shape:
```cpp
WindowBorder::~WindowBorder()
{
if (m_frameDrawer)
{
m_frameDrawer->Hide();
m_frameDrawer = nullptr;
}
if (m_window)
{
SetWindowLongPtrW(m_window, GWLP_USERDATA, 0);
DestroyWindow(m_window);
}
}
```
`m_frameDrawer` is nulled before `GWLP_USERDATA` is cleared and before
`DestroyWindow` is called. Any `WM_TIMER` that fires through `s_WndProc`
in that window dispatches to `WndProc → UpdateBorderPosition()` on an
instance whose `m_frameDrawer` has already been released — same null
deref, same access violation.
`UpdateBorderPosition` is also invoked from
`EVENT_OBJECT_LOCATIONCHANGE` / `EVENT_SYSTEM_MOVESIZEEND` in
`AlwaysOnTop.cpp` and from `WM_TIMER` in `WndProc`; both run on the
message-loop thread and either path can land here while the object is in
a transient half-constructed or half-destructed state.
## Change
Add `!m_frameDrawer` (and `!m_window`) to the early-return guard at the
top of `UpdateBorderPosition`. Three-line patch.
## How this was found
While reviewing the `WindowBorder` lifecycle for an unrelated
AlwaysOnTop tweak, the asymmetry between `UpdateBorderPosition` and
`UpdateBorderProperties` jumped out — the former dereferences
`m_frameDrawer` without the null check the latter performs.
## Tests
`src/modules/alwaysontop` has no test project today — `WindowBorder` is
tightly bound to Win32 (`HWND`, `DwmGetWindowAttribute`, `SetWindowPos`)
and `FrameDrawer` (Direct2D / D3D), with no abstraction layer to mock.
Adding meaningful native unit tests here would require a substantial
refactor that's well out of scope for this fix.
Manual validation:
- Build clean: `MSBuild
src\modules\alwaysontop\AlwaysOnTop\AlwaysOnTop.vcxproj
/p:Configuration=Release /p:Platform=x64` produces
`PowerToys.AlwaysOnTop.exe` with no warnings.
- Behavioural: with the guard added, the early-return path for "tracked
window has no valid extended frame bounds" simply skips the `Hide()`
call instead of crashing — same end-state for the user (border position
is left as-is until the next timer tick recovers it).
If we want a runtime regression net here, the right level is a UI /
lifecycle test that creates and pins/unpins windows under churn; that's
a separate piece of work and not gated on this fix.
## Risk
Three guarded conditions on a path that was already guarding one of
them. The behavioural delta only fires when the dereference *would* have
crashed — anywhere else the function is unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
||
|
moooyo
|
d6319516d0 |
[Skills] Fix wpf-to-winui3-migration SKILL.md failing to load (#49059)
## Summary of the Pull Request The `wpf-to-winui3-migration` agent skill failed to load. The `description` field in its `SKILL.md` YAML frontmatter was an **unquoted** plain scalar containing `Keywords: ` (a colon followed by a space). YAML interprets `: ` as a mapping key/value separator, so the skill loader failed with: > failed to parse YAML frontmatter: mapping values are not allowed in this context at line 2 column 651 Because `.claude/skills` is a symlink to `.github/skills`, the CLI enumerates the same file twice, so this single defect surfaced as **two** skill load errors (`skill_error_count: 2`). Fix: wrap the `description` value in single quotes so the colon is treated literally. No wording changes; the description stays 926 characters (well under the 1024 limit). ## PR Checklist - [ ] Closes: #xxx — N/A, trivial metadata fix, no tracking issue - [x] **Communication:** Metadata-only fix; no design discussion needed - [ ] **Tests:** N/A — no test harness for skill frontmatter; validated by YAML parsing (see below) - [x] **Localization:** N/A — not end-user-facing - [ ] **Dev docs:** N/A - [ ] **New binaries:** N/A ## Detailed Description of the Pull Request / Additional comments `.github/skills/wpf-to-winui3-migration/SKILL.md` line 3 changed from: ```yaml description: Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap. ``` to: ```yaml description: 'Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap.' ``` The three other top-level skills already quote (or avoid `: ` in) their descriptions, so only this one was affected. Single quotes are used because the description contains no quote characters, so no escaping is required. ## Validation Steps Performed - Reproduced the loader error from the Copilot CLI logs: `mapping values are not allowed in this context at line 2 column 651`. - Parsed the frontmatter of all 9 `SKILL.md` files with a YAML parser: before = 1 failure (this file), after = **0 failures**. - Confirmed parsed `name` (`wpf-to-winui3-migration`), `description` (926 chars, ≤ 1024), and `license` are intact and the literal `Keywords: WPF...` text is preserved. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Alex Mihaiuc
|
53737cbe31 |
ZoomIt add snip and panorama save hotkeys (#49075)
<!-- 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 - Fixes #45808 — ZoomIt's "Snip Save" hotkey was auto-derived by XOR'ing the Shift modifier from the Snip hotkey, causing `Ctrl+S` to be stolen when Snip was set to `Ctrl+Shift+S` - The Snip Save hotkey is now a separate, independently configurable setting (default: `Ctrl+Shift+6`, complementing the default Snip hotkey `Ctrl+6`) - Updated both the PowerToys Settings UI and the standalone ZoomIt options dialog - The same is applied for the scrolling screenshot keys <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #45808 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [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~~ N/A (no ZoomIt tests in repo) - [x] **Localization:** All end-user-facing strings can be localized - [x] ~~**Dev docs:** Added/updated~~ N/A in this case I think - [x] ~~**New binaries:** Added on the required places~~ N/A - [ ] [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 ZoomIt registered two hotkeys for Snip — the primary (`SNIP_HOTKEY`) and a "save to file" variant (`SNIP_SAVE_HOTKEY`) derived by toggling the Shift modifier via XOR: ```cpp RegisterHotKey(hWnd, SNIP_SAVE_HOTKEY, (g_SnipToggleMod ^ MOD_SHIFT), g_SnipToggleKey & 0xFF); ``` This worked fine for the default `Ctrl+6` (save became `Ctrl+Shift+6`), but when a user configured `Ctrl+Shift+S` as their Snip hotkey, the XOR removed Shift, making the save variant `Ctrl+S` — stealing a ubiquitous shortcut from every other application. ## Changes ### C++ Backend (ZoomIt core) - **`resource.h`** — Added `IDC_SNIP_SAVE_HOTKEY` control ID for the new dialog control - **`ZoomItSettings.h`** — Added `g_SnipSaveToggleKey` global variable (default: `Ctrl+Shift+6`) and its `RegSettings[]` entry for registry persistence - **`ZoomIt.rc`** — Added a second hotkey control ("Snip Save Toggle") to the standalone SNIP options dialog - **`Zoomit.cpp`** — Added `g_SnipSaveToggleMod` global; replaced all 4 XOR-derived `RegisterHotKey` calls with the new explicit setting; updated the options dialog init, read, validation, and save logic ### Settings Interop - **`ZoomItSettings.cpp`** — Added `SnipSaveToggleKey` to the `settings_with_special_semantics` map so it serializes as a hotkey JSON object ### C# Settings UI - **`ZoomItProperties.cs`** — Added `DefaultSnipSaveToggleKey` and `SnipSaveToggleKey` property - **`ZoomItViewModel.cs`** — Replaced the computed XOR-derived read-only getter with a full get/set property backed by the new `SnipSaveToggleKey` setting - **`ZoomItPage.xaml`** — Replaced the read-only markdown description with an editable `ShortcutControl` for the save hotkey - **`Resources.resw`** — Added "Save snip to file" header string; removed the old templated description <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Built and tested locally -- ✅ App shows additional shortcut for ZoomIt <img width="983" height="188" alt="image" src="https://github.com/user-attachments/assets/f73c1ecc-3aee-4dee-bfbb-b95764e7eb1c" /> ✅ I am able to save files via `CTRL + S` as normal ✅ I am able to use Snip activation with `CTRL + Shift + S` ✅ I am able to use Save snip to file with the assigned shortcut of `CTRL + Shift + 6` ✅ Other ZoomIt commands run as expected (e.g. LiveZoom with my mapping of `ALT + 4` --------- Co-authored-by: Sean Killeen <SeanKilleen@gmail.com> |
||
|
Dave Rayment
|
bf6ff579d3 |
[ZoomIt] Fix issue with recording filename suffixes (#43236)
<!-- 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 Fixes an issue where ZoomIt would always remove a numeric suffix from a suggested recording filename even when it was part of a user-chosen name. Also: appends a timestamp instead of a numeric suffix for the default filename, improving consistency with other tools and allowing for correct name ordering in Explorer views. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #43202 - [ ] **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 The `GetUniqueRecordingFilename()` function used regex to strip numeric suffixes, and incorrectly assumed that all `(N)` patterns were ZoomIt-generated. This broke user-provided filenames like "My Presentation (2025).mp4". ### Root cause ```cpp // Chop off index if it's there auto base = std::regex_replace( path.stem().wstring(), std::wregex( L" [(][0-9]+[)]$" ), L"" ); path.replace_filename( base + path.extension().wstring() ); ``` This code strips off _any_ numeric suffix. ### Solution The proposed solution tracks the user's chosen filename separately, using it as the base for the file renaming strategy. The new string `g_RecordingSaveBaseFilename` allows for additive suffix generation without using regex stripping. This change also allows us to remove **regex.h** as a dependency, reducing the application's file size. The code retains the addition of numeric suffixes for user-chosen filenames, but timestamp suffixes are now added when the filename is the default `Recording.mp4`; this is more consistent with tools like Windows Snipping Tool, and allows for correct ordering of files in Windows Explorer (previously, `Recording (11).mp4` would be sorted before `Recording (2).mp4`, for example). <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ### Test Scenario 1: Default filename with timestamp suffix 1. Launch ZoomIt, start first recording with <kbd>Ctrl</kbd>+<kbd>5</kbd>. 2. Stop the recording. The Save dialog shows "Recording.mp4". 3. Select **Save** to Accept this default. The file is saved as "Recording 2025-11-03 180719.mp4" or similar. 4. Start and stop another recording. 5. The Save dialog shows "Recording 2025-11-03 180800.mp4" or similar, i.e. with a distinct timestamp from the last save. Accept this suggestion by selecting **Save**. 6. Verify both files exist on disk. By default, this will be in your **Videos** folder. ### Test Scenario 2: Custom filename (ascending numeric suffix) 1. Launch ZoomIt, and start recording. 2. Stop the recording and change the suggested filename to "My Presentation.mp4". Select **Save** to save the file. 3. Start and stop a second recording. 4. Confirm the dialog suggests "My Presentation (1).mp4" as the filename. Select **Save** to accept this filename. 5. Start and stop a third recording. 6. Confirm the dialog suggests "My Presentation (2).mp4" as the filename. Select **Save** to accept the suggestion. 7. Verify all files exist on disk with the correct names. ### Test Scenario 3: User filename with parenthetical number (bug repro) 1. Launch ZoomIt and start recording. 2. Stop the recording and change the suggested filename to "My Presentation (2025).mp4". Select **Save** to save the recording to disk. 3. Start and stop a second recording. 4. Confirm the dialog suggests "My Presentation (2025) (1).mp4" as the filename. (This was broken before - the prior version would suggest "My Presentation.mp4".) 5. Accept the suggestion by selecting **Save**. 6. Start and stop a third recording. 7. Confirm the save dialog suggests "My Presentation (2025) (2).mp4". 8. Verify all files exist on disk with the correct names. ### Test Scenario 4: User modifies suggested filename 1. Save first recording as "Test.mp4". 2. Start and stop a second recording. 3. Confirm the second recording has a suggested filename of "Test (1).mp4". 4. Change the suggested filename to "TestFinal.mp4" before saving. 5. Start and stop a third recording. 6. Confirm the save dialog suggests "TestFinal (1).mp4". (Verifies correct updating of the base filename.) ### Test Scenario 5: Existing files at the save location 1. Manually create "Video.mp4" and "Video (1).mp4" in the Videos folder. 2. Start ZoomIt and save a recording to the same folder as "Video.mp4". Confirm you are asked to overwrite the existing file. 3. Select "Yes" and save the file. 4. Start and stop another recording. 7. Confirm that the Save dialog's suggested filename is "Video (2).mp4", skipping the manually-added file. ## Code updates ### Additional clean-up - Clarified path construction in recording initialisation block (replaced `/=` with explicit path building for a more readable approach). - Changed `DEFAULT_RECORDING_FILE` from a `#define` to a `constexpr` instead. The new base filename variable is based upon it. Co-authored-by: Niels Laute <niels.laute@live.nl> |
||
|
Michael Jolley
|
0afe525f31 |
Fix memory leaks in Command Palette: unsubscribe event handlers and dispose resources (#48884)
## Summary Fixes 6 memory leaks in Command Palette caused by event handlers not being unsubscribed and disposable resources not being released. ## Changes | File | Fix | |------|-----| | `MainListPage.cs` | Replace lambda on static `AllAppsCommandProvider.Page.PropChanged` with named method; unsubscribe in `Dispose()` | | `WinRTExtensionService.cs` | Unsubscribe static `PackageCatalog` events (`PackageInstalling`/`Uninstalling`/`Updating`) in `Dispose()` | | `MainWindow.xaml.cs` | Unsubscribe all event handlers in `Dispose()` (`SizeChanged`, `SettingsChanged`, `ActualThemeChanged`, `XamlRoot.Changed`, `CardElement.SizeChanged`, timer `Tick`, `ThemeChanged`, `KeyPressed`); replace lambda with named method | | `ContentFormControl.xaml.cs` | Unsubscribe previous `RenderedAdaptiveCard.Action` before subscribing to new card | | `BlurImageControl.cs` | Track `LoadedImageSurface` and unsubscribe `LoadCompleted` before loading a new image | | `ShowFileInFolderCommand.cs` | Dispose `Process` object returned by `Process.Start()` (handle leak) | ## Validation - [x] Build clean (`tools\build\build.ps1 -Path src\modules\cmdpal -Platform x64 -Configuration Debug`) — exit code 0 - [x] All 1809 CmdPal unit tests pass (2 pre-existing skips) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Michael Jolley
|
a43fb12d6f |
cmdpal: Support Enter key to submit FormContent (Adaptive Card) inputs (#48768)
## Summary Adds Enter key support for submitting Adaptive Card forms in the Command Palette. When a user presses Enter inside a single-line `Input.Text` field, the form is automatically submitted using the first `Action.Submit` or `Action.Execute` action on the card. ## Problem When extensions use `FormContent` with Adaptive Cards, pressing Enter inside an `Input.Text` field does not trigger submission. Users must click the submit button with their mouse (or tab to it), breaking keyboard-only workflows like login/unlock forms. ## Solution Added a `KeyDown` event handler on the rendered Adaptive Card's `FrameworkElement` in `ContentFormControl.xaml.cs`: - Intercepts `VirtualKey.Enter` when the source is a `TextBox` that doesn't accept returns (single-line) - Finds the first `AdaptiveSubmitAction` or `AdaptiveExecuteAction` on the card - Calls `HandleSubmit` with that action and the current user inputs via `RenderedAdaptiveCard.UserInputs.AsJson()` Multiline text inputs (`AcceptsReturn = true`) are excluded so Enter still inserts newlines. ## Validation - Single file change in `ContentFormControl.xaml.cs` - Uses existing `HandleSubmit` path — same behavior as clicking the submit button - No impact on cards without submit/execute actions - No impact on multiline text inputs Fixes #46003 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Christian Gaarden Gaardmark
|
bc56443443 |
New++ updated attribution (#49047)
## Summary of the Pull Request * Updated New+ attribution text and link after conversation with Niels * Text="Based on Christian Gaardmark's New++ from the Productivity Plus Pack" * Link="https://www.onegreatworld.com/products/productivity-plus-pack/?ref=settings_pt" ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [n/a] **Tests:** Added/updated and all pass - [n/a] **Localization:** All end-user-facing strings can be localized - [n/a] **Dev docs:** Added/updated - [n/a] **New binaries:** Added on the required places - [n/a] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [n/a] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [n/a] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [n/a] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [n/a] **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 * Text="Based on Christian Gaardmark's New++ from the Productivity Plus Pack" * Link="https://www.onegreatworld.com/products/productivity-plus-pack/?ref=settings_pt" ## Validation Steps Performed 1. Manually confirmed visual layout 2. Manually confirmed link <img width="470" height="65" alt="image" src="https://github.com/user-attachments/assets/56d6e454-89cf-4a26-b570-b162df51f4a9" /> cc: @niels9001 |
||
|
Clint Rutkas
|
3298625b67 |
Cancel stale Quick Accent toolbar render timer (#48944)
## Summary Quick Accent's ShowToolbar queues a delayed render of the accent menu through Task.Delay(...).ContinueWith(...). The continuation only checked _visible before rendering, so a timer started by an earlier key press could still fire for a **newer** summon — or one that had already been hidden — popping the accent menu earlier than the configured delay intended. This was surfaced while reviewing the press-and-hold work in #48937, but it is a pre-existing race independent of that feature, so it ships on its own. ## Fix - Tag each `ShowToolbar` summon with an incrementing `_showGeneration` id and capture it in the local closure. - The delayed continuation now renders only when it is still the most recent summon (`generation == _showGeneration`) **and** `_visible`. - Bump the generation when the toolbar hides, so any in-flight timer queued before the hide is cancelled. Everything runs on the UI thread (the dispatcher marshals `ShowToolbar`/hide and the continuation uses `FromCurrentSynchronizationContext`), so the counter needs no locking. ## Validation - Built `PowerAccent.UI` (C++ hook + Core) Debug|x64 — 0 warnings, 0 errors. - Manual: rapid repeated taps of an accent-capable letter no longer flash the menu early from a leftover timer; normal hold-to-open and navigation/commit are unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
ae9f241ef1 |
[FancyZones] Harden three shutdown races in WorkArea / ZonesOverlay / OnThreadExecutor (#48473)
## Summary Four small shutdown-/teardown-race fixes in FancyZones that I spotted while reading through the work-area and overlay teardown sequence for an unrelated review. Each one is independently safe in the happy path, but in combination they can crash the FancyZones host process during display changes, monitor configuration changes, a settings toggle mid-drag, or normal exit. ## Issues fixed ### 1. `~ZonesOverlay` joins a non-joinable thread when the constructor early-returns `ZonesOverlay::ZonesOverlay` can return early in two places — if `GetClientRect` fails or if `CreateHwndRenderTarget` returns a failure HRESULT (both reachable in the wild during a display-driver TDR or when a monitor is disconnected mid-init). When that happens, `m_renderThread` is never started and stays default-constructed. The destructor unconditionally calls `m_renderThread.join()`, which on a non-joinable thread is undefined behavior (MSVC throws `std::system_error`); thrown from an implicit-noexcept destructor it calls `std::terminate()`. Fix: guard the wake-up-and-join sequence with `if (m_renderThread.joinable())`. ### 2. `~WorkArea` returns the HWND to the window pool before the renderer is torn down `WorkArea`'s explicit destructor body calls `windowPool.FreeZonesOverlayWindow(m_window)` first, and only afterwards does implicit member destruction run `~ZonesOverlay` (which joins the render thread). Between those two steps the HWND is back in the pool and immediately eligible for reuse by the next `NewZonesOverlayWindow` call, while the still-alive render thread is using `m_renderTarget` to draw into it. If the pool hands the same HWND to a freshly-built `ZonesOverlay`, two render targets target the same window concurrently. Fix: reset `m_zonesOverlay` (which joins the render thread) before returning the window to the pool. ### 3. `~OnThreadExecutor` writes `_shutdown_request` outside the mutex The destructor mutates the shutdown flag without holding `_task_mutex`, then calls `_task_cv.notify_one()`. The worker checks the same flag inside `_task_cv.wait(lock, predicate)`. The atomic does make the value visible eventually, but if the notify lands in the narrow window where the worker has just evaluated the predicate as false and is about to atomically release the lock and sleep, the wakeup can be missed and `_worker_thread.join()` hangs. Fix: take `_task_mutex` around the `_shutdown_request = true` write so it pairs correctly with the `cv.wait`. ### 4. `WindowMouseSnap` keeps a dangling `WorkArea*` across `WorkAreaConfiguration::Clear()` `FancyZones::UpdateWorkAreas()` rebuilds `m_workAreaConfiguration` whenever monitor state changes mid-session, and the `SpanZonesAcrossMonitors` settings toggle hits the same `Clear()`. If the user is mid-drag at the moment one of these runs, the `WindowMouseSnap` instance owned by `FancyZones` is still holding both a `const` reference to the map being cleared (`m_activeWorkAreas`) and a raw `WorkArea*` into one of the entries that's about to be destroyed (`m_currentWorkArea`). The next `WM_MOUSEMOVE` -> `MoveSizeUpdate()` then dereferences a freed pointer. `WindowMouseSnap`'s destructor only resets window transparency, so relying on it doesn't help; the snapper has to be torn down explicitly. Fix: call `FancyZones::MoveSizeEnd()` (which already tears down the snapper cleanly and is a no-op when the snapper is null) before each `m_workAreaConfiguration.Clear()` call on these paths. ## Risk Low. All four changes are localized to teardown / reconfiguration paths and only tighten existing destruction sequences — the steady-state behavior of `ZonesOverlay::Render`/`Show`/`Hide`, the work-area public API, `OnThreadExecutor::submit`/`cancel`, and `WindowMouseSnap` drag handling is unchanged. The `WorkArea` reordering is the most behavioral change; it now guarantees the render thread has stopped using the HWND before the pool can recycle it, which is what the existing implicit-member-destruction order already implied but couldn't enforce given the explicit destructor body. ## Validation Spot-built locally; this repo's `dotnet restore` runtime-pack issue (unrelated to this PR — same NU1102 pattern that's affecting other open PRs) prevents a full `Build.cmd` here, but the C++ FancyZones modules involved are unchanged in their public surface and are exercised by existing unit tests in `FancyZonesTests` for the WorkArea code paths. --- ADO: https://microsoft.visualstudio.com/OS/_workitems/edit/54653316/ --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Jiří Polášek
|
67a9fa2d13 |
CmdPal: Ensure that directory paths passed from Bookmarks is quoted (#48955)
This PR ensures that directory paths passed from Bookmarks through `CommandLauncher` to Windows Explorer are properly quoted. In current implementation the directory path that should be opened through Windows Explorer is not quoted and if it contains a space then Explorer will treat it as multiple arguments instead. <!-- 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 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48672 <!-- - [ ] 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 |
||
|
Clint Rutkas
|
1cfc923bdb | Fix mismatched WebView2 versions, upgrade WebView2 (#49051) | ||
|
Clint Rutkas
|
2dd802f367 |
Fixing Windows.ImplementationLibrary mismatch between proj and package.config (#49050)
In the vcxproj files, it lists it correctly for Microsoft.Windows.ImplementationLibrary.1.0.260126.7 but the package files are incorrect |
||
|
Clint Rutkas
|
a0d17406ba |
Updating MessagePack (#49029)
Version bump on Message Pack |
||
|
Copilot
|
4a27c5d5f9 |
New+: Fix French translation guidance (Nouveau+ not Nouveauté+) (#47225)
## Summary of the Pull Request
French translation of "New+" was rendered as "Nouveauté+" ("Novelty+")
instead of "Nouveau+" ("New+"), inconsistent with how Windows itself
translates the "New" context menu item in French. This updates
translator guidance comments in the English resource files to explicitly
call out the correct French form.
## PR Checklist
- [ ] **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
Translator-facing `<comment>` fields updated across three resource files
to explicitly state the correct French translation and flag the wrong
one:
- **`NewShellExtensionContextMenu/resources.resx`** and
**`NewShellExtensionContextMenu.win10/resources.resx`** —
`context_menu_item_new`:
> _"…e.g. Danish it would become Ny+, **French it would become Nouveau+
(not Nouveauté+)**"_
- **`Settings.UI/Strings/en-us/Resources.resw`** — five `NewPlus.*` /
`Oobe_NewPlus.*` strings:
> _"…Localize product name in accordance with Windows New. **e.g. French
would be Nouveau+ (not Nouveauté+)**"_
Actual `.lcl` translation files are managed by the CDPX localization
pipeline; these comment updates feed directly into the guidance the
localization team sees when updating those files.
## Validation Steps Performed
Comment-only changes to XML resource files; no runtime behavior
affected. Verified all targeted entries were updated and no existing
checked-in `Nouveauté` strings remain in the repo.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: niels9001 <9866362+niels9001@users.noreply.github.com>
|
||
|
Dave Rayment
|
8bd5c1be6f |
[Quick Accent] Additions and reorg for IPA set. Additions to Special set (#49030)
<!-- 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 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #48840 - [x] Closes: #32437 - [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 - [ ] **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 The following additions and changes were made in response to the feedback given in #48840 and also following an audit of the IPA set. #### IPA | Character | Action |--|--| | `ɱ` | Added to **M** | | `ʍ` | Added to **W** | | `ɚ` | Added to **E** | | ` ͡ ` and ` ͜ ` | Added to **PERIOD** | `ɡ` | Added to **G** | `ɫ` | Added to **I** | `ʱ` | Added to **H** | `◌̝`, `◌̥`, `◌̚`, `ˈ` and `ˌ` | added to **PERIOD** | `ʎ` | Added to **Y** | `ʔ` | Added to **COMMA** and **SLASH** | `æ` | Added to **A** and **E** | `œ` | Added to **O** and **E** | `ʘ` | Added to **B** and **O** | `β`, `ɓ` | Added to **B** | `χ` | Added to **C** and **X** | `ç`, `ǂ` | Added to **C** | `ð`, `ɗ`, `ɖ`, `ǀ` | Added to **D** | `ɠ`, `ʛ` | Added to **G** | `ħ`, `ɥ`, `ɧ` | Added to **H** | `ʄ` | Added to **J** | `ɫ`, `ǁ` | Added to **L** | `ø` | Added to **O** I removed the caron vowel characters `ǎ`, `ǒ` and `ǔ`, as they should not have been in the IPA set. These characters are available in the Pinyin set. A small number of keys had entries reordered where common mappings would have been towards the end. This IPA update includes: - Click Consonants (`ʘ`, `ǀ`, `ǃ`, `ǂ`, `ǁ`), which are used in the phonetic transcription of Southern and Eastern African languages, most notably the Khoisan language groups and several Bantu languages (like Zulu and Xhosa). - Implosives and Ejectives (`ɓ`, `ɗ`, `ʼ`, etc.), which are essential for transcribing languages across the globe, including Indigenous languages of the Americas (e.g., Navajo and Mayan), the Caucasus (e.g., Georgian), Southeast Asia (e.g., Vietnamese), and widely across the African continent. #### SPECIAL set | Character | Action | Notes |--|--|--| | `‽` and `⸘` | Added to **SLASH** | | `⟨`, `⟩`, `⟪` and `⟫` | Replaced full-width CJK brackets with the Western versions. | `‰` and `‱` | Added to **P** <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing, with specific tests to confirm that the new combining marks display OK in the UI. |
||
|
Clint Rutkas
|
7b19b4c219 |
Add build-time guard for Windows long path support (#49028)
PowerToys has deeply nested source paths that exceed the legacy 260-character MAX_PATH limit. Contributors who haven't enabled Windows long path support hit cryptic 'path too long' / 'could not find file' errors during their first build. Add an EnsureLongPathsEnabled MSBuild target in Directory.Build.targets that reads HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled and fails fast with an actionable error (PTLONGPATH) pointing at tools\build\setup-dev-environment.ps1. Covers both Visual Studio and the command-line build scripts, skips design-time builds, and can be bypassed with /p:SkipLongPathsCheck=true. **What happens if Long file path isn't enabled.** <img width="824" height="916" alt="image" src="https://github.com/user-attachments/assets/30731f65-4011-48c0-94b9-e521b4c7d266" /> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Jessica Dene Earley-Cha
|
b73fd670be |
[CmdPal] Fix excessive Narrator announcements on More button open (#48928)
<!-- 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
Opening the More button caused Narrator to read a long cascade of
overlapping announcements — popup window, filter TextBox placeholder,
ListView item name, position ("1 of 4"), keyboard shortcut text — all
from a single keypress with no further input.
This PR replaces that cascade with a single, clean announcement:
**"Menu, {0} commands. {1}, {2} of {0}"**
(num of commands, first item in list, num of order in list, num of
commands)
**"Menu, 3 commands. Calculator, 1 of 3."**
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #48899
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [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
| File | Change |
|------|--------|
| `ContextMenu.xaml` | Set `AccessibilityView="Raw"` on ListView and
TextBox; added `NarratorAnnouncer` TextBlock for raising UIA
notifications |
| `ContextMenu.xaml.cs` | Added `AnnounceOpened()`,
`AnnounceSelectedItem()`, and `_isOpening` guard to prevent programmatic
selection changes from triggering UIA events during the flyout
transition |
| `CommandBar.xaml.cs` | Call `AnnounceOpened()` on flyout open |
| `DockControl.xaml.cs` | Same for dock context menu |
| `Resources.resw` | Added `ScreenReader_Announcement_ContextMenuOpened`
localized format string |
## How it works
- ListView and TextBox are permanently `AccessibilityView="Raw"` —
invisible
to Narrator, preventing all system-driven UIA announcements
- A zero-size `NarratorAnnouncer` TextBlock
(`AccessibilityView="Content"`,
`LiveSetting="Assertive"`) serves as the sole notification source
- On open: a deferred `RaiseNotificationEvent` fires one consolidated
announcement
- On arrow navigation: `AnnounceSelectedItem()` fires item name and
position
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
https://github.com/user-attachments/assets/4660741f-6b91-4a32-9a56-83c64343b67a
- [x] Build succeeds (0 errors)
- [x] 124 ViewModel unit tests pass
- [x] Manual Narrator testing: open, arrow navigate, close, reopen
- [x] Keyboard filtering (type to filter) still works
- [x] Enter to invoke selected command still works
- [x] Escape to close still works
|
||
|
Niels Laute
|
a46a4437e5 |
Fix unreadable What's New titles/links when OS and PowerToys themes differ (#48910)
## Summary of the Pull Request When the OS theme differs from the PowerToys theme (e.g. OS in Light, PowerToys set to Dark), the **What's New / release-notes (Scoobe)** page renders heading titles and hyperlinks with brushes pinned to the wrong theme, making them unreadable. The system caption buttons (min/max/close) are also not tinted to match the window theme. The release-notes page uses the CommunityToolkit `MarkdownTextBlock`, which captures its heading and link brushes from `Application.Current.Resources` when its theme config is created. Those resolve against the **OS (application) theme** rather than the window's selected element theme, so headings/links break whenever the two themes differ. ## PR Checklist - [x] Closes: #43970 - [x] Closes: #48832 - [x] **Communication:** Local workaround for a known upstream control bug - [ ] **Tests:** Manually validated (UI/theming change) - [x] **Localization:** No new end-user-facing strings - [ ] **Dev docs:** N/A ## Detailed Description of the Pull Request / Additional comments These are deliberately **local workarounds** until the upstream control resolves brushes against the element theme via [CommunityToolkit/Labs-Windows#785](https://github.com/CommunityToolkit/Labs-Windows/pull/785). Comments + `TODO`s in the code point at that PR so the workaround can be removed once it ships. **`ScoobeReleaseNotesPage`** - Pin the `MarkdownTextBlock.RequestedTheme` to the selected app theme and reassign the `H1`–`H6` heading brushes and the link brush (resolved for that theme) before the markdown is rendered. The themed brushes are read from the control's own `Foreground` (`TextFillColorPrimaryBrush`) and a hidden `LinkBrushProvider` carrier element (`AccentTextFillColorPrimaryBrush`). - Re-run the workaround and force a re-render on runtime theme changes (subscribe to the page's `ActualThemeChanged`), so titles/links stay readable when the user switches Light/Dark while the window is open. **`TitleBarHelper` (new) + `ScoobeWindow`** - Add a small shared `TitleBarHelper.ApplySystemThemeToCaptionButtons(window, theme)` (port of the WinUI Gallery helper + PowerToys conventions) and drive the Scoobe window's caption-button colors from the content's actual theme, updating on `ActualThemeChanged`. `ScoobeWindow` uses the built-in WinUI `TitleBar`, which — unlike the custom PowerToys `TitleBar` control used by the other Settings windows — does not tint the system caption buttons to the app theme. ## Validation Steps Performed - OS Light + PowerToys Dark: opened What's New → headings, hyperlinks, body text and caption buttons all render readable/dark-themed (previously black/unreadable titles). Confirmed working. - Switched OS Light → Dark while the Scoobe window was open → markdown content and caption buttons update live. - OS Dark: content pane, tables and titles render with the dark theme (addresses the "light pane in a dark window" report). <img width="1673" height="929" alt="Screenshot 2026-06-26 130638" src="https://github.com/user-attachments/assets/1db7fb37-f5ee-485b-863e-fc1ba0d13f6f" /> _OS is in Light Mode, while the app settings are set to Dark mode_ Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
3bf682048e | Grab and Move: square overlay corners in remote sessions (#48999) | ||
|
moooyo
|
28a9bbe8f0 |
[PowerDisplay] Add configurable mouse wheel increment for slider controls (#49002)
## Summary of the Pull Request Adds a Settings option that controls how much the PowerDisplay flyout sliders (brightness, contrast, volume) change per mouse-wheel notch. The value is chosen from a **preset dropdown** (`1, 2, 5, 10, 15, 20, 25`) and defaults to **5**, preserving today's behavior. Previously the per-notch step was hardcoded as `helpers:SliderExtensions.MouseWheelChange="5"` in four places in the flyout. <img width="1282" height="620" alt="image" src="https://github.com/user-attachments/assets/3b299a47-eb7b-4b53-b3dc-0540fbb25bfc" /> ## PR Checklist - [x] Closes: #48805 - [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 — _added `MouseWheelIncrementSettingsTests` to the existing `PowerDisplay.Lib.UnitTests`; passing via `vstest.console.exe`._ - [x] **Localization:** All end-user-facing strings can be localized — _new `PowerDisplay_MouseWheelIncrement.Header`/`.Description` in `en-us/Resources.resw`, surfaced via `x:Uid`._ - [ ] **Dev docs:** Added/updated — _N/A: small settings addition, no behavioral/architecture docs affected._ - [ ] **New binaries:** Added on the required places — _N/A: no new binaries or projects (the unit test was added to an existing test project)._ - [ ] [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:** _N/A._ ## Detailed Description of the Pull Request / Additional comments A single `int MouseWheelIncrement` is added to `PowerDisplayProperties` and persisted to `settings.json` under `mouse_wheel_increment`; it is edited in the Settings UI and read by the flyout app. The value applies uniformly to all four flyout sliders. **Data model** — `src/settings-ui/Settings.UI.Library/PowerDisplayProperties.cs` - `MouseWheelIncrement` (`int`, `[JsonPropertyName("mouse_wheel_increment")]`, default `5` set in the constructor, mirroring `MonitorRefreshDelay`). Old `settings.json` without the key deserializes to `5` (no migration). The whole type is already registered with the source-generated JSON contexts, so the new property serializes on both the Settings and flyout sides with no context change. **Settings UI (write side)** — `src/settings-ui/Settings.UI/...` - `PowerDisplayViewModel`: `MouseWheelIncrement` (get/set via `SetSettingsProperty`, calls `SignalSettingsUpdated()` so an open flyout updates live) and `MouseWheelIncrementOptions` = `{ 1, 2, 5, 10, 15, 20, 25 }`. - `PowerDisplayPage.xaml`: a `ComboBox` `SettingsCard` in the flyout-settings expander, immediately after "Monitor refresh delay", matching that card's markup. - `Strings/en-us/Resources.resw`: `Mouse wheel increment` + description. **Flyout (read side)** — `src/modules/powerdisplay/PowerDisplay/...` - `MainViewModel`: `[ObservableProperty] int MouseWheelIncrement` (default 5), loaded from settings in `LoadUIDisplaySettings()` (runs at startup and on the settings-updated IPC event, so the all-displays slider updates live). - `MonitorViewModel`: a read-only proxy `MouseWheelIncrement => _mainViewModel?.MouseWheelIncrement ?? 5` plus `RefreshMouseWheelIncrement()`, called from `ApplySettingsFromUI`'s per-monitor loop so the per-monitor sliders update live. - `MainWindow.xaml`: the four sliders' `SliderExtensions.MouseWheelChange` now bind to the setting — the all-displays slider to `ViewModel.MouseWheelIncrement`, the three per-monitor sliders (brightness/contrast/volume, inside the `MonitorViewModel` `DataTemplate`) to `MouseWheelIncrement`. ## Validation Steps Performed **Automated** - Unit tests (`PowerDisplay.Lib.UnitTests/MouseWheelIncrementSettingsTests.cs`), run via `vstest.console.exe` — passing: - default value is `5`; - legacy `settings.json` missing the key deserializes to `5` (no migration); - round-trip preserves a non-default value; - serialization emits the `mouse_wheel_increment` snake_case key. - `PowerToys.Settings` and the PowerDisplay flyout app both compile clean (the XAML compiler validates the new `x:Bind` bindings). - Confirmed the property flows through the source-generated JSON contexts (whole-type `[JsonSerializable(typeof(PowerDisplaySettings))]`) on both the Settings and flyout sides. **Pending (manual, on-device — reason this PR is a draft)** - [ ] Settings: the dropdown shows `5` on a fresh profile; changing it writes the new `mouse_wheel_increment` value to `settings.json`. - [ ] Flyout: scrolling each slider (all-displays brightness, per-monitor brightness/contrast/volume) steps by the selected value, including live update while the flyout is open. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Niels Laute
|
536e768cac |
Extend MSIX context-menu icon sizing to the standard logo set (#48925)
## Summary Addresses #48924. Several MSIX context-menu items did not ship the full standard logo set (e.g. File Locksmith was missing the 44x44 logo), so Windows fell back to a default icon in some surfaces. This updates the MSIX assets for **File Locksmith**, **Image Resizer** and **PowerRename** to provide the full logo set: 44x44 logo, small/large/150x150 tiles, and store logo. ## PR Checklist - [x] Closes #48924 - [ ] Tested manually ## Validation Icon-asset only change; no code modified. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Copilot
|
70ff4013b9 |
Add Shortcut Guide V2 manifest spec link to copilot-instructions.md (#48967)
Adds a reference to the WinGet Manifest Keyboard Shortcuts schema spec in `.github/copilot-instructions.md` so AI agents know where to find the correct field definitions, file naming conventions, and the `+` prefix rule when creating or editing Shortcut Guide V2 manifest files. ## Summary of the Pull Request Adds a new `## Shortcut Guide V2 Manifests` section to `.github/copilot-instructions.md` linking to [`doc/specs/WinGet Manifest Keyboard Shortcuts schema.md`](../doc/specs/WinGet%20Manifest%20Keyboard%20Shortcuts%20schema.md). This ensures agents authoring new manifest files follow the correct schema and naming scheme (e.g., `<PackageId>.<locale>.yml`, `+` prefix for apps without a WinGet package). ## PR Checklist - [ ] **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 `.github/copilot-instructions.md` gains a dedicated section: ```markdown ## Shortcut Guide V2 Manifests When creating or editing Shortcut Guide keyboard shortcut manifest files, follow the schema and naming conventions in the spec: - [WinGet Manifest Keyboard Shortcuts schema](<../doc/specs/WinGet Manifest Keyboard Shortcuts schema.md>) – manifest file format, field definitions, file naming, and the `+` prefix convention for apps without a WinGet package ``` No production code changes. ## Validation Steps Performed - Verified the relative link resolves to the correct spec file in the repository. - Confirmed the section is correctly placed before "Detailed Documentation". --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
ABHIJEET KALE
|
7a04d4c270 |
[ShortcutGuide] Add DaVinci Resolve keyboard shortcut manifest (#48651) (#48652)
Adds a shortcut manifest for DaVinci Resolve (professional video editing and color grading application by Blackmagic Design) so it appears in the Shortcut Guide overlay when the app is focused. The manifest contains 88 of the most commonly used DaVinci Resolve keyboard shortcuts organized into 8 categories: | Section | Shortcuts | Highlights | |---------|-----------|------------| | Popular shortcuts | 25 | Page navigation (F5-F8), Playback (JKL, Space), Edit basics (Cut, Blade, Ripple Delete) | | Timeline navigation | 13 | Frame/clip/track navigation, zoom, edit point jumping | | Edit | 14 | Cut/Copy/Paste/Duplicate, Render in Place, Compound Clip | | Color | 17 | Node management (Alt+S/P/L), viewer modes (1-5), Grade/Keyframe | | Fairlight | 8 | Mute/Solo/Record/Automation, Bounce Mix | | Fusion | 8 | View switching (1-4), Merge, Keyframe | | Media | 8 | Import, Smart Bin, Reveal in Explorer, Rename | | Deliver | 5 | Render Queue, Start Render, Output settings | The manifest follows the same YAML schema as existing manifests. No code changes needed -- manifests are auto-discovered at startup. |
||
|
Michael Jolley
|
8c434cd6f4 |
CmdPal: Fix LayoutCycleException in gallery screenshot strip (#48090)
## Summary Extension Gallery detail pages crash with `LayoutCycleException` / `AG_E_LAYOUT_CYCLE` when scrolling the screenshot strip horizontally on extensions that have many screenshots. ## Root Cause The screenshot `ItemsView` uses a horizontal `StackLayout` and is placed in a Grid row with `Height="Auto"`, inside a vertical `ScrollViewer`. The `ItemsView` itself contains an internal `ScrollView` for horizontal scrolling. When screenshots load asynchronously (`BitmapImage` decode completes), this triggers a layout feedback loop: 1. Image decodes → `ItemContainer` re-measures 2. Auto-height Grid row re-measures, offering `ItemsView` new available height 3. `ItemsView`'s internal `ScrollView` recalculates extents 4. Parent Grid row invalidates → outer `ScrollViewer` re-layouts → re-measures children → back to step 1 ## Fix Two XAML-only changes to `ExtensionGalleryItemPage.xaml`: 1. **Fixed Grid row height**: Changed the screenshot strip row from `Height="Auto"` to `Height="232"` (200px image + 16px top/bottom padding). The parent no longer queries `ItemsView` for desired height, breaking the cycle. 2. **Fixed item width**: Added `Width="356"` to the screenshot `Border` template (16:9 ratio: 200 × 16/9 ≈ 356). Provides a stable size before async image decode, preventing re-measure triggers. Fixes #47901 Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
ScymicX
|
d983dbc285 |
Fix VS Code workspace UNC paths (#48922)
## Summary of the Pull Request Fixes #47719 VS Code stores recently opened workspaces as URIs. A workspace on a Windows network share can be stored as `file://server/share/workspace.code-workspace`. The VS Code Workspaces plugin interpreted the server part of that URI as a VS Code remote authority. Because it was not a recognized remote authority, valid UNC workspaces were discarded. This change recognizes file URIs with a server authority as local UNC paths and converts them to the Windows UNC format: `\\server\share\...`. ## PR Checklist * [x] Closes #47719 * [x] **Communication:** This implementation follows the suggested direction in the issue discussion. * [ ] **Tests:** No automated regression test added. * [x] **Localization:** No user-facing strings were changed. * [x] **New binaries:** No binaries were added. * [x] **Documentation updated:** No documentation changes are required. ## Validation Steps Performed * Built the full PowerToys solution locally in `Release | x64` with 0 errors. * Started the locally built PowerToys instance. * Verified that the VS Code Workspaces plugin finds local workspaces. * Verified that UNC workspaces using both a hostname and an IP address appear in PowerToys Run. * Opened a UNC workspace successfully from PowerToys Run. |
||
|
Niels Laute
|
fb6843b0f1 |
Refactor transparent overlay into TransparentWindow + TransientSurface (#48915)
## Summary Refactors the reusable transparent-overlay infrastructure in `src/common/Common.UI.Controls/` into a clean separation between a pure host window and a self-animating acrylic surface. ### What changed - **`TransparentWindow`** is now animation-agnostic. It raises `Showing` / `Hiding` events; `Hiding` exposes a deferral so the HWND stays visible until the surface's out-animation finishes. - **`TransientSurface`** (renamed from `TransparentCard`) is a self-animating "pseudo-window" content control. It owns all chrome — `ThemeShadow`, always-active desktop acrylic, 1px border, rounded corners — and its own show/hide slide animations. - `SlideFrom` (`None`/`Left`/`Top`/`Right`/`Bottom`) selects the slide edge. `None` is the default and plays **no animation at all** (instant show/hide). - `AcrylicKind` (new) is exposed and bound to the backdrop via `TemplateBinding`, defaulting to **thin acrylic**. Consumers can override to `Default`/`Base`. - **`AlwaysActiveDesktopAcrylicBackdrop`** gains a matching `Kind` dependency property. - **CmdPal `ToastWindow`** is migrated to the new pattern as the proving consumer (`Surface.SubscribeTo(this)`). ### Coordination model A module declares a `<TransientSurface>` as the window's content and calls `SubscribeTo(window)` once. The window raises `Showing`/`Hiding`; the surface animates itself in/out and uses the `Hiding` deferral to keep the window alive until the out-animation completes. ## Testing - `Common.UI.Controls` builds clean (x64 Debug, exit 0). - `Microsoft.CmdPal.UI` builds clean (x64 Debug, exit 0). - ToastWindow keeps its slide-up animation (`SlideFrom="Bottom"`). https://github.com/user-attachments/assets/a06b0f1a-740a-4fcd-bba8-6f7a64ed261b --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Clint Rutkas
|
6dd1ce5dd1 |
Dev/crutkas/ripple v2.1 + spelling allow-list follow-up (#48232)
## Summary of the Pull Request Adds a follow-up metadata fix to the existing Mouse Highlighter ripple v2.1 work by allowing the term `xhair` in repo spell-check configuration. ## PR Checklist - [ ] **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 - Added `xhair` to `.github/actions/spell-check/expect.txt`. - This addresses spelling feedback on MouseHighlighter ripple/crosshair code without changing runtime behavior. - No functional changes to Mouse Highlighter logic were made in this follow-up commit. ## Validation Steps Performed - Verified the only content change is the new `xhair` entry in spell-check expected words. - Ran secret scanning on changed file (`.github/actions/spell-check/expect.txt`) with no findings. - Ran parallel validation: - Code Review: no issues. - CodeQL: skipped as trivial metadata-only change. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> |
||
|
Michael Jolley
|
9ea30ec523 |
CmdPal: Fix fallback results showing when disabled in Command Palette (#48777)
Fallback results were showing in Command Palette search results even when the user had disabled them in settings. When a fallback command is disabled (e.g., VS Code for Command Palette with `IsEnabled = false`), it is excluded from `configuredGlobalFallbackIds` (which only contains enabled + global fallbacks). However, during search filtering, all fallbacks NOT in `configuredGlobalFallbackIds` were unconditionally added to `commonFallbacks`, which gets scored and displayed in results. This means disabled fallbacks still appeared. To fix, I added an `IsEnabled` check when building the `commonFallbacks` list in `MainListPage.cs`. Disabled fallback commands are now properly excluded from search results. Fixes #48504 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Michael Jolley
|
1d11b732b7 |
[CmdPal] Fix memory leak in PerformanceWidgetsPage network band items (#48880)
## Summary
Fixes a memory leak in the Performance Monitor dock extension where
`GetItems()` created **new** `ListItem` instances for `_networkUpItem`
and `_networkDownItem` on every call.
## Problem
When the dock subscribes to `ItemsChanged` and calls `GetItems()` to
refresh, the band page path allocates 2 new `ListItem` objects each time
— the old ones are replaced in the fields but never collected (they
remain referenced by the `DockItemViewModel` wrappers until the next
refresh cycle). Under normal operation this leaks ~2 objects/second
indefinitely.
## Fix
Move `_networkUpItem`/`_networkDownItem` creation into the constructor
(matching the pattern used by CPU, Memory, GPU, and Battery items).
`GetItems()` now returns stable references. The `Updated` event handler
already updates their `.Title` properties, which propagates to the UI
via `PropChanged` → `CommandItemViewModel.Model_PropChanged`.
## Validation
- Build succeeds (`Microsoft.CmdPal.Ext.PerformanceMonitor.csproj`)
- Network up/down band items still receive title updates via the
existing `Updated` handler
- No `RaiseItemsChanged()` needed — `ListItem.Title` setter fires
`PropChanged`, which `DockItemViewModel` already observes
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit
v0.100.2
|
||
|
Mike Griese
|
ab4792a4b8 |
Revert "[CmdPal][Dock] Fix performance meter showing '???' after restart" (#48835)
Reverts microsoft/PowerToys#48682
I'm quite sure that OP did not build or test these changes, and they
should not have merged.
(cherry picked from commit
|
||
|
Niels Laute
|
c777fcc1e4 |
Fix CmdPal gallery crash when extension has no homepage (#48869)
## Summary
Selecting an extension in the CmdPal Extension Gallery crashed the app
when that extension had **no `homepage`** defined.
## Root cause
In `ExtensionGalleryItemPage.xaml`, the "View repository"
`HyperlinkButton` bound its `NavigateUri` (a `System.Uri`) directly to
the raw string property `ViewModel.Homepage`:
```xml
NavigateUri="{x:Bind ViewModel.Homepage, Mode=OneWay}"
```
`x:Bind` evaluates **all** bindings on an element regardless of
`Visibility`, and to assign a `string` to a `Uri` target it generates a
`new Uri(value)` conversion. When `homepage` is undefined, `Homepage` is
`null`, so the binding executes `new Uri(null)` →
`ArgumentNullException` → the page crashes on load. The
`Visibility="{... HasHomepage}"` collapse did not help because the
`NavigateUri` binding still runs.
Every other `NavigateUri` x:Bind in the codebase (`Link`, `LinkUri`) is
already bound to a `Uri?`, so the homepage hyperlink was the lone
offender.
## Fix
- **`ExtensionGalleryItemViewModel.cs`** — Added a validated `Uri?
HomepageUri` property backed by the existing `_homepageHttpUri` (already
`null` for missing or non-web homepages).
- **`ExtensionGalleryItemPage.xaml`** — Bound `NavigateUri` to
`ViewModel.HomepageUri` instead of the raw string. `null` is valid for
`NavigateUri`, so no conversion occurs. The tooltip still shows the
`Homepage` string.
- **Tests** — Added coverage asserting `HomepageUri` is set for a web
homepage and `null` when missing.
## Verification
- `Microsoft.CmdPal.UI.ViewModels`, `Microsoft.CmdPal.UI` (XAML
compile), and the unit test project all built cleanly (x64/Release, exit
code 0).
- All 24 `ExtensionGalleryItemViewModelTests` pass, including the two
new cases.
- Manually verified in VS that opening an extension without a homepage
no longer crashes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
https://github.com/user-attachments/assets/b268bafb-6bee-4862-9fbf-7a0e06675e36
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
||
|
Michael Jolley
|
28e078897a |
[CmdPal] Fix memory leak in PerformanceWidgetsPage network band items (#48880)
## Summary Fixes a memory leak in the Performance Monitor dock extension where `GetItems()` created **new** `ListItem` instances for `_networkUpItem` and `_networkDownItem` on every call. ## Problem When the dock subscribes to `ItemsChanged` and calls `GetItems()` to refresh, the band page path allocates 2 new `ListItem` objects each time — the old ones are replaced in the fields but never collected (they remain referenced by the `DockItemViewModel` wrappers until the next refresh cycle). Under normal operation this leaks ~2 objects/second indefinitely. ## Fix Move `_networkUpItem`/`_networkDownItem` creation into the constructor (matching the pattern used by CPU, Memory, GPU, and Battery items). `GetItems()` now returns stable references. The `Updated` event handler already updates their `.Title` properties, which propagates to the UI via `PropChanged` → `CommandItemViewModel.Model_PropChanged`. ## Validation - Build succeeds (`Microsoft.CmdPal.Ext.PerformanceMonitor.csproj`) - Network up/down band items still receive title updates via the existing `Updated` handler - No `RaiseItemsChanged()` needed — `ListItem.Title` setter fires `PropChanged`, which `DockItemViewModel` already observes --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Michael Jolley
|
64f1243bdf |
Skip auto-labeling PRs that already have labels (#48877)
## Summary The auto-labeler workflow now skips pull requests that already have labels applied before running the AI classification. This avoids overwriting or duplicating labels that were manually set by contributors or maintainers. ## Changes - Added a check in `labelIssue()` that returns early for PRs with existing labels, logging which labels are already present. - Issues continue to be labeled regardless (only PRs get the skip logic). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Mario Hewardt
|
e1074bc835 |
ZoomIt - Update notices (#48843)
<!-- 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 Update notices for ZoomIt dependency <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [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 - [ ] **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 |