2020-08-28 03:09:22 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
import "IAppearanceConfig.idl";
|
2021-07-01 19:08:46 +02:00
|
|
|
import "FontConfig.idl";
|
2021-02-20 00:50:52 +01:00
|
|
|
#include "IInheritable.idl.h"
|
|
|
|
|
|
|
|
#define INHERITABLE_PROFILE_SETTING(Type, Name) \
|
|
|
|
_BASE_INHERITABLE_SETTING(Type, Name); \
|
|
|
|
Microsoft.Terminal.Settings.Model.Profile Name##OverrideSource { get; }
|
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
namespace Microsoft.Terminal.Settings.Model
|
2020-08-28 03:09:22 +02:00
|
|
|
{
|
2021-02-20 00:50:52 +01:00
|
|
|
// This tag is used to identify the context in which the Profile was created
|
|
|
|
enum OriginTag
|
|
|
|
{
|
Reintroduce the Defaults page and the Reset buttons (#10588)
This pull request brings back the "Base Layer" page, now renamed to
"Defaults", and the "Reset to inherited value" buttons. The scope of
inheritance for which buttons will display has been widened.
The button will be visible in the following cases:
The user has set a setting for the current profile, and it overrides...
1. ... something in profiles.defaults.
2. ... something in a Fragment Extension profile.
3. ... something from a Dynamic Profile Generator.
4. ... something from the compiled-in defaults.
Compared to the original implementation of reset arrows, cases (1), (3)
and (4) are new. Rationale:
(1) The user can see a setting on the Defaults page, and they need a way
to reset back to it.
(3) Dynamic profiles are not meaningfully different from fragments, and
users may need a way to reset back to the default value generated
for WSL or PowerShell.
(4) The user can see a setting on the Defaults page, **BUT** they are
not the one who created it. They *still* need a way to get back to
it.
To support this, I've introduced another origin tag, "User", and renamed
"Custom" to "None". Due to the way origin/override detection works¹, we
cannot otherwise disambiguate between settings that came from the user
and settings that came from the compiled-in defaults.
Changes were required in TerminalSettings such that we could construct a
settings object with a profile that does not have a GUID. In making this
change, I fixed a bit of silliness where we took a profile, extracted
its guid, and used that guid to look up the same profile object. Oops.
I also fixed the PropertyChanged notifier to include the
XxxOverrideSource property.
The presence of the page and the reset arrows is restricted to
Preview- or Dev-branded builds. Stable builds will retain their current
behavior.
¹ `XxxOverrideSource` returns the profile *above* the current profile
that holds a value for setting `Xxx`. When the value is the
compiled-in value, `XxxOverrideSource` will be `null`. Since it's
supposed to be the profile above the current profile, it will also be
`null` if the profile contains a setting at this layer.
In short, `null` means "user specified" *or* "compiled in". Oops.
Fixes #10430
Validation
----------
* [x] Tested Release build to make sure it's mostly arrow-free (apart from fragments)
2021-07-10 00:03:41 +02:00
|
|
|
None = 0,
|
|
|
|
User,
|
2021-02-20 00:50:52 +01:00
|
|
|
InBox,
|
|
|
|
Generated,
|
2021-05-05 06:15:25 +02:00
|
|
|
Fragment,
|
|
|
|
ProfilesDefaults
|
2021-02-20 00:50:52 +01:00
|
|
|
};
|
|
|
|
|
2020-08-28 03:09:22 +02:00
|
|
|
enum CloseOnExitMode
|
|
|
|
{
|
|
|
|
Never = 0,
|
|
|
|
Graceful,
|
|
|
|
Always
|
|
|
|
};
|
|
|
|
|
2020-11-18 23:55:10 +01:00
|
|
|
[flags]
|
2020-10-16 00:27:27 +02:00
|
|
|
enum BellStyle
|
|
|
|
{
|
2021-05-25 00:51:03 +02:00
|
|
|
// !! If you update this, you must update the values in TerminalSettingsEditor/Profiles.xaml
|
2020-11-18 23:55:10 +01:00
|
|
|
Audible = 0x1,
|
2021-05-25 00:51:03 +02:00
|
|
|
Window = 0x2,
|
|
|
|
Taskbar = 0x4,
|
2020-11-18 23:55:10 +01:00
|
|
|
All = 0xffffffff
|
2020-10-16 00:27:27 +02:00
|
|
|
};
|
|
|
|
|
2021-02-19 19:11:07 +01:00
|
|
|
[default_interface] runtimeclass Profile : Windows.Foundation.IStringable {
|
2020-08-28 03:09:22 +02:00
|
|
|
Profile();
|
|
|
|
Profile(Guid guid);
|
|
|
|
|
2021-07-14 01:33:22 +02:00
|
|
|
void CreateUnfocusedAppearance();
|
|
|
|
void DeleteUnfocusedAppearance();
|
|
|
|
|
2021-08-24 00:00:08 +02:00
|
|
|
// True if the user explicitly removed this Profile from settings.json.
|
|
|
|
Boolean Deleted { get; };
|
2021-02-20 00:50:52 +01:00
|
|
|
OriginTag Origin { get; };
|
|
|
|
|
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184)
This commit reduces the code surface that interacts with raw JSON data,
reducing code complexity and improving maintainability.
Files that needed to be changed drastically were additionally
cleaned up to remove any code cruft that has accrued over time.
In order to facility this the following changes were made:
* Move JSON handling from `CascadiaSettings` into `SettingsLoader`
This allows us to use STL containers for data model instances.
For instance profiles are now added to a hashmap for O(1) lookup.
* JSON parsing within `SettingsLoader` doesn't differentiate between user,
inbox and fragment JSON data, reducing code complexity and size.
It also centralizes common concerns, like profile deduplication and
ensuring that all profiles are assigned a GUID.
* Direct JSON modification, like the insertion of dynamic profiles into
settings.json were removed. This vastly reduces code complexity,
but unfortunately removes support for comments in JSON on first start.
* `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced
with `FromJson`, allowing us to remove JSON-based color scheme validation.
* `Profile`s used to test their wish to layer using `ShouldBeLayered`, which
was replaced with a GUID-based hashmap lookup on previously parsed profiles.
Further changes were made as improvements upon the previous changes:
* Compact the JSON files embedded binary, saving 28kB
* Prevent double-initialization of the color table in `ColorScheme`
* Making `til::color` getters `constexpr`, allow better optimizations
The result is a reduction of:
* 48kB binary size for the Settings.Model.dll
* 5-10% startup duration
* 26% code for the `CascadiaSettings` class
* 1% overall code in this project
Furthermore this results in the following breaking changes:
* The long deprecated "globals" settings object will not be detected and no
warning will be created during load.
* The initial creation of a new settings.json will not produce helpful comments.
Both cases are caused by the removal of manual JSON handling and the
move to representing the settings file with model objects instead
## PR Checklist
* [x] Closes #5276
* [x] Closes #7421
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Out-of-box-experience is identical to before ✔️
(Except for the settings.json file lacking comments.)
* Existing user settings load correctly ✔️
* New WSL instances are added to user settings ✔️
* New fragments are added to user settings ✔️
* All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
|
|
|
INHERITABLE_PROFILE_SETTING(Guid, Guid);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(String, Name);
|
|
|
|
INHERITABLE_PROFILE_SETTING(String, Source);
|
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, Hidden);
|
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184)
This commit reduces the code surface that interacts with raw JSON data,
reducing code complexity and improving maintainability.
Files that needed to be changed drastically were additionally
cleaned up to remove any code cruft that has accrued over time.
In order to facility this the following changes were made:
* Move JSON handling from `CascadiaSettings` into `SettingsLoader`
This allows us to use STL containers for data model instances.
For instance profiles are now added to a hashmap for O(1) lookup.
* JSON parsing within `SettingsLoader` doesn't differentiate between user,
inbox and fragment JSON data, reducing code complexity and size.
It also centralizes common concerns, like profile deduplication and
ensuring that all profiles are assigned a GUID.
* Direct JSON modification, like the insertion of dynamic profiles into
settings.json were removed. This vastly reduces code complexity,
but unfortunately removes support for comments in JSON on first start.
* `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced
with `FromJson`, allowing us to remove JSON-based color scheme validation.
* `Profile`s used to test their wish to layer using `ShouldBeLayered`, which
was replaced with a GUID-based hashmap lookup on previously parsed profiles.
Further changes were made as improvements upon the previous changes:
* Compact the JSON files embedded binary, saving 28kB
* Prevent double-initialization of the color table in `ColorScheme`
* Making `til::color` getters `constexpr`, allow better optimizations
The result is a reduction of:
* 48kB binary size for the Settings.Model.dll
* 5-10% startup duration
* 26% code for the `CascadiaSettings` class
* 1% overall code in this project
Furthermore this results in the following breaking changes:
* The long deprecated "globals" settings object will not be detected and no
warning will be created during load.
* The initial creation of a new settings.json will not produce helpful comments.
Both cases are caused by the removal of manual JSON handling and the
move to representing the settings file with model objects instead
## PR Checklist
* [x] Closes #5276
* [x] Closes #7421
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Out-of-box-experience is identical to before ✔️
(Except for the settings.json file lacking comments.)
* Existing user settings load correctly ✔️
* New WSL instances are added to user settings ✔️
* New fragments are added to user settings ✔️
* All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
|
|
|
INHERITABLE_PROFILE_SETTING(Guid, ConnectionType);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(String, Icon);
|
|
|
|
INHERITABLE_PROFILE_SETTING(CloseOnExitMode, CloseOnExit);
|
|
|
|
INHERITABLE_PROFILE_SETTING(String, TabTitle);
|
Introduce MS.Term.Core.Color to replace W.U.Color for Core/Control/TSM (#9658)
This pull request introduces Microsoft.Terminal.Core.Color as an
alternative to both Windows.UI.Color and uint32_t/COLORREF in the
TerminalCore, ...Control, ...SettingsModel and ...SettingsEditor layers.
M.T.C.Color is trivially convertible to/from til::color and therefore
to/from COLORREF, W.U.Color, and any other color representation we might
need².
I've replaced almost every use of W.U.Color and uint32_t-as-color in the
above layers, with minor exception¹.
The need for this work is twofold.
First: We cannot bear a dependency from TerminalCore (which should,
on paper, be Windows 7 compatible) on Windows.UI or any other WinRT
namespace.
This work removes one big dependency on Windows.UI, but it does not go
all the way.
Second: TerminalCore chose to communicate mostly in packed uint32s
(COLORREF), which was inherently lossy and dangerous.
¹ The UI layers (TerminalControl, TerminalApp) still use
Windows.UI.Color as they are intimately connected to the UWP XAML UI.
² In the future, we might even be able to *use* the alpha channel...
## PR Checklist
* [x] I ran into the need for this when I introduced cursor inversion
* [X] Fixes a longstanding itch
## Validation Steps Performed
Built and ran all tests for the impacted layers, even the local ones!
2021-03-30 22:15:49 +02:00
|
|
|
INHERITABLE_PROFILE_SETTING(Windows.Foundation.IReference<Microsoft.Terminal.Core.Color>, TabColor);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, SuppressApplicationTitle);
|
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, UseAcrylic);
|
2021-03-17 21:47:24 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(Microsoft.Terminal.Control.ScrollbarState, ScrollState);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(String, Padding);
|
|
|
|
INHERITABLE_PROFILE_SETTING(String, Commandline);
|
|
|
|
|
|
|
|
INHERITABLE_PROFILE_SETTING(String, StartingDirectory);
|
2020-09-14 22:38:56 +02:00
|
|
|
String EvaluatedStartingDirectory { get; };
|
2020-08-28 03:09:22 +02:00
|
|
|
|
2021-07-01 19:08:46 +02:00
|
|
|
FontConfig FontInfo { get; };
|
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
IAppearanceConfig DefaultAppearance { get; };
|
|
|
|
INHERITABLE_PROFILE_SETTING(IAppearanceConfig, UnfocusedAppearance);
|
2020-10-27 18:35:09 +01:00
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(Microsoft.Terminal.Control.TextAntialiasingMode, AntialiasingMode);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, ForceFullRepaintRendering);
|
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, SoftwareRendering);
|
2021-04-09 00:46:16 +02:00
|
|
|
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_PROFILE_SETTING(Int32, HistorySize);
|
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, SnapOnInput);
|
|
|
|
INHERITABLE_PROFILE_SETTING(Boolean, AltGrAliasing);
|
|
|
|
INHERITABLE_PROFILE_SETTING(BellStyle, BellStyle);
|
2020-08-28 03:09:22 +02:00
|
|
|
}
|
|
|
|
}
|