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

[DHowett-MSFT]

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

• ignore json profile data not understood #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

[DHowett-MSFT]

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

[rbeesley]

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.

[Stanzilla]

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.

[adrianghc]

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?

[ghost]

🎉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
• Store Download

[ghost]

🎉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
• Store Download