starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity
Files
806d5e2d05a31bf042b6d98aeacd33d24880d189
terminal/src/cascadia/UnitTests_SettingsModel/SerializationTests.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

952 lines
40 KiB
C++
Raw Normal View History

Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "../TerminalSettingsModel/ColorScheme.h"
#include "../TerminalSettingsModel/CascadiaSettings.h"
#include "JsonTestClass.h"
#include "TestUtils.h"
#include <defaults.h>
using namespace Microsoft::Console;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
using namespace WEX::Common;
using namespace winrt::Microsoft::Terminal::Settings::Model;
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 15:47:24 -05:00
using namespace winrt::Microsoft::Terminal::Control;
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
namespace SettingsModelUnitTests
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
class SerializationTests : public JsonTestClass
{
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
TEST_CLASS(SerializationTests);
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
TEST_METHOD(GlobalSettings);
TEST_METHOD(Profile);
TEST_METHOD(ColorScheme);
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
TEST_METHOD(Actions);
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
TEST_METHOD(CascadiaSettings);
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
TEST_METHOD(LegacyFontSettings);
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
Allow inheriting env vars from `wt` again and other env var changes too (#15897) This PR is a few things: * part the first: Convert the `compatibility.reloadEnvironmentVariables` setting to a per-profile one. * The settings should migrate it from the user's old global place to the new one. * We also added it to "Profile>Advanced" while I was here. * Adds a new pair of commandline flags to `new-tab` and `split-pane`: `--inheritEnvironment` / `--reloadEnvironment` * On `wt` launch, bundle the entire environment that `wt` was spawned with, and put it into the `Remoting.CommandlineArgs`, and give them to the monarch (and ultimately, down to `TerminalPage` with the `AppCommandlineArgs`). DO THIS ALWAYS. * As a part of this, we’ll default to _reloading_ if there’s no explicit commandline set, and _inheriting_ if there is. * For example, `wt -- cmd` would inherit, and `wt -p “Command Prompt”` would reload.[^1] * This is a little wacky, but we’re trying to separate out the intentions here: * `wt -- cmd` feels like “I want to run cmd.exe (in a terminal tab)”. That feels like the user would _like_ environment variables from the calling process. They’re doing something more manual, so they get more refined control over it. * `wt` (or `wt -p “Command Prompt”`) is more like, “I want to run the Terminal (or, my Command Prompt profile) using whatever the Terminal would normally do”. So that feels more like a situation where it should just reload by default. (Of course, this will respect their settings here) ## References and Relevant Issues https://github.com/microsoft/terminal/issues/15496#issuecomment-1692450231 has more notes. ## Detailed Description of the Pull Request / Additional comments This is so VERY much plumbing. I'll try to leave comments in the interesting parts. ## PR Checklist - [x] This is not _all_ of #15496. We're also going to do a `-E foo=bar` arg on top of this. - [x] Tests added/passed - [x] Schema updated [^1]: In both these cases, plus the `environment` setting, of course.
2023-09-19 15:03:24 -05:00
TEST_METHOD(RoundtripReloadEnvVars);
TEST_METHOD(DontRoundtripNoReloadEnvVars);
Deduplicate identical inbox color schemes to heal user settings (#12800) Up until now, we have treated inbox, fragment and user color schemes the same: we load them all into one big map and when we save the settings file we write them *all* out. It's been a big annoyance pretty much forever. In addition to cluttering the user's settings file, it prevents us from making changes to the stock color schemes (like to change the cursor color, or to adjust the colors in Tango Dark, or what have you) because they're already copied in full in the user settings. It also means that we need some special UI affordances for color schemes that you are allowed to view but not to delete or rename. We also have a funny hardcoded list of color scheme names and we use that to determine whether they're "inbox" for UI purposes. Because of all that, we are hesitant to add *more* color schemes to the default set. This pull request resolves all of those issues at once. It: - Adds an "origin" to color schemes indicating where they're from (Inbox, Fragment, User, ...) - Replaces the Edit UI with a much simpler version that pretty much only has a "duplicate this color scheme to start editing it" button - Deletes color schemes that we consider to be equivalent to inbox ones; this allows us to finally disentangle the user's preferences from the terminal's. - Migrates all user settings that referred to schemes they may have modified (even implicitly!) to their modified versions. The equivalence check intentionally leaves out the cursor and selection colors, so that we have the freedom to change them in the future. The Origin is part of a new interface, `ISettingsModelObject`, which we can use in the future for things like Themes and Actions.
2024-02-27 13:07:08 -06:00
TEST_METHOD(RoundtripUserModifiedColorSchemeCollision);
TEST_METHOD(RoundtripUserModifiedColorSchemeCollisionUnusedByProfiles);
TEST_METHOD(RoundtripUserDeletedColorSchemeCollision);
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
private:
// Method Description:
// - deserializes and reserializes a json string representing a settings object model of type T
// - verifies that the generated json string matches the provided one
// Template Types:
// - <T>: The type of Settings Model object to generate (must be impl type)
// Arguments:
// - jsonString - JSON string we're performing the test on
// Return Value:
// - the JsonObject representing this instance
template<typename T>
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
void RoundtripTest(const std::string_view& jsonString)
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
const auto json{ VerifyParseSucceeded(jsonString) };
const auto settings{ T::FromJson(json) };
const auto result{ settings->ToJson() };
// Compare toString(json) instead of jsonString here.
// The toString writes the json out alphabetically.
// This trick allows jsonString to _not_ have to be
// written alphabetically.
VERIFY_ARE_EQUAL(toString(json), toString(result));
}
Add support for actions in fragments (#16185) Surprisingly easier than I thought this would be. ActionMap already supports layering (from defaults.json), so this basically re-uses a lot of that for fun and profit. The trickiest bits: * In `SettingsLoader::_parseFragment`, I'm constructing a fake, empty JSON object, and taking _only_ the actions out from the fragment, and stuffing them into this temp json. Then, I parse that as a globals object, and set _that_ as the parent to the user settings file. That results in _only_ the actions from the fragment being parsed before the user's actions. * In that same method, I'm also explicitly preventing the ActionMap (et al.) from parsing `keys` from these actions. We don't want fragments to be able to say "ctrl+f is clear buffer" or something like that. This required a bit of annoying plumbing. Closes #16063 Tests added. Docs need to be updated.
2024-02-26 12:27:57 -08:00
// Helper to remove the `$schema` property from a json object. We
// populate that based off the local path to the settings file. Of
// course, that's entirely unpredictable in tests. So cut it out before
// we do any sort of roundtrip testing.
static Json::Value removeSchema(Json::Value json)
{
if (json.isMember("$schema"))
{
json.removeMember("$schema");
}
return json;
}
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
};
void SerializationTests::GlobalSettings()
{
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view globalsString{ R"(
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"initialRows": 30,
"initialCols": 120,
"initialPosition": ",",
"launchMode": "default",
"alwaysOnTop": false,
Control 'Touch Keyboard and Handwriting Panel Service' warning (#9015) Add a setting to turn off the warning if 'Touch Keyboard and Handwriting Panel Service' is disabled. The service might not start in some case, and it doesn't affect the input in some computer. This PR turn off the warning even if the service is disabled. The setting name is "inputServiceWarning". ## Validation Steps Performed I manually set the service to "Disabled", restarted the Terminal, verified the warning up, then set "inputServiceWarning" to false and restarted the Terminal, and the warning didn't appear. References #8095 References https://github.com/microsoft/terminal/issues/7886#issuecomment-729350169
2021-02-23 04:08:49 +08:00
"inputServiceWarning": true,
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"copyOnSelect": false,
"copyFormatting": "all",
"wordDelimiters": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502",
"alwaysShowTabs": true,
"showTabsInTitlebar": true,
"showTerminalTitleInTitlebar": true,
"tabWidthMode": "equal",
"tabSwitcherMode": "mru",
"startOnUserLogin": false,
"theme": "system",
"snapToGridOnResize": true,
"disableAnimations": false,
"confirmCloseAllTabs": true,
"largePasteWarning": true,
"multiLinePasteWarning": true,
Trim trailing whitespace option (#11473) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Opt in setting to trim trailing white space when pasting a text into the terminal <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9400 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manually testing to paste text with and without trailing white spaces, with and without the option activated
2021-10-28 17:38:23 +02:00
"trimPaste": true,
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"experimental.input.forceVT": false,
"experimental.rendering.forceFullRepaint": false,
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
"experimental.rendering.software": false,
"actions": []
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
})" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view smallGlobalsString{ R"(
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"actions": []
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
})" };
RoundtripTest<implementation::GlobalAppSettings>(globalsString);
RoundtripTest<implementation::GlobalAppSettings>(smallGlobalsString);
}
void SerializationTests::Profile()
{
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view profileString{ R"(
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
"name": "Windows PowerShell",
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"startingDirectory": "%USERPROFILE%",
"icon": "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png",
"hidden": false,
"tabTitle": "Cool Tab",
"suppressApplicationTitle": false,
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
"font": {
"face": "Cascadia Mono",
Add support for switching the scheme based on the app's theme (#14064) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet. This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4066 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4066 * [x] Closes #14050 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA. * [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #4066 and also teams messages with @carlos-zamora <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments -Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object. -Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName. -Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName -Added and Updated Test to align to the new code. Acceptable Json values, "colorScheme": { "dark": "Campbell", "light": "Campbell" } or "colorScheme": "Campbell" <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Individual testing along with the test case added.
2022-12-06 09:33:22 -08:00
"size": 12.0,
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
"weight": "normal"
},
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"padding": "8, 8, 8, 8",
"antialiasingMode": "grayscale",
"cursorShape": "bar",
"cursorColor": "#CCBBAA",
"cursorHeight": 10,
"altGrAliasing": true,
"colorScheme": "Campbell",
"tabColor": "#0C0C0C",
"foreground": "#AABBCC",
"background": "#BBCCAA",
"selectionBackground": "#CCAABB",
"useAcrylic": false,
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
"opacity": 50,
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"backgroundImage": "made_you_look.jpeg",
"backgroundImageStretchMode": "uniformToFill",
"backgroundImageAlignment": "center",
"backgroundImageOpacity": 1.0,
"scrollbarState": "visible",
"snapOnInput": true,
"historySize": 9001,
"closeOnExit": "graceful",
Support environment variables in the settings (#15082) Existing environment variables can be referenced by enclosing the name in percent characters (e.g. `%PATH%`). Resurrects #9287 by @christapley. Tests added and manually tested. Closes #2785 Closes #9233 Co-authored-by: Chris Tapley <chris.tapley.81@gmail.com>
2023-04-12 00:01:11 +01:00
"experimental.retroTerminalEffect": false,
"environment":
{
"KEY_1": "VALUE_1",
"KEY_2": "%KEY_1%",
"KEY_3": "%PATH%"
}
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
})" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view smallProfileString{ R"(
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
"name": "Custom Profile"
})" };
// Setting "tabColor" to null tests two things:
// - null should count as an explicit user-set value, not falling back to the parent's value
// - null should be acceptable even though we're working with colors
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view weirdProfileString{ R"(
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
{
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
"guid" : "{8b039d4d-77ca-5a83-88e1-dfc8e895a127}",
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"name": "Weird Profile",
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
"hidden": false,
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"tabColor": null,
"foreground": null,
"source": "local"
})" };
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
static constexpr std::string_view profileWithIcon{ R"(
{
"guid" : "{8b039d4d-77ca-5a83-88e1-dfc8e895a127}",
"name": "profileWithIcon",
"hidden": false,
"icon": "foo.png"
})" };
static constexpr std::string_view profileWithNullIcon{ R"(
{
"guid" : "{8b039d4d-77ca-5a83-88e1-dfc8e895a127}",
"name": "profileWithNullIcon",
"hidden": false,
"icon": null
})" };
static constexpr std::string_view profileWithNoIcon{ R"(
{
"guid" : "{8b039d4d-77ca-5a83-88e1-dfc8e895a127}",
"name": "profileWithNoIcon",
"hidden": false,
"icon": "none"
})" };
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
RoundtripTest<implementation::Profile>(profileString);
RoundtripTest<implementation::Profile>(smallProfileString);
RoundtripTest<implementation::Profile>(weirdProfileString);
Make the Settings Model tests into proper CI tests (#16773) This pull request removes the need for the SettingsModel tests to run in a UAP harness and puts them into the standard CI rotation. This required some changes to `Run-Tests.ps1` to ensure that the right `te.exe` is selected for each test harness. It's a bit annoying, but for things that depend on a `resources.pri`, that file must be in the same directory as the EXE that is hosting the test. Not the DLL, mind you, the EXE. In our case, that's `TE.ProcessHost.exe` The bulk of the change is honestly namespace tidying. Co-authored-by: Mike Griese <migrie@microsoft.com> Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
2024-02-29 11:00:04 -06:00
RoundtripTest<implementation::Profile>(profileWithIcon);
RoundtripTest<implementation::Profile>(profileWithNullIcon);
RoundtripTest<implementation::Profile>(profileWithNoIcon);
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
}
void SerializationTests::ColorScheme()
{
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view schemeString{ R"({
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
"name": "Campbell",
"cursorColor": "#FFFFFF",
"selectionBackground": "#131313",
"background": "#0C0C0C",
"foreground": "#F2F2F2",
"black": "#0C0C0C",
"blue": "#0037DA",
"cyan": "#3A96DD",
"green": "#13A10E",
"purple": "#881798",
"red": "#C50F1F",
"white": "#CCCCCC",
"yellow": "#C19C00",
"brightBlack": "#767676",
"brightBlue": "#3B78FF",
"brightCyan": "#61D6D6",
"brightGreen": "#16C60C",
"brightPurple": "#B4009E",
"brightRed": "#E74856",
"brightWhite": "#F2F2F2",
"brightYellow": "#F9F1A5"
})" };
RoundtripTest<implementation::ColorScheme>(schemeString);
}
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
void SerializationTests::Actions()
{
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// simple command
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString1{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": "paste" }
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// complex command
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString2A{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": { "action": "setTabColor" } }
])" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString2B{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": { "action": "setTabColor", "color": "#112233" } }
])" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString2C{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": { "action": "copy" } },
{ "command": { "action": "copy", "singleLine": true, "copyFormatting": "html" } }
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// simple command with key chords
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString3{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": "toggleAlwaysOnTop", "keys": "ctrl+a" },
{ "command": "toggleAlwaysOnTop", "keys": "ctrl+b" }
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// complex command with key chords
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString4A{ R"([
Add support for switching the scheme based on the app's theme (#14064) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet. This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4066 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4066 * [x] Closes #14050 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA. * [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #4066 and also teams messages with @carlos-zamora <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments -Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object. -Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName. -Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName -Added and Updated Test to align to the new code. Acceptable Json values, "colorScheme": { "dark": "Campbell", "light": "Campbell" } or "colorScheme": "Campbell" <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Individual testing along with the test case added.
2022-12-06 09:33:22 -08:00
{ "command": { "action": "adjustFontSize", "delta": 1.0 }, "keys": "ctrl+c" },
{ "command": { "action": "adjustFontSize", "delta": 1.0 }, "keys": "ctrl+d" }
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// command with name and icon and multiple key chords
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString5{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "icon": "image.png", "name": "Scroll To Top Name", "command": "scrollToTop", "keys": "ctrl+e" },
{ "command": "scrollToTop", "keys": "ctrl+f" }
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// complex command with new terminal args
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString6{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": { "action": "newTab", "index": 0 }, "keys": "ctrl+g" },
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// complex command with meaningful null arg
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString7{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": { "action": "renameWindow", "name": null }, "keys": "ctrl+h" }
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// nested command
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString8{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
"name": "Change font size...",
"commands": [
Add support for switching the scheme based on the app's theme (#14064) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet. This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4066 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4066 * [x] Closes #14050 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA. * [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #4066 and also teams messages with @carlos-zamora <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments -Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object. -Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName. -Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName -Added and Updated Test to align to the new code. Acceptable Json values, "colorScheme": { "dark": "Campbell", "light": "Campbell" } or "colorScheme": "Campbell" <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Individual testing along with the test case added.
2022-12-06 09:33:22 -08:00
{ "command": { "action": "adjustFontSize", "delta": 1.0 } },
{ "command": { "action": "adjustFontSize", "delta": -1.0 } },
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": "resetFontSize" },
]
}
])" };
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// iterable command
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString9A{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
"name": "New tab",
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": "${profile.name}",
"command": { "action": "newTab", "profile": "${profile.name}" }
}
]
}
])" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString9B{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"commands":
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
[
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"command":
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
"action": "sendInput",
"input": "${profile.name}"
},
"iterateOn": "profiles"
}
],
"name": "Send Input ..."
}
])" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString9C{ R""([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"commands":
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
[
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"commands":
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
[
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"command":
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{
"action": "sendInput",
"input": "${profile.name} ${scheme.name}"
},
"iterateOn": "schemes"
}
],
"iterateOn": "profiles",
"name": "nest level (${profile.name})"
}
],
"name": "Send Input (Evil) ..."
}
])"" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString9D{ R""([
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
{
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"command":
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
{
"action": "newTab",
"profile": "${profile.name}"
},
"icon": "${profile.icon}",
"iterateOn": "profiles",
"name": "${profile.name}: New tab"
}
])"" };
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
// unbound command
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view actionsString10{ R"([
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
{ "command": "unbound", "keys": "ctrl+c" }
])" };
Log::Comment(L"simple command");
RoundtripTest<implementation::ActionMap>(actionsString1);
Log::Comment(L"complex commands");
RoundtripTest<implementation::ActionMap>(actionsString2A);
RoundtripTest<implementation::ActionMap>(actionsString2B);
RoundtripTest<implementation::ActionMap>(actionsString2C);
Log::Comment(L"simple command with key chords");
RoundtripTest<implementation::ActionMap>(actionsString3);
Log::Comment(L"complex commands with key chords");
Fix serialisation of findMatch action (#11233) ## Summary of the Pull Request Fixes the serialisation of the findMatch action so that the direction is stored. ## PR Checklist * [x] Closes #11225 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx ## Validation Steps Performed Added a test and tested manually.
2021-09-15 19:00:33 +01:00
RoundtripTest<implementation::ActionMap>(actionsString4A);
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
Log::Comment(L"command with name and icon and multiple key chords");
RoundtripTest<implementation::ActionMap>(actionsString5);
Log::Comment(L"complex command with new terminal args");
RoundtripTest<implementation::ActionMap>(actionsString6);
Log::Comment(L"complex command with meaningful null arg");
RoundtripTest<implementation::ActionMap>(actionsString7);
Log::Comment(L"nested command");
RoundtripTest<implementation::ActionMap>(actionsString8);
Log::Comment(L"iterable command");
RoundtripTest<implementation::ActionMap>(actionsString9A);
RoundtripTest<implementation::ActionMap>(actionsString9B);
RoundtripTest<implementation::ActionMap>(actionsString9C);
Bugfix: serialize iterable commands (#10373) ## Summary of the Pull Request Fixes a bug where top-level iterable commands were not serialized. ## PR Checklist * [X] Closes #10365 * [X] Tests added/passed ## Detailed Description of the Pull Request / Additional comments - `Command::ToJson`: - iterable commands deserve the same treatment as nested commands - `ActionMap`: - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
2021-06-10 14:25:27 -04:00
RoundtripTest<implementation::ActionMap>(actionsString9D);
Introduce serialization for actions (#9926) ## Summary of the Pull Request This PR builds on the `ActionMap` PR (#6900) by leveraging `ActionMap` to serialize actions. From the top down, the process is now as follows: - `CascadiaSettings`: remove the hack of copying whatever we had for actions before. - `GlobalAppSettings`: serialize the `ActionMap` to `"actions": []` - `ActionMap`: iterate over the internal `_ActionMap` (list of actions) and serialize each `Command` - `Command`: **THIS IS WHERE THE MAGIC HAPPENS!** For _each_ key mapping, serialize an action. Only the first one needs to include the name and icon. - `ActionAndArgs`: Find the relevant `IActionArgs` parser and serialize the `ActionAndArgs`. - `ActionArgs`: **ANNOYING CHANGE** Serialize any args that are set. We _need_ each setting to be saved as a `std::optional`. As with inheritance, this allows us to distinguish an explicit setting to the default value (sometimes `null`) vs an implicit "give me the default value". This allows us to serialize only the relevant details of each action, rather than writing _all_ of the args. ## References - #8100: Inheritance/Layering for lists - This tracks layering and better serialization for color schemes _and_ actions. This PR resolves half of that issue. The next step is to apply the concepts used in this PR (and #9621) to solve the similar problem for color schemes. - #6900: Actions page ## Validation Steps Performed Tests added!
2021-05-20 14:44:04 -04:00
Log::Comment(L"unbound command");
RoundtripTest<implementation::ActionMap>(actionsString10);
}
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
void SerializationTests::CascadiaSettings()
{
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view settingsString{ R"({
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"$help" : "https://aka.ms/terminal-documentation",
"$schema" : "https://aka.ms/terminal-profiles-schema",
"defaultProfile": "{61c54bbd-1111-5271-96e7-009a87ff44bf}",
"disabledProfileSources": [ "Windows.Terminal.Wsl" ],
Fix a crash on startup with a `folder` entry without `entries` (#14629) `_Entries` was getting default constructed to `nullptr`. We should be careful about that. Adds a test too, and fixes a regression in the local tests introduced in #13763. Closes #14557
2023-01-19 13:12:40 -06:00
"newTabMenu":
[
{
"type": "remainingProfiles"
}
],
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
"profiles": {
"defaults": {
"font": {
"face": "Zamora Code"
}
},
"list": [
{
"font": { "face": "Cascadia Code" },
"guid": "{61c54bbd-1111-5271-96e7-009a87ff44bf}",
"name": "HowettShell"
},
{
"hidden": true,
"guid": "{c08b0496-e71c-5503-b84e-3af7a7a6d2a7}",
"name": "BhojwaniShell"
},
{
"antialiasingMode": "aliased",
"guid": "{fe9df758-ac22-5c20-922d-c7766cdd13af}",
"name": "NiksaShell"
}
]
},
"schemes": [
{
"name": "Cinnamon Roll",
"cursorColor": "#FFFFFD",
"selectionBackground": "#FFFFFF",
"background": "#3C0315",
"foreground": "#FFFFFD",
"black": "#282A2E",
"blue": "#0170C5",
"cyan": "#3F8D83",
"green": "#76AB23",
"purple": "#7D498F",
"red": "#BD0940",
"white": "#FFFFFD",
"yellow": "#E0DE48",
"brightBlack": "#676E7A",
"brightBlue": "#5C98C5",
"brightCyan": "#8ABEB7",
"brightGreen": "#B5D680",
"brightPurple": "#AC79BB",
"brightRed": "#BD6D85",
"brightWhite": "#FFFFFD",
"brightYellow": "#FFFD76"
}
],
"actions": [
{ "command": { "action": "sendInput", "input": "VT Griese Mode" }, "keys": "ctrl+k" }
Two sets of localtest fixes for July 2022 (#13603) Cleans up a couple local test failures. * [x] Closes #13474: So, I clearly hadn't ran the local tests at the end of the themes PR. We needed a sensible fallback to SOME theme, even if there wasn't one provided in the user json. This is only really hit in the tests (that don't also include `defaults.json`. * [x] Closes #13323: Meh, the ordering of the keys in this test doesn't matter. Ordering is a map implementation detail. This is fine. * [x] Ran tests locally
2022-07-27 14:39:51 -05:00
],
"theme": "system",
"themes": []
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184) This commit reduces the code surface that interacts with raw JSON data, reducing code complexity and improving maintainability. Files that needed to be changed drastically were additionally cleaned up to remove any code cruft that has accrued over time. In order to facility this the following changes were made: * Move JSON handling from `CascadiaSettings` into `SettingsLoader` This allows us to use STL containers for data model instances. For instance profiles are now added to a hashmap for O(1) lookup. * JSON parsing within `SettingsLoader` doesn't differentiate between user, inbox and fragment JSON data, reducing code complexity and size. It also centralizes common concerns, like profile deduplication and ensuring that all profiles are assigned a GUID. * Direct JSON modification, like the insertion of dynamic profiles into settings.json were removed. This vastly reduces code complexity, but unfortunately removes support for comments in JSON on first start. * `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced with `FromJson`, allowing us to remove JSON-based color scheme validation. * `Profile`s used to test their wish to layer using `ShouldBeLayered`, which was replaced with a GUID-based hashmap lookup on previously parsed profiles. Further changes were made as improvements upon the previous changes: * Compact the JSON files embedded binary, saving 28kB * Prevent double-initialization of the color table in `ColorScheme` * Making `til::color` getters `constexpr`, allow better optimizations The result is a reduction of: * 48kB binary size for the Settings.Model.dll * 5-10% startup duration * 26% code for the `CascadiaSettings` class * 1% overall code in this project Furthermore this results in the following breaking changes: * The long deprecated "globals" settings object will not be detected and no warning will be created during load. * The initial creation of a new settings.json will not produce helpful comments. Both cases are caused by the removal of manual JSON handling and the move to representing the settings file with model objects instead ## PR Checklist * [x] Closes #5276 * [x] Closes #7421 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Out-of-box-experience is identical to before ✔️ (Except for the settings.json file lacking comments.) * Existing user settings load correctly ✔️ * New WSL instances are added to user settings ✔️ * New fragments are added to user settings ✔️ * All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
})" };
const auto settings{ winrt::make_self<implementation::CascadiaSettings>(settingsString) };
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
const auto result{ settings->ToJson() };
Add support for actions in fragments (#16185) Surprisingly easier than I thought this would be. ActionMap already supports layering (from defaults.json), so this basically re-uses a lot of that for fun and profit. The trickiest bits: * In `SettingsLoader::_parseFragment`, I'm constructing a fake, empty JSON object, and taking _only_ the actions out from the fragment, and stuffing them into this temp json. Then, I parse that as a globals object, and set _that_ as the parent to the user settings file. That results in _only_ the actions from the fragment being parsed before the user's actions. * In that same method, I'm also explicitly preventing the ActionMap (et al.) from parsing `keys` from these actions. We don't want fragments to be able to say "ctrl+f is clear buffer" or something like that. This required a bit of annoying plumbing. Closes #16063 Tests added. Docs need to be updated.
2024-02-26 12:27:57 -08:00
VERIFY_ARE_EQUAL(toString(removeSchema(VerifyParseSucceeded(settingsString))),
toString(removeSchema(result)));
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
}
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
void SerializationTests::LegacyFontSettings()
{
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view profileString{ R"(
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
{
"name": "Profile with legacy font settings",
"fontFace": "Cascadia Mono",
Add support for switching the scheme based on the app's theme (#14064) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet. This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4066 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4066 * [x] Closes #14050 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA. * [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #4066 and also teams messages with @carlos-zamora <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments -Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object. -Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName. -Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName -Added and Updated Test to align to the new code. Acceptable Json values, "colorScheme": { "dark": "Campbell", "light": "Campbell" } or "colorScheme": "Campbell" <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Individual testing along with the test case added.
2022-12-06 09:33:22 -08:00
"fontSize": 12.0,
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
"fontWeight": "normal"
})" };
Fix failing TestHostApp unit tests (#11394) This commit fixes various failing TestHostApp unit tests. Most of these broke as part of 168d28b (#11184). ## PR Checklist * [x] Closes #11339 * [x] I work here * [x] Tests added/passed
2021-10-05 20:21:03 +02:00
static constexpr std::string_view expectedOutput{ R"(
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
{
"name": "Profile with legacy font settings",
"font": {
"face": "Cascadia Mono",
Add support for switching the scheme based on the app's theme (#14064) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This pull request solved the problem of users not being able to set color schemes specifically for dark or light mode. Now the code has been updated to accept a dark and light color scheme in the json. The old setting is still compatible. Keep in mind if you update your color scheme through the settings UI, it will set both dark and light to the color scheme selected. This is because the settings UI update for selecting both Dark and Light color schemes is not supported yet. This also solves the problem of the UI not using the system OS theme. Now you can select system theme and your color scheme will be selected based on if the system theme is dark or light. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4066 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #4066 * [x] Closes #14050 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA. * [x] Tests added/passed I believe so, added one test to ColorSchemeTests.cpp and I believe it passed. Also had to modify TerminalSettingsTests.cpp to accept the new ApplyAppearanceSettings function template * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #4066 and also teams messages with @carlos-zamora <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments -Removed ColorSchemeName from MTSMSettings.h in order to process the setting for both string and object. -Added DarkColorSchemeName and LightColorSchemeName properties to the AppearanceConfig to replace ColorSchemeName. -Hacked a few processes to play nice with all 3 properties listed above as in some cases around the UI, we need to still use the ColorSchemeName. Once we change the UI I believe we can go back to just Dark and LightColorSchemeName -Added and Updated Test to align to the new code. Acceptable Json values, "colorScheme": { "dark": "Campbell", "light": "Campbell" } or "colorScheme": "Campbell" <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Individual testing along with the test case added.
2022-12-06 09:33:22 -08:00
"size": 12.0,
Group font options in the json into a single object (#10433) Introduces `FontConfig`, an object that isolates font-related settings in our profiles Users can now define font settings in their json as so: ``` "font":{ "face": "Consolas", "size": 12 } ``` Backwards compatible with the currently expected way of defining font settings in the json, note however that upon hitting 'Save' in the SUI, these settings **will be rewritten to the font-object style in the json (as above)**. ## Validation Steps Performed Existing functionality works, new functionality works References #1790 Closes #6049
2021-07-01 10:08:46 -07:00
"weight": "normal"
}
})" };
const auto json{ VerifyParseSucceeded(profileString) };
const auto settings{ implementation::Profile::FromJson(json) };
const auto result{ settings->ToJson() };
const auto jsonOutput{ VerifyParseSucceeded(expectedOutput) };
VERIFY_ARE_EQUAL(toString(jsonOutput), toString(result));
}
Allow inheriting env vars from `wt` again and other env var changes too (#15897) This PR is a few things: * part the first: Convert the `compatibility.reloadEnvironmentVariables` setting to a per-profile one. * The settings should migrate it from the user's old global place to the new one. * We also added it to "Profile>Advanced" while I was here. * Adds a new pair of commandline flags to `new-tab` and `split-pane`: `--inheritEnvironment` / `--reloadEnvironment` * On `wt` launch, bundle the entire environment that `wt` was spawned with, and put it into the `Remoting.CommandlineArgs`, and give them to the monarch (and ultimately, down to `TerminalPage` with the `AppCommandlineArgs`). DO THIS ALWAYS. * As a part of this, we’ll default to _reloading_ if there’s no explicit commandline set, and _inheriting_ if there is. * For example, `wt -- cmd` would inherit, and `wt -p “Command Prompt”` would reload.[^1] * This is a little wacky, but we’re trying to separate out the intentions here: * `wt -- cmd` feels like “I want to run cmd.exe (in a terminal tab)”. That feels like the user would _like_ environment variables from the calling process. They’re doing something more manual, so they get more refined control over it. * `wt` (or `wt -p “Command Prompt”`) is more like, “I want to run the Terminal (or, my Command Prompt profile) using whatever the Terminal would normally do”. So that feels more like a situation where it should just reload by default. (Of course, this will respect their settings here) ## References and Relevant Issues https://github.com/microsoft/terminal/issues/15496#issuecomment-1692450231 has more notes. ## Detailed Description of the Pull Request / Additional comments This is so VERY much plumbing. I'll try to leave comments in the interesting parts. ## PR Checklist - [x] This is not _all_ of #15496. We're also going to do a `-E foo=bar` arg on top of this. - [x] Tests added/passed - [x] Schema updated [^1]: In both these cases, plus the `environment` setting, of course.
2023-09-19 15:03:24 -05:00
void SerializationTests::RoundtripReloadEnvVars()
{
static constexpr std::string_view oldSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"compatibility.reloadEnvironmentVariables": false,
"profiles": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"historySize": 1,
"commandline": "cmd.exe"
}
],
"actions": [
{
"name": "foo",
"command": "closePane",
"keys": "ctrl+shift+w"
}
]
})" };
static constexpr std::string_view newSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles":
{
"defaults":
{
"compatibility.reloadEnvironmentVariables": false
},
"list":
[
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"historySize": 1,
"commandline": "cmd.exe"
}
]
},
"actions": [
{
"name": "foo",
"command": "closePane",
"keys": "ctrl+shift+w"
}
]
})" };
implementation::SettingsLoader oldLoader{ oldSettingsJson, DefaultJson };
oldLoader.MergeInboxIntoUserSettings();
oldLoader.FinalizeLayering();
VERIFY_IS_TRUE(oldLoader.FixupUserSettings(), L"Validate that this will indicate we need to write them back to disk");
const auto oldSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(oldLoader));
const auto oldResult{ oldSettings->ToJson() };
implementation::SettingsLoader newLoader{ newSettingsJson, DefaultJson };
newLoader.MergeInboxIntoUserSettings();
newLoader.FinalizeLayering();
newLoader.FixupUserSettings();
const auto newSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(newLoader));
const auto newResult{ newSettings->ToJson() };
VERIFY_ARE_EQUAL(toString(newResult), toString(oldResult));
}
void SerializationTests::DontRoundtripNoReloadEnvVars()
{
// Kinda like the above test, but confirming that _nothing_ happens if
// we don't have a setting to migrate.
static constexpr std::string_view oldSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"historySize": 1,
"commandline": "cmd.exe"
}
],
"actions": [
{
"name": "foo",
"command": "closePane",
"keys": "ctrl+shift+w"
}
]
})" };
implementation::SettingsLoader oldLoader{ oldSettingsJson, DefaultJson };
oldLoader.MergeInboxIntoUserSettings();
oldLoader.FinalizeLayering();
oldLoader.FixupUserSettings();
const auto oldSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(oldLoader));
const auto oldResult{ oldSettings->ToJson() };
Log::Comment(L"Now, create a _new_ settings object from the re-serialization of the first");
implementation::SettingsLoader newLoader{ toString(oldResult), DefaultJson };
newLoader.MergeInboxIntoUserSettings();
newLoader.FinalizeLayering();
newLoader.FixupUserSettings();
const auto newSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(newLoader));
VERIFY_IS_FALSE(newSettings->ProfileDefaults().HasReloadEnvironmentVariables(),
L"Ensure that the new settings object didn't find a reloadEnvironmentVariables");
}
Deduplicate identical inbox color schemes to heal user settings (#12800) Up until now, we have treated inbox, fragment and user color schemes the same: we load them all into one big map and when we save the settings file we write them *all* out. It's been a big annoyance pretty much forever. In addition to cluttering the user's settings file, it prevents us from making changes to the stock color schemes (like to change the cursor color, or to adjust the colors in Tango Dark, or what have you) because they're already copied in full in the user settings. It also means that we need some special UI affordances for color schemes that you are allowed to view but not to delete or rename. We also have a funny hardcoded list of color scheme names and we use that to determine whether they're "inbox" for UI purposes. Because of all that, we are hesitant to add *more* color schemes to the default set. This pull request resolves all of those issues at once. It: - Adds an "origin" to color schemes indicating where they're from (Inbox, Fragment, User, ...) - Replaces the Edit UI with a much simpler version that pretty much only has a "duplicate this color scheme to start editing it" button - Deletes color schemes that we consider to be equivalent to inbox ones; this allows us to finally disentangle the user's preferences from the terminal's. - Migrates all user settings that referred to schemes they may have modified (even implicitly!) to their modified versions. The equivalence check intentionally leaves out the cursor and selection colors, so that we have the freedom to change them in the future. The Origin is part of a new interface, `ISettingsModelObject`, which we can use in the future for things like Themes and Actions.
2024-02-27 13:07:08 -06:00
void SerializationTests::RoundtripUserModifiedColorSchemeCollision()
{
static constexpr std::string_view oldSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
},
{
"name": "profile1",
"colorScheme": "Tango Dark",
"guid": "{d0a65a9d-8665-4128-97a4-a581aa747aa7}"
}
],
"schemes": [
{
"background": "#121314",
"black": "#121314",
"blue": "#121314",
"brightBlack": "#121314",
"brightBlue": "#121314",
"brightCyan": "#121314",
"brightGreen": "#121314",
"brightPurple": "#121314",
"brightRed": "#121314",
"brightWhite": "#121314",
"brightYellow": "#121314",
"cursorColor": "#121314",
"cyan": "#121314",
"foreground": "#121314",
"green": "#121314",
"name": "Campbell",
"purple": "#121314",
"red": "#121314",
"selectionBackground": "#121314",
"white": "#121314",
"yellow": "#121314"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#3465A4",
"brightBlack": "#555753",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#FFFFFF",
"cyan": "#06989A",
"foreground": "#D3D7CF",
"green": "#4E9A06",
"name": "Tango Dark",
"purple": "#75507B",
"red": "#CC0000",
"selectionBackground": "#FFFFFF",
"white": "#D3D7CF",
"yellow": "#C4A000"
},
]
})" };
// Key differences: one fewer color scheme (Tango Dark has been deleted) and defaults.colorScheme is set.
static constexpr std::string_view newSettingsJson{ R"-(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles":
{
"defaults": {
"colorScheme": "Campbell (modified)"
},
"list":
[
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
},
{
"name": "profile1",
"colorScheme": "Tango Dark",
"guid": "{d0a65a9d-8665-4128-97a4-a581aa747aa7}"
}
]
},
"actions": [ ],
"schemes": [
{
"background": "#121314",
"black": "#121314",
"blue": "#121314",
"brightBlack": "#121314",
"brightBlue": "#121314",
"brightCyan": "#121314",
"brightGreen": "#121314",
"brightPurple": "#121314",
"brightRed": "#121314",
"brightWhite": "#121314",
"brightYellow": "#121314",
"cursorColor": "#121314",
"cyan": "#121314",
"foreground": "#121314",
"green": "#121314",
"name": "Campbell",
"purple": "#121314",
"red": "#121314",
"selectionBackground": "#121314",
"white": "#121314",
"yellow": "#121314"
}
]
})-" };
implementation::SettingsLoader oldLoader{ oldSettingsJson, DefaultJson };
oldLoader.MergeInboxIntoUserSettings();
oldLoader.FinalizeLayering();
VERIFY_IS_TRUE(oldLoader.FixupUserSettings(), L"Validate that this will indicate we need to write them back to disk");
const auto oldSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(oldLoader));
const auto oldResult{ oldSettings->ToJson() };
implementation::SettingsLoader newLoader{ newSettingsJson, DefaultJson };
newLoader.MergeInboxIntoUserSettings();
newLoader.FinalizeLayering();
newLoader.FixupUserSettings();
const auto newSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(newLoader));
const auto newResult{ newSettings->ToJson() };
VERIFY_ARE_EQUAL(toString(newResult), toString(oldResult));
}
void SerializationTests::RoundtripUserModifiedColorSchemeCollisionUnusedByProfiles()
{
static constexpr std::string_view oldSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
}
],
"schemes": [
{
"background": "#111111",
"black": "#111111",
"blue": "#111111",
"brightBlack": "#111111",
"brightBlue": "#111111",
"brightCyan": "#111111",
"brightGreen": "#111111",
"brightPurple": "#111111",
"brightRed": "#111111",
"brightWhite": "#111111",
"brightYellow": "#111111",
"cursorColor": "#111111",
"cyan": "#111111",
"foreground": "#111111",
"green": "#111111",
"name": "Tango Dark",
"purple": "#111111",
"red": "#111111",
"selectionBackground": "#111111",
"white": "#111111",
"yellow": "#111111"
},
]
})" };
// Key differences: Tango Dark has been renamed; nothing else has changed
static constexpr std::string_view newSettingsJson{ R"-(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles":
{
"list":
[
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
}
]
},
"actions": [ ],
"schemes": [
{
"background": "#111111",
"black": "#111111",
"blue": "#111111",
"brightBlack": "#111111",
"brightBlue": "#111111",
"brightCyan": "#111111",
"brightGreen": "#111111",
"brightPurple": "#111111",
"brightRed": "#111111",
"brightWhite": "#111111",
"brightYellow": "#111111",
"cursorColor": "#111111",
"cyan": "#111111",
"foreground": "#111111",
"green": "#111111",
"name": "Tango Dark (modified)",
"purple": "#111111",
"red": "#111111",
"selectionBackground": "#111111",
"white": "#111111",
"yellow": "#111111"
},
]
})-" };
implementation::SettingsLoader oldLoader{ oldSettingsJson, DefaultJson };
oldLoader.MergeInboxIntoUserSettings();
oldLoader.FinalizeLayering();
VERIFY_IS_TRUE(oldLoader.FixupUserSettings(), L"Validate that this will indicate we need to write them back to disk");
const auto oldSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(oldLoader));
const auto oldResult{ oldSettings->ToJson() };
implementation::SettingsLoader newLoader{ newSettingsJson, DefaultJson };
newLoader.MergeInboxIntoUserSettings();
newLoader.FinalizeLayering();
newLoader.FixupUserSettings();
const auto newSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(newLoader));
const auto newResult{ newSettings->ToJson() };
VERIFY_ARE_EQUAL(toString(newResult), toString(oldResult));
}
void SerializationTests::RoundtripUserDeletedColorSchemeCollision()
{
static constexpr std::string_view oldSettingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
}
],
"schemes": [
{
"name": "Tango Dark",
"foreground": "#D3D7CF",
"background": "#000000",
"cursorColor": "#FFFFFF",
"black": "#000000",
"red": "#CC0000",
"green": "#4E9A06",
"yellow": "#C4A000",
"blue": "#3465A4",
"purple": "#75507B",
"cyan": "#06989A",
"white": "#D3D7CF",
"brightBlack": "#555753",
"brightRed": "#EF2929",
"brightGreen": "#8AE234",
"brightYellow": "#FCE94F",
"brightBlue": "#729FCF",
"brightPurple": "#AD7FA8",
"brightCyan": "#34E2E2",
"brightWhite": "#EEEEEC"
}
]
})" };
// Key differences: Tango Dark has been deleted, as it was identical to the inbox one.
static constexpr std::string_view newSettingsJson{ R"-(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles":
{
"list":
[
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
}
]
},
"actions": [ ],
"schemes": [ ]
})-" };
implementation::SettingsLoader oldLoader{ oldSettingsJson, DefaultJson };
oldLoader.MergeInboxIntoUserSettings();
oldLoader.FinalizeLayering();
VERIFY_IS_TRUE(oldLoader.FixupUserSettings(), L"Validate that this will indicate we need to write them back to disk");
const auto oldSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(oldLoader));
const auto oldResult{ oldSettings->ToJson() };
implementation::SettingsLoader newLoader{ newSettingsJson, DefaultJson };
newLoader.MergeInboxIntoUserSettings();
newLoader.FinalizeLayering();
newLoader.FixupUserSettings();
const auto newSettings = winrt::make_self<implementation::CascadiaSettings>(std::move(newLoader));
const auto newResult{ newSettings->ToJson() };
VERIFY_ARE_EQUAL(toString(newResult), toString(oldResult));
}
Add Serializer to CascadiaSettings (#8018) ## Summary of the Pull Request This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated. `CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents. #### Limitations: - all of the color schemes are serialized regardless of them coming from defaults.json or settings.json - keybindings/actions are copied/pasted ## References #1564 - Settings UI TSM Specs (#6904 and #7876) ## PR Checklist * [x] Tests added/passed
2020-11-16 16:37:19 -08:00
}
Reference in New Issue Copy Permalink