This is a fix for a pair of related crashes.
Basically, we'd crash on startup if we failed to initialize WinGet. This could happen in two different places:
* If WinGet wasn't installed, then we'd explode, cause obviously we can't call its APIs
* If we're running as Admin, we won't be able to instantiate it's COM server.
Regardless of how it happens, I've defaulted us to just _not enabling the winget built-in_. That's the simplest solution here.
As I was helpfully reminded, there's also an elevated WindowsPackageManagerFactory we could use too - though, that wouldn't solve the case of "winget isn't installed"
Closes#38460Closes#38440 (most likely)
In CmdPal and PT Run, if you currently try to go to mouse pointer, it fails. This looks to be due to capitalization in the command. This can be validated via run dialog also.
shifting to lowercase fixes the bug.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #38223
## Summary of the Pull Request
Fix#38337 and implement continuous navigation like PT Run v1
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #38337
* add settings definition
* fix typos and improve settings
* make spell checker happy
* new icon type error
* first code to handle custom formats
* support parsing of new formats
* spelling and typos
* comment fix
* spell check
* start implement custom format results
* last changes
* finish implementation
* spell checker
* settings name
* add missing format
* reorder settings
* dev docs
* change ELF to EAB
* update dev docs
* last changes
* test cases
* fix typos
* fix typo
* port changes
* fixes
* changes
* fixes
* leap year support
* days in month
* tests
* comment
* fix comment
It appears there are two issues in WinGet regarding the installation of dependencies.
https://github.com/microsoft/winget-cli/issues/4661https://github.com/microsoft/winget-cli/issues/4679
For CmdPal 0.1, we're going to skip installing dependencies to make extension installation more robust. This will mostly work because extensions will depend on the same frameworks as the command palette itself (for now).
We will revert this once these two issues are fixed.
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
- `appLicensing` avoids the issue where installation requires access to the store servers for licensing.
- It was decided that PowerToys would manage CmdPal's startup.
This only repros on my desktop, so I suppose that means a slower machine is needed
I was mistaken, and assumed we were already operating on a copy here. We weren't. That meant that it was possible for another extension to be detected, change the list, and crash the whole palette.
## Validation Steps Performed
No longer does my desktop crash on startup
<!-- 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
Attempt to fix `Layout cycle detected. Layout could not complete` exception when CmdPal is moved on a screen with different DPI.
I can repro almost 100% and no longer occurs after switching tags `ItemsView` with `ItemsControl`.
Doesn't seem to break visual and don't expect a huge number of tags so use an `ItemsControl` shouldn't be a problem.
<img width="491" alt="image" src="https://github.com/user-attachments/assets/05b698b2-ebe7-4356-bdaa-4de93aea13e6" />
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries
- [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder
- [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects
- [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
What we were doing only worked in English. The `.ToString` would get
you the text of the nav item, not the `Tag`
`InvokedItemContainer` gets you the `NavigationViewItem`.
<!-- 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
All apps:
- Fix missing second command for opnening settings page
Time and Date plugin:
- fix for missing settings list in global plugin manager
- fix for wrong page title
system plugin
- fix for missing settings page in global plugin manager
- fix for missing open button on plugin list
- ~fix for wrong icon for firmware boot~
- fix for wrong subtitle for ipv6
- fix for wrong details for mac address
- fix for wrong layout of network details
- layout improvements for network details
- change default value for "hide disconected networks" to $false
- rename empty recycle bin setting to "Hide Empty Recycle Bin command"
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries
- [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder
- [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects
- [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
More than a couple people hit mYsTeRiOuS iSsUeS on ARM. Extensions would load the first time, but never again. Their processes would start, but the objects would fail to load.
Fortunately, @azchohfi discovered that using `Shmuelie.WinRTServer`, rather than the one pilfered from devhome, doesn't have this problem.
I don't have an ARM machine to validate the changes, but @lauren-ciha thankfully did the groundwork to get this validated in their extension, so I think this should work.
Closes https://github.com/zadjii-msft/PowerToys/issues/97
- Removing the redundant icon + text in the bottom left corner
- Minor styling tweaks
- Adding subtle show/hide animations
- Improved narrator support for Settings button
- Minor design tweaks to the tags for better visibility (still needs more work in the future)
There is a bug in command palette where the top level commands from extensions gets duplicated after the extension raises items changed, or when it is requested by CmdPal for any reason. This didn't happen when we kill CmdPal and open it again.
When investigating, I noticed that the `UpdateCommandsForProvider` method was not deleting the top level commands for the extension.
This seems to be happening because the comparison `var isTheSame = wrapper == firstCommand;` is not comparing objects of the same type. It was comparing a `TopLevelViewModel` with a `CommandItem`, and it was never set to `true`.
I change it to compare the `TopLevelViewModel` of both commands, and now it seems to be detecting correctly.
Another option of fix could be comparing the `CommandItem`s.
closes https://github.com/zadjii-msft/PowerToys/issues/511
---
Another bug that I found while testing today is that when a user uninstalled or updated an extension, it was still being listed as an enabled extension. This was generating duplicates in the top level commands in case of updating an extension, and resulting in unpredictable behavior and occasional crashes in CmdPal.
Added a fix for that on `ExtensionService`, removing the uninstalled extensions also from the `_enabledExtensions` list.
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
## Summary of the Pull Request
Make settings window single.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** https://github.com/zadjii-msft/PowerToys/issues/581
## Validation Steps Performed
Manual test.
- Open settings windows multiple times
- Activate minimized settings window
The original code not work. It will throw com exception.
I prefer to use ClipboardHelper one.
-----
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Update OOBE's CmdPal page to show the actual hotkey and style it similar to other OOBE pages.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Open OOBE and verify it looks like other OOBE pages.
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
I forgot that packages write to a virtualized registry, rather than the
real one. As it turn out, the registry plugin requires being able to
write to the registry to be able to open the correct location
Closes#38053
