terminal/src/cascadia/TerminalSettingsEditor/Profiles.cpp

535 lines
21 KiB
C++
Raw Normal View History

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "Profiles.h"
#include "PreviewConnection.h"
#include "Profiles.g.cpp"
#include "EnumEntry.h"
#include <LibraryResources.h>
#include "..\WinRTUtils\inc\Utils.h"
using namespace winrt::Windows::UI::Text;
using namespace winrt::Windows::UI::Xaml;
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
using namespace winrt::Windows::UI::Xaml::Controls;
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
using namespace winrt::Windows::UI::Xaml::Data;
using namespace winrt::Windows::UI::Xaml::Navigation;
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Foundation::Collections;
using namespace winrt::Microsoft::Terminal::Settings::Model;
namespace winrt::Microsoft::Terminal::Settings::Editor::implementation
{
Windows::Foundation::Collections::IObservableVector<Editor::Font> ProfileViewModel::_MonospaceFontList{ nullptr };
Windows::Foundation::Collections::IObservableVector<Editor::Font> ProfileViewModel::_FontList{ nullptr };
ProfileViewModel::ProfileViewModel(const Model::Profile& profile, const Model::CascadiaSettings& appSettings) :
_profile{ profile },
_defaultAppearanceViewModel{ winrt::make<implementation::AppearanceViewModel>(profile.DefaultAppearance().try_as<AppearanceConfig>()) },
_originalProfileGuid{ profile.Guid() },
_appSettings{ appSettings },
_unfocusedAppearanceViewModel{ nullptr }
{
// Add a property changed handler to our own property changed event.
// This propagates changes from the settings model to anybody listening to our
// unique view model members.
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
PropertyChanged([this](auto&&, const PropertyChangedEventArgs& args) {
const auto viewModelProperty{ args.PropertyName() };
if (viewModelProperty == L"IsBaseLayer")
{
// we _always_ want to show the background image settings in base layer
_NotifyChanges(L"BackgroundImageSettingsVisible");
}
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
else if (viewModelProperty == L"StartingDirectory")
{
// notify listener that all starting directory related values might have changed
// NOTE: this is similar to what is done with BackgroundImagePath above
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
_NotifyChanges(L"UseParentProcessDirectory", L"UseCustomStartingDirectory");
}
});
// Do the same for the starting directory
if (!StartingDirectory().empty())
{
_lastStartingDirectoryPath = StartingDirectory();
}
// generate the font list, if we don't have one
if (!_FontList || !_MonospaceFontList)
{
UpdateFontList();
}
if (profile.HasUnfocusedAppearance())
{
_unfocusedAppearanceViewModel = winrt::make<implementation::AppearanceViewModel>(profile.UnfocusedAppearance().try_as<AppearanceConfig>());
}
_defaultAppearanceViewModel.IsDefault(true);
}
Model::TerminalSettings ProfileViewModel::TermSettings() const
{
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
return Model::TerminalSettings::CreateWithProfile(_appSettings, _profile, nullptr).DefaultSettings();
}
// Method Description:
// - Updates the lists of fonts and sorts them alphabetically
void ProfileViewModel::UpdateFontList() noexcept
try
{
// initialize font list
std::vector<Editor::Font> fontList;
std::vector<Editor::Font> monospaceFontList;
// get a DWriteFactory
com_ptr<IDWriteFactory> factory;
THROW_IF_FAILED(DWriteCreateFactory(
DWRITE_FACTORY_TYPE_SHARED,
__uuidof(IDWriteFactory),
reinterpret_cast<::IUnknown**>(factory.put())));
// get the font collection; subscribe to updates
com_ptr<IDWriteFontCollection> fontCollection;
THROW_IF_FAILED(factory->GetSystemFontCollection(fontCollection.put(), TRUE));
for (UINT32 i = 0; i < fontCollection->GetFontFamilyCount(); ++i)
{
try
{
// get the font family
com_ptr<IDWriteFontFamily> fontFamily;
THROW_IF_FAILED(fontCollection->GetFontFamily(i, fontFamily.put()));
// get the font's localized names
com_ptr<IDWriteLocalizedStrings> localizedFamilyNames;
THROW_IF_FAILED(fontFamily->GetFamilyNames(localizedFamilyNames.put()));
// construct a font entry for tracking
if (const auto fontEntry{ _GetFont(localizedFamilyNames) })
{
// check if the font is monospaced
try
{
com_ptr<IDWriteFont> font;
THROW_IF_FAILED(fontFamily->GetFirstMatchingFont(DWRITE_FONT_WEIGHT::DWRITE_FONT_WEIGHT_NORMAL,
DWRITE_FONT_STRETCH::DWRITE_FONT_STRETCH_NORMAL,
DWRITE_FONT_STYLE::DWRITE_FONT_STYLE_NORMAL,
font.put()));
// add the font name to our list of monospace fonts
const auto castedFont{ font.try_as<IDWriteFont1>() };
if (castedFont && castedFont->IsMonospacedFont())
{
monospaceFontList.emplace_back(fontEntry);
}
}
CATCH_LOG();
// add the font name to our list of all fonts
fontList.emplace_back(std::move(fontEntry));
}
}
CATCH_LOG();
}
// sort and save the lists
std::sort(begin(fontList), end(fontList), FontComparator());
_FontList = single_threaded_observable_vector<Editor::Font>(std::move(fontList));
std::sort(begin(monospaceFontList), end(monospaceFontList), FontComparator());
_MonospaceFontList = single_threaded_observable_vector<Editor::Font>(std::move(monospaceFontList));
}
CATCH_LOG();
Editor::Font ProfileViewModel::_GetFont(com_ptr<IDWriteLocalizedStrings> localizedFamilyNames)
{
// used for the font's name as an identifier (i.e. text block's font family property)
std::wstring nameID;
UINT32 nameIDIndex;
// used for the font's localized name
std::wstring localizedName;
UINT32 localizedNameIndex;
// use our current locale to find the localized name
BOOL exists{ FALSE };
HRESULT hr;
wchar_t localeName[LOCALE_NAME_MAX_LENGTH];
if (GetUserDefaultLocaleName(localeName, LOCALE_NAME_MAX_LENGTH))
{
hr = localizedFamilyNames->FindLocaleName(localeName, &localizedNameIndex, &exists);
}
if (SUCCEEDED(hr) && !exists)
{
// if we can't find the font for our locale, fallback to the en-us one
// Source: https://docs.microsoft.com/en-us/windows/win32/api/dwrite/nf-dwrite-idwritelocalizedstrings-findlocalename
hr = localizedFamilyNames->FindLocaleName(L"en-us", &localizedNameIndex, &exists);
}
if (!exists)
{
// failed to find the correct locale, using the first one
localizedNameIndex = 0;
}
// get the localized name
UINT32 nameLength;
THROW_IF_FAILED(localizedFamilyNames->GetStringLength(localizedNameIndex, &nameLength));
localizedName.resize(nameLength);
THROW_IF_FAILED(localizedFamilyNames->GetString(localizedNameIndex, localizedName.data(), nameLength + 1));
// now get the nameID
hr = localizedFamilyNames->FindLocaleName(L"en-us", &nameIDIndex, &exists);
if (FAILED(hr) || !exists)
{
// failed to find it, using the first one
nameIDIndex = 0;
}
// get the nameID
THROW_IF_FAILED(localizedFamilyNames->GetStringLength(nameIDIndex, &nameLength));
nameID.resize(nameLength);
THROW_IF_FAILED(localizedFamilyNames->GetString(nameIDIndex, nameID.data(), nameLength + 1));
if (!nameID.empty() && !localizedName.empty())
{
return make<Font>(nameID, localizedName);
}
return nullptr;
}
IObservableVector<Editor::Font> ProfileViewModel::CompleteFontList() const noexcept
{
return _FontList;
}
IObservableVector<Editor::Font> ProfileViewModel::MonospaceFontList() const noexcept
{
return _MonospaceFontList;
}
winrt::guid ProfileViewModel::OriginalProfileGuid() const noexcept
{
return _originalProfileGuid;
}
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
bool ProfileViewModel::CanDeleteProfile() const
{
Allow generated profiles to be deleted (#11007) Re-enables the delete button for generated profiles in the settings UI. Additionally fixes "Startup Profiles" to only list active profiles. Profiles are considered deleted if they're absent from settings.json, but their GUID has been encountered before. Or in other words, from a user's perspective: Generated profiles are added to the settings.json automatically only once. Thus if the user chooses to delete the profile (e.g. using the delete button) they aren't re-added automatically and thus appear to have been deleted. Meanwhile those generated profiles are actually only marked as "hidden" as well as "deleted", but still exist in internal profile lists. The "hidden" attribute hides them from all existing menus. The "deleted" one hides them from the settings UI and prevents them from being written to disk. It would've been preferrable of course to just not generate and add deleted profile to internal profile lists in the first place. But this would've required far more wide-reaching changes. The settings UI for instance requires a list of _all_ profiles in order to allow a user to re-create previously deleted profiles. Such an approach was attempted but discarded because of it's current complexity overhead. ## References * Part of #9997 * A sequel to 5d36e5d ## PR Checklist * [x] Closes #10960 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * "Startup Profiles" doesn't list deleted profiles ✔️ * Manually removing an item from settings.json removes the profile ✔️ * Removing cmd.exe and saving doesn't create empty objects (#10960) ✔️ * "Add a new profile" lists deleted profiles ✔️ * "Duplicate" recreates previously deleted profiles ✔️ * Profiles are always created with GUIDs ✔️
2021-08-24 00:00:08 +02:00
return !IsBaseLayer();
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
}
Editor::AppearanceViewModel ProfileViewModel::DefaultAppearance()
{
return _defaultAppearanceViewModel;
}
bool ProfileViewModel::HasUnfocusedAppearance()
{
return _profile.HasUnfocusedAppearance();
}
bool ProfileViewModel::EditableUnfocusedAppearance()
{
if constexpr (Feature_EditableUnfocusedAppearance::IsEnabled())
{
return true;
}
return false;
}
bool ProfileViewModel::ShowUnfocusedAppearance()
{
return EditableUnfocusedAppearance() && HasUnfocusedAppearance();
}
void ProfileViewModel::CreateUnfocusedAppearance(const Windows::Foundation::Collections::IMapView<hstring, Model::ColorScheme>& schemes,
const IHostedInWindow& windowRoot)
{
_profile.CreateUnfocusedAppearance();
_unfocusedAppearanceViewModel = winrt::make<implementation::AppearanceViewModel>(_profile.UnfocusedAppearance().try_as<AppearanceConfig>());
_unfocusedAppearanceViewModel.Schemes(schemes);
_unfocusedAppearanceViewModel.WindowRoot(windowRoot);
_NotifyChanges(L"UnfocusedAppearance", L"HasUnfocusedAppearance", L"ShowUnfocusedAppearance");
}
void ProfileViewModel::DeleteUnfocusedAppearance()
{
_profile.DeleteUnfocusedAppearance();
_unfocusedAppearanceViewModel = nullptr;
_NotifyChanges(L"UnfocusedAppearance", L"HasUnfocusedAppearance", L"ShowUnfocusedAppearance");
}
Editor::AppearanceViewModel ProfileViewModel::UnfocusedAppearance()
{
return _unfocusedAppearanceViewModel;
}
bool ProfileViewModel::UseParentProcessDirectory()
{
return StartingDirectory().empty();
}
// This function simply returns the opposite of UseParentProcessDirectory.
// We bind the 'IsEnabled' parameters of the textbox and browse button
// to this because it needs to be the reverse of UseParentProcessDirectory
// but we don't want to create a whole new converter for inverting a boolean
bool ProfileViewModel::UseCustomStartingDirectory()
{
return !UseParentProcessDirectory();
}
void ProfileViewModel::UseParentProcessDirectory(const bool useParent)
{
if (useParent)
{
// Stash the current value of StartingDirectory. If the user
// checks and un-checks the "Use parent process directory" button, we want
// the path that we display in the text box to remain unchanged.
//
// Only stash this value if it's not empty
if (!StartingDirectory().empty())
{
_lastStartingDirectoryPath = StartingDirectory();
}
StartingDirectory(L"");
}
else
{
// Restore the path we had previously cached as long as it wasn't empty
// If it was empty, set the starting directory to %USERPROFILE%
// (we need to set it to something non-empty otherwise we will automatically
// disable the text box)
if (_lastStartingDirectoryPath.empty())
{
StartingDirectory(L"%USERPROFILE%");
}
else
{
StartingDirectory(_lastStartingDirectoryPath);
}
}
}
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
void ProfilePageNavigationState::DeleteProfile()
{
auto deleteProfileArgs{ winrt::make_self<DeleteProfileEventArgs>(_Profile.Guid()) };
_DeleteProfileHandlers(*this, *deleteProfileArgs);
}
void ProfilePageNavigationState::CreateUnfocusedAppearance()
{
_Profile.CreateUnfocusedAppearance(_Schemes, _WindowRoot);
}
void ProfilePageNavigationState::DeleteUnfocusedAppearance()
{
_Profile.DeleteUnfocusedAppearance();
}
Profiles::Profiles() :
_previewControl{ Control::TermControl(Model::TerminalSettings{}, make<PreviewConnection>()) }
{
InitializeComponent();
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
INITIALIZE_BINDABLE_ENUM_SETTING(AntiAliasingMode, TextAntialiasingMode, winrt::Microsoft::Terminal::Control::TextAntialiasingMode, L"Profile_AntialiasingMode", L"Content");
INITIALIZE_BINDABLE_ENUM_SETTING_REVERSE_ORDER(CloseOnExitMode, CloseOnExitMode, winrt::Microsoft::Terminal::Settings::Model::CloseOnExitMode, L"Profile_CloseOnExit", L"Content");
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
INITIALIZE_BINDABLE_ENUM_SETTING(ScrollState, ScrollbarState, winrt::Microsoft::Terminal::Control::ScrollbarState, L"Profile_ScrollbarVisibility", L"Content");
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
const auto startingDirCheckboxTooltip{ ToolTipService::GetToolTip(StartingDirectoryUseParentCheckbox()) };
Automation::AutomationProperties::SetFullDescription(StartingDirectoryUseParentCheckbox(), unbox_value<hstring>(startingDirCheckboxTooltip));
Automation::AutomationProperties::SetName(DeleteButton(), RS_(L"Profile_DeleteButton/Text"));
_previewControl.IsEnabled(false);
_previewControl.AllowFocusWhenDisabled(false);
ControlPreview().Child(_previewControl);
}
void Profiles::OnNavigatedTo(const NavigationEventArgs& e)
{
_State = e.Parameter().as<Editor::ProfilePageNavigationState>();
// generate the font list, if we don't have one
if (!_State.Profile().CompleteFontList() || !_State.Profile().MonospaceFontList())
{
ProfileViewModel::UpdateFontList();
}
// Check the use parent directory box if the starting directory is empty
if (_State.Profile().StartingDirectory().empty())
{
StartingDirectoryUseParentCheckbox().IsChecked(true);
}
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
// Subscribe to some changes in the view model
// These changes should force us to update our own set of "Current<Setting>" members,
// and propagate those changes to the UI
_ViewModelChangedRevoker = _State.Profile().PropertyChanged(winrt::auto_revoke, [=](auto&&, const PropertyChangedEventArgs& args) {
const auto settingName{ args.PropertyName() };
if (settingName == L"AntialiasingMode")
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
{
_PropertyChangedHandlers(*this, PropertyChangedEventArgs{ L"CurrentAntiAliasingMode" });
}
else if (settingName == L"CloseOnExit")
{
_PropertyChangedHandlers(*this, PropertyChangedEventArgs{ L"CurrentCloseOnExitMode" });
}
else if (settingName == L"BellStyle")
{
_PropertyChangedHandlers(*this, PropertyChangedEventArgs{ L"IsBellStyleFlagSet" });
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
}
else if (settingName == L"ScrollState")
{
_PropertyChangedHandlers(*this, PropertyChangedEventArgs{ L"CurrentScrollState" });
}
_previewControl.Settings(_State.Profile().TermSettings());
_previewControl.UpdateSettings();
});
// The Appearances object handles updating the values in the settings UI, but
// we still need to listen to the changes here just to update the preview control
_AppearanceViewModelChangedRevoker = _State.Profile().DefaultAppearance().PropertyChanged(winrt::auto_revoke, [=](auto&&, const PropertyChangedEventArgs& /*args*/) {
_previewControl.Settings(_State.Profile().TermSettings());
_previewControl.UpdateSettings();
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
});
// Navigate to the pivot in the provided navigation state
ProfilesPivot().SelectedIndex(static_cast<int>(_State.LastActivePivot()));
_previewControl.Settings(_State.Profile().TermSettings());
// There is a possibility that the control has not fully initialized yet,
// so wait for it to initialize before updating the settings (so we know
// that the renderer is set up)
_previewControl.Initialized([&](auto&& /*s*/, auto&& /*e*/) {
_previewControl.UpdateSettings();
});
}
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
void Profiles::OnNavigatedFrom(const NavigationEventArgs& /*e*/)
{
_ViewModelChangedRevoker.revoke();
_AppearanceViewModelChangedRevoker.revoke();
}
bool Profiles::IsBellStyleFlagSet(const uint32_t flag)
{
return (WI_EnumValue(_State.Profile().BellStyle()) & flag) == flag;
}
void Profiles::SetBellStyleAudible(winrt::Windows::Foundation::IReference<bool> on)
{
auto currentStyle = State().Profile().BellStyle();
WI_UpdateFlag(currentStyle, Model::BellStyle::Audible, winrt::unbox_value<bool>(on));
State().Profile().BellStyle(currentStyle);
}
void Profiles::SetBellStyleWindow(winrt::Windows::Foundation::IReference<bool> on)
{
auto currentStyle = State().Profile().BellStyle();
WI_UpdateFlag(currentStyle, Model::BellStyle::Window, winrt::unbox_value<bool>(on));
State().Profile().BellStyle(currentStyle);
}
void Profiles::SetBellStyleTaskbar(winrt::Windows::Foundation::IReference<bool> on)
{
auto currentStyle = State().Profile().BellStyle();
WI_UpdateFlag(currentStyle, Model::BellStyle::Taskbar, winrt::unbox_value<bool>(on));
State().Profile().BellStyle(currentStyle);
}
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
void Profiles::DeleteConfirmation_Click(IInspectable const& /*sender*/, RoutedEventArgs const& /*e*/)
{
auto state{ winrt::get_self<ProfilePageNavigationState>(_State) };
state->DeleteProfile();
}
void Profiles::CreateUnfocusedAppearance_Click(IInspectable const& /*sender*/, RoutedEventArgs const& /*e*/)
{
_State.CreateUnfocusedAppearance();
}
void Profiles::DeleteUnfocusedAppearance_Click(IInspectable const& /*sender*/, RoutedEventArgs const& /*e*/)
{
_State.DeleteUnfocusedAppearance();
}
fire_and_forget Profiles::Icon_Click(IInspectable const&, RoutedEventArgs const&)
{
auto lifetime = get_strong();
const auto parentHwnd{ reinterpret_cast<HWND>(_State.WindowRoot().GetHostingWindow()) };
auto file = co_await OpenImagePicker(parentHwnd);
if (!file.empty())
{
_State.Profile().Icon(file);
}
}
fire_and_forget Profiles::Commandline_Click(IInspectable const&, RoutedEventArgs const&)
{
auto lifetime = get_strong();
static constexpr COMDLG_FILTERSPEC supportedFileTypes[] = {
{ L"Executable Files (*.exe, *.cmd, *.bat)", L"*.exe;*.cmd;*.bat" },
{ L"All Files (*.*)", L"*.*" }
};
static constexpr winrt::guid clientGuidExecutables{ 0x2E7E4331, 0x0800, 0x48E6, { 0xB0, 0x17, 0xA1, 0x4C, 0xD8, 0x73, 0xDD, 0x58 } };
const auto parentHwnd{ reinterpret_cast<HWND>(_State.WindowRoot().GetHostingWindow()) };
auto path = co_await OpenFilePicker(parentHwnd, [](auto&& dialog) {
THROW_IF_FAILED(dialog->SetClientGuid(clientGuidExecutables));
try
{
auto folderShellItem{ winrt::capture<IShellItem>(&SHGetKnownFolderItem, FOLDERID_ComputerFolder, KF_FLAG_DEFAULT, nullptr) };
dialog->SetDefaultFolder(folderShellItem.get());
}
CATCH_LOG(); // non-fatal
THROW_IF_FAILED(dialog->SetFileTypes(ARRAYSIZE(supportedFileTypes), supportedFileTypes));
THROW_IF_FAILED(dialog->SetFileTypeIndex(1)); // the array is 1-indexed
THROW_IF_FAILED(dialog->SetDefaultExtension(L"exe;cmd;bat"));
});
if (!path.empty())
{
_State.Profile().Commandline(path);
}
}
fire_and_forget Profiles::StartingDirectory_Click(IInspectable const&, RoutedEventArgs const&)
{
auto lifetime = get_strong();
const auto parentHwnd{ reinterpret_cast<HWND>(_State.WindowRoot().GetHostingWindow()) };
auto folder = co_await OpenFilePicker(parentHwnd, [](auto&& dialog) {
static constexpr winrt::guid clientGuidFolderPicker{ 0xAADAA433, 0xB04D, 0x4BAE, { 0xB1, 0xEA, 0x1E, 0x6C, 0xD1, 0xCD, 0xA6, 0x8B } };
THROW_IF_FAILED(dialog->SetClientGuid(clientGuidFolderPicker));
try
{
auto folderShellItem{ winrt::capture<IShellItem>(&SHGetKnownFolderItem, FOLDERID_ComputerFolder, KF_FLAG_DEFAULT, nullptr) };
dialog->SetDefaultFolder(folderShellItem.get());
}
CATCH_LOG(); // non-fatal
DWORD flags{};
THROW_IF_FAILED(dialog->GetOptions(&flags));
THROW_IF_FAILED(dialog->SetOptions(flags | FOS_PICKFOLDERS)); // folders only
});
if (!folder.empty())
{
_State.Profile().StartingDirectory(folder);
}
}
void Profiles::Pivot_SelectionChanged(Windows::Foundation::IInspectable const& /*sender*/,
Represent inheritance in Settings UI (#8919) ## Summary of the Pull Request Introduces the `SettingContainer`. `SettingContainer` is used to wrap a setting in the settings UI and provide the following functionality: - a reset button next to the header - tooltips and automation properties for the setting being wrapped - a comment stating if you are currently overriding a setting ## References [Spec - Inheritance in Settings UI](https://github.com/microsoft/terminal/blob/main/doc/specs/%231564%20-%20Settings%20UI/cascading-settings.md) #8804 - removes the ambiguity of leaving a setting blank #6800 - Settings UI Epic #8899 - Automation properties for Settings UI #8768 - Keyboard Navigation ## PR Checklist * [X] Closes #8804 ## Detailed Description of the Pull Request / Additional comments A few highlights in this PR: - CommonResources.xaml: - we need to merge the SettingContainerStyle.xaml in there. Otherwise, XAML doesn't merge these files properly and can't apply the template. - Profiles.cpp: - view model checks if the starting directory and background image were reset, to determine which value to show when unchecking the special value - `Profiles::OnNavigatedTo()` needs a property changed handler to update its own "Current<Setting>" and update the UI properly - Profiles.xaml: - basically wrapped all of the settings we want to be inheritable in there - `Binding` is used instead of `x:Bind` in some places because `x:Bind` can't find the parent `SettingContainer` and gives you a compiler error. - Resources.resw: - had to set the "HeaderText" and "HelpText" on each setting container. Does a decent localization burden, unfortunately. - `SettingContainer` files - This operates by creating a template and applying that template over other settings. This allows you to inject the existing controls inside of this. This means that we need to provide our UIElements names and access/modify them via `OnApplyTemplate` - We had to remove the header from each individual control, and have `SettingContainer` be in charge of it. This allows us to add the reset button in there. - Due to the problem mentioned earlier about CommonResources.xaml, we can't reference anything from CommonResources.xaml. - Using `DependencyProperty` to let us set a few properties in the XML files. Particularly, `Has<Setting>` and `Clear<Setting>` are what do all the heavy lifting of interacting with the inheritance model. ## Demo ![Inheritance Demo](https://user-images.githubusercontent.com/11050425/106192086-92a56680-6160-11eb-838c-4ec0beb54965.gif) ## Validation Steps Performed - Verified correct binding behavior with the following generic setting controls: - radio buttons - toggle switch - text block - slider - settings with browse buttons - the background image alignment control - controls with special check boxes (starting directory and background image) ## Next Steps - The automation properties have been verified using NVDA. This is a part of resolving #8899. - The override text is currently "Overrides a setting". According to #8269, we actually want to add a hyperlink in there that navigates to the parent profile object. This will be a follow-up task as it requires settings model changes.
2021-02-08 19:04:43 +01:00
RoutedEventArgs const& /*e*/)
{
_State.LastActivePivot(static_cast<Editor::ProfilesPivots>(ProfilesPivot().SelectedIndex()));
}
}