Color Table | Font Face, size | Status Line Visibility, contents
Cursor Color | Scrollbar Visibility | ~~Window Size~~[1]
History Size | |
Buffer Size [1] | |
* [1] I believe only the "Default" or "Initial" buffer size should be the one we truly store in the settings. When the app first boots up, it can use that value to with the font size to figure out how big its window should be. When additional tabs/panes are created, they should inherit the size of the existing window. Similarly, VS could first calculate how much space it has available, then override that value when creating the terminal.
Project Cascadia needs to be able to persist settings as a bipartite globals-profiles structure.
VS needs to be able to persist settings just as a simple set of global settings.
When the application needs to retrieve these settings, they need to use them as a tripartite structure: frontend-component-terminal settings.
Each component implementation will also ned to have some settings that control it.
The terminal also will have some settings specific to the terminal.
### Globals and Profiles
With \*nix-like terminals, settings are typically structured as two parts:
Globals and Profiles.
Globals are settings that affect the entirety of the terminal application. They wouldn't be different from one pane to the next. An example is the Terminal KeyBindings - these should be the same for all tabs/panes that are running as a part of the terminal application.
Profiles are what you might consider per-application settings. These are settings that can be different from one terminal instance to the next. One of the primary differentiators between profiles is the commandline used to start the terminal instance - this enables the user to have both a `cmd` profile and a `powershell` profile, for example. Things like the color table/scheme, font size, history length, these all change per-profile.
Per-Profile | Globals
------------------------|------------------------
Color Table | Keybindings
Cursor Color | Scrollbar Visibility
History Size | Status Line Visibility, contents
Font Face, size | Window Size
Shell Commandline |
### Simple Settings
An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specifc to Project Cascadia.
The Application can store whatever settings it wants in its implementation of `IApplicationSettings`. When it instantiates a Terminal Component, it will pass its `IComponentSettings` to it.
The Component will then create the Terminal using the `TerminalSettings`.
#### Project Cascadia Settings Details
The `CascadiaSettings` will store the settings as two parts:
* A set of global data & settings
* A list of Profiles, that each have more data
When Cascadia starts up, it'll load all the settings, including the Globals and profiles. The Globals will also tell us which profile is the "Default" profile we should use to instantiate the terminal.
Using the globals and the Profile, it'll convert those to a `ApplicationSettings : IApplicationSettings`.
It'll read data from that `ApplicationSettings` to initialize things it needs to know.
* It'll determine whether or not to display the status line
* It'll query the Component settings for the default size of the component, so it knows how big of a space it needs to reserve for it
It'll then instantiate a `UWPTerminalComponent` and pass it the `UWPComponentSettings`.
This is a rough draft of what these members might all be like.
However, when Cascadia's settings change, we're going to possibly change some global settings and possibly some profile settings. The profile's that are changed may or may not be currently active.
> Say we have two different panes open with different profiles (A and B).
> What happens if we change the settings for one profile's font and not the other's?
> ~~We resize the height of the terminal to account for the change in height of the win~~
>
> We should never change the window size in response to a settings change if there is more than one tab/pane open.
> > never?
Cascadia would have to maintain a mapping of which components have which profiles:
```csharp
class CascadiaTerminalInstance
{
GUID ProfileGuid;
UWPTerminalComponent component;
}
```
Then, when the settings are closed, it'll enumerate all of the components it has loaded, and apply the updated settings to them. It'll do this by looking up the profile GUID of the component, then getting the `ApplicationSettings` for the profile, then calling `UpdateSettings` on the component.
~~We need to have a way so that only the currently foreground component can change the window size.~~
I don't like that - if we change the font size, we should just recalculate how many characters can fit in the current window size.
## Questions / TODO
* How does this interplay with setting properties of the terminal component in XAML?
* I would think that the component would load the XAML properties first, and if the controlling application calls `UpdateSettings` on the component, then those in-XAML properties would likely get overwritten.
* It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entriely in XAML, go right ahead.
* Any settings that *are* exposed through XAML properties *should* also be exposed in the component's settings implementation as well.