Files
PowerToys/src/modules/cmdpal/Microsoft.CmdPal.UI.ViewModels/FallbackSettingsViewModel.cs

90 lines
3.0 KiB
C#
Raw Normal View History

CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
// Copyright (c) Microsoft Corporation
// The Microsoft Corporation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.
using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Messaging;
using Microsoft.CmdPal.UI.ViewModels.Messages;
CmdPal: Extract persistence services from SettingsModel and AppStateModel (#46312) ## Summary of the Pull Request Extracts persistence (load/save) logic from `SettingsModel` and `AppStateModel` into dedicated service classes, following the single-responsibility principle. Consumers now interact with `ISettingsService` and `IAppStateService` instead of receiving raw model objects through DI. **New services introduced:** - `IPersistenceService` / `PersistenceService` — generic `Load<T>` / `Save<T>` with AOT-compatible `JsonTypeInfo<T>`, ensures target directory exists before writing - `ISettingsService` / `SettingsService` — loads settings on construction, runs migrations, exposes `Settings` property and `SettingsChanged` event - `IAppStateService` / `AppStateService` — loads state on construction, exposes `State` property and `StateChanged` event **Key changes:** - `SettingsModel` and `AppStateModel` are now pure data models — all file I/O, migration, and directory management removed - Raw `SettingsModel` and `AppStateModel` removed from DI container; consumers receive the appropriate service - `IApplicationInfoService.ConfigDirectory` injected into services for config path resolution (no more hardcoded `Utilities.BaseSettingsPath`) - ~30 consumer files updated across `Microsoft.CmdPal.UI.ViewModels` and `Microsoft.CmdPal.UI` projects - All `#pragma warning disable SA1300` suppressions removed — convenience accessors replaced with direct `_settingsService.Settings` / `_appStateService.State` access - Namespace prefixes (`Services.ISettingsService`) replaced with proper `using` directives ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** N/A — no end-user-facing strings changed - [ ] **Dev docs:** N/A — internal refactor, no public API changes - [ ] **New binaries:** N/A — no new binaries introduced ## Detailed Description of the Pull Request / Additional comments ### Architecture Services are registered as singletons in `App.xaml.cs`: ```csharp services.AddSingleton<IPersistenceService, PersistenceService>(); services.AddSingleton<ISettingsService, SettingsService>(); services.AddSingleton<IAppStateService, AppStateService>(); ``` `PersistenceService.Save<T>` writes the serialized model directly to disk, creating the target directory if it doesn't exist. It also does not attempt to merge existing and new settings/state. `SettingsService` runs hotkey migrations on load and raises `SettingsChanged` after saves. `AppStateService` always raises `StateChanged` after saves. ### Files changed (41 files, +1169/−660) | Area | Files | What changed | |------|-------|-------------| | New services | `Services/IPersistenceService.cs`, `PersistenceService.cs`, `ISettingsService.cs`, `SettingsService.cs`, `IAppStateService.cs`, `AppStateService.cs` | New service interfaces and implementations | | Models | `SettingsModel.cs`, `AppStateModel.cs` | Stripped to pure data bags | | DI | `App.xaml.cs` | Service registration, removed raw model DI | | ViewModels | 12 files | Constructor injection of services | | UI | 10 files | Service injection replacing model access | | Settings | `DockSettings.cs` | `Colors.Transparent` replaced with struct literal to avoid WinUI3 COM dependency | | Tests | `PersistenceServiceTests.cs`, `SettingsServiceTests.cs`, `AppStateServiceTests.cs` | 38 unit tests covering all three services | | Config | `.gitignore` | Added `.squad/`, `.github/agents/` exclusions | ## Validation Steps Performed - Built `Microsoft.CmdPal.UI` with MSBuild (x64/Debug) — exit code 0, clean build - Ran 38 unit tests via `vstest.console.exe` — all passing - Verified no remaining `#pragma warning disable SA1300` blocks - Verified no remaining `Services.` namespace prefixes --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-20 18:58:27 -05:00
using Microsoft.CmdPal.UI.ViewModels.Services;
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
namespace Microsoft.CmdPal.UI.ViewModels;
public partial class FallbackSettingsViewModel : ObservableObject
{
CmdPal: Extract persistence services from SettingsModel and AppStateModel (#46312) ## Summary of the Pull Request Extracts persistence (load/save) logic from `SettingsModel` and `AppStateModel` into dedicated service classes, following the single-responsibility principle. Consumers now interact with `ISettingsService` and `IAppStateService` instead of receiving raw model objects through DI. **New services introduced:** - `IPersistenceService` / `PersistenceService` — generic `Load<T>` / `Save<T>` with AOT-compatible `JsonTypeInfo<T>`, ensures target directory exists before writing - `ISettingsService` / `SettingsService` — loads settings on construction, runs migrations, exposes `Settings` property and `SettingsChanged` event - `IAppStateService` / `AppStateService` — loads state on construction, exposes `State` property and `StateChanged` event **Key changes:** - `SettingsModel` and `AppStateModel` are now pure data models — all file I/O, migration, and directory management removed - Raw `SettingsModel` and `AppStateModel` removed from DI container; consumers receive the appropriate service - `IApplicationInfoService.ConfigDirectory` injected into services for config path resolution (no more hardcoded `Utilities.BaseSettingsPath`) - ~30 consumer files updated across `Microsoft.CmdPal.UI.ViewModels` and `Microsoft.CmdPal.UI` projects - All `#pragma warning disable SA1300` suppressions removed — convenience accessors replaced with direct `_settingsService.Settings` / `_appStateService.State` access - Namespace prefixes (`Services.ISettingsService`) replaced with proper `using` directives ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** N/A — no end-user-facing strings changed - [ ] **Dev docs:** N/A — internal refactor, no public API changes - [ ] **New binaries:** N/A — no new binaries introduced ## Detailed Description of the Pull Request / Additional comments ### Architecture Services are registered as singletons in `App.xaml.cs`: ```csharp services.AddSingleton<IPersistenceService, PersistenceService>(); services.AddSingleton<ISettingsService, SettingsService>(); services.AddSingleton<IAppStateService, AppStateService>(); ``` `PersistenceService.Save<T>` writes the serialized model directly to disk, creating the target directory if it doesn't exist. It also does not attempt to merge existing and new settings/state. `SettingsService` runs hotkey migrations on load and raises `SettingsChanged` after saves. `AppStateService` always raises `StateChanged` after saves. ### Files changed (41 files, +1169/−660) | Area | Files | What changed | |------|-------|-------------| | New services | `Services/IPersistenceService.cs`, `PersistenceService.cs`, `ISettingsService.cs`, `SettingsService.cs`, `IAppStateService.cs`, `AppStateService.cs` | New service interfaces and implementations | | Models | `SettingsModel.cs`, `AppStateModel.cs` | Stripped to pure data bags | | DI | `App.xaml.cs` | Service registration, removed raw model DI | | ViewModels | 12 files | Constructor injection of services | | UI | 10 files | Service injection replacing model access | | Settings | `DockSettings.cs` | `Colors.Transparent` replaced with struct literal to avoid WinUI3 COM dependency | | Tests | `PersistenceServiceTests.cs`, `SettingsServiceTests.cs`, `AppStateServiceTests.cs` | 38 unit tests covering all three services | | Config | `.gitignore` | Added `.squad/`, `.github/agents/` exclusions | ## Validation Steps Performed - Built `Microsoft.CmdPal.UI` with MSBuild (x64/Debug) — exit code 0, clean build - Ran 38 unit tests via `vstest.console.exe` — all passing - Verified no remaining `#pragma warning disable SA1300` blocks - Verified no remaining `Services.` namespace prefixes --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-20 18:58:27 -05:00
private readonly ISettingsService _settingsService;
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
private readonly ProviderSettingsViewModel _providerSettingsViewModel;
private FallbackSettings _fallbackSettings;
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
public string DisplayName { get; private set; } = string.Empty;
public IconInfoViewModel Icon { get; private set; } = new(null);
public string Id { get; private set; } = string.Empty;
public bool IsEnabled
{
get => _fallbackSettings.IsEnabled;
set
{
if (value != _fallbackSettings.IsEnabled)
{
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
var newSettings = _fallbackSettings with { IsEnabled = value };
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
if (!newSettings.IsEnabled)
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
{
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
newSettings = newSettings with { IncludeInGlobalResults = false };
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
}
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
_fallbackSettings = newSettings;
_providerSettingsViewModel.UpdateFallbackSettings(Id, _fallbackSettings);
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
OnPropertyChanged(nameof(IsEnabled));
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
WeakReferenceMessenger.Default.Send<ReloadCommandsMessage>(new());
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
}
}
}
public bool IncludeInGlobalResults
{
get => _fallbackSettings.IncludeInGlobalResults;
set
{
if (value != _fallbackSettings.IncludeInGlobalResults)
{
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
var newSettings = _fallbackSettings with { IncludeInGlobalResults = value };
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
if (!newSettings.IsEnabled)
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
{
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
newSettings = newSettings with { IsEnabled = true };
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
}
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
_fallbackSettings = newSettings;
_providerSettingsViewModel.UpdateFallbackSettings(Id, _fallbackSettings);
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
OnPropertyChanged(nameof(IncludeInGlobalResults));
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
WeakReferenceMessenger.Default.Send<ReloadCommandsMessage>(new());
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
}
}
}
public FallbackSettingsViewModel(
TopLevelViewModel fallback,
FallbackSettings fallbackSettings,
CmdPal: Extract persistence services from SettingsModel and AppStateModel (#46312) ## Summary of the Pull Request Extracts persistence (load/save) logic from `SettingsModel` and `AppStateModel` into dedicated service classes, following the single-responsibility principle. Consumers now interact with `ISettingsService` and `IAppStateService` instead of receiving raw model objects through DI. **New services introduced:** - `IPersistenceService` / `PersistenceService` — generic `Load<T>` / `Save<T>` with AOT-compatible `JsonTypeInfo<T>`, ensures target directory exists before writing - `ISettingsService` / `SettingsService` — loads settings on construction, runs migrations, exposes `Settings` property and `SettingsChanged` event - `IAppStateService` / `AppStateService` — loads state on construction, exposes `State` property and `StateChanged` event **Key changes:** - `SettingsModel` and `AppStateModel` are now pure data models — all file I/O, migration, and directory management removed - Raw `SettingsModel` and `AppStateModel` removed from DI container; consumers receive the appropriate service - `IApplicationInfoService.ConfigDirectory` injected into services for config path resolution (no more hardcoded `Utilities.BaseSettingsPath`) - ~30 consumer files updated across `Microsoft.CmdPal.UI.ViewModels` and `Microsoft.CmdPal.UI` projects - All `#pragma warning disable SA1300` suppressions removed — convenience accessors replaced with direct `_settingsService.Settings` / `_appStateService.State` access - Namespace prefixes (`Services.ISettingsService`) replaced with proper `using` directives ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** N/A — no end-user-facing strings changed - [ ] **Dev docs:** N/A — internal refactor, no public API changes - [ ] **New binaries:** N/A — no new binaries introduced ## Detailed Description of the Pull Request / Additional comments ### Architecture Services are registered as singletons in `App.xaml.cs`: ```csharp services.AddSingleton<IPersistenceService, PersistenceService>(); services.AddSingleton<ISettingsService, SettingsService>(); services.AddSingleton<IAppStateService, AppStateService>(); ``` `PersistenceService.Save<T>` writes the serialized model directly to disk, creating the target directory if it doesn't exist. It also does not attempt to merge existing and new settings/state. `SettingsService` runs hotkey migrations on load and raises `SettingsChanged` after saves. `AppStateService` always raises `StateChanged` after saves. ### Files changed (41 files, +1169/−660) | Area | Files | What changed | |------|-------|-------------| | New services | `Services/IPersistenceService.cs`, `PersistenceService.cs`, `ISettingsService.cs`, `SettingsService.cs`, `IAppStateService.cs`, `AppStateService.cs` | New service interfaces and implementations | | Models | `SettingsModel.cs`, `AppStateModel.cs` | Stripped to pure data bags | | DI | `App.xaml.cs` | Service registration, removed raw model DI | | ViewModels | 12 files | Constructor injection of services | | UI | 10 files | Service injection replacing model access | | Settings | `DockSettings.cs` | `Colors.Transparent` replaced with struct literal to avoid WinUI3 COM dependency | | Tests | `PersistenceServiceTests.cs`, `SettingsServiceTests.cs`, `AppStateServiceTests.cs` | 38 unit tests covering all three services | | Config | `.gitignore` | Added `.squad/`, `.github/agents/` exclusions | ## Validation Steps Performed - Built `Microsoft.CmdPal.UI` with MSBuild (x64/Debug) — exit code 0, clean build - Ran 38 unit tests via `vstest.console.exe` — all passing - Verified no remaining `#pragma warning disable SA1300` blocks - Verified no remaining `Services.` namespace prefixes --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-20 18:58:27 -05:00
ProviderSettingsViewModel providerSettings,
ISettingsService settingsService)
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
{
CmdPal: Extract persistence services from SettingsModel and AppStateModel (#46312) ## Summary of the Pull Request Extracts persistence (load/save) logic from `SettingsModel` and `AppStateModel` into dedicated service classes, following the single-responsibility principle. Consumers now interact with `ISettingsService` and `IAppStateService` instead of receiving raw model objects through DI. **New services introduced:** - `IPersistenceService` / `PersistenceService` — generic `Load<T>` / `Save<T>` with AOT-compatible `JsonTypeInfo<T>`, ensures target directory exists before writing - `ISettingsService` / `SettingsService` — loads settings on construction, runs migrations, exposes `Settings` property and `SettingsChanged` event - `IAppStateService` / `AppStateService` — loads state on construction, exposes `State` property and `StateChanged` event **Key changes:** - `SettingsModel` and `AppStateModel` are now pure data models — all file I/O, migration, and directory management removed - Raw `SettingsModel` and `AppStateModel` removed from DI container; consumers receive the appropriate service - `IApplicationInfoService.ConfigDirectory` injected into services for config path resolution (no more hardcoded `Utilities.BaseSettingsPath`) - ~30 consumer files updated across `Microsoft.CmdPal.UI.ViewModels` and `Microsoft.CmdPal.UI` projects - All `#pragma warning disable SA1300` suppressions removed — convenience accessors replaced with direct `_settingsService.Settings` / `_appStateService.State` access - Namespace prefixes (`Services.ISettingsService`) replaced with proper `using` directives ## PR Checklist - [ ] **Communication:** I've discussed this with core contributors already. - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** N/A — no end-user-facing strings changed - [ ] **Dev docs:** N/A — internal refactor, no public API changes - [ ] **New binaries:** N/A — no new binaries introduced ## Detailed Description of the Pull Request / Additional comments ### Architecture Services are registered as singletons in `App.xaml.cs`: ```csharp services.AddSingleton<IPersistenceService, PersistenceService>(); services.AddSingleton<ISettingsService, SettingsService>(); services.AddSingleton<IAppStateService, AppStateService>(); ``` `PersistenceService.Save<T>` writes the serialized model directly to disk, creating the target directory if it doesn't exist. It also does not attempt to merge existing and new settings/state. `SettingsService` runs hotkey migrations on load and raises `SettingsChanged` after saves. `AppStateService` always raises `StateChanged` after saves. ### Files changed (41 files, +1169/−660) | Area | Files | What changed | |------|-------|-------------| | New services | `Services/IPersistenceService.cs`, `PersistenceService.cs`, `ISettingsService.cs`, `SettingsService.cs`, `IAppStateService.cs`, `AppStateService.cs` | New service interfaces and implementations | | Models | `SettingsModel.cs`, `AppStateModel.cs` | Stripped to pure data bags | | DI | `App.xaml.cs` | Service registration, removed raw model DI | | ViewModels | 12 files | Constructor injection of services | | UI | 10 files | Service injection replacing model access | | Settings | `DockSettings.cs` | `Colors.Transparent` replaced with struct literal to avoid WinUI3 COM dependency | | Tests | `PersistenceServiceTests.cs`, `SettingsServiceTests.cs`, `AppStateServiceTests.cs` | 38 unit tests covering all three services | | Config | `.gitignore` | Added `.squad/`, `.github/agents/` exclusions | ## Validation Steps Performed - Built `Microsoft.CmdPal.UI` with MSBuild (x64/Debug) — exit code 0, clean build - Ran 38 unit tests via `vstest.console.exe` — all passing - Verified no remaining `#pragma warning disable SA1300` blocks - Verified no remaining `Services.` namespace prefixes --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-20 18:58:27 -05:00
_settingsService = settingsService;
CmdPal: Make settings and app state immutable (#46451) ## Summary This PR refactors CmdPal settings/state to be immutable end-to-end. ### Core changes - Convert model types to immutable records / init-only properties: - `SettingsModel` - `AppStateModel` - `ProviderSettings` - `DockSettings` - `RecentCommandsManager` - supporting settings types (fallback/hotkey/alias/top-level hotkey/history items, etc.) - Replace mutable collections with immutable equivalents where appropriate: - `ImmutableDictionary<,>` - `ImmutableList<>` - Move mutation flow to atomic service updates: - `ISettingsService.UpdateSettings(Func<SettingsModel, SettingsModel>)` - `IAppStateService.UpdateState(Func<AppStateModel, AppStateModel>)` - Update ViewModels/managers/services to use copy-on-write (`with`) patterns instead of in-place mutation. - Update serialization context + tests for immutable model graph compatibility. ## Why Issue #46437 is caused by mutable shared state being updated from different execution paths/threads, leading to race-prone behavior during persistence/serialization. By making settings/app state immutable and using atomic swap/update patterns, we remove in-place mutation and eliminate this class of concurrency bug. ## Validation - Built successfully: - `Microsoft.CmdPal.UI.ViewModels` - `Microsoft.CmdPal.UI` - `Microsoft.CmdPal.UI.ViewModels.UnitTests` - Updated unit tests for immutable update patterns. Fixes #46437 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-27 12:54:58 -05:00
_providerSettingsViewModel = providerSettings;
CmdPal: Fallback ranking and global results (#43549) > [!IMPORTANT] > For extension developers, this release includes a new required `string Id` property for `FallbackCommandItem`. While your existing extensions will continue to work, without this `Id` being set, your fallbacks will not display and will not be rankable. > Before this is released, you will want to prepare your extension fallbacks. > > As an example, we are naming our built-in extensions as: > - Calculator extension provider Id: `com.microsoft.cmdpal.builtin.calculator` > - Calculator extension fallback: `com.microsoft.cmdpal.builtin.calculator.fallback` > > While the content of the Id isn't important, what is important is that it is unique to your extension and fallback to avoid conflicting with other extensions. Now the good stuff: ## What the heck does it do!? ### The backstory In PowerToys 0.95, we released performance improvements to Command Palette. One of the many ways we improved its speed is by no longer ranking fallback commands with other "top level" commands. Instead, all fallbacks would surface at the bottom of the results and be listed in the order they were registered with Command Palette. But this was only a temporary solution until the work included in this pull request was ready. In reality, not all fallbacks were treated equally. We marked the calculator and run fallbacks as "special." Special fallbacks **were** ranked like top-level commands and allowed to surface to the top of the results. ### The new "hotness" This PR brings the power of fallback management back to the people. In the Command Palette settings, you, dear user, can specify what order you want fallbacks to display in at the bottom of the results. This keeps those fallbacks unranked by Command Palette but displays them in an order that makes sense for you. But keep in mind, these will still live at the bottom of search results. But alas, we have also heard your cries that you'd like _some_ fallbacks to be ranked by Command Palette and surface to the top of the results. So, this PR allows you to mark any fallback as "special" by choosing to include them in the global results. Special (Global) fallbacks are treated like "top level" commands and appear in the search result based on their title & description. ### Screenshots/video <img width="1005" height="611" alt="image" src="https://github.com/user-attachments/assets/8ba5d861-f887-47ed-8552-ba78937322d2" /> <img width="1501" height="973" alt="image" src="https://github.com/user-attachments/assets/9edb7675-8084-4f14-8bdc-72d7d06d500e" /> <img width="706" height="744" alt="image" src="https://github.com/user-attachments/assets/81ae0252-b87d-4172-a5ea-4d3102134baf" /> <img width="666" height="786" alt="image" src="https://github.com/user-attachments/assets/acb76acf-531d-4e60-bb44-d1edeec77dce" /> ### GitHub issue maintenance details Closes #38312 Closes #38288 Closes #42524 Closes #41024 Closes #40351 Closes #41696 Closes #40193 --------- Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Jiří Polášek <me@jiripolasek.com>
2025-12-22 17:08:15 -06:00
_fallbackSettings = fallbackSettings;
Id = fallback.Id;
DisplayName = string.IsNullOrWhiteSpace(fallback.DisplayTitle)
? (string.IsNullOrWhiteSpace(fallback.Title) ? providerSettings.DisplayName : fallback.Title)
: fallback.DisplayTitle;
Icon = new(fallback.InitialIcon);
Icon.InitializeProperties();
}
}