_targets #45572_
This change allows our contact menu factory to actually create and add
additional context menu commands for pinning commands to the top level.
Now for any command provider built with the latest SDK that return
subcommands with an ID, we will add additional context menu commands
that allows you to pin that command to the top level.
<img width="540" height="181" alt="image"
src="https://github.com/user-attachments/assets/6c2cfe3c-4143-44d1-9308-bfc71db4c842"
/>
<img width="729" height="317" alt="image"
src="https://github.com/user-attachments/assets/4ff75c9f-1f35-4c1e-a03e-6fab5cbab423"
/>
related to https://github.com/microsoft/PowerToys/issues/45191
related to https://github.com/microsoft/PowerToys/issues/45201
This PR notably does not remove pinning from the apps extension. I
thought that made sense to do as a follow-up PR for the sake of
reviewability.
---
description from #45676 which was merged into this
Removes the code that the apps provider was using to support pinning
apps to the top level list of commands. Now the all apps provider just
uses the global support for pinning commands to the top level.
This does have the side effect of removing the separation of pinned apps
from unpinned apps on the All Apps page. However, we all pretty much
agree that wasn't a particularly widely used feature, and it's safe to
remove.
With this, we can finally call this issue done 🎉
closes https://github.com/microsoft/PowerToys/issues/45191
## Summary of the Pull Request
This PR unlocks lightning-fast mode for Command Palette:
- Hides visual and motion distractions when updating the result list:
- Ensures the first interactable result item is selected as early as
possible after the result list is updated, reducing flashing and
blinking caused by the selection highlight moving around.
- Removes the list item selection indicator animation (unfortunately by
removing the pill altogether for now) and prevents it from temporarily
appearing on other items as the selection moves.
- Adds a new "Results" section header above the home page results when
no other section is present.
- This ensures the first item on the home page has consistent visuals
and styling, preventing offsets and excessive visual changes when
elements are replaced in place.
- Improves update performance and container reuse:
- Fixes the `removed` output parameter in `ListHelper.UpdateInPlace` to
only include items that were actually removed (items that were merely
moved to a different position should not be reported as removed).
- Adds unit tests to prevent regression.
- Updates `ListHelper.UpdateInPlace` for `ObservableCollection` to use
`Move` instead of `Remove`/`Add`, and avoids `Clear` to prevent
`ListView` resets (which force recreation of all item containers and are
expensive).
- Adds a simple cache for list page item view models to reduce
unnecessary recreation during forward incremental search.
- `ListViewModel` and `FetchItems` have no notion of item lifetime or
incremental search phase, so the cache intentionally remains simple
rather than clever.
- Updates ListPage templates to make them a little lighter:
- Tag template uses OneTime, instead of OneWay - since Tag is immutable
- Replaces ItemsControl with ItemsRepeater for Tag list on list items
- Increases the debounce for showing the details pane and adds a
debounce for hiding it. This improves performance when browsing the list
and prevents the details pane animation from bouncing left and right
## Pictures? Moving!
https://github.com/user-attachments/assets/36428d20-cf46-4321-83c0-d94d6d4a2299
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #44407
- [x] Closes: #45691
## Summary
MainListPage hardcoded _appResultLimit = 10 instead of reading from
AllAppsCommandProvider.TopLevelResultLimit, which correctly parses the
user's SearchResultLimit setting. This meant changing the results limit
in settings had no effect on the apps extension fallback results.
## Changes
- `MainListPage.cs` — Replaced the hardcoded _appResultLimit = 10 field
with a computed property AppResultLimit that delegates to
AllAppsCommandProvider.TopLevelResultLimit.
- `MainListPageResultFactoryTests.cs` — Added three regression tests:
- `Merge_AppLimitOfOne_ReturnsOnlyTopApp` — verifies limit of 1 returns
only the top app
- `Merge_AppLimitOfZero_ReturnsNoApps` — verifies limit of 0 returns no
apps
- `Merge_AppLimitOfOne_WithOtherResults_AppsAreLimited` — verifies apps
are limited even when mixed with other result types
## Validation
- [X] Existing tests pass
- [X] New regression tests cover edge cases for the appResultLimit
parameter
## Linked Issues
- Fixes#45654
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary of the Pull Request
This PR improves fuzzy matching in Command Palette by:
- Precomputing normalized strings to enable faster comparisons
- Reducing memory allocations during matching, effectively down to zero
It also introduces several behavioral improvements:
- Strips diacritics from the normalized search string to improve
matching across languages
- Suppresses the same-case bonus when the query consists entirely of
lowercase characters -- reflecting typical user input patterns
- Allows skipping word separators -- enabling queries like Power Point
to match PowerPoint
This implementation is currently kept internal and is used only on the
home page. For other scenarios, the `FuzzyStringMatcher` from
`Microsoft.CommandPalette.Extensions.Toolkit` is being improved instead.
`PrecomputedFuzzyMatcher` offers up to a 100× performance improvement
over the current `FuzzyStringMatcher`, and approximately 2–5× better
performance compared to the improved version.
The improvement might seem small, but it adds up and becomes quite
noticeable when filtering the entire home page—whether the user starts a
new search or changes the query non-incrementally (e.g., using
backspace).
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #45226
- [x] Closes: #44066
- [ ] **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
> [!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#38312Closes#38288Closes#42524Closes#41024Closes#40351Closes#41696Closes#40193
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Jiří Polášek <me@jiripolasek.com>
## 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.
## Summary of the Pull Request
This PR stops fallback commands from showing on the homepage when
there’s no query, with the reasons detailed in the linked issue.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #44004
<!-- - [ ] 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 change marks the System command provider as special, ensuring
fallback items are surfaced at the top of the list.
Additionally, the SystemCommandExtensionProvider ID has been updated to
comply with the new naming convention.
As a small cleanup, SystemCommandExtensionProvider is now sealed.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Related to: #42524
- [ ] **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 introduces a hotfix that updates special fallback items
separately from the rest. This allows the loop handling special fallback
items to finish faster, ensuring they are not delayed by other fallback
items. As a result, calculator and run fallback items will be more
readily available to users.
This partially solves #42286 for special fallback items.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Related to: #42286
- [ ] **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
Closes#42241Closes#42245
Apps that were pinned would show in search results twice. Resolved.
Run & Calculator wouldn't show in search results. Resolved.
In #41959 we changed the string matcher's weighting. It ended up giving
us lower scores than before.
That meant that the weighting from recent commands was far too heavy,
and it was polluting the results. Basically any command that you'd run
would be like, 30 characters of weight heavier than anything you
haven't.
This increases the weight of all string matches by 10x. That means
something like
`Command Prompt` will get a string matched weight of `100` instead of
`10`. This balances better with the weighting from frecency (where the
MRU command gets +35, then `+min(5*uses,35)`, for up to 70 points of
weight)
It also adds a bunch of tests here, to try and catch this again in the
future.
Closes#42158
## Summary of the Pull Request
CmdPal now displays the search box only on pages that derive from
ListPage. On ContentPage (forms, etc.), the search box is hidden.
- Moves keyboard shortcut handling from SearchBox to ShellPage so
shortcuts are always handled.
- Keeps the search box hidden/disabled to preserve layout metrics.
- Refines focus management to prevent focus jumps during navigation.
- For ContentPage page's content gains focus automatically (not just
form inputs, but now markdown content as well - so you can scroll
immediately, for example).
- Adds accessibility (a11y) tweaks: when navigating to content pages
without a visible search box, sets an explicit focus target so screen
readers announce a meaningful element. Screen reader will now announce
navigation to the page.
- Adds a title to the main list page - "Home".
https://github.com/user-attachments/assets/f60d0826-df1f-468e-8e41-0266cd27878b
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #38967
- [ ] **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
Still a WIP, but here's the deets so far:
## No more throwing canceled tokens
Throwing exceptions is expensive and since we essentially cancel tokens
anytime someone is typing beyond the debounce, we could be throwing
exceptions a ton during search. Since we don't care about those past
executions, now they just `return`.
## Reduced number of apps returned in search
While users can specify how many apps (no limit, 1, 5), if they specify
no limit, we hard limit it at 10. For a few reasons, fuzzy search gets
_really_ fuzzy sometimes and gives answers that users would think is
just plain wrong and they make the response list longer than it needs to
be.
## Fuzzy search: still fuzzy, but faster
Replaced `StringMatcher` class with `FuzzyStringMatcher`.
`FuzzyStringMatcher` is a C# port by @zadjii-msft of the Rust port by
@lhecker for [microsoft/edit](https://github.com/microsoft/edit), which
I believe originally came from [VS
Code](https://github.com/microsoft/vscode). It's a whole fuzzy rabbit
hole. But it's faster than the `StringMatcher` class it replaced.
## Fallbacks, you need to fall back
"In the beginning, fallbacks were created. This had made many people
very angry and has been widely regarded as a bad move."
Hitchhiker's Guide to the Galaxy jokes aside, fallbacks are one cause of
slower search results. A few modifications have been made to get them
out of the way without reverting their ability to do things dynamically.
1. Fallbacks are no longer scored and will always* appear at the bottom
of the search results
2. In updating their search text, we now use a cancellation token to
stop processing previous searches when a new keypress is recorded.
## * But Calculator & Run are special
So, remember when I said that all fallbacks will not be ranked and
always display at the bottom of the results? Surprise, some will be
ranked and displayed based on that score. Specifically, Calculator and
Run are fallbacks that are whitelisted from the restrictions mentioned
above. They will continue to act as they do today.
We do have the ability to add future fallbacks to that whitelist as
well.
---
## Current preview
Updated: 2025-09-24
https://github.com/user-attachments/assets/c74c9a8e-e438-4101-840b-1408d2acaefd
---
Closes#39763Closes#39239Closes#39948Closes#38594Closes#40330
What the title says. 😄
Rather than relying on the potentially overloaded `!=` or `==` operators
when checking for null, now we'll use the `is` expression (possibly
combined with the `not` operator) to ensure correct checking. Probably
overkill for many of these classes, but decided to err on the side of
consistency. Would matter more on classes that may be inherited or
extended.
Using `is` and `is not` will provide us a guarantee that no
user-overloaded equality operators (`==`/`!=`) is invoked when a
`expression is null` is evaluated.
In code form, changed all instances of:
```c#
something != null
something == null
```
to:
```c#
something is not null
something is null
```
The one exception was checking null on a `KeyChord`. `KeyChord` is a
struct which is never null so VS will raise an error when trying this
versus just providing a warning when using `keyChord != null`. In
reality, we shouldn't do this check because it can't ever be null. In
the case of a `KeyChord` it **would** be a `KeyChord` equivalent to:
```c#
KeyChord keyChord = new ()
{
Modifiers = 0,
Vkey = 0,
ScanCode = 0
};
```
related to some #40113 work
The extension SDK shouldn't rely on a preview version of the Windows
SDK. It should use the stable one.
Also moves some messages around that we didn't need
A regression from #40132
We need to set the value of `_includeApps` in the `MainListPage` ctor.
Without it, if the user doesn't have any extensions installed, the value
is never updated.
## Summary of the Pull Request
Self-refresh of `MainListPage` introduced in #40132 causes unnecessary
spawning of tasks by `ReapplySearchInBackground` and pushing the code
down the scenic route instead of taking shortcut.
This drop-in fix introduces a single-worker coalescing refresh loop to
eliminate thread-pool churn and syncs state in early-return paths.
## PR Checklist
- [x] Closes: #40916
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** no change
- [ ] **Localization:** nothing
- [ ] **Dev docs:** nothing
- [ ] **New binaries:** none
- [ ] **Documentation updated:** nothing
<!-- 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
Changes the placeholder in the filter box only on the main list page to
"Search for apps, files and commands...":
<img width="786" height="473" alt="image"
src="https://github.com/user-attachments/assets/844d27ae-61cf-42c9-a7f6-ae78817e928c"
/>
The default value remains unchanged as "Type here to search..." for all
other pages (both built-in and internal), unless the author overrides
it:
<img width="786" height="473" alt="image"
src="https://github.com/user-attachments/assets/aeb3500b-9e36-4e35-8dd7-3bd226336823"
/>
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] Closes: #40763
- [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
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Added/updated
- [x] **New binaries:** none
- [x] **Documentation updated:**
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
Closes#40781
Filters out TopLevelCommands whose Id matches an app coming from the
`AllAppsCommandProvider.Page.GetItems()`.
Hate adding processing there, but without adding some type of `bool
HideMeOnSearch` to something low enough (like ICommandItem), I don't see
another way to distinguish these.
This entirely rewrites the shell page. It feels a lot more like the old
run dialog now.
* It's got icons for files & exes
* it can handle network paths
* it can handle `commands /with args...`
* it'll suggest files in that path as you type
* it handles `%environmentVariables%`
* it handles `"Paths with\spaces in them"`
* it shows you the path as a suggestion, in the text box, as you move
the selection
References:
Closes#39044Closes#39419Closes#38298Closes#40311
### Remaining todo's
* [x] Remove the `GenerateAppxManifest` change, and file something to
fix that. We are still generating msix's on every build, wtf
* [x] Clean-up code
* [x] Double-check loc
* [x] Remove a bunch of debug printing that we don't need anymore
* [ ] File a separate PR for moving the file (indexer) commands into a
common project, and re-use those here
* [x] Add history support again! I totally tore that out
* did that in #40427
* [x] make `shell:` paths and weird URI's just work. Good test is
`x-cmdpal://settings`
### further optimizations that probably aren't blocking
* [x] Our fast up-to-date is clearly broken, but I think that's been
broken since early 0.91
* [x] If the exe doesn't change, we don't need to create a new ListItem
for it. We can just re-use the current one, and just change the args
* [ ] if the directory hasn't changed, but we typed more chars (e.g.
`c:\windows\s` -> `c:\windows\sys`), we should cache the ListItem's from
the first query, and re-use them if possible.
_targets #40504_
Major refactoring for #40113
This moves a large swath of the codebase to a `.Core` project. "Core"
doesn't have any explicit dependencies on "extensions", settings or the
current `MainListPage`. It's just a filterable list of stuff. This
should let us make this component a bit more reusable.
This is half of a PR. As I did this, I noticed a particular bit of code
for TopLevelVViewModels and CommandPaletteHost that was _very rough_.
Solving it in this PR would make "move everything to a new project" much
harder to review. So I'm submitting two PRs simultaneously, so we can
see the changes separately, then merge together.
<!-- 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
Prevents installed applications from appearing in the top-level search
when Installed Apps extension is disabled.
Previously, application commands were still returned in the global
search results even when the *Installed Apps* extension was turned off.
To match user expectations, the search now respects the extension’s
enabled state.
- Added `IsActive` property to `CommandProviderWrapper` to indicate
whether the provider is both valid and enabled by the user in the
settings.
- Updated `MainListPage` to verify that the provider for `AllApps` is
active before including apps in filtered results.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39937
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** nothing to update
- [x] **New binaries:** none
- [x] **Documentation updated:** nothing to update
<!-- 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
Verified that the Installed app entries are shown in the top-level
search only when the Installed apps extension is enabled. Verified that
turning the Installed apps extension on or off has an immediate effect,
and that the behavior persists after an application restart.
The problem:
> * we need to go update all the Fallback commands. (these are ones that extensions can use to react to the search text - basically, "what the user typed wasn't found immediately, but here's something they can fall back on"
> * this is wacky, because the way I had it, I update each item, and if it "changes visibility", then we need to update the main list, because we've already removed it from the list. So we need to re-update the list to account for that
> * you missed it reading that (and i missed it writing it) but that basically means we re-populate the list F={num fallbacks} times, because each one sends the "do it again" message
> * That results in us basically creating (F+1)*(N=num items+apps) view models, initializing them, and not needing most of them
The crux here being a single thread, to update all the fallback items,
that then only raises _one_ items changed at the very end.
I don't love this, one misbehaving fallback could stop all the others. In theory, we should do a parallel update of all these things, with a like, 1s timeout on each leg.
But it has gotta be faster till we can do #38140 (or similar)
Closes: (not sure I filed one). But the first typed character _felt_ slow.
This is a much tidier solution. Don't default _everything_ to a weight of 1 if the query is whitespace. Instead, do a simple string contains check (because FuzzySearch will beef it on just whitespace)
Closes#38133
I originally based this off of #38157, so I know these two won't collide
Both `TopLevelCommandItemWrapper` and `TopLevelViewModel` were really the same thing. The latter was from an earlier prototype, and the former is a more correct, safer abstraction. We really should have only ever used the former, but alas, we only used it for the SUI, and it piggy-backed off the latter, and that meant the latter's bugs became the former's.
tldr: I made the icon access safe in the SUI.
And while I was doing this, because we now have a cleaner VM abstraction here in the host, we can actually cleanly disable extensions, because the `CommandProviderWrapper` knows which `ViewModel`s it made.
Closes https://github.com/zadjii-msft/PowerToys/issues/426
Closes https://github.com/zadjii-msft/PowerToys/issues/478
Closes https://github.com/zadjii-msft/PowerToys/issues/577
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes#3200, closes#3600, closes#7770, closes#34273, closes#36471, closes#20976, closes#14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
