Add Spec for winrt TerminalSettings

[carlos-zamora]

Summary of the Pull Request

This introduces a spec for (what I like to call) winrt TerminalSettings. Basically, we need to move over some of the code that resides in TerminalApp that relates to the settings model, then expose some of the settings objects as winrt objects. Doing so will allow us to access/modify settings across different project layers (a must-have for the Settings UI).

References

#885 - winrt Terminal Settings issue
#1564 - spec for most of the backend work for Settings UI

[zadjii-msft]

Gonna throw this out there without reading the spec yet - AppSettings. That way we avoid the redundant Terminal - Microsoft.Terminal.AppSettings

[DHowett]

should the namespace and DLL be Microsoft.Terminal.Settings.Model for completeness' sake?

[zadjii-msft]

I have thoughts, so let's discuss. I think the winrt-ification of the app settings is important, but I think we can do that without mucking up the layering too much.

[DHowett]

I think I'm fine with this. It's a very small spec ;P

[DHowett]

chatted; i'd like this spec to flesh out the model API a little more. How does the app get a settings object? How does it save it? Who provides the json files? Who listens for json file changes?

[carlos-zamora]

The section on keybindings was discussed with Griese. The presented code is an excerpt from that discussion.

[carlos-zamora]

Next step: Add a section on how to identify where a setting comes from (and exposing that info to the TerminalSettingsEditor).

Sample Scenario

The TerminalSettingsEditor displays the following color scheme for each profile object

    "defaults": "Solarized", // profiles.defaults
    "A": "Raspberry", // profile A
    "B": "Tango", // profile B
    "C": "Solarized" // profile C

If profiles.defaults gets changed to "Tango", the following occurs

    "defaults": "Tango",
    "A": "Raspberry",
    "B": "Tango",
    "C": "Tango"

If profiles.defaults then gets changed to "Campbell", the following occurs

    "defaults": "Campbell",
    "A": "Raspberry",
    "B": "Tango", // Tango or Campbell?
    "C": "Campbell" // Tango or Campbell?

If you look at the configuration of settings.json, this is easy to figure out:

{
    "profiles":
    {
        "defaults": {
            // Scenarios:
            //  1. Solarized
            //  2. Tango
            //  3. Campbell
            "colorScheme": "Tango"
        },
        "list": [
            {
                "profile": "A",
                "colorScheme": "Raspberry"
            },
            {
                "profile": "B",
                "colorScheme": "Tango"
            },
            {
                "profile": "C"
            }
        ]
    }
}

But we need the TerminalSettingsEditor to indicate the source of the fallback value.

NOTE: recording fallback source is important for the following scenarios

• profiles.defaults
• copyFormatting keybinding arg
• Theming
• Keybindings

[carlos-zamora]

Next step: Add a section on how to identify where a setting comes from (and exposing that info to the TerminalSettingsEditor).

Sample Scenario
NOTE: recording fallback source is important for the following scenarios

• profiles.defaults
• copyFormatting keybinding arg
• Theming
• Keybindings

This should be an addendum. And I don't want to hold up #7667.

This shouldn't be news to most of the team since I presented it a while back.

[zadjii-msft]

I don't believe anything I have here rises above a nit. I'm not interested in bogging this spec down in the bureaucracy of perfection any longer, let's get 'er moving

[carlos-zamora]

Discussed offline that we'll merge this one in with 2 approvals. I'll create addendums to this spec.