mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-02-24 04:00:02 +01:00
<!-- 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 introduces batching for property change notifications emitted by Command Palette view models. It also adds a secondary notification path that is guaranteed to execute on a background thread. - Introduces **`BatchUpdateManager`**, which batches `INotifyPropertyChanged` events from view models and replays them in a coordinated way. - Slightly reduces UI thread contention and allows related UI updates to be applied together, reducing visual "tearing" in list items (when title, subtitle and icon are updated separately with slight delay). Batching won't mitigate all occurences, but its good enough and works auto-magically. - Adds a complementary background notification event that: - Is guaranteed to run on a background thread. - Fires before UI-thread notifications. - Allows consumers to attach handlers without blocking COM out-of-proc objects. - Updates `TopLevelViewModel` to subscribe to the background property change event instead of the UI-thread one. - This avoids unintentionally shifting work onto the UI thread and re-triggering expensive operations there. - Previously, because `TopLevelViewModel` wraps another view model and our view models raise `INPC` on the UI thread by default, its handler was executing on the UI thread and re-raising the event as `IListItem.PropertyChanged`, causing `FetchProperty` methods to run on the UI thread again. - Ideally, `TopLevelViewModel` should be reworked to address this more cleanly, but that turned out to be a non-trivial change. This PR applies a targeted mitigation in the meantime. <!-- 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
PowerToys Source Code
Code organization
The PowerToys are split into DLLs for each PowerToy module (modules folder), and an executable (runner folder) that loads and manages those DLLs.
The settings window is a separate executable, contained in settings-ui folder. It utilizes a WebView to display an HTML-based settings window.
The common contains code for a static library with helper functions, used by both the runner and the PowerToys modules.