starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Feature Request: Cascading settings (with a hardcoded default.json?) #1035

New Issue
Closed
opened 2026-01-30 22:14:21 +00:00 by claunia · 17 comments
claunia commented 2026-01-30 22:14:21 +00:00
Owner
Copy Link

Originally created by @DHowett-MSFT on GitHub (May 13, 2019).

Originally assigned to: @zadjii-msft on GitHub.

Proposal

Include a default profiles.json in the package, allow the user to override it and merge their settings into it.

Questions

  • What if you want to delete a stock profile?
  • Optional features?
  • Turn off defaults? Perhaps {... "thing": null, }?

Child Work Items

  • #1880 Keep the original json blob around, and when we make edits to it, only append them or replace the existing values

Things that need to be done to accomplish Cascading Settings

Each <h3> here is a single PR into master, broken into either sub-PRs or work for me to do as a part of that PR

[x] Don't re-serialize settings on load (PR: #2475)

This should be done first and foremost. This is not really helping anyone. Old settings all migrate nicely, so whatever. Let's just pull it.

[_] Combine a defaults.json with a profiles.json (PR: #2515)

  • Add a defaults.json to the package
  • Create a function for layering a Json::Value on top of an existing object
  • Add tests for layering a profile json blob on top of a profile
  • Add functions to search a list of Profiles for a duplicate, and layer on that dupe or create a new Profile if no such dupe exists.
  • Ensure we can layer each of the following: (WITH TESTS)
    • layer profiles
    • layer color schemes
    • layer keybindings (for a matching key, the user action should override the default action) (NEEDS TESTS)
    • layer globals (NEEDS TESTS)
  • When loading settings, load defaults, then layer user settings on top of default profiles
  • Maintain user settings ordering, not defaults+user ordering
  • Add support for unbinding default keys
    • unbind with "unbound"
    • unbind with null
  • Add support for hiding profiles
  • Ensure that we can reset optional default settings with null (e.g. "iconPath": null)
  • Create the User Settings file if it doesn't exist
  • Stamp the "defaults.json" file into the code, so we can't possibly fail loading it
  • Add support for Alt clicking on "settings" to launch the defaults.json file
  • default construct profiles with scheme "Campbell" to make "scheme" and unnecessary setting in the partial diff

[_] Add Dynamic Profile Generators

  • Add Dynamic Profile Generator for WSL
    • Create Dynamic Profile Generator interface
    • Provide DPG's with GetNamespaceGuid and GetGuidForName functions from App somehow We're not doing this anymore. We'll create the GUID for the profile when it's returned, if it has a GUID of {0}
      • Add a test for generateing a guid based on namespace if GUID is {0}
    • Add layering for dynamic profiles based on guid and source, not just guid
  • Add Dynamic Profile Generator for Powershell Core
  • Add Dynamic Profile Generator for Azure Cloud Shell
  • Ensure that existing WSL, Powershell Core, and Azure profiles gracefully migrate to dynamic profiles
  • Add disabledProfileSources in user settings to hide dynamic profiles by namespace
  • On first launch of the terminal, if Powershell Core exists, make it the default profile
  • When adding this profiles, insert them into our JSON parse tree to save them
    • Only add the delta between the default profile and the dynamic profile's default state to the json. Don't include any user customizations (though at this point there won't be any)
  • Ensure adding a dynamic entry doesn't reformat settings
  • For profiles that were created from a dynamic profile source, they'll have both a guid and source guid that must both match. If a user profile with a source set does not find a matching profile at load time, the profile should be ignored.
  • profile diffs should probably not include "table". Probably don't need to include in the diff keys that are std::nullopt in both the base and derived.
  • Make sure to re-order profiles so they're { user profiles, dynamics not in user profiles, defaults not in user profiles }

[_] Smart Serializing

This would be needed for a Settings UI, so we don't necessarily need it for 1.0

  • Keep the original JSON parse tree around in memory
  • Only serialize things different from defaults
    • profiles
    • schemes
    • keybindings
Originally created by @DHowett-MSFT on GitHub (May 13, 2019). Originally assigned to: @zadjii-msft on GitHub. **Proposal** Include a default `profiles.json` in the package, allow the user to override it and merge their settings into it. **Questions** * What if you want to delete a stock profile? * Optional features? * Turn off defaults? Perhaps `{... "thing": null, }`? ### Child Work Items * [x] #1880 Keep the original json blob around, and when we make edits to it, only append them or replace the existing values <hr> ## Things that need to be done to accomplish Cascading Settings Each `<h3>` here is a single PR into master, broken into either sub-PRs or work for me to do as a part of that PR ### [x] Don't re-serialize settings on load (PR: #2475) This should be done first and foremost. This is not really helping anyone. Old settings all migrate nicely, so whatever. Let's just pull it. ### [_] Combine a defaults.json with a profiles.json (PR: #2515) * [x] Add a defaults.json to the package * [x] Create a function for layering a `Json::Value` on top of an existing object * [x] Add tests for layering a profile json blob on top of a profile * [x] Add functions to search a list of `Profile`s for a duplicate, and layer on that dupe or create a new `Profile` if no such dupe exists. * [x] Ensure we can layer each of the following: (WITH TESTS) * [x] layer profiles * [x] layer color schemes * [x] layer keybindings (for a matching key, the user action should override the default action) **(NEEDS TESTS)** * [x] layer globals **(NEEDS TESTS)** * [x] When loading settings, load defaults, then layer user settings on top of default profiles * [x] Maintain user settings ordering, not defaults+user ordering * [x] Add support for unbinding default keys - [x] unbind with `"unbound"` - [x] unbind with `null` * [x] Add support for hiding profiles * [x] Ensure that we can reset optional default settings with `null` (e.g. `"iconPath": null`) * [x] Create the User Settings file if it doesn't exist * [x] Stamp the "defaults.json" file into the code, so we can't possibly fail loading it * [x] Add support for Alt clicking on "settings" to launch the defaults.json file * [x] default construct profiles with scheme "Campbell" to make "scheme" and unnecessary setting in the partial diff ### [_] Add Dynamic Profile Generators * [x] Add Dynamic Profile Generator for WSL * [x] Create Dynamic Profile Generator interface * [x] ~~Provide DPG's with `GetNamespaceGuid` and `GetGuidForName` functions from `App` somehow~~ We're not doing this anymore. We'll create the GUID for the profile when it's returned, if it has a GUID of {0} - [x] Add a test for generateing a guid based on namespace if GUID is {0} * [x] Add layering for dynamic profiles based on `guid` and `source`, not _just_ `guid` * [x] Add Dynamic Profile Generator for Powershell Core * [x] Add Dynamic Profile Generator for Azure Cloud Shell * [x] Ensure that existing WSL, Powershell Core, and Azure profiles gracefully migrate to dynamic profiles * [x] Add `disabledProfileSources` in user settings to hide dynamic profiles by namespace * [ ] On first launch of the terminal, if Powershell Core exists, make it the default profile * [x] When adding this profiles, insert them into our JSON parse tree to save them * [x] Only add the delta between the default profile and the dynamic profile's default state to the json. Don't include any user customizations (though at this point there won't be any) * [x] Ensure adding a dynamic entry doesn't reformat settings * [ ] For profiles that were created from a dynamic profile source, they'll have both a `guid` and `source` guid that must _both_ match. If a user profile with a `source` set does not find a matching profile at load time, the profile **should be ignored**. * [ ] profile diffs should probably not include `"table"`. Probably don't need to include in the diff keys that are `std::nullopt` in both the base and derived. * [ ] Make sure to re-order profiles so they're { user profiles, dynamics not in user profiles, defaults not in user profiles } ### [_] Smart Serializing This would be needed for a Settings UI, so we don't necessarily need it for 1.0 * [ ] Keep the original JSON parse tree around in memory * [ ] Only serialize things different from defaults * [x] profiles * [ ] schemes * [ ] keybindings
claunia commented 2026-01-30 22:14:22 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 13, 2019):

This will be helped by UUIDv5 profile GUIDs. I'll file that later.

@DHowett-MSFT commented on GitHub (May 13, 2019): This will be helped by UUIDv5 profile GUIDs. I'll file that later.
claunia commented 2026-01-30 22:14:22 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (May 29, 2019):

The default profiles.json should also be recreated from the application itself if the user makes a breaking change. They could uninstall and then reinstall, but that has a lot of negative problems as well such as losing any customizations they might have already made. It'd be better to give a path for recovery if the user makes a mistake and there is a chance this could happen if the user is given the chance to modify on their own.

@rbeesley commented on GitHub (May 29, 2019): The default profiles.json should also be recreated from the application itself if the user makes a breaking change. They could uninstall and then reinstall, but that has a lot of negative problems as well such as losing any customizations they might have already made. It'd be better to give a path for recovery if the user makes a mistake and there is a chance this could happen if the user is given the chance to modify on their own.
claunia commented 2026-01-30 22:14:22 +00:00
Author
Owner
Copy Link

@Stanzilla commented on GitHub (Jun 23, 2019):

I would love to be able to overwrite per profile settings with a global one, let's say I want to use the same color scheme everywhere, setting it in the global section should do that.

@Stanzilla commented on GitHub (Jun 23, 2019): I would love to be able to overwrite per profile settings with a global one, let's say I want to use the same color scheme everywhere, setting it in the global section should do that.
claunia commented 2026-01-30 22:14:23 +00:00
Author
Owner
Copy Link

@Forinil commented on GitHub (Jun 28, 2019):

I'm not entirely sure why my issue (#1674) was linked here, but I want to stress that it is not a duplicate of #1289. In my case the autoscanning on first launch found WSL distro that was not installed and did not find any of those that were installed.

@Forinil commented on GitHub (Jun 28, 2019): I'm not entirely sure why my issue (#1674) was linked here, but I want to stress that it is not a duplicate of #1289. In my case the autoscanning **on first launch** found WSL distro that was not installed and did not find any of those that were installed.
claunia commented 2026-01-30 22:14:23 +00:00
Author
Owner
Copy Link

@Forinil commented on GitHub (Jun 28, 2019):

It seems that Windows Terminal configuration is synchronised across devices.
Why would you do that?
I'm sure I'm not the only person who has different shell combinations installed on different computers.

@Forinil commented on GitHub (Jun 28, 2019): It seems that Windows Terminal configuration is synchronised across devices. Why would you do that? I'm sure I'm not the only person who has different shell combinations installed on different computers.
claunia commented 2026-01-30 22:14:23 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 28, 2019):

The spec for this issue is tracking "dynamic profiles," which will resolve issues like "my WSL distribution doesn't exist, but it was in my profile" and "I have a WSL distribution that hasn't appeared in my list." That's why this is the "duplicate master" for those issues.

@DHowett-MSFT commented on GitHub (Jun 28, 2019): The spec for this issue is tracking "dynamic profiles," which will resolve issues like "my WSL distribution doesn't exist, but it was in my profile" and "I have a WSL distribution that hasn't appeared in my list." That's why this is the "duplicate master" for those issues.
claunia commented 2026-01-30 22:14:23 +00:00
Author
Owner
Copy Link

@Stanzilla commented on GitHub (Jun 28, 2019):

Now that I think about it, my issue about being able to override profile specific settings also doesn't quite fit as a duplicate here

@Stanzilla commented on GitHub (Jun 28, 2019): Now that I think about it, my issue about being able to override profile specific settings also doesn't quite fit as a duplicate here
claunia commented 2026-01-30 22:14:24 +00:00
Author
Owner
Copy Link

@stephtr commented on GitHub (Jun 29, 2019):

I'm not sure whether that's the right place to comment on, but regarding the "dynamic profiles", I would like them to also include Node, Python, C# (csi), ... shells by default (if installed).

@stephtr commented on GitHub (Jun 29, 2019): I'm not sure whether that's the right place to comment on, but regarding the "dynamic profiles", I would like them to also include Node, Python, C# (csi), ... shells by default (if installed).
claunia commented 2026-01-30 22:14:24 +00:00
Author
Owner
Copy Link

@kfarmer-msft commented on GitHub (Jul 3, 2019):

Couldn't WT register a URI scheme that apps could use to add themselves (eg, ms-terminal:///add-profile?guid=&cmdline=&icon=)?

That would avoid having to chase everyone's personal console apps around, as well as trying to locate good icons for them (don't forget VS Dev Prompt, Exchange Online tools, Azure, various databases...). Of course, developers would need to call that URI...

For Store apps, it'd be interesting if a new "Console" capability were available to mediate that discovery, but this isn't necessarily the place for that discussion.

@kfarmer-msft commented on GitHub (Jul 3, 2019): Couldn't WT register a URI scheme that apps could use to add themselves (eg, ms-terminal:///add-profile?guid=<guid>&cmdline=<cmdline>&icon=<icon path>)? That would avoid having to chase everyone's personal console apps around, as well as trying to locate good icons for them (don't forget VS Dev Prompt, Exchange Online tools, Azure, various databases...). Of course, developers would need to call that URI... For Store apps, it'd be interesting if a new "Console" capability were available to mediate that discovery, but this isn't necessarily the place for that discussion.
claunia commented 2026-01-30 22:14:24 +00:00
Author
Owner
Copy Link

@Forinil commented on GitHub (Jul 3, 2019):

It sounds interesting, although I’m guessing the developers wouldn’t bother
with it unless WT became popular. Also guid should not be a parameter,
but rather generated internally by WT to ensure uniqueness.

@Forinil commented on GitHub (Jul 3, 2019): It sounds interesting, although I’m guessing the developers wouldn’t bother with it unless WT became popular. Also `guid` should not be a parameter, but rather generated internally by WT to ensure uniqueness.
claunia commented 2026-01-30 22:14:25 +00:00
Author
Owner
Copy Link

@kfarmer-msft commented on GitHub (Jul 3, 2019):

I’m guessing the developers wouldn’t bother with it unless WT became popular

Hence my own comment on that ;)

Answer: Make WT popular. I for one hate command lines, but really am having a bit of fun with this thing, so perhaps there's hope yet.

guid should not be a parameter, but rather generated internally by WT to ensure uniqueness.

That means that multiple calls from the same console provider turn into multiple entries. Console providers need to proclaim their own identity, so they (not the terminal) should be in the job of determining the GUID.

This is no different today from applications having to be trusted to use legitimate GUIDs during their development. If such GUID-determination were really up to the terminal, then we could just ditch it and instead compose a hash of the profile entry at load time (having already been annoyed at the "Terminal silently broken because of multiple profiles having the same GUID after I add a couple new ones" problem).

@kfarmer-msft commented on GitHub (Jul 3, 2019): > I’m guessing the developers wouldn’t bother with it unless WT became popular Hence my own comment on that ;) Answer: Make WT popular. I for one hate command lines, but really am having a bit of fun with this thing, so perhaps there's hope yet. > `guid` should not be a parameter, but rather generated internally by WT to ensure uniqueness. That means that multiple calls from the same console provider turn into multiple entries. Console providers need to proclaim their own identity, so they (not the terminal) should be in the job of determining the GUID. This is no different today from applications having to be trusted to use legitimate GUIDs during their development. If such GUID-determination were really up to the terminal, then we could just ditch it and instead compose a hash of the profile entry at load time (having already been annoyed at the "Terminal silently broken because of multiple profiles having the same GUID after I add a couple new ones" problem).
claunia commented 2026-01-30 22:14:25 +00:00
Author
Owner
Copy Link

@rbeesley commented on GitHub (Jul 3, 2019):

If such GUID-determination were really up to the terminal, then we could just ditch it and instead compose a hash of the profile entry at load time.

Why couldn't we create a GUID from a hash if it isn't provided? That makes things a lot easier. If you create a profile but don't provide a GUID in the profiles.json, we could use the commandline property to generate one on behalf of the user. If there is already a hash that matches, add an instance number to the end of the string and hash again until you don't have a collision. As this string is only used to create the GUID and has no other intrinsic value, it could be tossed or added to the profile as well, since you could also just look for the max instance number and increment.

The value of this is that the GUID would be deterministic, unless you already had a profile for the same commandline property, but it would be easy for a user to generate a meaningful one on their own. Secondly, if an app registers a shell with WT, it could provide it's own token and if handled through a protocol, WT could respond with what token it used, handling collisions in its own.

In other words, if PowerShell wanted to register with "commandline" : "powershell.exe", and then some cmdlet were executed which would try to register it again, WT would just respond with what it chose. If a different app, for the sake of argument cmd.exe, tried to supply it's own GUID when registering, WT would either accept it and add the profile, or it would respond with the disambiguated profile it determined.

Apps get to provide their own if they choose to, but users don't need to worry about it for themselves, and WT will manage collisions and mitigate them in a deterministic way.

@rbeesley commented on GitHub (Jul 3, 2019): >If such GUID-determination were really up to the terminal, then we could just ditch it and instead compose a hash of the profile entry at load time. Why couldn't we create a GUID from a hash if it isn't provided? That makes things a lot easier. If you create a profile but don't provide a GUID in the profiles.json, we could use the commandline property to generate one on behalf of the user. If there is already a hash that matches, add an instance number to the end of the string and hash again until you don't have a collision. As this string is only used to create the GUID and has no other intrinsic value, it could be tossed or added to the profile as well, since you could also just look for the max instance number and increment. The value of this is that the GUID would be deterministic, unless you already had a profile for the same commandline property, but it would be easy for a user to generate a meaningful one on their own. Secondly, if an app registers a shell with WT, it could provide it's own token and if handled through a protocol, WT could respond with what token it used, handling collisions in its own. In other words, if PowerShell wanted to register with "commandline" : "powershell.exe", and then some cmdlet were executed which would try to register it again, WT would just respond with what it chose. If a different app, for the sake of argument cmd.exe, tried to supply it's own GUID when registering, WT would either accept it and add the profile, or it would respond with the disambiguated profile it determined. Apps get to provide their own if they choose to, but users don't need to worry about it for themselves, and WT will manage collisions and mitigate them in a deterministic way.
claunia commented 2026-01-30 22:14:25 +00:00
Author
Owner
Copy Link

@kfarmer-msft commented on GitHub (Jul 4, 2019):

Why couldn't we create a GUID from a hash if it isn't provided?

You could. You describe one possible hashing function, which while a good basic approach is prone to a race condition, where multiple runs would map order-dependent output hashes to different requests whose order is not knowable. If profile settings are intended to persist over the inevitable reinstall, this would be a problem.

You could push the problem out further by adding more information into the hash (working directory [problematic], name [should avoid, for localization reasons], ID of the requester [consider the complaint raised about the requester supplying a GUID for the profile.. how would this differ?], etc), but in the end it is easier IMO to just let the requester produce a GUID for the profile they're trying to register: there's a long and reasonably-respected history around cooperating where IDs are concerned. It really only breaks down through intentional hijacking, and I think it's good enough.

@kfarmer-msft commented on GitHub (Jul 4, 2019): > Why couldn't we create a GUID from a hash if it isn't provided? You could. You describe one possible hashing function, which while a good basic approach is prone to a race condition, where multiple runs would map order-dependent output hashes to different requests whose order is not knowable. If profile settings are intended to persist over the inevitable reinstall, this would be a problem. You could push the problem out further by adding more information into the hash (working directory [problematic], name [should avoid, for localization reasons], ID of the requester [consider the complaint raised about the requester supplying a GUID for the profile.. how would this differ?], etc), but in the end it is easier IMO to just let the requester produce a GUID for the profile they're trying to register: there's a long and reasonably-respected history around cooperating where IDs are concerned. It really only breaks down through intentional hijacking, and I think it's good enough.
claunia commented 2026-01-30 22:14:25 +00:00
Author
Owner
Copy Link

@rkeithhill commented on GitHub (Jul 5, 2019):

I was just going to submit such a feature request. But I was thinking of the defaults as just another section of profiles.json e.g.:

  ...
  "profileDefaults": {
    "acrylicOpacity" : 0.85,
    "closeOnExit" : true,
    "colorScheme" : "Campbell",
    "cursorColor" : "#FFFFFF",
    "cursorShape" : "bar",
    "fontFace" : "Consolas",
    "fontSize" : 11,
    "historySize" : 9001,
    "padding" : "5, 5, 5, 5",
    "snapOnInput" : true,
    "startingDirectory" : "%USERPROFILE%",
    "useAcrylic" : true
  },
  "profiles" :
  [
      {
          "colorScheme" : "One Half Dark",
          "commandline" : "C:\\Program Files\\PowerShell\\6\\pwsh.exe",
          "guid" : "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
          "icon" : "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png",
          "name" : "PowerShell Core"
      },
      {
          "background" : "#012456",
          "commandline" : "powershell.exe",
          "guid" : "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
          "icon" : "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png",
          "name" : "Windows PowerShell"
      },
      {
          "commandline" : "cmd.exe",
          "guid" : "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
          "icon" : "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png",
          "name" : "cmd"
      },
      ...

You should only need to supply non-default values like name, guid and commandline for each individual profile. This makes individual profiles simpler and gives users the ability to easily change say the font size for all their profiles.

@rkeithhill commented on GitHub (Jul 5, 2019): I was just going to submit such a feature request. But I was thinking of the defaults as just another section of `profiles.json` e.g.: ```json ... "profileDefaults": { "acrylicOpacity" : 0.85, "closeOnExit" : true, "colorScheme" : "Campbell", "cursorColor" : "#FFFFFF", "cursorShape" : "bar", "fontFace" : "Consolas", "fontSize" : 11, "historySize" : 9001, "padding" : "5, 5, 5, 5", "snapOnInput" : true, "startingDirectory" : "%USERPROFILE%", "useAcrylic" : true }, "profiles" : [ { "colorScheme" : "One Half Dark", "commandline" : "C:\\Program Files\\PowerShell\\6\\pwsh.exe", "guid" : "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "icon" : "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png", "name" : "PowerShell Core" }, { "background" : "#012456", "commandline" : "powershell.exe", "guid" : "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "icon" : "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png", "name" : "Windows PowerShell" }, { "commandline" : "cmd.exe", "guid" : "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "icon" : "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png", "name" : "cmd" }, ... ``` You should only need to supply non-default values like `name`, `guid` and `commandline` for each individual profile. This makes individual profiles simpler and gives users the ability to easily change say the font size for all their profiles.
claunia commented 2026-01-30 22:14:26 +00:00
Author
Owner
Copy Link

@adrianghc commented on GitHub (Sep 5, 2019):

Couldn't WT register a URI scheme that apps could use to add themselves (eg, ms-terminal:///add-profile?guid=&cmdline=&icon=)?

That would avoid having to chase everyone's personal console apps around, as well as trying to locate good icons for them (don't forget VS Dev Prompt, Exchange Online tools, Azure, various databases...). Of course, developers would need to call that URI...

For Store apps, it'd be interesting if a new "Console" capability were available to mediate that discovery, but this isn't necessarily the place for that discussion.

I came to the repo to suggest exactly this, good to see I'm not alone with this.

I think one of the advantages of having the GUID be provided by the shell that wants to register itself instead of generated by WT on call is that uninstalls and subsequent unregistrations of shells would become easier that way.

As for making WT popular, I wonder if one day when WT is far enough in development it could be added to Windows as an optional feature. In that case shell apps could check if WT is present during their install and expect it with a certain probability.

Perhaps we should create a separate issue for this?

@adrianghc commented on GitHub (Sep 5, 2019): > Couldn't WT register a URI scheme that apps could use to add themselves (eg, ms-terminal:///add-profile?guid=&cmdline=&icon=)? > > That would avoid having to chase everyone's personal console apps around, as well as trying to locate good icons for them (don't forget VS Dev Prompt, Exchange Online tools, Azure, various databases...). Of course, developers would need to call that URI... > > For Store apps, it'd be interesting if a new "Console" capability were available to mediate that discovery, but this isn't necessarily the place for that discussion. I came to the repo to suggest exactly this, good to see I'm not alone with this. I think one of the advantages of having the GUID be provided by the shell that wants to register itself instead of generated by WT on call is that uninstalls and subsequent unregistrations of shells would become easier that way. As for making WT popular, I wonder if one day when WT is far enough in development it could be added to Windows as an optional feature. In that case shell apps could check if WT is present during their install and expect it with a certain probability. Perhaps we should create a separate issue for this?
claunia commented 2026-01-30 22:14:26 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 24, 2019):

:tada:This issue was addressed in #2515, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.🎉

Handy links:

@ghost commented on GitHub (Sep 24, 2019): :tada:This issue was addressed in #2515, which has now been successfully released as `Windows Terminal Preview v0.5.2661.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.5.2661.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:14:27 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 24, 2019):

:tada:This issue was addressed in #2603, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.🎉

Handy links:

@ghost commented on GitHub (Sep 24, 2019): :tada:This issue was addressed in #2603, which has now been successfully released as `Windows Terminal Preview v0.5.2661.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.5.2661.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Issue-Feature Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1035
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?