2019-05-03 00:29:04 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
#include "pch.h"
|
|
|
|
#include "TerminalSettings.h"
|
2021-02-09 02:07:11 +01:00
|
|
|
#include "../../types/inc/colorTable.hpp"
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2019-05-23 19:36:29 +02:00
|
|
|
#include "TerminalSettings.g.cpp"
|
2021-04-21 22:35:06 +02:00
|
|
|
#include "TerminalSettingsCreateResult.g.cpp"
|
2019-05-23 19:36:29 +02:00
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
using namespace winrt::Microsoft::Terminal::Control;
|
2021-02-09 02:07:11 +01:00
|
|
|
using namespace Microsoft::Console::Utils;
|
2020-09-14 22:38:56 +02:00
|
|
|
|
2021-03-16 00:15:25 +01:00
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Model::implementation
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2020-12-03 00:14:11 +01:00
|
|
|
static std::tuple<Windows::UI::Xaml::HorizontalAlignment, Windows::UI::Xaml::VerticalAlignment> ConvertConvergedAlignment(ConvergedAlignment alignment)
|
|
|
|
{
|
|
|
|
// extract horizontal alignment
|
|
|
|
Windows::UI::Xaml::HorizontalAlignment horizAlign;
|
|
|
|
switch (alignment & static_cast<ConvergedAlignment>(0x0F))
|
|
|
|
{
|
|
|
|
case ConvergedAlignment::Horizontal_Left:
|
|
|
|
horizAlign = Windows::UI::Xaml::HorizontalAlignment::Left;
|
|
|
|
break;
|
|
|
|
case ConvergedAlignment::Horizontal_Right:
|
|
|
|
horizAlign = Windows::UI::Xaml::HorizontalAlignment::Right;
|
|
|
|
break;
|
|
|
|
case ConvergedAlignment::Horizontal_Center:
|
|
|
|
default:
|
|
|
|
horizAlign = Windows::UI::Xaml::HorizontalAlignment::Center;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// extract vertical alignment
|
|
|
|
Windows::UI::Xaml::VerticalAlignment vertAlign;
|
|
|
|
switch (alignment & static_cast<ConvergedAlignment>(0xF0))
|
|
|
|
{
|
|
|
|
case ConvergedAlignment::Vertical_Top:
|
|
|
|
vertAlign = Windows::UI::Xaml::VerticalAlignment::Top;
|
|
|
|
break;
|
|
|
|
case ConvergedAlignment::Vertical_Bottom:
|
|
|
|
vertAlign = Windows::UI::Xaml::VerticalAlignment::Bottom;
|
|
|
|
break;
|
|
|
|
case ConvergedAlignment::Vertical_Center:
|
|
|
|
default:
|
|
|
|
vertAlign = Windows::UI::Xaml::VerticalAlignment::Center;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return { horizAlign, vertAlign };
|
|
|
|
}
|
|
|
|
|
2021-03-16 00:15:25 +01:00
|
|
|
// Method Description:
|
2021-04-09 00:46:16 +02:00
|
|
|
// - Create a TerminalSettingsCreateResult for the provided profile guid. We'll
|
2021-03-16 00:15:25 +01:00
|
|
|
// use the guid to look up the profile that should be used to
|
|
|
|
// create these TerminalSettings. Then, we'll apply settings contained in the
|
|
|
|
// global and profile settings to the instance.
|
|
|
|
// Arguments:
|
|
|
|
// - appSettings: the set of settings being used to construct the new terminal
|
|
|
|
// - profileGuid: the unique identifier (guid) of the profile
|
|
|
|
// - keybindings: the keybinding handler
|
2021-04-09 00:46:16 +02:00
|
|
|
// Return Value:
|
|
|
|
// - A TerminalSettingsCreateResult, which contains a pair of TerminalSettings objects,
|
|
|
|
// one for when the terminal is focused and the other for when the terminal is unfocused
|
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
|
|
|
Model::TerminalSettingsCreateResult TerminalSettings::CreateWithProfile(const Model::CascadiaSettings& appSettings, const Model::Profile& profile, const IKeyBindings& keybindings)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2021-03-16 00:15:25 +01:00
|
|
|
auto settings{ winrt::make_self<TerminalSettings>() };
|
|
|
|
settings->_KeyBindings = keybindings;
|
|
|
|
|
2020-09-14 22:38:56 +02:00
|
|
|
const auto globals = appSettings.GlobalSettings();
|
2021-04-09 00:46:16 +02:00
|
|
|
settings->_ApplyProfileSettings(profile);
|
2021-03-16 00:15:25 +01:00
|
|
|
settings->_ApplyGlobalSettings(globals);
|
2021-04-09 00:46:16 +02:00
|
|
|
settings->_ApplyAppearanceSettings(profile.DefaultAppearance(), globals.ColorSchemes());
|
|
|
|
|
|
|
|
Model::TerminalSettings child{ nullptr };
|
|
|
|
if (const auto& unfocusedAppearance{ profile.UnfocusedAppearance() })
|
|
|
|
{
|
|
|
|
auto childImpl = settings->CreateChild();
|
|
|
|
childImpl->_ApplyAppearanceSettings(unfocusedAppearance, globals.ColorSchemes());
|
|
|
|
child = *childImpl;
|
|
|
|
}
|
2021-03-16 00:15:25 +01:00
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
return winrt::make<TerminalSettingsCreateResult>(*settings, child);
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Method Description:
|
|
|
|
// - Create a TerminalSettings object for the provided newTerminalArgs. We'll
|
|
|
|
// use the newTerminalArgs to look up the profile that should be used to
|
|
|
|
// create these TerminalSettings. Then, we'll apply settings contained in the
|
|
|
|
// newTerminalArgs to the profile's settings, to enable customization on top
|
|
|
|
// of the profile's default values.
|
|
|
|
// Arguments:
|
|
|
|
// - appSettings: the set of settings being used to construct the new terminal
|
|
|
|
// - newTerminalArgs: An object that may contain a profile name or GUID to
|
|
|
|
// actually use. If the Profile value is not a guid, we'll treat it as a name,
|
|
|
|
// and attempt to look the profile up by name instead.
|
|
|
|
// * Additionally, we'll use other values (such as Commandline,
|
|
|
|
// StartingDirectory) in this object to override the settings directly from
|
|
|
|
// the profile.
|
|
|
|
// - keybindings: the keybinding handler
|
2021-04-09 00:46:16 +02:00
|
|
|
// Return Value:
|
|
|
|
// - A TerminalSettingsCreateResult object, which contains a pair of TerminalSettings
|
|
|
|
// objects. One for when the terminal is focused and one for when the terminal is unfocused.
|
|
|
|
Model::TerminalSettingsCreateResult TerminalSettings::CreateWithNewTerminalArgs(const CascadiaSettings& appSettings,
|
|
|
|
const NewTerminalArgs& newTerminalArgs,
|
|
|
|
const IKeyBindings& keybindings)
|
2020-09-14 22:38:56 +02:00
|
|
|
{
|
2021-08-23 19:11:53 +02:00
|
|
|
const auto profile = appSettings.GetProfileForArgs(newTerminalArgs);
|
|
|
|
auto settingsPair{ CreateWithProfile(appSettings, profile, keybindings) };
|
2021-04-09 00:46:16 +02:00
|
|
|
auto defaultSettings = settingsPair.DefaultSettings();
|
2020-09-14 22:38:56 +02:00
|
|
|
|
|
|
|
if (newTerminalArgs)
|
|
|
|
{
|
|
|
|
// Override commandline, starting directory if they exist in newTerminalArgs
|
|
|
|
if (!newTerminalArgs.Commandline().empty())
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.Commandline(newTerminalArgs.Commandline());
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
if (!newTerminalArgs.StartingDirectory().empty())
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.StartingDirectory(newTerminalArgs.StartingDirectory());
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
if (!newTerminalArgs.TabTitle().empty())
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.StartingTitle(newTerminalArgs.TabTitle());
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
2021-08-25 01:31:27 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
// There was no title, and no profile from which to infer the title.
|
|
|
|
// Per GH#6776, promote the first component of the command line to the title.
|
|
|
|
// This will ensure that the tab we spawn has a name (since it didn't get one from its profile!)
|
|
|
|
if (newTerminalArgs.Profile().empty() && !newTerminalArgs.Commandline().empty())
|
|
|
|
{
|
|
|
|
const std::wstring_view commandLine{ newTerminalArgs.Commandline() };
|
|
|
|
const auto start{ til::at(commandLine, 0) == L'"' ? 1 : 0 };
|
|
|
|
const auto terminator{ commandLine.find_first_of(start ? L'"' : L' ', start) }; // look past the first character if it starts with "
|
|
|
|
// We have to take a copy here; winrt::param::hstring requires a null-terminated string
|
|
|
|
const std::wstring firstComponent{ commandLine.substr(start, terminator - start) };
|
|
|
|
defaultSettings.StartingTitle(firstComponent);
|
|
|
|
}
|
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
if (newTerminalArgs.TabColor())
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.StartingTabColor(winrt::Windows::Foundation::IReference<winrt::Microsoft::Terminal::Core::Color>{ til::color{ newTerminalArgs.TabColor().Value() } });
|
2020-11-20 05:36:18 +01:00
|
|
|
}
|
2021-03-08 16:23:50 +01:00
|
|
|
if (newTerminalArgs.SuppressApplicationTitle())
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.SuppressApplicationTitle(newTerminalArgs.SuppressApplicationTitle().Value());
|
2021-03-08 16:23:50 +01:00
|
|
|
}
|
2021-03-29 22:04:39 +02:00
|
|
|
if (!newTerminalArgs.ColorScheme().empty())
|
|
|
|
{
|
|
|
|
const auto schemes = appSettings.GlobalSettings().ColorSchemes();
|
|
|
|
if (const auto& scheme = schemes.TryLookup(newTerminalArgs.ColorScheme()))
|
|
|
|
{
|
2021-04-09 00:46:16 +02:00
|
|
|
defaultSettings.ApplyColorScheme(scheme);
|
2021-03-29 22:04:39 +02:00
|
|
|
}
|
|
|
|
}
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
return settingsPair;
|
|
|
|
}
|
|
|
|
|
|
|
|
void TerminalSettings::_ApplyAppearanceSettings(const IAppearanceConfig& appearance, const Windows::Foundation::Collections::IMapView<winrt::hstring, ColorScheme>& schemes)
|
|
|
|
{
|
|
|
|
_CursorShape = appearance.CursorShape();
|
|
|
|
_CursorHeight = appearance.CursorHeight();
|
|
|
|
if (!appearance.ColorSchemeName().empty())
|
|
|
|
{
|
|
|
|
if (const auto scheme = schemes.TryLookup(appearance.ColorSchemeName()))
|
|
|
|
{
|
|
|
|
ApplyColorScheme(scheme);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (appearance.Foreground())
|
|
|
|
{
|
|
|
|
_DefaultForeground = til::color{ appearance.Foreground().Value() };
|
|
|
|
}
|
|
|
|
if (appearance.Background())
|
|
|
|
{
|
|
|
|
_DefaultBackground = til::color{ appearance.Background().Value() };
|
|
|
|
}
|
|
|
|
if (appearance.SelectionBackground())
|
|
|
|
{
|
|
|
|
_SelectionBackground = til::color{ appearance.SelectionBackground().Value() };
|
|
|
|
}
|
|
|
|
if (appearance.CursorColor())
|
|
|
|
{
|
|
|
|
_CursorColor = til::color{ appearance.CursorColor().Value() };
|
|
|
|
}
|
|
|
|
if (!appearance.BackgroundImagePath().empty())
|
|
|
|
{
|
|
|
|
_BackgroundImage = appearance.ExpandedBackgroundImagePath();
|
|
|
|
}
|
|
|
|
|
|
|
|
_BackgroundImageOpacity = appearance.BackgroundImageOpacity();
|
|
|
|
_BackgroundImageStretchMode = appearance.BackgroundImageStretchMode();
|
|
|
|
std::tie(_BackgroundImageHorizontalAlignment, _BackgroundImageVerticalAlignment) = ConvertConvergedAlignment(appearance.BackgroundImageAlignment());
|
|
|
|
|
|
|
|
_RetroTerminalEffect = appearance.RetroTerminalEffect();
|
|
|
|
_PixelShaderPath = winrt::hstring{ wil::ExpandEnvironmentStringsW<std::wstring>(appearance.PixelShaderPath().c_str()) };
|
Add an ENUM setting for disabling rendering "intense" text as bold (#10759)
## Summary of the Pull Request
This adds a new setting `intenseTextStyle`. It's a per-appearance, control setting, defaulting to `"all"`.
* When set to `"all"` or `["bold", "bright"]`, then we'll render text as both **bold** and bright (1.10 behavior)
* When set to `"bold"`, `["bold"]`, we'll render text formatted with `^[[1m` as **bold**, but not bright
* When set to `"bright"`, `["bright"]`, we'll render text formatted with `^[[1m` as bright, but not bold. This is the pre 1.10 behavior
* When set to `"none"`, we won't do anything special for it at all.
## references
* I last did this in #10648. This time it's an enum, so we can add bright in the future. It's got positive wording this time.
* ~We will want to add `"bright"` as a value in the future, to disable the auto intense->bright conversion.~ I just did that now.
* #5682 is related
## PR Checklist
* [x] Closes #10576
* [x] I seriously don't think we have an issue for "disable intense is bright", but I'm not crazy, people wanted that, right? https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423 was the closest
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/381
## Validation Steps Performed
<!-- ![image](https://user-images.githubusercontent.com/18356694/125480327-07f6b711-6bca-4c1b-9a76-75fc978c702d.png) -->
![image](https://user-images.githubusercontent.com/18356694/128929228-504933ee-cf50-43a2-9982-55110ba39191.png)
Yea that works. Printed some bold text, toggled it on, the text was no longer bold. hooray.
### EDIT, 10 Aug
```json
"intenseTextStyle": "none",
"intenseTextStyle": "bold",
"intenseTextStyle": "bright",
"intenseTextStyle": "all",
"intenseTextStyle": ["bold", "bright"],
```
all work now. Repro script:
```sh
printf "\e[1m[bold]\e[m[normal]\e[34m[blue]\e[1m[bold blue]\e[m\n"
```
2021-08-16 15:45:56 +02:00
|
|
|
|
|
|
|
_IntenseIsBold = WI_IsFlagSet(appearance.IntenseTextStyle(), Microsoft::Terminal::Settings::Model::IntenseStyle::Bold);
|
|
|
|
_IntenseIsBright = WI_IsFlagSet(appearance.IntenseTextStyle(), Microsoft::Terminal::Settings::Model::IntenseStyle::Bright);
|
2021-09-20 19:08:13 +02:00
|
|
|
|
2021-10-08 00:43:17 +02:00
|
|
|
_AdjustIndistinguishableColors = appearance.AdjustIndistinguishableColors();
|
Remove the fallback to 50% opacity when only `useAcrylic` is set (#11363)
This logic was seemingly redundant. There's two cases I'm looking at here:
#### Case 1
```jsonc
"defaults":
{
"opacity": 35
},
"list":
[
{
"commandline": "cmd.exe",
"name": "Command Prompt"
},
```
In this case, we wouldn't set the `TerminalSettings` Opacity to .35, we'd set it to 1.0, because the profile didn't have an `opactity`.
#### Case 2
```jsonc
"defaults":
{
"useAcrylic": true
},
"list":
[
{
"commandline": "cmd.exe",
"name": "Command Prompt"
},
```
In this case we still want to have an acrylic effect. Previously, we'd default this effect to 50% opaque. I'm not sure that we can actually get that anymore. BUT it turns out, we _can_ have 100% opacity and HostBackdropAcrylic. It is very subtle, but is maybe something we should be allowing anyways. It kinda looks like:
![image](https://user-images.githubusercontent.com/18356694/135168469-35d1f55b-58d1-4ee3-a717-76000c2574b9.png)
* [x] Fixes #11355
* [x] Regressed in #11180
* [x] I work here
2021-09-29 12:26:20 +02:00
|
|
|
_Opacity = appearance.Opacity();
|
2021-03-16 00:15:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Method Description:
|
2021-04-09 00:46:16 +02:00
|
|
|
// - Creates a TerminalSettingsCreateResult from a parent TerminalSettingsCreateResult
|
|
|
|
// - The returned defaultSettings inherits from the parent's defaultSettings, and the
|
|
|
|
// returned unfocusedSettings inherits from the returned defaultSettings
|
|
|
|
// - Note that the unfocused settings needs to be entirely unchanged _except_ we need to
|
|
|
|
// set its parent to the other settings object that we return. This is because the overrides
|
|
|
|
// made by the control will live in that other settings object, so we want to make
|
|
|
|
// sure the unfocused settings inherit from that.
|
|
|
|
// - Another way to think about this is that initially we have UnfocusedSettings inherit
|
|
|
|
// from DefaultSettings. This function simply adds another TerminalSettings object
|
|
|
|
// in the middle of these two, so UnfocusedSettings now inherits from the new object
|
|
|
|
// and the new object inherits from the DefaultSettings. And this new object is what
|
|
|
|
// the control can put overrides in.
|
|
|
|
// Arguments:
|
|
|
|
// - parent: the TerminalSettingsCreateResult that we create a new one from
|
2021-03-16 00:15:25 +01:00
|
|
|
// Return Value:
|
2021-04-09 00:46:16 +02:00
|
|
|
// - A TerminalSettingsCreateResult object that contains a defaultSettings that inherits
|
|
|
|
// from parent's defaultSettings, and contains an unfocusedSettings that inherits from
|
|
|
|
// its defaultSettings
|
|
|
|
Model::TerminalSettingsCreateResult TerminalSettings::CreateWithParent(const Model::TerminalSettingsCreateResult& parent)
|
2021-03-16 00:15:25 +01:00
|
|
|
{
|
|
|
|
THROW_HR_IF_NULL(E_INVALIDARG, parent);
|
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
auto defaultImpl{ get_self<TerminalSettings>(parent.DefaultSettings()) };
|
|
|
|
auto defaultChild = defaultImpl->CreateChild();
|
|
|
|
if (parent.UnfocusedSettings())
|
|
|
|
{
|
|
|
|
parent.UnfocusedSettings().SetParent(*defaultChild);
|
|
|
|
}
|
|
|
|
return winrt::make<TerminalSettingsCreateResult>(*defaultChild, parent.UnfocusedSettings());
|
2021-03-16 00:15:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Method Description:
|
|
|
|
// - Sets our parent to the provided TerminalSettings
|
|
|
|
// Arguments:
|
|
|
|
// - parent: our new parent
|
|
|
|
void TerminalSettings::SetParent(const Model::TerminalSettings& parent)
|
|
|
|
{
|
|
|
|
ClearParents();
|
|
|
|
com_ptr<TerminalSettings> parentImpl;
|
|
|
|
parentImpl.copy_from(get_self<TerminalSettings>(parent));
|
2021-11-24 21:22:45 +01:00
|
|
|
AddLeastImportantParent(parentImpl);
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
|
2021-04-21 22:35:06 +02:00
|
|
|
Model::TerminalSettings TerminalSettings::GetParent()
|
|
|
|
{
|
|
|
|
if (_parents.size() > 0)
|
|
|
|
{
|
|
|
|
return *_parents.at(0);
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2020-09-14 22:38:56 +02:00
|
|
|
// Method Description:
|
|
|
|
// - Apply Profile settings, as well as any colors from our color scheme, if we have one.
|
|
|
|
// Arguments:
|
|
|
|
// - profile: the profile settings we're applying
|
|
|
|
// - schemes: a map of schemes to look for our color scheme in, if we have one.
|
|
|
|
// Return Value:
|
|
|
|
// - <none>
|
2021-04-09 00:46:16 +02:00
|
|
|
void TerminalSettings::_ApplyProfileSettings(const Profile& profile)
|
2020-09-14 22:38:56 +02:00
|
|
|
{
|
|
|
|
// Fill in the Terminal Setting's CoreSettings from the profile
|
|
|
|
_HistorySize = profile.HistorySize();
|
|
|
|
_SnapOnInput = profile.SnapOnInput();
|
|
|
|
_AltGrAliasing = profile.AltGrAliasing();
|
|
|
|
|
|
|
|
// Fill in the remaining properties from the profile
|
|
|
|
_ProfileName = profile.Name();
|
2021-11-10 22:19:52 +01:00
|
|
|
_ProfileSource = profile.Source();
|
2020-09-14 22:38:56 +02:00
|
|
|
_UseAcrylic = profile.UseAcrylic();
|
|
|
|
|
2021-07-01 19:08:46 +02:00
|
|
|
_FontFace = profile.FontInfo().FontFace();
|
|
|
|
_FontSize = profile.FontInfo().FontSize();
|
|
|
|
_FontWeight = profile.FontInfo().FontWeight();
|
2021-07-23 01:15:44 +02:00
|
|
|
_FontFeatures = profile.FontInfo().FontFeatures();
|
|
|
|
_FontAxes = profile.FontInfo().FontAxes();
|
2020-09-14 22:38:56 +02:00
|
|
|
_Padding = profile.Padding();
|
|
|
|
|
|
|
|
_Commandline = profile.Commandline();
|
|
|
|
|
2020-10-27 18:35:09 +01:00
|
|
|
_StartingDirectory = profile.EvaluatedStartingDirectory();
|
2020-09-14 22:38:56 +02:00
|
|
|
|
|
|
|
// GH#2373: Use the tabTitle as the starting title if it exists, otherwise
|
|
|
|
// use the profile name
|
|
|
|
_StartingTitle = !profile.TabTitle().empty() ? profile.TabTitle() : profile.Name();
|
|
|
|
|
|
|
|
if (profile.SuppressApplicationTitle())
|
|
|
|
{
|
|
|
|
_SuppressApplicationTitle = profile.SuppressApplicationTitle();
|
|
|
|
}
|
|
|
|
|
Introduce AtlasEngine - A new text rendering prototype (#11623)
This commit introduces "AtlasEngine", a new text renderer based on DxEngine.
But unlike it, DirectWrite and Direct2D are only used to rasterize glyphs.
Blending and placing these glyphs into the target view is being done using
Direct3D and a simple HLSL shader. Since this new renderer more aggressively
assumes that the text is monospace, it simplifies the implementation:
The viewport is divided into cells, and its data is stored as a simple matrix.
Modifications to this matrix involve only simple pointer arithmetic and is easy
to understand. But just like with DxEngine however, DirectWrite
related code remains extremely complex and hard to understand.
Supported features:
* Basic text rendering with grayscale AA
* Foreground and background colors
* Emojis, including zero width joiners
* Underline, dotted underline, strikethrough
* Custom font axes and features
* Selections
* All cursor styles
* Full alpha support for all colors
* _Should_ work with Windows 7
Unsupported features:
* A more conservative GPU memory usage
The backing texture atlas for glyphs is grow-only and will not shrink.
After 256MB of memory is used up (~20k glyphs) text output
will be broken until the renderer is restarted.
* ClearType
* Remaining gridlines (left, right, top, bottom, double underline)
* Hyperlinks don't get full underlines if hovered in WT
* Softfonts
* Non-default line renditions
Performance:
* Runs at up to native display refresh rate
Unfortunately the frame rate often drops below refresh rate, due us
fighting over the buffer lock with other parts of the application.
* CPU consumption is up to halved compared to DxEngine
AtlasEngine is still highly unoptimized. Glyph hashing
consumes up to a third of the current CPU time.
* No regressions in WT performance
VT parsing and related buffer management takes up most of the CPU time (~85%),
due to which the AtlasEngine can't show any further improvements.
* ~2x improvement in raw text throughput in OpenConsole
compared to DxEngine running at 144 FPS
* ≥10x improvement in colored VT output in WT/OpenConsole
compared to DxEngine running at 144 FPS
2021-11-13 01:10:06 +01:00
|
|
|
_UseAtlasEngine = profile.UseAtlasEngine();
|
2020-09-14 22:38:56 +02:00
|
|
|
_ScrollState = profile.ScrollState();
|
|
|
|
|
|
|
|
_AntialiasingMode = profile.AntialiasingMode();
|
|
|
|
|
|
|
|
if (profile.TabColor())
|
|
|
|
{
|
|
|
|
const til::color colorRef{ profile.TabColor().Value() };
|
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
|
|
|
_TabColor = static_cast<winrt::Microsoft::Terminal::Core::Color>(colorRef);
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Method Description:
|
|
|
|
// - Applies appropriate settings from the globals into the TerminalSettings object.
|
|
|
|
// Arguments:
|
|
|
|
// - globalSettings: the global property values we're applying.
|
|
|
|
// Return Value:
|
|
|
|
// - <none>
|
2021-03-16 00:15:25 +01:00
|
|
|
void TerminalSettings::_ApplyGlobalSettings(const Model::GlobalAppSettings& globalSettings) noexcept
|
2020-09-14 22:38:56 +02:00
|
|
|
{
|
|
|
|
_InitialRows = globalSettings.InitialRows();
|
|
|
|
_InitialCols = globalSettings.InitialCols();
|
|
|
|
|
|
|
|
_WordDelimiters = globalSettings.WordDelimiters();
|
|
|
|
_CopyOnSelect = globalSettings.CopyOnSelect();
|
2021-02-09 23:18:20 +01:00
|
|
|
_FocusFollowMouse = globalSettings.FocusFollowMouse();
|
2020-09-14 22:38:56 +02:00
|
|
|
_ForceFullRepaintRendering = globalSettings.ForceFullRepaintRendering();
|
|
|
|
_SoftwareRendering = globalSettings.SoftwareRendering();
|
|
|
|
_ForceVTInput = globalSettings.ForceVTInput();
|
2021-04-24 00:36:51 +02:00
|
|
|
_TrimBlockSelection = globalSettings.TrimBlockSelection();
|
2021-05-17 06:20:09 +02:00
|
|
|
_DetectURLs = globalSettings.DetectURLs();
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
|
2020-09-14 22:38:56 +02:00
|
|
|
// Method Description:
|
|
|
|
// - Apply a given ColorScheme's values to the TerminalSettings object.
|
|
|
|
// Sets the foreground, background, and color table of the settings object.
|
|
|
|
// Arguments:
|
|
|
|
// - scheme: the ColorScheme we are applying to the TerminalSettings object
|
|
|
|
// Return Value:
|
|
|
|
// - <none>
|
2021-03-16 00:15:25 +01:00
|
|
|
void TerminalSettings::ApplyColorScheme(const Model::ColorScheme& scheme)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2021-04-21 22:35:06 +02:00
|
|
|
// If the scheme was nullptr, then just clear out the current color
|
|
|
|
// settings.
|
|
|
|
if (scheme == nullptr)
|
|
|
|
{
|
Persist window layout on window close (#10972)
This commit adds initial support for saving window layout on application
close.
Done:
- Add user setting for if tabs should be maintained.
- Added events to track the number of open windows for the monarch, and
then save if you are the last window closing.
- Saves layout when the user explicitly hits the "Close Window" button.
- If the user manually closed all of their tabs (through the tab x
button or through closing all panes on the tab) then remove any saved
state.
- Saves in the ApplicationState file a list of actions the terminal can
perform to restore its layout and the window size/position
information.
- This saves an action to focus the correct pane, but this won't
actually work without #10978. Note that if you have a pane zoomed, it
does still zoom the correct pane, but when you unzoom it will have a
different pane selected.
Todo:
- multiple windows? Right now it can only handle loading/saving one
window.
- PR #11083 will save multiple windows.
- This also sometimes runs into the existing bug where multiple tabs
appear to be focused on opening.
Next Steps:
- The business logic of when the save is triggered can be adjusted as
necessary.
- Right now I am taking the pragmatic approach and just saving the state
as an array of objects, but only ever populate it with 1, that way
saving multiple windows in the future could be added without breaking
schema compatibility. Selfishly I'm hoping that handling multiple
windows could be spun off into another pr/feature for now.
- One possible thing that can maybe be done is that the commandline can
be augmented with a "--saved ##" attribute that would load from the
nth saved state if it exists. e.g. if there are 3 saved windows, on
first load it can spawn three wt --saved {0,1,2} that would reopen the
windows? This way there also exists a way to load a copy of a previous
window (if it is in the saved state).
- Is the application state something that is planned to be public/user
editable? In theory the user could since it is just json, but I don't
know what it buys them over just modifying their settings and
startupActions.
Validation Steps Performed:
- The happy path: open terminal -> set setting to true -> close terminal
-> reopen and see tabs. Tested with powershell/cmd/wsl windows.
- That closing all panes/tabs on their own will remove the saved
session.
- Open multiple windows, close windows and confirm that the last window
closed saves its state.
The generated file stores a sequence of actions that will be executed to
restore the terminal to its saved form.
References #8324
This is also one of the items on microsoft/terminal#5000
Closes #766
2021-09-09 00:44:53 +02:00
|
|
|
ClearAppliedColorScheme();
|
2021-04-21 22:35:06 +02:00
|
|
|
ClearDefaultForeground();
|
|
|
|
ClearDefaultBackground();
|
|
|
|
ClearSelectionBackground();
|
|
|
|
ClearCursorColor();
|
|
|
|
_ColorTable = std::nullopt;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Persist window layout on window close (#10972)
This commit adds initial support for saving window layout on application
close.
Done:
- Add user setting for if tabs should be maintained.
- Added events to track the number of open windows for the monarch, and
then save if you are the last window closing.
- Saves layout when the user explicitly hits the "Close Window" button.
- If the user manually closed all of their tabs (through the tab x
button or through closing all panes on the tab) then remove any saved
state.
- Saves in the ApplicationState file a list of actions the terminal can
perform to restore its layout and the window size/position
information.
- This saves an action to focus the correct pane, but this won't
actually work without #10978. Note that if you have a pane zoomed, it
does still zoom the correct pane, but when you unzoom it will have a
different pane selected.
Todo:
- multiple windows? Right now it can only handle loading/saving one
window.
- PR #11083 will save multiple windows.
- This also sometimes runs into the existing bug where multiple tabs
appear to be focused on opening.
Next Steps:
- The business logic of when the save is triggered can be adjusted as
necessary.
- Right now I am taking the pragmatic approach and just saving the state
as an array of objects, but only ever populate it with 1, that way
saving multiple windows in the future could be added without breaking
schema compatibility. Selfishly I'm hoping that handling multiple
windows could be spun off into another pr/feature for now.
- One possible thing that can maybe be done is that the commandline can
be augmented with a "--saved ##" attribute that would load from the
nth saved state if it exists. e.g. if there are 3 saved windows, on
first load it can spawn three wt --saved {0,1,2} that would reopen the
windows? This way there also exists a way to load a copy of a previous
window (if it is in the saved state).
- Is the application state something that is planned to be public/user
editable? In theory the user could since it is just json, but I don't
know what it buys them over just modifying their settings and
startupActions.
Validation Steps Performed:
- The happy path: open terminal -> set setting to true -> close terminal
-> reopen and see tabs. Tested with powershell/cmd/wsl windows.
- That closing all panes/tabs on their own will remove the saved
session.
- Open multiple windows, close windows and confirm that the last window
closed saves its state.
The generated file stores a sequence of actions that will be executed to
restore the terminal to its saved form.
References #8324
This is also one of the items on microsoft/terminal#5000
Closes #766
2021-09-09 00:44:53 +02:00
|
|
|
AppliedColorScheme(scheme);
|
2021-04-21 22:35:06 +02:00
|
|
|
_DefaultForeground = til::color{ scheme.Foreground() };
|
|
|
|
_DefaultBackground = til::color{ scheme.Background() };
|
|
|
|
_SelectionBackground = til::color{ scheme.SelectionBackground() };
|
|
|
|
_CursorColor = til::color{ scheme.CursorColor() };
|
|
|
|
|
|
|
|
const auto table = scheme.Table();
|
|
|
|
std::array<winrt::Microsoft::Terminal::Core::Color, COLOR_TABLE_SIZE> colorTable{};
|
|
|
|
std::transform(table.cbegin(), table.cend(), colorTable.begin(), [](auto&& color) {
|
|
|
|
return static_cast<winrt::Microsoft::Terminal::Core::Color>(til::color{ color });
|
|
|
|
});
|
|
|
|
ColorTable(colorTable);
|
|
|
|
}
|
2020-09-14 22:38:56 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
winrt::Microsoft::Terminal::Core::Color TerminalSettings::GetColorTableEntry(int32_t index) noexcept
|
2020-09-14 22:38:56 +02:00
|
|
|
{
|
2021-02-08 23:01:40 +01:00
|
|
|
return ColorTable().at(index);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void TerminalSettings::ColorTable(std::array<winrt::Microsoft::Terminal::Core::Color, 16> colors)
|
2021-02-08 23:01:40 +01:00
|
|
|
{
|
|
|
|
_ColorTable = colors;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
std::array<winrt::Microsoft::Terminal::Core::Color, COLOR_TABLE_SIZE> TerminalSettings::ColorTable()
|
2021-02-08 23:01:40 +01:00
|
|
|
{
|
|
|
|
auto span = _getColorTableImpl();
|
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
|
|
|
std::array<winrt::Microsoft::Terminal::Core::Color, COLOR_TABLE_SIZE> colorTable{};
|
2021-02-08 23:01:40 +01:00
|
|
|
if (span.size() > 0)
|
|
|
|
{
|
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
|
|
|
std::copy(span.begin(), span.end(), colorTable.begin());
|
2021-02-08 23:01:40 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
const auto campbellSpan = CampbellColorTable();
|
|
|
|
std::transform(campbellSpan.begin(), campbellSpan.end(), colorTable.begin(), [](auto&& color) {
|
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
|
|
|
return static_cast<winrt::Microsoft::Terminal::Core::Color>(til::color{ color });
|
2021-02-08 23:01:40 +01:00
|
|
|
});
|
|
|
|
}
|
|
|
|
return colorTable;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
gsl::span<winrt::Microsoft::Terminal::Core::Color> TerminalSettings::_getColorTableImpl()
|
2021-02-08 23:01:40 +01:00
|
|
|
{
|
|
|
|
if (_ColorTable.has_value())
|
|
|
|
{
|
|
|
|
return gsl::make_span(*_ColorTable);
|
|
|
|
}
|
|
|
|
for (auto&& parent : _parents)
|
|
|
|
{
|
|
|
|
auto parentSpan = parent->_getColorTableImpl();
|
|
|
|
if (parentSpan.size() > 0)
|
|
|
|
{
|
|
|
|
return parentSpan;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return {};
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
}
|