Summary of the Pull Request

Currently, the TermControl and ControlCore recieve a settings object that implements IControlSettings. They use for this for both reading the settings they should use, and also storing some runtime overrides to those settings (namely, Opacity). The object they recieve currently is a T.S.M.TerminalSettings object, as well as another TerminalSettings object if the user wants to have an unfocusedAppearance. All these are all hosted in the same process, so everything is fine and dandy.

With the upcoming move to having the Terminal split into multiple processes, this will no longer work. If the ControlCore in the Content Process is given a pointer to a TerminalSettings in a certain Window Process, and that control is subsequently moved to another window, then there's no guarantee that the original TerminalSettings object continues to exist. In this scenario, when window 1 is closed, now the Core is unable to read any settings, because the process that owned that object no longer exists.

The solution to this issue is to have the ControlCore's own their own copy of the settings they were created with. that way, they can be confident those settings will always exist. Enter ControlSettings, a dumb struct for just storing all the contents of the Settings. I used x-macros for this, so that we don't need to copy-paste into this file every time we add a setting.

Changing this has all sorts of other fallout effects:

• Previewing a scheme/anything is a tad bit more annoying. Before, we could just sneak the previewed scheme into a TerminalSettings that lived between the settings we created the control with, and the settings they were actually using, and it would just work. Even explaining that here, it sounds like magic, because it was. However, now, the TermControl can't use a layered TerminalSettings for the settings anymore. Now we need to actually read out the current color table, and set the whole scheme when we change it. So now there's also a Microsoft.Terminal.Core.Scheme struct for holding that data.
  • Why a struct? Because that will go across the process boundary as a blob, rather than as a pointer to an object in the other process. That way we can transit the whole struct from window to core safely.
• A TermControl doesn't have a IControlSettings at all anymore - it initalizes itself via the settings in the Core. This will be useful for tear-out, when we need to have the TermControl initialize itself from just a ControlCore, without being able to rebuild the settings from scratch.
• The TabTests that were written under the assumption that the Control had a layered TerminalSettings obviously broke, as they were designed to. They've been modified to reflect the new reality.
• When we initialize the Control, we give it the settings and the UnfocusedAppearance all at once. If we don't give it an unfocusedAppearance, it will just use the focused appearance as the unfocused appearance.
• The Control no longer can write settings to the ControlSettings. We don't want to be storing things in there. Pretty much everything we set in the control, we store somewhere other than in the settings object itself. However, opacity and useAcrylic, we need to store in a handy new RUNTIME_SETTING property. We can write those runtime overrides to those properties.
• We no longer store the color scheme for a pane in the persisted state. I'm tracking that in megathread: Window State Persistence #9800. I don't think it's too hard to add back, but I wanted this in front of eyes sooner than later.

References

• Add support for tab tearoff and tab merge #1256
• Scenario: Windows Terminal 2.0 Process Model Improvements #5000
• Enable previewing the color scheme in the command palette #9794 has the scheme previewing in it.
• Additional commands could be previewable #9818 is WAY more possible now.

PR Checklist

• Surprisingly there wasn't ever a card or issue for this one. This was only ever a bullet point in Scenario: Windows Terminal 2.0 Process Model Improvements #5000.
• A bunch of these issues were fixed along the way, though I never intended to fix them:
  • Closes Previewing a scheme with an unfocused appearance set straight up doesn't work #11571
  • Closes Duplicate code in TermControl.cpp #11586
  • Closes Make all the ICoreSettings / IControlSettings properties getters-only #7219
  • Closes Color scheme preview via command palette and settings reload resets zoom level #11067
  • I think Introduce AtlasEngine - A new text rendering prototype #11623 actually ended up resolving this one, but I'm double tapping on it here: Closes Background image does not display with antialiasingMode = cleartype #5703
• I work here
• Tests added/passed
• [n/a] Requires documentation to be updated

Detailed Description of the Pull Request / Additional comments

Along the way I tried to clean up code where possible, but not too agressively.

I didn't end up converting the various MockTerminalSettings classes used in tests to the x macros quite yet. I wanted to merge this with #11416 in main before I went too crazy.

Validation Steps Performed

• Scheme previewing works
• Adjusting the font size works
• focused/unfocused appearances still work
• mouse-wheeling opacity still works
• acrylic & cleartype still does the right thing
• saving the settings still works
• going wild on sliding the opacity slider in the settings doesn't crash the terminal
• toggling retro effects with a keybinding still works
• toggling retro effects with the command palette works
• The matrix of (useAcrylic(true,false))x(opacity(50,100))x(antialiasingMode(cleartype, grayscale)) works as expected. Slightly changed, falls back to grayscale more often, but looks more right.