terminal/src/cascadia/TerminalSettingsModel/JsonUtils.h

913 lines
27 KiB
C
Raw Normal View History

Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- JsonUtils.h
Abstract:
Introduce TerminalSettingsModel project (#7667) 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 18:56:59 +02:00
- Helpers for the Terminal Settings Model project
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
Author(s):
- Mike Griese - August 2019
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
- Dustin Howett - January 2020
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
--*/
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
#pragma once
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
#include <json.h>
#include "../types/inc/utils.hpp"
namespace winrt
{
// If we don't use winrt, nobody will include the ConversionTraits for winrt stuff.
// If nobody includes it, these forward declarations will suffice.
struct guid;
struct hstring;
namespace Windows::Foundation
{
template<typename T>
struct IReference;
}
}
Introduce TerminalSettingsModel project (#7667) 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 18:56:59 +02:00
// Method Description:
// - Create a std::string from a string_view. We do this because we can't look
// up a key in a Json::Value with a string_view directly, so instead we'll use
// this helper. Should a string_view lookup ever be added to jsoncpp, we can
// remove this entirely.
// Arguments:
// - key: the string_view to build a string from
// Return Value:
// - a std::string to use for looking up a value from a Json::Value
inline std::string JsonKey(const std::string_view key)
{
return static_cast<std::string>(key);
}
namespace Microsoft::Terminal::Settings::Model::JsonUtils
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
namespace Detail
{
// Function Description:
// - Returns a string_view to a Json::Value's internal string storage,
// hopefully without copying it.
__declspec(noinline) inline const std::string_view GetStringView(const Json::Value& json)
{
const char* begin{ nullptr };
const char* end{ nullptr };
json.getString(&begin, &end);
const std::string_view zeroCopyString{ begin, gsl::narrow_cast<size_t>(end - begin) };
return zeroCopyString;
}
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
}
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
template<typename T>
struct OptionOracle
{
template<typename U> // universal parameter
static constexpr bool HasValue(U&&)
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
return true;
}
};
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
template<typename T>
struct OptionOracle<std::optional<T>>
{
static constexpr std::optional<T> EmptyV() { return std::nullopt; }
static constexpr bool HasValue(const std::optional<T>& o) { return o.has_value(); }
// We can return a reference here because the original value is stored inside an std::optional
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
static constexpr auto&& Value(const std::optional<T>& o) { return *o; }
};
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
template<typename T>
struct OptionOracle<::winrt::Windows::Foundation::IReference<T>>
{
static constexpr ::winrt::Windows::Foundation::IReference<T> EmptyV() { return nullptr; }
static constexpr bool HasValue(const ::winrt::Windows::Foundation::IReference<T>& o) { return static_cast<bool>(o); }
// We CANNOT return a reference here because IReference does NOT return a reference to its internal memory
static constexpr auto Value(const ::winrt::Windows::Foundation::IReference<T>& o) { return o.Value(); }
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
};
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
class SerializationError : public std::runtime_error
{
public:
SerializationError() :
runtime_error("failed to serialize") {}
};
class DeserializationError : public std::runtime_error
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
public:
DeserializationError(const Json::Value& value) :
runtime_error(std::string("failed to deserialize ") + (value.isNull() ? "" : value.asCString())),
jsonValue{ value } {}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
void SetKey(std::string_view newKey)
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
if (!key)
{
key = newKey;
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
std::optional<std::string> key;
Json::Value jsonValue;
std::string expectedType;
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<typename T>
struct ConversionTrait
{
// Forward-declare these so the linker can pick up specializations from elsewhere!
T FromJson(const Json::Value&);
bool CanConvert(const Json::Value& json);
Json::Value ToJson(const T& val);
std::string TypeDescription() const { return "<unknown>"; }
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<std::string>
{
std::string FromJson(const Json::Value& json)
{
return json.asString();
}
bool CanConvert(const Json::Value& json)
{
return json.isString();
}
Json::Value ToJson(const std::string& val)
{
return val;
}
std::string TypeDescription() const
{
return "string";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<std::wstring>
{
std::wstring FromJson(const Json::Value& json)
{
return til::u8u16(Detail::GetStringView(json));
}
bool CanConvert(const Json::Value& json) const
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
return json.isString();
}
Json::Value ToJson(const std::wstring& val)
{
return til::u16u8(val);
}
std::string TypeDescription() const
{
return "string";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<typename T>
struct ConversionTrait<std::unordered_map<std::string, T>>
{
std::unordered_map<std::string, T> FromJson(const Json::Value& json) const
{
std::unordered_map<std::string, T> val;
val.reserve(json.size());
ConversionTrait<T> trait;
for (auto it = json.begin(), end = json.end(); it != end; ++it)
{
GetValue(*it, val[it.name()], trait);
}
return val;
}
bool CanConvert(const Json::Value& json) const
{
if (!json.isObject())
{
return false;
}
ConversionTrait<T> trait;
for (const auto& v : json)
{
if (!trait.CanConvert(v))
{
return false;
}
}
return true;
}
Json::Value ToJson(const std::unordered_map<std::string, T>& val)
{
Json::Value json{ Json::objectValue };
for (const auto& [k, v] : val)
{
SetValueForKey(json, k, v);
}
return json;
}
std::string TypeDescription() const
{
return fmt::format("map (string, {})", ConversionTrait<T>{}.TypeDescription());
}
};
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
#ifdef WINRT_BASE_H
template<>
struct ConversionTrait<winrt::hstring> : public ConversionTrait<std::wstring>
{
// Leverage the wstring converter's validation
winrt::hstring FromJson(const Json::Value& json)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
if (json.isNull())
{
return winrt::hstring{};
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
return winrt::hstring{ til::u8u16(Detail::GetStringView(json)) };
}
Json::Value ToJson(const winrt::hstring& val)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
if (val == winrt::hstring{})
{
return Json::Value::nullSingleton();
}
return til::u16u8(val);
}
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
bool CanConvert(const Json::Value& json) const
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
{
// hstring has a specific behavior for null, so it can convert it
return ConversionTrait<std::wstring>::CanConvert(json) || json.isNull();
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<typename T>
struct ConversionTrait<winrt::Windows::Foundation::Collections::IMap<winrt::hstring, T>>
{
winrt::Windows::Foundation::Collections::IMap<winrt::hstring, T> FromJson(const Json::Value& json) const
{
std::unordered_map<winrt::hstring, T> val;
val.reserve(json.size());
ConversionTrait<T> trait;
for (auto it = json.begin(), end = json.end(); it != end; ++it)
{
GetValue(*it, val[winrt::to_hstring(it.name())], trait);
}
return winrt::single_threaded_map<winrt::hstring, T>(std::move(val));
}
bool CanConvert(const Json::Value& json) const
{
if (!json.isObject())
{
return false;
}
ConversionTrait<T> trait;
for (const auto& v : json)
{
if (!trait.CanConvert(v))
{
return false;
}
}
return true;
}
Json::Value ToJson(const winrt::Windows::Foundation::Collections::IMap<winrt::hstring, T>& val)
{
Json::Value json{ Json::objectValue };
for (const auto& [k, v] : val)
{
SetValueForKey(json, til::u16u8(k), v);
}
return json;
}
std::string TypeDescription() const
{
return fmt::format("map (string, {})", ConversionTrait<T>{}.TypeDescription());
}
};
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
#endif
template<>
struct ConversionTrait<bool>
{
bool FromJson(const Json::Value& json)
{
return json.asBool();
}
bool CanConvert(const Json::Value& json)
{
return json.isBool();
}
Json::Value ToJson(const bool val)
{
return val;
}
std::string TypeDescription() const
{
return "true | false";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<int>
{
int FromJson(const Json::Value& json)
{
return json.asInt();
}
bool CanConvert(const Json::Value& json)
{
return json.isInt();
}
Json::Value ToJson(const int& val)
{
return val;
}
std::string TypeDescription() const
{
return "number";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<unsigned int>
{
unsigned int FromJson(const Json::Value& json)
{
return json.asUInt();
}
bool CanConvert(const Json::Value& json)
{
return json.isUInt();
}
Json::Value ToJson(const unsigned int& val)
{
return val;
}
std::string TypeDescription() const
{
return "number (>= 0)";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<float>
{
float FromJson(const Json::Value& json)
{
return json.asFloat();
}
bool CanConvert(const Json::Value& json)
{
return json.isNumeric();
}
Json::Value ToJson(const float& val)
{
return val;
}
std::string TypeDescription() const
{
return "number";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<double>
{
double FromJson(const Json::Value& json)
{
return json.asDouble();
}
bool CanConvert(const Json::Value& json)
{
return json.isNumeric();
}
Json::Value ToJson(const double& val)
{
return val;
}
std::string TypeDescription() const
{
return "number";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<GUID>
{
GUID FromJson(const Json::Value& json)
{
return ::Microsoft::Console::Utils::GuidFromString(til::u8u16(Detail::GetStringView(json)));
}
bool CanConvert(const Json::Value& json)
{
if (!json.isString())
{
return false;
}
const auto string{ Detail::GetStringView(json) };
return string.length() == 38 && string.front() == '{' && string.back() == '}';
}
Json::Value ToJson(const GUID& val)
{
return til::u16u8(::Microsoft::Console::Utils::GuidToString(val));
}
std::string TypeDescription() const
{
return "guid";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
// GUID and winrt::guid are mutually convertible,
// but IReference<winrt::guid> throws some of this off
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
template<>
struct ConversionTrait<winrt::guid>
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
winrt::guid FromJson(const Json::Value& json) const
{
return static_cast<winrt::guid>(ConversionTrait<GUID>{}.FromJson(json));
}
bool CanConvert(const Json::Value& json) const
{
return ConversionTrait<GUID>{}.CanConvert(json);
}
Json::Value ToJson(const winrt::guid& val)
{
return ConversionTrait<GUID>{}.ToJson(val);
}
std::string TypeDescription() const
{
return ConversionTrait<GUID>{}.TypeDescription();
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
template<>
struct ConversionTrait<til::color>
{
til::color FromJson(const Json::Value& json)
{
return ::Microsoft::Console::Utils::ColorFromHexString(Detail::GetStringView(json));
}
bool CanConvert(const Json::Value& json)
{
if (!json.isString())
{
return false;
}
const auto string{ Detail::GetStringView(json) };
return (string.length() == 7 || string.length() == 4) && string.front() == '#';
}
Json::Value ToJson(const til::color& val)
{
return til::u16u8(val.ToHexString(true));
}
std::string TypeDescription() const
{
return "color (#rrggbb, #rgb)";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
#ifdef WINRT_Windows_UI_H
template<>
struct ConversionTrait<winrt::Windows::UI::Color>
{
winrt::Windows::UI::Color FromJson(const Json::Value& json) const
{
return static_cast<winrt::Windows::UI::Color>(ConversionTrait<til::color>{}.FromJson(json));
}
bool CanConvert(const Json::Value& json) const
{
return ConversionTrait<til::color>{}.CanConvert(json);
}
Json::Value ToJson(const winrt::Windows::UI::Color& val)
{
return ConversionTrait<til::color>{}.ToJson(val);
}
std::string TypeDescription() const
{
return ConversionTrait<til::color>{}.TypeDescription();
}
};
#endif
#ifdef WINRT_Microsoft_Terminal_Core_H
template<>
struct ConversionTrait<winrt::Microsoft::Terminal::Core::Color>
{
winrt::Microsoft::Terminal::Core::Color FromJson(const Json::Value& json) const
{
return static_cast<winrt::Microsoft::Terminal::Core::Color>(ConversionTrait<til::color>{}.FromJson(json));
}
bool CanConvert(const Json::Value& json) const
{
return ConversionTrait<til::color>{}.CanConvert(json);
}
Json::Value ToJson(const winrt::Microsoft::Terminal::Core::Color& val)
{
return ConversionTrait<til::color>{}.ToJson(val);
}
std::string TypeDescription() const
{
return ConversionTrait<til::color>{}.TypeDescription();
}
};
#endif
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
template<typename T, typename TDelegatedConverter = ConversionTrait<typename std::decay<T>::type>, typename TOpt = std::optional<typename std::decay<T>::type>>
struct OptionalConverter
{
using Oracle = OptionOracle<TOpt>;
TDelegatedConverter delegatedConverter{};
TOpt FromJson(const Json::Value& json)
{
if (!json && !delegatedConverter.CanConvert(json))
{
// If the nested converter can't deal with null, emit an empty optional
// If it can, it probably has specific null behavior that it wants to use.
return Oracle::EmptyV();
}
TOpt val{ delegatedConverter.FromJson(json) };
return val;
}
bool CanConvert(const Json::Value& json)
{
return json.isNull() || delegatedConverter.CanConvert(json);
}
Json::Value ToJson(const TOpt& val)
{
if (!Oracle::HasValue(val))
{
return Json::Value::nullSingleton();
}
return delegatedConverter.ToJson(Oracle::Value(val));
}
std::string TypeDescription() const
{
return delegatedConverter.TypeDescription();
}
};
template<typename T>
struct ConversionTrait<std::optional<T>> : public OptionalConverter<T, ConversionTrait<T>, std::optional<T>>
{
};
#ifdef WINRT_Windows_Foundation_H
template<typename T>
struct ConversionTrait<::winrt::Windows::Foundation::IReference<T>> : public OptionalConverter<T, ConversionTrait<T>, ::winrt::Windows::Foundation::IReference<T>>
{
};
#endif
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
template<typename T, typename TBase>
struct EnumMapper
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
using BaseEnumMapper = EnumMapper<T, TBase>;
using ValueType = T;
using pair_type = std::pair<std::string_view, T>;
T FromJson(const Json::Value& json)
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
const auto name{ Detail::GetStringView(json) };
for (const auto& pair : TBase::mappings)
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
if (pair.first == name)
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
return pair.second;
}
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
DeserializationError e{ json };
e.expectedType = static_cast<const TBase&>(*this).TypeDescription();
throw e;
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
bool CanConvert(const Json::Value& json)
{
return json.isString();
}
Json::Value ToJson(const T& val)
{
for (const auto& pair : TBase::mappings)
{
if (pair.second == val)
{
return { pair.first.data() };
}
}
throw SerializationError{};
}
std::string TypeDescription() const
{
std::vector<std::string_view> names;
std::transform(TBase::mappings.cbegin(), TBase::mappings.cend(), std::back_inserter(names), [](auto&& p) { return p.first; });
return fmt::format("{}", fmt::join(names, " | "));
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
// FlagMapper is EnumMapper, but it works for bitfields.
// It supports a string (single flag) or an array of strings.
// Does an O(n*m) search; meant for small search spaces!
//
// Cleverly leverage EnumMapper to do the heavy lifting.
template<typename T, typename TBase>
struct FlagMapper : public EnumMapper<T, TBase>
{
private:
// Hide BaseEnumMapper so FlagMapper's consumers cannot see
// it.
using BaseEnumMapper = EnumMapper<T, TBase>::BaseEnumMapper;
public:
using BaseFlagMapper = FlagMapper<T, TBase>;
static constexpr T AllSet{ static_cast<T>(~0u) };
static constexpr T AllClear{ static_cast<T>(0u) };
T FromJson(const Json::Value& json)
{
if (json.isString())
{
return BaseEnumMapper::FromJson(json);
}
else if (json.isArray())
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
{
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
unsigned int seen{ 0 };
T value{};
for (const auto& element : json)
{
const auto newFlag{ BaseEnumMapper::FromJson(element) };
if (++seen > 1 &&
((newFlag == AllClear && value != AllClear) ||
(value == AllClear && newFlag != AllClear)))
{
// attempt to combine AllClear (explicitly) with anything else
DeserializationError e{ element };
e.expectedType = static_cast<const TBase&>(*this).TypeDescription();
throw e;
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
value |= newFlag;
}
return value;
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// We'll only get here if CanConvert has failed us.
return AllClear;
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
Json::Value ToJson(const T& val)
{
if (val == AllClear)
{
return BaseEnumMapper::ToJson(AllClear);
}
else if (val == AllSet)
{
return BaseEnumMapper::ToJson(AllSet);
}
else if (WI_IsSingleFlagSet(val))
{
return BaseEnumMapper::ToJson(val);
}
else
{
Json::Value json{ Json::ValueType::arrayValue };
for (const auto& pair : TBase::mappings)
{
if (pair.second != AllClear &&
(val & pair.second) == pair.second &&
WI_IsSingleFlagSet(pair.second))
{
json.append(BaseEnumMapper::ToJson(pair.second));
}
}
return json;
}
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
bool CanConvert(const Json::Value& json)
{
return BaseEnumMapper::CanConvert(json) || json.isArray();
}
};
template<typename T>
struct PermissiveStringConverter
{
};
template<>
struct PermissiveStringConverter<std::wstring>
{
std::wstring FromJson(const Json::Value& json)
{
return til::u8u16(json.asString());
}
bool CanConvert(const Json::Value& /*unused*/)
{
return true;
}
std::string TypeDescription() const
{
return "any";
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
};
// Method Description:
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// - Helper that will populate a reference with a value converted from a json object.
// Arguments:
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// - json: the json object to convert
// - target: the value to populate with the converted result
// Return Value:
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// - a boolean indicating whether the value existed (in this case, was non-null)
//
// GetValue, type-deduced, manual converter
template<typename T, typename Converter>
bool GetValue(const Json::Value& json, T& target, Converter&& conv)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
if (!conv.CanConvert(json))
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
DeserializationError e{ json };
e.expectedType = conv.TypeDescription();
throw e;
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
target = conv.FromJson(json);
return true;
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
// GetValue, forced return type, manual converter
template<typename T, typename Converter>
std::decay_t<T> GetValue(const Json::Value& json, Converter&& conv)
{
std::decay_t<T> local{};
GetValue(json, local, std::forward<Converter>(conv));
return local; // returns zero-initialized or value
}
// GetValueForKey, type-deduced, manual converter
template<typename T, typename Converter>
bool GetValueForKey(const Json::Value& json, std::string_view key, T& target, Converter&& conv)
{
if (auto found{ json.find(&*key.cbegin(), (&*key.cbegin()) + key.size()) })
{
try
{
return GetValue(*found, target, std::forward<Converter>(conv));
}
catch (DeserializationError& e)
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
{
e.SetKey(key);
throw; // rethrow now that it has a key
}
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
return false;
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// GetValueForKey, forced return type, manual converter
template<typename T, typename Converter>
std::decay_t<T> GetValueForKey(const Json::Value& json, std::string_view key, Converter&& conv)
{
std::decay_t<T> local{};
GetValueForKey(json, key, local, std::forward<Converter>(conv));
return local; // returns zero-initialized?
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// GetValue, type-deduced, with automatic converter
template<typename T>
bool GetValue(const Json::Value& json, T& target)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
return GetValue(json, target, ConversionTrait<typename std::decay<T>::type>{});
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// GetValue, forced return type, with automatic converter
template<typename T>
std::decay_t<T> GetValue(const Json::Value& json)
{
std::decay_t<T> local{};
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
GetValue(json, local, ConversionTrait<typename std::decay<T>::type>{});
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
return local; // returns zero-initialized or value
}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
// GetValueForKey, type-deduced, with automatic converter
template<typename T>
bool GetValueForKey(const Json::Value& json, std::string_view key, T& target)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
return GetValueForKey(json, key, target, ConversionTrait<typename std::decay<T>::type>{});
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
// GetValueForKey, forced return type, with automatic converter
template<typename T>
std::decay_t<T> GetValueForKey(const Json::Value& json, std::string_view key)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
return GetValueForKey<T>(json, key, ConversionTrait<typename std::decay<T>::type>{});
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
}
// Get multiple values for keys (json, k, &v, k, &v, k, &v, ...).
// Uses the default converter for each v.
// Careful: this can cause a template explosion.
constexpr void GetValuesForKeys(const Json::Value& /*json*/) {}
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
template<typename T, typename... Args>
void GetValuesForKeys(const Json::Value& json, std::string_view key1, T&& val1, Args&&... args)
{
GetValueForKey(json, key1, val1);
GetValuesForKeys(json, std::forward<Args>(args)...);
}
// SetValueForKey, type-deduced, manual converter
template<typename T, typename Converter>
void SetValueForKey(Json::Value& json, std::string_view key, const T& target, Converter&& conv)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
// We don't want to write any empty optionals into JSON (right now).
if (OptionOracle<T>::HasValue(target))
{
// demand guarantees that it will return a value or throw an exception
*json.demand(&*key.cbegin(), (&*key.cbegin()) + key.size()) = conv.ToJson(target);
}
}
// SetValueForKey, type-deduced, with automatic converter
template<typename T>
void SetValueForKey(Json::Value& json, std::string_view key, const T& target)
{
Rework JsonUtils' optional handling to let Converters see null (#8175) The JsonUtils changes in #8018 revealed that we need more robust, configurable optional handling. We learned that there's a class of values that was previously underrepresented in our API: _strings that have an explicit empty value_. The Settings model supports starting directory, icon, background image et al values that are empty. That emptiness _overrides_ a value set in a lower layer, so it is not sufficient to represent the empty value for any one of those fields as an unset optional. There are a couple other settings for which we've implemented a hand-rolled option type (for roughly the same reason): foreground, background, any color fields that override values from the color scheme _or_ the lower layer profile. These requirements are best fulfilled by better optional support in JsonUtils. Where the library would originally detect known types of optional and pre-filter them out during `GetValue` and `SetValue`, it will now defer to another conversion trait. This commit introduces a helper conversion trait and an "option oracle". The conversion trait will use the option oracle to detect emptiness, generate empty option values, and read values out of option types. In so doing, the trait is insulated from the implementation details of any specific option type. Any special logic for handling JSON null and option types has been stripped from GetValue. Due to this, there is an express change in behavior for some converters: * `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has been upgraded from a silent no-op to an exception. Further, I took the opportunity to replace NullableSetting with std::optional<std::optional<T>>, which accurately represents "setting that the user might explicitly clear". I've added a test to JsonUtilsTests to make sure it can serialize/deserialize double optionals the way we expect it to. Tests (Local, Unit for TerminalApp/SettingsModel): Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0 [1]: Explicitly, if `T` is not an option type _and the converter does not support null_.
2020-11-10 00:13:02 +01:00
SetValueForKey(json, key, target, ConversionTrait<typename std::decay<T>::type>{});
}
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 21:57:10 +02:00
};
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
Introduce TerminalSettingsModel project (#7667) 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 18:56:59 +02:00
#define JSON_ENUM_MAPPER(...) \
template<> \
struct ::Microsoft::Terminal::Settings::Model::JsonUtils::ConversionTrait<__VA_ARGS__> : \
public ::Microsoft::Terminal::Settings::Model::JsonUtils::EnumMapper<__VA_ARGS__, ::Microsoft::Terminal::Settings::Model::JsonUtils::ConversionTrait<__VA_ARGS__>>
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
Introduce TerminalSettingsModel project (#7667) 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 18:56:59 +02:00
#define JSON_FLAG_MAPPER(...) \
template<> \
struct ::Microsoft::Terminal::Settings::Model::JsonUtils::ConversionTrait<__VA_ARGS__> : \
public ::Microsoft::Terminal::Settings::Model::JsonUtils::FlagMapper<__VA_ARGS__, ::Microsoft::Terminal::Settings::Model::JsonUtils::ConversionTrait<__VA_ARGS__>>
Convert most of our JSON deserializers to use type-based conversion (#6590) This pull request converts the following JSON deserializers to use the new JSON deserializer pattern: * Profile * Command * ColorScheme * Action/Args * GlobalSettings * CascadiaSettingsSerialization This is the completion of a long-term JSON refactoring that makes our parser and deserializer more type-safe and robust. We're finally able to get rid of all our manual enum conversion code and unify JSON conversion around _types_ instead of around _keys_. I've introduced another file filled with template specializations, TerminalSettingsSerializationHelpers.h, which comprises a single unit that holds all of the JSON deserializers (and eventually serializers) for every type that comes from TerminalApp or TerminalSettings. I've also moved some types out of Profile and GlobalAppSettings into a new SettingsTypes.h to improve settings locality. This does to some extent constitute a breaking change for already-broken settings. Instead of parsing "successfully" (where invalid values are null or 0 or unknown or unset), deserialization will now fail when there's a type mismatch. Because of that, some tests had to be removed. While I was on a refactoring spree, I removed a number of helpless helpers, like GetWstringFromJson (which converted a u8 string to an hstring to make a wstring out of its data pointer :|) and _ConvertJsonToBool. In the future, we can make the error types more robust and give them position and type information such that a conformant application can display rich error information ("line 3 column 3, I expected a string, you gave me an integer"). Closes #2550.
2020-07-17 03:31:09 +02:00
#define JSON_MAPPINGS(Count) \
static constexpr std::array<pair_type, Count> mappings