CmdPal: Add settings, alias, and hotkey actions to top-level context menus

[jiripolasek]

Summary of the Pull Request

• Automatically add a Settings menu item for extensions that expose a settings page
• Replace provider-authored settings-page context menu items so they open the Settings window instead (based on [CmdPal] Open settings in Settings #46047)
• Add Change alias and Change global hotkey actions to top-level command context menus
• Navigate directly to the owning extension page and focus the relevant settings section or command control
• Group the new settings-related actions into a separate context menu section and update their icons

Pictures? Pictures!

Screen.Recording.2026-03-10.182002.mp4

PR Checklist

• Closes: #xxx
• Closes: There should be a consistent way for users to get to settings from within an extension experience #38278

• 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 for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[michaeljolley]

I love the settings stuff. On alias/hotkey, it starts to get pretty bloated. I could see "Change Alias/Hotkey", but really, settings takes them there.

[jiripolasek]

I love the settings stuff. On alias/hotkey, it starts to get pretty bloated. I could see "Change Alias/Hotkey", but really, settings takes them there.

a) This helps with discoverability. I know it’s there, you know it’s there, but users don’t. Even if they open the Settings page, shortcuts and aliases are hidden in a collapsed expander.

b) As currently implemented, the "Settings" command only appears for custom extension settings (the adaptive card content) and takes you there. Not all extensions have that. It could be changed to "just" open the Extension Settings page, but that would lose part of its appeal: if the menu item is present, there’s something useful to configure.

[michaeljolley]

I just worry about that context menu becoming like the context menu in Windows.

[michaeljolley]

@niels9001, would love your input here

[michaeljolley]

Pinging @niels9001

[niels9001]

@jiripolasek @michaeljolley I believe we are using a ListView instead of a MenuFlyout for this, right - because the latter doesn't support binding an ItemsSource 😢?

Because then, we could just have a single entry that is something called 'customization' and we could do a sub flyout?

[michaeljolley]

@jiripolasek @michaeljolley I believe we are using a ListView instead of a MenuFlyout for this, right - because the latter doesn't support binding an ItemsSource 😢?

Because then, we could just have a single entry that is something called 'customization' and we could do a sub flyout?

It's using our built-in context-menu component. That is a ListView. However, it behaves just like our standard ContextMenu in that selecting a command that has subcommands simply dives into those subcommands rather than opening another flyout.

[niels9001]

@jiripolasek @michaeljolley I believe we are using a ListView instead of a MenuFlyout for this, right - because the latter doesn't support binding an ItemsSource 😢?

Because then, we could just have a single entry that is something called 'customization' and we could do a sub flyout?

It's using our built-in context-menu component. That is a ListView. However, it behaves just like our standard ContextMenu in that selecting a command that has subcommands simply dives into those subcommands rather than opening another flyout.

Right.. so for this example, should all of these be grouped under a Copy context menu?

I think that would make sense in e.g. an app or OS UX, for a launcher I dunno.. question stays that you'd want to differentiate between primirary actions and secomdary actions.

E.g. in the OP changing the alias is a one time thing - and a user would not need direct access to it so a submenu could make sense there - actually reduces cognitive load and improves glancibility too by hiding / keeping things short and clean.

[jiripolasek]

If we do this, we should find another way to teach the user about the hotkeys and aliases. Moving them out of sight will greatly reduce discoveribility. But then, it might have been a wrong too for a wrong problem altogether.

[jiripolasek]

@niels9001 would you like the new "Customize" submenu encompass Settings also?

The only thing I'm not sure is how it behaves when the Customize (or any submenu) becomed the secondary command (Ctrl+Enter).