Add support for changing the active color scheme with an action

[zadjii-msft]

Summary of the Pull Request

Adds the setColorScheme action, to change the color scheme of the active control to one given by the name parameter. name is required. If name is not the name of a color scheme, the action does nothing.

References

• Being done as a stepping stone to Allow commands to be previewed in the command palette #6689

PR Checklist

• Closes Add a shortcut action for switching to a specific color scheme #5401
• I work here
• Tests added/passed
• [n/a] Requires documentation to be updated

Detailed Description of the Pull Request / Additional comments

Technically, the action is being done by changing the settings of the current TerminalSettings of the TermControl. Frankly, it should be operating on a copy of the TermControl's IControlSettings, then updating the control's settings, or the Control should just listen for changes to it's setting's properties, and update in real time (without a manual call to UpdateSettings. However, both those paths are somewhere unknowable beyond #6904, so we'll just do this for now.

Validation Steps Performed

• tested manually with a scheme that exists
• tested manually with a scheme that doesn't exist

[carlos-zamora]

• Update docs
• What happens when the user misspells the scheme name?
  • Right now, it looks like you go all the way down to CascadiaSettings::ApplyColorScheme and just don't apply the scheme.
  • (Option 1) Should we have some sort of validation/warning? Then we prevent adding a dead keybinding. (this is my preferred route)
  • (Option 2) Should we mark this keybinding as un-handled, and pass the key event straight to the terminal? (this might be a fine way to handle it if option 1 is too much work? But I still think we should do option 1)

[zadjii-msft]

• What happens when the user misspells the scheme name?
  • Right now, it looks like you go all the way down to CascadiaSettings::ApplyColorScheme and just don't apply the scheme.
  • (Option 1) Should we have some sort of validation/warning? Then we prevent adding a dead keybinding. (this is my preferred route)
  • (Option 2) Should we mark this keybinding as un-handled, and pass the key event straight to the terminal? (this might be a fine way to handle it if option 1 is too much work? But I still think we should do option 1)

I don't think the validation code can really handle that right now - I'll file a follow up for now.

I will do the "don't mark it as handled" thing now.

[zadjii-msft]

@carlos-zamora Docs PR: MicrosoftDocs/terminal#105

[ghost]

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[ghost]

🎉Windows Terminal Preview v1.3.2382.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download