Mike Griese

CmdPal: Add a new dedicated dock flyout (#51092) _Targets https://github.com/microsoft/PowerToys/pull/51091_ Part 4 of the dock flyout refactor, for https://github.com/microsoft/PowerToys/issues/45861 Closes #45861 <img width="628" height="663" alt="image" src="https://github.com/user-attachments/assets/d2e6a828-86a9-4ccc-a28c-097dde204a50" /> <img width="583" height="413" alt="image" src="https://github.com/user-attachments/assets/93b094fd-ed02-4609-b358-795a5831b5d4" /> Lots of new controls, but kind of a lot of the same stuff we already do in ShellViewModel. Admittedly, brought over the finish line with AI. I started this refactor back when the Dock first shipped, but it was still too far from shipping to work. AI created the flyout control which was a lot better than the original "just use our context menu control" which was kinda terrible. And also just generally splitting the humongous refactor into bits that could be reviewed more easily

CmdPal: Remove the WeakReferenceMessenger for most things (#51038) _Targets #51034_ Part 2 of the dock flyout refactor, for https://github.com/microsoft/PowerToys/issues/45861 This PR removes a bunch of the `WeakReferenceMessenger` use from the command bar and the search box. Currently, those are just single instances, so it's fine to have a WRM send messages to just them. However, with the planned dock flyout, we're _not_ going to have a single instance of them anymore. There will be one instance for the main window, and one for the flyout. So before we can add a dock flyout, we have to have the ShellPage actually strictly own the controls it owns. It's basically a ton of slight refactoring to pass around actual context to the viewmodels, rather than relying on weak message passing. > [!NOTE] > For reviewers: I'd review this commit-by-commit. I know that this is a huge pain all up. I also didn't want to file a stack of like 20 PRs, that seemed goofy. It's a changelist that has to touch the world, but each part of it is actually relatively well contained. > Start by clicking > ### [HERE](https://github.com/microsoft/PowerToys/pull/51038/changes/10502b906999ed2248ab4970ef9b88d0bbe30842) > then reviewing the commit, then hitting the `Next >` button at the top

Prepare for per-window settings (#20328) This is part one of a two-part pair of PRs to add support for per window name settings to the Windows terminal. This first PR functionally does very little. It introduces the concept of a `WindowSettings` object, where each `WindowSettings` object may be different based off of the name of the window. **However**, the settings model doesn't actually expose different instances of `WindowSettings` currently. It just introduces one fake instance that actually just wraps the global settings object to store all of them. This means that functionally the code hasn't actually changed in this PR. We are just accessing these properties through an intermediate type. Largely this PR is mostly mechanical. where we previously would have been accessing properties on the `GlobalAppSettings`, now we are just accessing the `_currentWindowSettings()` (via a helper, or passing as a parameter). All of this refactoring can be done now to always access the correct window settings object so that the next PR is much easier to read. That is where it will get more interesting and we will have more instances of window settings. Refs #9992

CmdPal: add an in-place adaptive card updater (#50211) Adds a library for in-place updating of our adaptive cards, so that our performance graphs don't flicker anymore. > [!WARNING] > Here be basilisks! > > This entire library is maintained by LLMs. Humans didn't write the code, and no human actually owns this code. > > This library was generated to experiment with the big picture problem "can we update the content of a rendered Adaptive Card without replacing the entire card?" > > I would fully suspect that this is not the correct approach to solve this problem. It is _an_ approach however, and it's one that works well enough to continue experimenting with. Everything in `Microsoft.CmdPal.AdaptiveCards.IncrementalRendering` was LLM generated and I admittedly, only very lightly reviewed it. I hate myself, but it does work. I don't want to pontificate too highly on the state of _ｅｖｅｒｙｔｈｉｎｇ_. We're going to need to do more experimentation with projects that are largely LLM maintained[^1]. CmdPal is most definitely not that. It remains human owned. This is a relatively small and self-contained sub-project that we can pilot what that means for the rest of the broader project. Closes #46362 [^1]: much to my own chagrin.

CmdPal: Safely handle invoking an extension that died (#51443) This is an issue I noticed while debugging the dock with a dev build. If I quit out of the dev build, then try to click on a dock item on my stable build. If that item was from an extension, I would no longer be able to run any commands in command palette at all. Turns out the issue is much bigger than just dock items. It seems if we tried to perform the command for any item from an extension that has died, we would throw an exception outside of the try/catch in `ShellViewModel::PerformCommand`. That would cause us to never release the `_handleInvokeTask`, and we'd never be able to start invoking another command. Looks like the call to `command.Unsave.Name` got moved from inside the try/catch to outside in #43905. Whoops. While I was here, I thought it best that we remove this footgun. PerformCommandMessage now carries around a `CommandViewModel` instead of just an `ExtensionObject<ICommand>`, so that consumers can use the cached name & Id rather than begging to use `.Unsafe` on it. Closes: probably nothing, maybe something though?

CmdPal: Preserve page command context (#51034) Part 1 of the dock flyout refactor, for #45861 This is some simple refactoring to make sure that we retain the page context of where a command was invoked from, so that when we invoke that command, we actually use the real provider of that command. This doesn't really matter today. Today, the "dock flyout" is just the command palette, manually navigated to the page of the dock item. So today, the `CurrentPage.ProviderContext` (read in `ShellViewModel`) is actually correct. But in the future, the dock flyout won't just be the `CurrentPage`. When that happens, we'll need to know the actual page that the command came from so that we can properly look up the right extension it came from.

CmdPal: Extract page navigation helpers from ShellViewModel (#51091) _Targets https://github.com/microsoft/PowerToys/pull/51038_ Part 3 of the dock flyout refactor, for https://github.com/microsoft/PowerToys/issues/45861 Move the page-creation and page-initialization logic out of `ShellViewModel` into a new internal `PageNavigationService`, so it can be shared by other navigation surfaces later. No behavior change is intended. Moved into `PageNavigationService`: - `ResolveHost` / `ResolveProviderContext`: host and provider-context lookup that was inline in `ShellViewModel.PerformCommand`. - `InitializePageAsync`: the background `InitializeCommand` run that was in `ShellViewModel.LoadPageViewModelAsync`. - `TryPreparePage`: list-page launch-option validation, view-model creation through `IPageViewModelFactoryService`, and `IsRootPage` defaults. `ShellViewModel` keeps ownership of `CurrentPage`. The "activate page after load" logic is consolidated into `SetCurrentPageAfterLoad` instead of being duplicated in both load branches. Adds `PageNavigationServiceTests`, a shared `TestAppExtensionHost`, and `ShellViewModel` tests for page load/activation and root-page navigation.

CmdPal: don't save settings on load unless they changed (#51353) Looking at the logs from a debug startup and holy hell batman, it's so noisy. Looks like every time that we added a fallback command to a provider, we'd save the settings. Even if we'd already seen that fallback. In practice, this resulted in **46** saves, because of all the PT fallbacks. Literally every load - 46 saves. Even if nothing changed. This PR skips writing the file if nothing changed. Saves about 2s[^1] of startup time. Closes nothing, I know what I'm doing [^1]: LLM measurment, not my own

CmdPal: batch DockBands updated into a single event (#51362) `TopLevelCommandManager` added/removed dock bands one at a time, raising a `CollectionChanged` per band. Every `DockViewModel` (one per monitor) rebuilt all of its bands on each event. Yikes. This PR instead adds `AddRange`/`RemoveRange` methods to `DockBandsCollection`. Now each provider load/enable/disable/removal raises just one `Reset`. If you're thinking "you're just moving the Add, won't that still raise events", it doesn't. `ObservableCollection.Add` is the thing that actually raises `CollectionChanged` events. Since we're not calling that, and are instead just writing to the underlying collection directly, then the only event raised is the one we raise ourselves. Robots did some measuring on my machine Measured on a 2-monitor machine, Debug x64 Dev build, 10 pinned bands (builtin + Azure/GitHub/VirtualDesktops extensions), 5 cold launches each, via temporary counters (not committed). Values identical across runs except times (medians shown). | Variant | DockBands events | Rebuilds | Band inits | Band init time | "failed to find" warnings | |--------------------|-----------------:|---------:|-----------:|---------------:|--------------------------:| | main (baseline) | 23 | 24 | 138 | 3829 ms | 102 | | batching (A) | 2 | 3 | 15 | 199 ms | 15 | * "Band init time" is total time spent in DockBandViewModel.InitializeProperties (cross-process calls on background threads).

CmdPal: Add support for richer content in Details (#50180) what if you could put an Adaptive Card into the list item's details? that'd be cool. <img width="781" height="448" alt="image" src="https://github.com/user-attachments/assets/7b6a7e42-d521-4646-a035-beb3b2f270d7" /> Lots of potential here to stick other things in there too, since now we're just accepting a list of `IContent`. Referenced in: #41125 Referenced in: #42003 Referenced in: #39200