Draft Spec for Cascading Default + User Settings

[zadjii-msft]

Summary of the Pull Request

Adds a spec describing how a cascading settings model should work. This spec describes a model where there are two sets of settings, "Default" and "User" settings, and the two are layered to create the runtime settings.

PR Checklist

• Specs Feature Request: Cascading settings (with a hardcoded default.json?) #754
• CLA signed. If not, go over here and sign the CLA
• [N/A] Tests added/passed
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

Just read the spec.

[DHowett-MSFT]

I love this. It's great.

I have a huge question:

do we need a locally cascading default profile?

Here's what I'm thinking:

I want to set 100% of my profiles to cursorShape: pie and cursorColor: raspberry, but if I have more and more profiles that will get increasingly onerous when I then want to change cursorColor: blueberry...

@carlos-zamora has some requests in this area too.

[mcpiroman]

Here is my model of settings, adopted form #1513. It's main goals are:

1. Graduality and modularity
2. Reduction of boilerplate
3. Easy of syncing and usage on large scale

The things I didn't mention below remain as their are now or in above spec/discussion, like default settings. I'd make this an issue or PR but I was instructed to write it here.

• There are 2 kinds of settings:

  • Application/window - e.g. defaultProfile, showOpenTermionalInCurrentDirectory, windowBorderStyle.
  • Pane - everything else like font, colors/color schema.

• There are profiles, but thier function is limited to being pretty much just a button. Essentially, they only have following attributes:

  • guid
  • name - the text displayed on button
  • icon

• All settings are defined in groups which are JSON elements like the present globals.

• Groups have conditions that activate them. They may be:

  1. executiong command line - with support for pattern matching
  2. profile guid that launched the pane - note that terminal/pane could be launched without profile e.g. by directly executing program or script (like double clicking cmd.exe)
  3. user name
  4. machine name / other machine identifier
  5. domain name
  6. no condition - simply always active ("global")

• Groups that were enabled by the condition that is higher in previous list overwrite groups enabled by these that are lower.

• All groups can have pane settings, but only these enabled by user name or below can have application settings.

• Groups may also include other groups by theirs guid/name. Once included, these would be active regardless to the their condition.

• All groups can be in single file, but may also be separated into multiple files. E.g. each user may have file in his own user directory, there may be one on the machine for all users and one shared in domain for all computers. This resolves problem with permissions to edit local settings. Decision on the layout of this files depends on administrator.

• Terminal at startup looks only at the local settings file. This file (and others too) may have include element with paths to other files that terminal then loads.

• For simplicity, profiles may have settings in their body. Terminal treats it as though it was a group with a condition on the profile's guid.

[carlos-zamora]

The spec is very detailed (which is great for what we need right now), but I definitely think we need some kind of easily accessible tutorial or user docs when we release this feature.

[carlos-zamora]

I'm also confused by defaults.json. So, it's a local json file that we generate from our code, but they can't make changes to it? It sounds like it might just be easier to hardcode these default in our code and refer to them like we do now. Is this supposed to be a stepping stone toward them being able to just define what they want their defaults to be?

[zadjii-msft]

@carlos-zamora you better believe there's going to be a much easier doc for this when it comes out. This is more the technical implementation details, when I make an actual PR for it, I'll make sure to include a settings-howto.md with a user-friendly explanation of how the layering works.

Theoretically, everything the user currently has will still work, though some may become redundant. Future user profiles will be simpler to read, with the minimum set of key-value pairs in them.

[sba923]

Just my €0.02: IMVHO this has lower priority than #1770. Of course, the full settings experience needs both.

[zadjii-msft]

@miniksa @DHowett-MSFT can I get some additional passes on this?

[miniksa]

I'm good with this. I just left a few nits.