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
This commit is an amalgamation of some of the TSM changes in PR #8048.
It:
* Introduces CascadiaSettings.CreateNewProfile to add a new profile
* Introduces CascadiaSettings.ProfileDefaults, which returns the
"defaults" object as a profile
* Fixes the font weight deserializer to work on uint16_ts
* Fixes a property getter in ColorScheme to not be a property getter
* Fixes a reserialization error with default profiles
* Sets a default icon for all profiles (to the C:\ Segoe MDL2 icon)
## Summary of the Pull Request
This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated.
`CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents.
#### Limitations:
- all of the color schemes are serialized regardless of them coming from defaults.json or settings.json
- keybindings/actions are copied/pasted
## References
#1564 - Settings UI
TSM Specs (#6904 and #7876)
## PR Checklist
* [x] Tests added/passed
## Summary of the Pull Request
Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string:
* `true`, `"mru"`: Use the tab switcher with MRU tab switching
* `"inOrder"`: Use the tab switcher, with in-order tab switching
* `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order.
This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread.
## References
* #7952 introduced MRU tab switching
## PR Checklist
* [x] Closes#8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task
* [x] I work here
* [x] Tests added/passed - YOU BET THEY WERE
* [ ] Requires documentation to be updated
## Validation Steps Performed
I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting.
I also _ran the test_ I added.
## Summary of the Pull Request
Introduces `IInheritable` as an interface that helps move cascading settings into the Terminal Settings Model. `GlobalAppSettings` and `Profile` both are now `IInheritable`. `CascadiaSettings` was updated to `CreateChild()` for globals and each profile when we are loading the JSON data.
IInheritable does most of the heavy lifting. It introduces a two new macros and the interface. The macros help implement the fallback functionality for nullable and non-nullable settings.
## References
#7876 - Spec Addendum
#6904 - TSM Spec
#1564 - Settings UI
#7876 - `Copy()` needs to be updated to include _parent
## Summary of the Pull Request
This implements the `Copy` function for `CascadiaSettings`. Copy performs a deep copy of a `CascadiaSettings` object. This is needed for data binding in the Terminal Settings Editor.
The `Copy` function was basically implemented in every settings model object. This was mostly just repetitive work.
## References
#7667 - TSM
#1564 - Settings UI
## PR Checklist
* [X] Tests added/passed
Introduces a new TerminalSettingsModel (TSM) project. This project is
responsible for (de)serializing and exposing Windows Terminal's settings
as WinRT objects.
## References
#885: TSM epic
#1564: Settings UI is dependent on this for data binding and settings access
#6904: TSM Spec
In the process of ripping out TSM from TerminalApp, a few other changes
were made to make this possible:
1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was
moved to `CascadiaSettings`
- These are defined as static functions. They also no longer check if
`AppLogic::Current()` is nullptr.
2. `enum LaunchMode` was moved from TerminalApp to TSM
3. `AzureConnectionType` and `TelnetConnectionType` were moved from the
profile generators to their respective TerminalConnections
4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are
exposed as `hstring` instead of `std::filesystem::path`
5. `Command::ExpandCommands()` was exposed via the IDL
- This required some of the warnings to be saved to an `IVector`
instead of `std::vector`, among some other small changes.
6. The localization resources had to be split into two halves.
- Resource file linked in init.cpp. Verified at runtime thanks to the
StaticResourceLoader.
7. Added constructors to some `ActionArgs`
8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to
`JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp.
A large amount of work includes moving to the new namespace
(`TerminalApp` --> `Microsoft::Terminal::Settings::Model`).
Fixing the tests had its own complications. Testing required us to split
up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a
non-local test variant can be found in #7743.
Closes#885
2020-10-06 09:56:59 -07:00
Renamed from src/cascadia/TerminalApp/GlobalAppSettings.cpp (Browse further)
