d57fb84557
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)
50 lines
1.5 KiB
C++
50 lines
1.5 KiB
C++
/*++
|
|
Copyright (c) Microsoft Corporation
|
|
Licensed under the MIT license.
|
|
|
|
Module Name:
|
|
- SettingContainer
|
|
|
|
Abstract:
|
|
- This is a XAML container that wraps settings in the Settings UI.
|
|
It interacts with the inheritance logic from the TerminalSettingsModel
|
|
and represents it in the Settings UI.
|
|
|
|
Author(s):
|
|
- Carlos Zamora - January 2021
|
|
|
|
--*/
|
|
|
|
#pragma once
|
|
|
|
#include "SettingContainer.g.h"
|
|
#include "Utils.h"
|
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Editor::implementation
|
|
{
|
|
struct SettingContainer : SettingContainerT<SettingContainer>
|
|
{
|
|
public:
|
|
SettingContainer();
|
|
|
|
void OnApplyTemplate();
|
|
|
|
DEPENDENCY_PROPERTY(Windows::Foundation::IInspectable, Header);
|
|
DEPENDENCY_PROPERTY(hstring, HelpText);
|
|
DEPENDENCY_PROPERTY(bool, HasSettingValue);
|
|
DEPENDENCY_PROPERTY(IInspectable, SettingOverrideSource);
|
|
TYPED_EVENT(ClearSettingValue, Editor::SettingContainer, Windows::Foundation::IInspectable);
|
|
|
|
private:
|
|
static void _InitializeProperties();
|
|
static void _OnHasSettingValueChanged(Windows::UI::Xaml::DependencyObject const& d, Windows::UI::Xaml::DependencyPropertyChangedEventArgs const& e);
|
|
static hstring _GenerateOverrideMessage(const IInspectable& settingOrigin);
|
|
void _UpdateOverrideSystem();
|
|
};
|
|
}
|
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Editor::factory_implementation
|
|
{
|
|
BASIC_FACTORY(SettingContainer);
|
|
}
|