Add a explorer context menu entry to let the user pick the profile they want to "open here"

[zadjii-msft]

Follow up from #6100

We should add another entry to the explorer context menu to let the user select which profile.

This is the only other option I'm considering at this time, I don't want to clutter that UI too badly.

notes:

• We could maybe allow arbitrary customization akin to what we're planning for #1571.
• #9749, #11348: people want to use startupActions in the specified directory
• #9991 maybe also relevant

[tru0067]

Hiya! This is an issue I found after creating my own personalized context menu for windows terminal using a registry edit.

It seems that the current implementation uses a different approach to populating the context menu, through a shell extension via appxmanifest. To me, an implementation involving directly adding registry keys directly through a .reg or .bat script seems to have several solid pros, namely:

• Very easy to disable (by simply deleting the relevant registry keys), from the high number of duplicate issues requesting this feature it seems like this is something that people want to be able to do (see eg. Issue 8105).

• Easily extensible, by simply adding/editing the existing keys users would be able to add their own start-up options, e.g:

  • Opening windows terminal with two tabs/splits running different shells in the relevant directory.

  • Opening windows terminal and running a command (e.g. starting a server, or opening the directory in a terminal based text editor), etc.

  • Setting certain context menu items to only appear on shift click (Issue 6113) by simply adding the "Extended"="" string-value to the key.

  The default keys would provide a useful template for such customized context menu items, and it would also allow for customized options to appear within any default cascading menus (eg. for multiple profiles, as mentioned in this issue).

• There is already a strong precedent for terminals using registry keys for their context menus, namely PowerShell's "Open PowerShell window here".

Additionally, I do not think that this implementation would have to wait for the internal bug-fix mentioned in Issue 6414, though that may be a moot point as that may be resolved before any context menu changes go through.

Admittedly, I can see one flaw of such an implementation, newly added profiles may have very poor discoverability. A cascading menu listing all profiles may need to be manually refreshed - this seems like an option that could be quite accessible within the planned gui settings, but with the current settings.json it might be a hassle ( { "refreshContextMenu": true } ? ).

Similarly, deleted profiles may linger unwantedly - again something that might be easily addressed within gui settings in which profiles are removed by pressing a button, but with settings.json it would be tricky. Diffing for removed profiles doesn't seem like a good idea, and simply deleting all keys that do not match a profile may have the unwanted side effect of removing any of the user's custom added keys.

If this approach does seem to be beneficial it would be something I'd be interested in contributing to, though there may be some benefits to the current implementation that I am unaware of.

Thanks and kind regards!!

[kirsan31]

Very needed feature. I was thinking that after open from explorer context menu every new tab will preserve current dir, but no :(

[Flightkick]

Stumbled upon this project while searching this topic: https://github.com/lextm/windowsterminal-shell I would rather see this kind of functionality included in Windows Terminal instead of being provided as a third-party PowerShell script. Though the idea is nice. It looks like the linked project only checks the profiles during installation so changes after that won't change anything. A per-profile toggle would be nice to control which profiles to show in the context menu (just like there's a toggle now for which profiles to show in the dropdown within Windows Terminal).

[zadjii-msft]

Notes:

• I don't know how to add nested menu entries to File Explorer. I'm not sure there's a sample of how to do it that's not older than I am.
• I tried in dev/migrie/fhl/nested-file-explorer.
• I'd love to just try this out without even using the settings model, as a test. Alas, I have no idea how.
  • Adding actual settings parsing might be hard. A dependency on WinRT would be hard.
• I'm imagining two settings at the moment:
  • globals.allProfilesInContextMenu: when true, the context menu entry has all the non-hidden profiles listed as nested entries.
  • globals.runAsAdminInContextMenu: When true, we'll add a second entry for "(As Admin)". This entry will also obey the above one, switching between a single entry and a nested one.
• John L from the shell team has a context menu samples repo in OS.Developer, internally. I put the relevant file in https://gist.github.com/zadjii-msft/fc6b2ba8fda66cf7cc37fa7a21cc731a, because idl if that's OSS or not