Spec for Default Profile Settings

[zadjii-msft]

Refer to the original issue: Default Profile for Common Profile Settings #2325

So this is my summary of everything we discussed regarding "default profile settings". The original PR was #3369, but we were not in agreement on the UX, so this PR is for discussion about that.

I put forth 4 proposals that were mentioned in the discussion.

We'll iterate on this in the comments below, and if we can come to a consensus, I'll update the spec accordingly.

[DHowett-MSFT]

One additional concern:

I still want a place to define a default settings block that isn't one of my profiles.

• If it has to be a real live profile, would it be.. hidden=true?
  • Would the inheritee inherit the hidden=true?
  • If it wasn't, what would stop it from showing up in my list?
• If it had to be a real profile, would I then have to override the commandline?

Imagine this scenario:

"profiles": [
	{
		"guid": "{abcd}",
		"name": "cmd",
		"fontFace": "Cascadia Code",
		"background": "#f00ff0",
		"commandline": "cmd.exe"
	},
	{
		"guid": "{defg}",
		"name": "WSL",
		"inheritsFrom": "{abcd}", // inherit from cmd because i put my defaults in there
		"source": "Microsoft.Terminal.Wsl" // AUTOGENERATED DYNAMIC PROFILE
	}
]

Does "WSL" inherit the commandline? It should, since it inherits everything from cmd.

we probably do want inheritance eventually: I want to be able to do this:

"profiles": [
	{
		"guid": "{defg}",
		"name": "Ubuntu",
		"source": "Microsoft.Terminal.Wsl" // AUTOGENERATED DYNAMIC PROFILE
	},
	{
		"name": "Ubuntu (dark theme)",
		"inheritsFrom": "{defg}", // Ubuntu
		"background": "#000000",
		"colorScheme": "Really quite dark",

		// I don't know the commandline: it's based on the ubuntu profile.
		// I shouldn't _need_ to know it.

		"source": "Microsoft.Terminal.Wsl"
	}
]

that is out of spec for this proposal.

[zadjii-msft]

I concur. 4 seems like the weakest proposal on paper, for this feature. Good overall, but far too heavy-handed for "these settings apply to every profile".

[carlos-zamora]

It seems like source and inheritsFrom are kinda trying to do the same thing then. What if we combined them? source is either a...

• string (i.e.: Microsoft.Terminal.WSL or other dynamic profile ones)
• guid: directly inherit the resolved profile with this guid

We already check for duplicate guids so we know it's a one-to-one relationship between a guid and a profile.

[carlos-zamora]

Argh. I want it but you're probably right about it being too heavy-handed for this feature. 😭

[DHowett-MSFT]

also ugh the schema violation

[DHowett-MSFT]

I do not consider a conflict with defaults.json to be a reason to not do a thing. If the problem is one of user education, we can get the word out on the streets in a different way.

[zadjii-msft]

I strongly agree.

[zadjii-msft]

My opinion on the matter is that proposal 1 is the easiest to identify it's purpose, mentally parse, and easiest to change in the file. I don't believe that defaultSettings or profileDefaultSettings (or heck even globalDefaultSettings) is too hard to grasp as being a different thing from defaults in the defaults.json, and that documentation will make this easier to understand.

That's my opinion though, and I'm susceptible to being convinced otherwise.

[miniksa]

I personally like 4 the most for its infinite flexibility, but I'm biased since I am the one who verbally suggested that in the meeting.

I would like to throw out 2 because magic constants are terrible.

But if I have to lose on my "infinitely flexible" one, I prefer 3 to 1 because I like the scoped use of the word "default" with the object.

[leonMSFT]

I'm partial to approach 3. I like how it looks the most. It's the most intuitive for me personally, and it can get rid of confusion (if there's any) around defaultProfile, defaultSettings, and all default related keys surrounding profiles. However, I totally get that having that big of a schema change could make this feature unnecessarily hard.

I'm okay with 1. I agree with you @zadjii-msft, any confusion around approach 1 could get ironed out with some documentation.

One thing I'd like to propose is to rename defaultProfile to something like startupProfile, and place the Default Profile Settings in a key named literally, defaultProfileSettings. I may be forgetting some situations where this might be even more confusing, so disregard this suggestion if so.

[carlos-zamora]

At one point there was a 5th proposal:

• any of the settings for profiles should freely go in globals.

{
    "defaultProfile": "<guid>",
    "fontFace": "Cascadia Code",
    "profiles": [ ... ]
}

From what I remember, this was abandoned because in a situation like the one above, it is unclear if "fontFace" would change the App's font vs the profiles' font.

[carlos-zamora]

Personal favorite (though I really just want inheritance). I really like the following aspects of it...

1. Easy schema change
2. Supporting the "profiles": [ ... ] vs "profiles": { "defaults": { ... }, "list": [ ... ] } syntax change is clever. I like the idea of just overloading it. Then maybe deprecating support for the legacy version at some point.
3. Scoping this to "profiles" is really easy to understand. No doubt that I am specifically making changes to my profiles

I'm thinking about what this would look like with the Settings UI. It would feel pretty intuitive. You could choose which specific profile you want to edit. Or just choose "edit my default profile settings" and it would edit this thing directly.

Love it.

[DHowett-MSFT]

Given that we can do 3 with a good fallback for "just treat it as an array", I think I'm sold on it.

[zadjii-msft]

There's a dev team quorum on proposal 3, so I'll update the spec to reflect this. Thanks for the discussion all!

[DHowett-MSFT]

Marking Request Changes now that we've settled on proposal 3.

[carlos-zamora]

Gracias

[zadjii-msft]

@miniksa / @leonMSFT / @cinnamon-msft can I get a third on this spec?

[DHowett-MSFT]

@microsoft/windows-console-team this needs a third.