Simplifies monitor metadata by removing Manufacturer and ConnectionType properties and related extraction logic. Refactors WMI controller to always instantiate, relying on monitor discovery for support. Updates model property summaries for clarity, adjusts LightSwitchListener log prefix, and removes Manufacturer from MonitorViewModel. Streamlines code and improves documentation consistency.
Move brightness setup from MonitorDiscoveryHelper to DdcCiController to avoid slow I2C operations during monitor discovery. Set default brightness to 50 and update after discovery. Remove unused brightness methods and type aliases. Update comments to clarify initialization responsibilities.
Removed obsolete helper methods and the MonitorFeatureHelper class, streamlining monitor feature parsing and value conversion logic. Cleaned up thread-safe dictionary utilities by dropping rarely used methods. Updated application icon path in project file. Documentation comments were clarified for consistency.
Eliminated the GetPhysicalHandle method, which handled monitor handle lookup by Id or direct handle. This refactors PhysicalMonitorHandleManager to no longer provide handle retrieval logic.
Replaced BrightnessInfo with generic VcpFeatureValue struct to represent any VCP feature (brightness, color temp, input source, etc.). Updated IMonitorController and all controller implementations to use VcpFeatureValue for relevant methods. Simplified and unified VCP set/get logic, removed redundant validation and obsolete DdcCiNative methods, and updated helper classes accordingly. Improved code clarity and maintainability by generalizing VCP feature handling throughout the codebase.
Refactored MonitorManager to use dedicated controller fields for
O(1) lookup based on CommunicationMethod, replacing the async
GetControllerForMonitorAsync with a synchronous method. Removed
CanControlMonitorAsync from IMonitorController and all
implementations, simplifying the interface and controller logic.
Updated controller discovery and disposal logic accordingly.
Improved performance and maintainability by eliminating
unnecessary async checks and streamlining controller management.
Updated PowerDisplay.wxs to use WiX Toolset v4 schema URLs for compatibility. Added PowerDisplay.wxs to build and file restoration steps in PowerToysInstallerVNext.wixproj, ensuring it is included and managed in the installer package.
Relocated the Twinkle Tray license and attribution from after the NuGet packages list to a new "Utility: PowerDisplay" section in NOTICE.md, aligning it with the format used for other utilities. No changes were made to the content of the notice.
Refactor monitor discovery and rotation logic to use the GdiDeviceName property for accurate display targeting, especially in multi-monitor setups. Update the Monitor model to include GdiDeviceName, adjust DisplayRotationService and MonitorManager to use it, and enhance logging for better traceability. Also, unify hardware property application in MonitorViewModel to reduce code duplication. These changes increase reliability and maintainability of monitor control operations.
Refactor monitor matching and persistence to use a single, stable Id (format: "{Source}_{EdidId}_{MonitorNumber}") across all components. Remove HardwareId and DeviceKey properties from Monitor, update ProfileMonitorSetting to use MonitorId, and simplify MonitorMatchingHelper logic. Update DDC/CI, WMI, ViewModels, Settings UI, and unit tests to rely on Id for all lookups, state management, and handle mapping. Improves reliability for multi-monitor setups and simplifies codebase by removing legacy fallback logic.
Simplify MainViewModel by removing legacy HardwareId matching and the ApplyColorTemperatureAsync method. Update ApplyProfileAsync to accept only monitor settings and match monitors by InternalName. Improve documentation in ThemeChangedEventArgs and ProfileService for clarity. Streamline method signatures and remove outdated compatibility code.
Refactored IdentifyMonitors to use Windows API for mapping display areas to monitor numbers via HMONITOR and GDI device names. This ensures correct monitor numbering in identify windows, especially in complex setups. Added detailed logging and only counts successfully created windows.
Eliminates the UI and backend logic for synchronizing all monitor brightness levels. Refactors monitor list update logic to distinguish between initial load and refresh, introducing RestoreMonitorSettings for startup state restoration. Streamlines feature visibility application and settings handling for improved maintainability.
Simplifies color temperature initialization by moving it from async handling in MainViewModel to synchronous initialization during monitor enumeration in DdcCiController. Removes related async methods and UI update logic, reducing complexity and ensuring color temperature values are available immediately after enumeration.
Move all monitor initialization (capabilities, input source) into the controller discovery phase, eliminating redundant async initialization steps from MonitorManager. Remove obsolete initialization methods from MonitorManager. Add helper methods in DdcCiController for capability and input source setup. Improve logging for monitor capabilities. This streamlines monitor setup, reduces redundant work, and improves performance.
Refactor GetUserFriendlyName to use UserFriendlyNameLength for accurate string extraction from the WMI UserFriendlyName buffer. This ensures only valid characters are included, improving reliability when parsing monitor names.
Refactored DiscoverMonitorsAsync in DdcCiController to remove Task.Run and simplify async flow and error handling. Updated XML doc for Name property in IMonitorController to clarify its purpose.
Refactor monitor enumeration to use GDI device name and device path for accurate matching with Windows display config data. Expand MonitorDisplayInfo with new fields, add native interop for source device names, and enhance robustness for multi-monitor and mirror mode setups. Improve logging and remove index-based matching.
Switch monitor discovery from EnumDisplayDevices to QueryDisplayConfig for stable identification using hardware ID and monitor number. Simplify CandidateMonitor structure and remove DisplayDeviceInfo and related matching logic. Update device key format to "{HardwareId}_{MonitorNumber}" for improved handle management. Rewrite CreateMonitorFromPhysical to use MonitorDisplayInfo directly. Update documentation and remove obsolete helpers for better reliability and maintainability.
- Split monitor discovery into three clear phases for readability and performance
- Introduce CandidateMonitor record for better data handling
- Fetch DDC/CI capabilities in parallel to speed up enumeration
- Filter out NULL physical monitor handles and retry up to 3 times
- Refactor color temperature and input source access to use generic VCP feature methods
- Add discrete VCP value validation for safer set operations
- Move input source verification to a dedicated method
- Improve error handling and logging throughout
- Remove obsolete tuple code and update documentation for maintainability
StatusText property and all related UI updates have been removed
from MainViewModel and MainWindow. Status and error messages are
now logged via Logger instead of being shown in the UI. This
simplifies the ViewModel and centralizes error reporting. Only
IsScanning and IsLoading remain for UI state indication.
- Replace custom error UI with Logger.LogError for exceptions
- Remove acrylic backdrop; use semi-transparent black background
- Scale IdentifyWindow size for DPI using GetDpiForWindow
- Remove ValueChanged handlers from sliders; use PointerCaptureLost
- Delete unused event handlers and clean up using directives
- Simplify input source switching logic in MainWindow
Updated PowerDisplayPage, DashboardViewModel, and LightSwitchViewModel to use the SettingsUtils.Default singleton instance instead of creating new SettingsUtils objects. This change ensures consistent settings utility usage and improves resource management.
Expanded keyword lists in expect.txt for DBLCLKS, edid, MBR, MSIXCA, PATCOPY, and VERBW sections to include new identifiers and terminology. No removals; changes support new features and components.
Replaces IntPtr with nint for window handles and native API calls in WindowHelper, removing 32/64-bit conditional logic. Cleans up unused minimize/restore methods. Updates TrayIconService constructor usage in App.xaml.cs.
Deleted obsolete PNG asset. Added Microsoft.WindowsDesktop.App as a framework reference in the project file to ensure consistent Microsoft.VisualBasic.dll versioning across WinUI3 apps, without enabling WPF or WinForms. No changes to log file exclusions or App.xaml handling.
<!-- 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
Adds a new command-line interface (CLI) tool for FancyZones, enabling
users and automation scripts to manage window layouts without the GUI.
**Commands:**
| Command | Aliases | Description |
|---------|---------|-------------|
| `help` | | Displays general help information for all commands |
| `open-editor` | `editor`, `e` | Launch FancyZones layout editor |
| `get-monitors` | `monitors`, `m` | List all monitors and their
properties |
| `get-layouts` | `layouts`, `ls` | List all available layouts with
ASCII art preview |
| `get-active-layout` | `active`, `a` | Show currently active layout |
| `set-layout <uuid>` | `set`, `s` | Apply layout by UUID or template
name |
| `open-settings` | `settings` | Open FancyZones settings page |
| `get-hotkeys` | `hotkeys`, `hk` | List all layout hotkeys |
| `set-hotkey <key> <uuid>` | `shk` | Assign hotkey (0-9) to custom
layout |
| `remove-hotkey <key>` | `rhk` | Remove hotkey assignment |
**Key Capabilities:**
- ASCII art visualization of layouts (grid, focus, priority-grid,
canvas)
- Support for both template layouts and custom layouts
- Monitor-specific layout targeting (`--monitor N` or `--all`)
- Real-time notification to FancyZones via Windows messages
- Native AOT compilation support for fast startup
### Example Usage
```bash
# List all layouts with visual previews
FancyZonesCLI.exe ls
# Apply "columns" template to all monitors
FancyZonesCLI.exe s columns --all
# Set custom layout on monitor 2
FancyZonesCLI.exe s {uuid} --monitor 2
# Assign hotkey Win+Ctrl+Alt+3 to a layout
FancyZonesCLI.exe shk 3 {uuid}
```
https://github.com/user-attachments/assets/2b141399-a4ca-4f64-8750-f123b7e0fea7
<!-- 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
## Summary of the Pull Request
This PR replaces the current LINQ-based results compilation query of
combining, sorting and filtering the four result sources with a 3-way
merge operation plus a final append. It provides a performance increase
as well as a significant reduction in allocations.
<!-- 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
- [x] **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 existing code:
1. Limits the number of apps returned to a pre-defined maximum.
2. Sorts the apps list.
3. Appends filtered items, scored fallback items and the apps list
together.
4. Sorts the three lists based on their score.
5. Appends the non-scored fallback items, with empty items excluded.
6. Selects just the `Item` from each.
7. Creates an array from the enumerable.
```csharp
if (_filteredApps?.Count > 0)
{
limitedApps = _filteredApps.OrderByDescending(s => s.Score).Take(_appResultLimit).ToList();
}
var items = Enumerable.Empty<Scored<IListItem>>()
.Concat(_filteredItems is not null ? _filteredItems : [])
.Concat(_scoredFallbackItems is not null ? _scoredFallbackItems : [])
.Concat(limitedApps)
.OrderByDescending(o => o.Score)
// Add fallback items post-sort so they are always at the end of the list
// and eventually ordered based on user preference
.Concat(_fallbackItems is not null ? _fallbackItems.Where(w => !string.IsNullOrEmpty(w.Item.Title)) : [])
.Select(s => s.Item)
.ToArray();
```
We can exploit the fact that each of the three 'scored' lists are
pre-ordered, and replace the query with a 3-way merge and final append
of the non-scored fallback items.
By pre-sizing the results array we can avoid all the extra allocations
of the LINQ-based solution.
### Proof of pre-ordering
In `UpdateSearchText`, each of the lists is defined by calling
`ListHelpers.FilterListWithScores`:
```csharp
// Produce a list of everything that matches the current filter.
_filteredItems = [.. ListHelpers.FilterListWithScores<IListItem>(newFilteredItems ?? [], SearchText, scoreItem)];
```
```csharp
_scoredFallbackItems = ListHelpers.FilterListWithScores<IListItem>(newFallbacksForScoring ?? [], SearchText, scoreItem);
```
```csharp
var scoredApps = ListHelpers.FilterListWithScores<IListItem>(newApps, SearchText, scoreItem);
...
_filteredApps = [.. scoredApps];
```
In `FilterListWithScores`, the results are ordered by score:
```csharp
var scores = items
.Select(li => new Scored<T>() { Item = li, Score = scoreFunction(query, li) })
.Where(score => score.Score > 0)
.OrderByDescending(score => score.Score);
```
(This also makes the existing `OrderByDescending()` for `_filteredApps`
before the LINQ query redundant.)
### K-way merge
Since the results are pre-sorted, we can do a direct merge in linear
time. This is what the new `MainListPageResultFactory`'s `Create`
achieves. As the lists may be different sizes, the routine does a 3-way
merge, followed by a 2-way merge and a single list drain to finish. Each
element is only visited once.
### Benchmarks
A separate benchmark project is
[here](https://github.com/daverayment/MainListBench), written with
Benchmark.net.
The project compares the current LINQ-based solution against:
1. An Array-based algorithm which pre-assigns a results array and still
sorts the 3 scored sets of results. This shows a naive non-LINQ solution
which is still _O(n log n)_ because of the sort.
2. The k-way merge, which is described above. _O(n)_ for both time and
space complexity.
3. A heap merge algorithm, which uses a priority queue instead of
tracking each of the lists separately. (This is _O(n log k)_ in terms of
time complexity and _O(n + k)_ for space.)
Care is taken to ensure stable sorting of items. When preparing the
benchmark data, items with identical scores are assigned to confirm each
algorithm performs identically to the LINQ `OrderBy` approach, which
performs a stable sort.
Results show that the merge performs best in terms of both runtime
performance and allocations, sometimes by a significant margin. Compared
to the LINQ approach, merge runs 400%+ faster and with at most ~20% of
the allocations:
<img width="1135" height="556" alt="image"
src="https://github.com/user-attachments/assets/9f9d3932-1592-49d6-8a07-4ea3ba7a0cc5"
/>
<img width="1149" height="553" alt="image"
src="https://github.com/user-attachments/assets/ae9e9e0a-b255-4c1a-af4b-e791dea80fa4"
/>
See here for all charts and raw stats from the run:
https://docs.google.com/spreadsheets/d/1y2mmWe8dfpbLxF_eqPbEGvaItmqp6HLfSp-rw99hzWg/edit?usp=sharing
### Cons
1. Existing performance is not currently an issue. This could be seen as
a premature optimisation.
2. The new code introduces an inherent contract between the results
compilation routine and the lists, i.e. that they must be sorted.
This PR was really for research and learning more about CmdPal (and a
bit of algorithm practice because it's Advent of Code time), so please
feel free to reject if you feel the cons outweigh the pros.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Added unit tests to exercise the new code, which confirm that the
specific ordering is preserved, and the filtering and pre-trimming of
the apps list is performed as before.
- Existing non-UI unit tests run. NB: I _could not_ run any UI Tests on
my system and just got an early bail-out each time.
- Manual testing in (non-AOT) Release mode.
<!-- 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: #41939
<!-- - [ ] 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
Before
After
I noticed the double "active" line around the items when the ListPage is
focused. I was unable to find where that is defined. Ideally, the
black-border would go away.
I tested with AOT turned on.
The behavior accounts for suggestions. If the SearchBar is focused and
there is a suggestion, right-arrow will [continue] to complete the
suggestion.
<!-- 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 pull request updates several dependencies to newer versions in the
`Directory.Packages.props` file. The main focus is on upgrading the
Microsoft Windows App SDK packages to ensure the project uses the latest
features and bug fixes.
Dependency version updates:
* Upgraded `Microsoft.WindowsAppSDK`,
`Microsoft.WindowsAppSDK.Foundation`, `Microsoft.WindowsAppSDK.AI`, and
`Microsoft.WindowsAppSDK.Runtime` to their latest respective versions,
replacing previous 1.8.25* releases with newer builds.
<!-- Please review the items on the PR checklist before submitting-->
Refactor VCP code handling and improve immutability
Refactored `WaitForColorTempAndSaveAsync` to use `IReadOnlyList<Task>` for improved immutability. Removed the `GetMonitorViewModel` method from `MainViewModel.Monitors.cs`.
Simplified VCP code handling in `MainViewModel.Settings.cs` by inlining the logic of `BuildVcpCodesList` and `BuildFormattedVcpCodesList` into the object initialization for `monitorInfo`. This reduces redundancy and improves code readability and maintainability.
Refactored `DisplayChangeWatcher` to enhance thread safety by
introducing `_initialEnumerationComplete` and ensuring state
changes and event handling are dispatched to the UI thread.
Removed `MonitorListChangedEventArgs` and the `MonitorsChanged`
event from `MonitorManager`, simplifying monitor management
logic. Updated `MainViewModel` to remove its dependency on
`MonitorsChanged`.
Cleaned up `TrayIconService` by removing unused `_showWindowAction`
and simplifying resource fallback logic. Fixed minor wording
inconsistencies in XML documentation.
These changes improve maintainability, thread safety, and
performance.
The `DisplayChangeWatcher` class is now a partial class, enabling its definition to be split across multiple files. Added two private fields: `_dispatcherQueue` for managing thread-safe operations and `_debounceDelay` for debouncing with a 1-second delay. Updated the `DeviceWatcher` field to use nullable reference types (`DeviceWatcher?`).
Replaced the custom RelayCommand implementation with the
[RelayCommand] attribute from the CommunityToolkit.Mvvm library
to simplify command creation and reduce boilerplate code.
- Removed RelayCommand and RelayCommand<T> classes.
- Added CommunityToolkit.Mvvm package to the project.
- Updated MainViewModel and MonitorViewModel to use
[RelayCommand] for command generation.
- Cleaned up unused imports related to the removed RelayCommand.
This change improves maintainability and aligns the project
with modern MVVM practices.
Refactored `SettingsUtils` initialization across multiple files
(`App.xaml.cs`, `MainWindow.xaml.cs`, `MainViewModel.cs`) to use
`SettingsUtils.Default` instead of creating new instances. This
improves consistency, reduces redundancy, and promotes better
resource management.
Updated the project ID for `PowerDisplayModuleInterface.vcxproj`
in `PowerToys.slnx` to reflect a configuration or structural
change in the project setup.
<!-- 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
The old implementation checked
`HKLM\Software\Classes\powertoys\InstallScope` first. If this key
existed (even as a remnant from incomplete uninstall), it would
immediately return `PerMachine` without validating the actual
installation.
### Fix
- Uses Windows standard Uninstall registry (most reliable source of
truth)
- Identifies PowerToys Bundle by exact `BundleUpgradeCode` GUID match
- MSI component entries (always in HKLM) are automatically ignored since
they don't have `BundleUpgradeCode`
- Checks HKCU first, then HKLM, properly handling the fact that Bundle
location reflects true install scope
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #43696
<!-- - [ ] 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
<!-- 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
SettingsUtils is initialized multiple times over the whole solution.
This creates one singeltone instance (with the default settings), so it
only has to be initialized once (and improve performance a bit with
that)
<!-- 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
<!-- 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 ToolGood.Words.Pinyin package to support pinyin conversion
- Implement pinyin matching in StringMatcher class
- Update project dependencies and Directory.Packages.props
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #38417#39343
- [ ] **Communication:** I've discussed this with core contributors
already. If 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
I've completed a rough implementation of pinyin support, but since I'm
currently unsure where to add the toggle for pinyin support, this
feature is enabled by default for now.
https://github.com/user-attachments/assets/59df0180-05ad-4b4a-a858-29aa15e40fd2
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Signed-off-by: 舰队的偶像-岛风酱! <frg2089@outlook.com>
Co-authored-by: Yu Leng <yuleng@microsoft.com>
## Summary of the Pull Request
This pull request updates the build system for several native and
managed projects, modernizing NuGet package management and improving
code analysis configuration. The main changes involve switching from
legacy `packages.config` and manual `.props`/`.targets` imports to
PackageReference style for native projects, updating package versions,
and streamlining code analysis settings.
**Build system modernization and package management:**
* Migrated native projects (`PowerToys.MeasureToolCore.vcxproj`,
`FindMyMouse.vcxproj`) from legacy `packages.config` and manual
`.props`/`.targets` imports to NuGet PackageReference style, simplifying
dependency management and build configuration. This includes removing
the `packages.config` file and related import/error logic, and
introducing `PackageReference` items for required packages.
[[1]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL3-R18)
[[2]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aR41-L41)
[[3]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL145-R153)
[[4]](diffhunk://#diff-d3a7d80ebbca915b42727633451e769ed2306b418ef3d82b3b04fd5f79560f17L1-L17)
[[5]](diffhunk://#diff-0f27869c4e90c8fd2c81f5688c58da99afcc9e5767e69ef7938265dbb6928e0fL3-R13)
* Updated the centralized package versions in
`Directory.Packages.props`, adding new entries for `boost`,
`boost_regex-vc143`, `Microsoft.Windows.ImplementationLibrary`, and
`Microsoft.WindowsAppSDK.Foundation` to support the new build system and
dependencies.
[[1]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156R10-R11)
[[2]](diffhunk://#diff-5baf5f9e448ad54ab25a091adee0da05d4d228481c9200518fcb1b53a65d4156R74-R77)
**Code analysis improvements:**
* Added configuration to both native and managed projects
(`PowerToys.MeasureToolCore.vcxproj`, `MeasureToolUI.csproj`) to
suppress specific warnings (81010002) and exclude NuGet cache files from
code analysis, reducing noise and improving build performance.
[[1]](diffhunk://#diff-76320b3a74a9241df46edb536ba0f817d7150ddf76bb0fe677e2b276f8bae95aL3-R18)
[[2]](diffhunk://#diff-4f2b49a1a5cc7da36ee6d5044792ef681fd0ea5bea12db9ebd4c3090680d4b07R6-R11)
**Project reference and output handling:**
* Updated the managed project (`MeasureToolUI.csproj`) to handle native
project outputs more robustly, ensuring the WinMD and DLL files are
available at runtime and configuring the project reference to avoid
assembly reference issues.
**Compiler configuration:**
* Enhanced C++ compiler settings in `Cpp.Build.props` to treat
angle-bracket includes as external, disable warnings and analysis for
external headers, and optimize build performance.
## Summary of the Pull Request
This PR fixes an Image Resizer issue where **Fill** mode operations were
silently aborted when **Shrink Only** was enabled (the default) and
scale was 1.0 on one dimension, resulting in files that were renamed
according to the intended target size but which actually contained the
original, unmodified image.
This also fixes a latent bug regarding square images and the **Ignore
Orientation** setting, and improves the readability of the core
`Transform` method.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #43772
<!-- - [ ] 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
### Fix **Shrink Only** logic preventing the correct cropping of images
**Issue:**
When using **Fill** mode, the scaling factor is calculated based on the
larger dimension to ensure the image fills the target box. In scenarios
where one dimension matches the target and the other overflows (e.g.
shrinking a 100x100 pixel image to 50x100), the calculated scale factor
is `1.0`.
The previous `ShrinkOnly` logic included this:
```csharp
if (_settings.ShrinkOnly
&& _settings.SelectedSize.Unit != ResizeUnit.Percent
&& (scaleX >= 1 || scaleY >= 1))
{
return source;
}
```
This correctly prevents `ShrinkOnly` operations from returning upscaled
result images, but it also exits too early for cases where the user is
cropping the image across one dimension only, leaving the other at scale
1. Effectively, the later cropping code is never run and instead of
returning the cropped image, the original is returned. The _intended_
target dimensions are correct, which results in the filename parts not
matching the resulting image size.
**Fix:**
The logic has been split between upscaling and cropping, so:
1. If the scale on either dimension is > `1.0`, return the source
(explicitly preventing upscaling for **Shrink Only** mode).
2. If the scale is <= `1.0` then check if the original dimensions exceed
the target dimensions. If a crop is required, proceed with it even if
the scale is exactly `1.0`.
### Fix for square images triggering orientation swap
**Issue:**
The "Ignore Orientation" check in the original code used a compound
boolean check:
```csharp
(originalWidth < originalHeight != width < height)
```
This clever but less than readable statement detects orientation
mismatches. The section also includes a logic issue. When the original
image was square, `originalWidth < originalHeight` evaluated to `false`,
treating it as Landscape. If the target dimensions were Portrait, the
logic detected a mismatch and swapped the target dimensions incorrectly,
which would crop the height instead of the width.
'Fortunately' this bug was masked by the first bug, as the crop code
would never be reached anyway.
**Fix:**
The orientation detection routine was refactored to explicitly check for
Landscape vs. Portrait states. Square images are now naturally excluded,
as they have neither Landscape nor Portrait orientations. This now
prevents the dimensions from being swapped.
### Refactoring/readability
The main `Transform` method has been cleaned up:
- Replaced widespread use of `var` with `double` and `int` for dimension
and scale calculations.
- Replaced the non-obvious XOR orientation check (`a < b != c < d`) with
named booleans (`isInputLandscape`, `isTargetPortrait` etc.) to make the
intent more self-documenting.
- New and expanded comments throughout.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Three new unit tests have been added to `ResizeOperationTests.cs` to
cover the **Fill** mode edge cases:
1. `TransformHonorsFillWithShrinkOnlyWhenCropRequired`: Verifies than an
image requiring a crop but no scaling is processed correctly (tests that
the original bug report is resolved).
2. `TransformHonorsFillWithShrinkOnlyWhenUpscaleAttempted`: Confirms
that when `ShrinkOnly` is set, any upscaling operations are still
blocked.
3. `TransformHonorsFillWithShrinkOnlyWhenNoChangeRequired`: Verifies
that the system returns the source if neither scaling nor cropping is
required.
I also manually verified the bug fix with a test 4000 x 6000 pixel
source file with 1920 x `Auto` **Fill** mode and **Shrink Only**
settings, mirroring the original user's settings, and their source and
target dimensions.
<!-- 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 fixes a line break in the RDC extension toast message, replacing
unescaped \r with a new line (\r in the XML is not recognized as a new
line escape sequence).
<!-- 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
