maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/LocalTests_SettingsModel/TerminalSettingsTests.cpp

653 lines
34 KiB
C++
Raw Normal View History

Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "../TerminalSettingsModel/CascadiaSettings.h"
#include "../TerminalSettingsModel/TerminalSettings.h"
#include "TestUtils.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 21:47:24 +01:00
using namespace winrt::Microsoft::Terminal::Control;
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
namespace SettingsModelLocalTests
{
// TODO:microsoft/terminal#3838:
// Unfortunately, these tests _WILL NOT_ work in our CI. We're waiting for
// an updated TAEF that will let us install framework packages when the test
// package is deployed. Until then, these tests won't deploy in CI.
class TerminalSettingsTests
{
// Use a custom AppxManifest to ensure that we can activate winrt types
// from our test. This property will tell taef to manually use this as
// the AppxManifest for this test class.
// This does not yet work for anything XAML-y. See TabTests.cpp for more
// details on that.
BEGIN_TEST_CLASS(TerminalSettingsTests)
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TestHostAppXManifest.xml")
END_TEST_CLASS()
TEST_METHOD(TryCreateWinRTType);
TEST_METHOD(TestTerminalArgsForBinding);
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
TEST_METHOD(MakeSettingsForProfile);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
TEST_METHOD(MakeSettingsForDefaultProfileThatDoesntExist);
TEST_METHOD(TestLayerProfileOnColorScheme);
Move commandline->title promotion into TerminalSettings (#11029) It was insufficient to only promote commandline components to titles during commandline parsing, because we also have a whole complement of actions that contain NewTerminalArgs. The tests caught me out a little too late (sorry!). I decided it was better move promotion down to TerminalSettings. Fixes #6776 Re-implements #10998
2021-08-25 01:31:27 +02:00
TEST_METHOD(TestCommandlineToTitlePromotion);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
TEST_CLASS_SETUP(ClassSetup)
{
return true;
}
};
void TerminalSettingsTests::TryCreateWinRTType()
{
TerminalSettings settings;
VERIFY_IS_NOT_NULL(settings);
auto oldFontSize = settings.FontSize();
settings.FontSize(oldFontSize + 5);
auto newFontSize = settings.FontSize();
VERIFY_ARE_NOT_EQUAL(oldFontSize, newFontSize);
}
void TerminalSettingsTests::TestTerminalArgsForBinding()
{
const std::string settingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
Use the "base" profile for incoming handoff and new commands (#11022) This pull request introduces our first use of the "base" profile as an actual profile. Incoming commandlines from `wt foo` *and* default terminal handoffs will be hosted in the base profile. **THIS IS A BREAKING CHANGE** for user behavior. The original behavior where commandlines were hosted in the "default" profile (in most cases, Windows PowerShell) led to user confusion: "why does cmd use my powershell icon?" and "why does the title say PowerShell?". Making this change unifies the user experience so that we can land commandline detection in #10952. Users who want the original behavior can get it back for commandline invocation by specifying a profile using the `-p` argument, as in `wt -p PowerShell -- cmd`. As a temporary stopgap, users who attempt to duplicate the base profile will get their specified default profile until we land #5047. This feature is hidden behind the same feature flag that controls the visibility of base/"Defaults" in the settings UI. Fixes #10669 Related to #6776
2021-08-26 00:41:42 +02:00
"profiles": { "list": [
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"historySize": 1,
"commandline": "cmd.exe"
},
{
"name": "profile1",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"historySize": 2,
"commandline": "pwsh.exe"
},
{
"name": "profile2",
"historySize": 3,
"commandline": "wsl.exe"
}
],
Use the "base" profile for incoming handoff and new commands (#11022) This pull request introduces our first use of the "base" profile as an actual profile. Incoming commandlines from `wt foo` *and* default terminal handoffs will be hosted in the base profile. **THIS IS A BREAKING CHANGE** for user behavior. The original behavior where commandlines were hosted in the "default" profile (in most cases, Windows PowerShell) led to user confusion: "why does cmd use my powershell icon?" and "why does the title say PowerShell?". Making this change unifies the user experience so that we can land commandline detection in #10952. Users who want the original behavior can get it back for commandline invocation by specifying a profile using the `-p` argument, as in `wt -p PowerShell -- cmd`. As a temporary stopgap, users who attempt to duplicate the base profile will get their specified default profile until we land #5047. This feature is hidden behind the same feature flag that controls the visibility of base/"Defaults" in the settings UI. Fixes #10669 Related to #6776
2021-08-26 00:41:42 +02:00
"defaults": {
"historySize": 29
} },
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
"keybindings": [
{ "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } },
{ "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } },
{ "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } },
{ "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } },
{ "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } },
{ "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } },
{ "keys": ["ctrl+g"], "command": { "action": "newTab" } },
{ "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } },
{ "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } },
{ "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } }
]
})" };
const winrt::guid guid0{ ::Microsoft::Console::Utils::GuidFromString(L"{6239a42c-0000-49a3-80bd-e8fdd045185c}") };
const winrt::guid guid1{ ::Microsoft::Console::Utils::GuidFromString(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}") };
CascadiaSettings settings{ til::u8u16(settingsJson) };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionMap = settings.GlobalSettings().ActionMap();
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(3u, settings.ActiveProfiles().Size());
const auto profile2Guid = settings.ActiveProfiles().GetAt(2).Guid();
VERIFY_ARE_NOT_EQUAL(winrt::guid{}, profile2Guid);
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
const auto& actionMapImpl{ winrt::get_self<implementation::ActionMap>(actionMap) };
VERIFY_ARE_EQUAL(12u, actionMapImpl->_KeyMap.size());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('A'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Right, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Profile().empty());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid0, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"cmd.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(1, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('B'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Right, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid1, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"pwsh.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(2, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('C'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Right, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"profile1", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid1, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"pwsh.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(2, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('D'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Right, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"profile2", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(profile2Guid, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"wsl.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(3, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('E'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Down, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"foo.exe", realArgs.TerminalArgs().Commandline());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Use the "base" profile for incoming handoff and new commands (#11022) This pull request introduces our first use of the "base" profile as an actual profile. Incoming commandlines from `wt foo` *and* default terminal handoffs will be hosted in the base profile. **THIS IS A BREAKING CHANGE** for user behavior. The original behavior where commandlines were hosted in the "default" profile (in most cases, Windows PowerShell) led to user confusion: "why does cmd use my powershell icon?" and "why does the title say PowerShell?". Making this change unifies the user experience so that we can land commandline detection in #10952. Users who want the original behavior can get it back for commandline invocation by specifying a profile using the `-p` argument, as in `wt -p PowerShell -- cmd`. As a temporary stopgap, users who attempt to duplicate the base profile will get their specified default profile until we land #5047. This feature is hidden behind the same feature flag that controls the visibility of base/"Defaults" in the settings UI. Fixes #10669 Related to #6776
2021-08-26 00:41:42 +02:00
if constexpr (Feature_ShowProfileDefaultsInSettings::IsEnabled())
{
// This action specified a command but no profile; it gets reassigned to the base profile
VERIFY_ARE_EQUAL(settings.ProfileDefaults(), profile);
VERIFY_ARE_EQUAL(29, termSettings.HistorySize());
}
else
{
VERIFY_ARE_EQUAL(guid0, profile.Guid());
VERIFY_ARE_EQUAL(1, termSettings.HistorySize());
}
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"foo.exe", termSettings.Commandline());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('F'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 Adds directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [x] 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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 22:14:57 +02:00
VERIFY_ARE_EQUAL(SplitDirection::Down, realArgs.SplitDirection());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"profile1", realArgs.TerminalArgs().Profile());
VERIFY_ARE_EQUAL(L"foo.exe", realArgs.TerminalArgs().Commandline());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid1, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"foo.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(2, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('G'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Profile().empty());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid0, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"cmd.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(1, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('H'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"c:\\foo", realArgs.TerminalArgs().StartingDirectory());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid0, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"cmd.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(L"c:\\foo", termSettings.StartingDirectory());
VERIFY_ARE_EQUAL(1, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('I'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"c:\\foo", realArgs.TerminalArgs().StartingDirectory());
VERIFY_ARE_EQUAL(L"profile2", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(profile2Guid, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"wsl.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(L"c:\\foo", termSettings.StartingDirectory());
VERIFY_ARE_EQUAL(3, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('J'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"bar", realArgs.TerminalArgs().TabTitle());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid0, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"cmd.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(L"bar", termSettings.StartingTitle());
VERIFY_ARE_EQUAL(1, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('K'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_TRUE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_TRUE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"bar", realArgs.TerminalArgs().TabTitle());
VERIFY_ARE_EQUAL(L"profile2", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(profile2Guid, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"wsl.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(L"bar", termSettings.StartingTitle());
VERIFY_ARE_EQUAL(3, termSettings.HistorySize());
}
{
Introduce vk() and sc() key chord specifiers (#10666) This commit introduces an alternative to specifying key bindings as a combination of key modifiers and a character. It allows you to specify an explicit virtual key as `vk(nnn)`. Additionally this commit makes it possible to bind actions to scan codes. As scan code 41 appears to be the button below the Escape key on virtually all keyboards, we'll be able to bind the quake mode hotkey to `win+sc(41)` and have it work consistently across most if not all keyboard layouts. ## PR Checklist * [x] Closes #7539, Closes #10203 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed The following was tested both on US and DE keyboard layouts: * Ctrl+, opens settings ✔️ * Win+` opens quake mode window ✔️ * Ctrl+plus/minus increase/decrease font size ✔️
2021-07-21 00:34:51 +02:00
KeyChord kc{ true, false, false, false, static_cast<int32_t>('L'), 0 };
Introduce ActionMap to Terminal Settings Model (#9621) This entirely removes `KeyMapping` from the settings model, and builds on the work done in #9543 to consolidate all actions (key bindings and commands) into a unified data structure (`ActionMap`). ## References #9428 - Spec #6900 - Actions page Closes #7441 ## Detailed Description of the Pull Request / Additional comments The important thing here is to remember that we're shifting our philosophy of how to interact/represent actions. Prior to this, the actions arrays in the JSON would be deserialized twice: once for key bindings, and again for commands. By thinking of every entry in the relevant JSON as a `Command`, we can remove a lot of the context switching between working with a key binding vs a command palette item. #9543 allows us to make that shift. Given the work in that PR, we can now deserialize all of the relevant information from each JSON action item. This allows us to simplify `ActionMap::FromJson` to simply iterate over each JSON action item, deserialize it, and add it to our `ActionMap`. Internally, our `ActionMap` operates as discussed in #9428 by maintaining a `_KeyMap` that points to an action ID, and using that action ID to retrieve the `Command` from the `_ActionMap`. Adding actions to the `ActionMap` automatically accounts for name/key-chord collisions. A `NameMap` can be constructed when requested; this is for the Command Palette. Querying the `ActionMap` is fairly straightforward. Helper functions were needed to be able to distinguish an explicit unbinding vs the command not being found in the current layer. Internally, we store explicitly unbound names/key-chords as `ShortcutAction::Invalid` commands. However, we return `nullptr` when a query points to an unbound command. This is done to hide this complexity away from any caller. The command palette still needs special handling for nested and iterable commands. Thankfully, the expansion of iterable commands is performed on an `IMapView`, so we can just expose `NameMap` as a consolidation of `ActionMap`'s `NameMap` with its parents. The same can be said for exposing key chords in nested commands. ## Validation Steps Performed All local tests pass.
2021-05-05 06:50:13 +02:00
auto actionAndArgs = ::TestUtils::GetActionAndArgs(actionMap, kc);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, actionAndArgs.Action());
const auto& realArgs = actionAndArgs.Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_IS_NOT_NULL(realArgs.TerminalArgs());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Commandline().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().StartingDirectory().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().TabTitle().empty());
VERIFY_IS_FALSE(realArgs.TerminalArgs().Profile().empty());
VERIFY_ARE_EQUAL(L"foo.exe", realArgs.TerminalArgs().Commandline());
VERIFY_ARE_EQUAL(L"c:\\foo", realArgs.TerminalArgs().StartingDirectory());
VERIFY_ARE_EQUAL(L"bar", realArgs.TerminalArgs().TabTitle());
VERIFY_ARE_EQUAL(L"profile1", realArgs.TerminalArgs().Profile());
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile{ settings.GetProfileForArgs(realArgs.TerminalArgs()) };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, realArgs.TerminalArgs(), nullptr) };
const auto termSettings = settingsStruct.DefaultSettings();
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_ARE_EQUAL(guid1, profile.Guid());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_EQUAL(L"foo.exe", termSettings.Commandline());
VERIFY_ARE_EQUAL(L"bar", termSettings.StartingTitle());
VERIFY_ARE_EQUAL(L"c:\\foo", termSettings.StartingDirectory());
VERIFY_ARE_EQUAL(2, termSettings.HistorySize());
}
}
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
void TerminalSettingsTests::MakeSettingsForProfile()
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
{
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
// Test that making settings generally works.
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
const std::string settingsString{ R"(
{
"defaultProfile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name" : "profile0",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"historySize": 1
},
{
"name" : "profile1",
"guid": "{6239a42c-2222-49a3-80bd-e8fdd045185c}",
"historySize": 2
}
]
})" };
CascadiaSettings settings{ til::u8u16(settingsString) };
const auto guid1 = ::Microsoft::Console::Utils::GuidFromString(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}");
const auto guid2 = ::Microsoft::Console::Utils::GuidFromString(L"{6239a42c-2222-49a3-80bd-e8fdd045185c}");
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
const auto profile1 = settings.FindProfile(guid1);
const auto profile2 = settings.FindProfile(guid2);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
try
{
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
auto terminalSettings{ TerminalSettings::CreateWithProfile(settings, profile1, nullptr) };
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_NOT_EQUAL(nullptr, terminalSettings);
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
VERIFY_ARE_EQUAL(1, terminalSettings.DefaultSettings().HistorySize());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
catch (...)
{
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_IS_TRUE(false, L"This call to CreateWithProfile should succeed");
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
try
{
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
auto terminalSettings{ TerminalSettings::CreateWithProfile(settings, profile2, nullptr) };
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
VERIFY_ARE_NOT_EQUAL(nullptr, terminalSettings);
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
VERIFY_ARE_EQUAL(2, terminalSettings.DefaultSettings().HistorySize());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
catch (...)
{
Rely more on profile objects and less on GUIDs (#10982) Right now, we store GUIDs in panes and most of the functions for interacting with profiles on the settings model take GUIDs and look up profiles. This pull request changes how we store and look up profiles to prefer profile objects. Panes store strong references to their originating profiles, which simplifies settings lookup for CloseOnExit and the bell settings. In fact, deleting a pane's profile no longer causes it to forget which CloseOnExit setting applies to it. Duplicating a pane that is hosting a deleted profile (#5047) now duplicates the profile, even though it is otherwise unreachable. This makes the world more consistent and allows us to _eventually_ support panes hosting profiles that do not have GUIDs that can be looked up in the profile list. This is a gateway to #6776 and #10669, and consolidating the profile lookup logic will help with #10952. PR #10588 introduced TerminalSettings::CreateWithProfile and made ...CreateWithProfileByID a thin wrapper over top it, which looked up the profile by GUID before proceeding. It has also been removed, as its last caller is gone. Closes #5047
2021-08-23 19:11:53 +02:00
VERIFY_IS_TRUE(false, L"This call to CreateWithProfile should succeed");
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
try
{
const auto termSettings{ TerminalSettings::CreateWithNewTerminalArgs(settings, nullptr, nullptr) };
VERIFY_ARE_NOT_EQUAL(nullptr, termSettings);
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
VERIFY_ARE_EQUAL(1, termSettings.DefaultSettings().HistorySize());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
catch (...)
{
VERIFY_IS_TRUE(false, L"This call to CreateWithNewTerminalArgs should succeed");
}
}
void TerminalSettingsTests::MakeSettingsForDefaultProfileThatDoesntExist()
{
// Test that MakeSettings _doesnt_ throw when we load settings with a
// defaultProfile that's not in the list, we validate the settings, and
// then call MakeSettings(nullopt). The validation should ensure that
// the default profile is something reasonable
const std::string settingsString{ R"(
{
"defaultProfile": "{6239a42c-3333-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name" : "profile0",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"historySize": 1
},
{
"name" : "profile1",
"guid": "{6239a42c-2222-49a3-80bd-e8fdd045185c}",
"historySize": 2
}
]
})" };
CascadiaSettings settings{ til::u8u16(settingsString) };
VERIFY_ARE_EQUAL(2u, settings.Warnings().Size());
VERIFY_ARE_EQUAL(2u, settings.ActiveProfiles().Size());
VERIFY_ARE_EQUAL(settings.GlobalSettings().DefaultProfile(), settings.ActiveProfiles().GetAt(0).Guid());
try
{
const auto termSettings{ TerminalSettings::CreateWithNewTerminalArgs(settings, nullptr, nullptr) };
VERIFY_ARE_NOT_EQUAL(nullptr, termSettings);
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
VERIFY_ARE_EQUAL(1, termSettings.DefaultSettings().HistorySize());
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
catch (...)
{
VERIFY_IS_TRUE(false, L"This call to CreateWithNewTerminalArgs should succeed");
}
}
void TerminalSettingsTests::TestLayerProfileOnColorScheme()
{
Log::Comment(NoThrowString().Format(
L"Ensure that setting (or not) a property in the profile that should override a property of the color scheme works correctly."));
const std::string settings0String{ R"(
{
"defaultProfile": "profile5",
"profiles": [
{
"name" : "profile0",
"colorScheme": "schemeWithCursorColor"
},
{
"name" : "profile1",
"colorScheme": "schemeWithoutCursorColor"
},
{
"name" : "profile2",
"colorScheme": "schemeWithCursorColor",
"cursorColor": "#234567"
},
{
"name" : "profile3",
"colorScheme": "schemeWithoutCursorColor",
"cursorColor": "#345678"
},
{
"name" : "profile4",
"cursorColor": "#456789"
},
{
"name" : "profile5"
}
],
"schemes": [
{
"name": "schemeWithCursorColor",
"cursorColor": "#123456"
},
{
"name": "schemeWithoutCursorColor"
}
]
})" };
CascadiaSettings settings{ til::u8u16(settings0String) };
VERIFY_ARE_EQUAL(6u, settings.ActiveProfiles().Size());
VERIFY_ARE_EQUAL(2u, settings.GlobalSettings().ColorSchemes().Size());
auto createTerminalSettings = [&](const auto& profile, const auto& schemes) {
auto terminalSettings{ winrt::make_self<implementation::TerminalSettings>() };
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
terminalSettings->_ApplyProfileSettings(profile);
terminalSettings->_ApplyAppearanceSettings(profile.DefaultAppearance(), schemes);
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
return terminalSettings;
};
auto terminalSettings0 = createTerminalSettings(settings.ActiveProfiles().GetAt(0), settings.GlobalSettings().ColorSchemes());
auto terminalSettings1 = createTerminalSettings(settings.ActiveProfiles().GetAt(1), settings.GlobalSettings().ColorSchemes());
auto terminalSettings2 = createTerminalSettings(settings.ActiveProfiles().GetAt(2), settings.GlobalSettings().ColorSchemes());
auto terminalSettings3 = createTerminalSettings(settings.ActiveProfiles().GetAt(3), settings.GlobalSettings().ColorSchemes());
auto terminalSettings4 = createTerminalSettings(settings.ActiveProfiles().GetAt(4), settings.GlobalSettings().ColorSchemes());
auto terminalSettings5 = createTerminalSettings(settings.ActiveProfiles().GetAt(5), settings.GlobalSettings().ColorSchemes());
VERIFY_ARE_EQUAL(ARGB(0, 0x12, 0x34, 0x56), terminalSettings0->CursorColor()); // from color scheme
VERIFY_ARE_EQUAL(DEFAULT_CURSOR_COLOR, terminalSettings1->CursorColor()); // default
VERIFY_ARE_EQUAL(ARGB(0, 0x23, 0x45, 0x67), terminalSettings2->CursorColor()); // from profile (trumps color scheme)
VERIFY_ARE_EQUAL(ARGB(0, 0x34, 0x56, 0x78), terminalSettings3->CursorColor()); // from profile (not set in color scheme)
VERIFY_ARE_EQUAL(ARGB(0, 0x45, 0x67, 0x89), terminalSettings4->CursorColor()); // from profile (no color scheme)
VERIFY_ARE_EQUAL(DEFAULT_CURSOR_COLOR, terminalSettings5->CursorColor()); // default
}
Move commandline->title promotion into TerminalSettings (#11029) It was insufficient to only promote commandline components to titles during commandline parsing, because we also have a whole complement of actions that contain NewTerminalArgs. The tests caught me out a little too late (sorry!). I decided it was better move promotion down to TerminalSettings. Fixes #6776 Re-implements #10998
2021-08-25 01:31:27 +02:00
void TerminalSettingsTests::TestCommandlineToTitlePromotion()
{
const std::string settingsJson{ R"(
{
"defaultProfile": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"profiles": { "list": [
{
"name": "profile0",
"guid": "{6239a42c-0000-49a3-80bd-e8fdd045185c}",
"historySize": 1,
"commandline": "cmd.exe"
},
],
"defaults": {
"historySize": 29
} }
})" };
const winrt::guid guid0{ ::Microsoft::Console::Utils::GuidFromString(L"{6239a42c-0000-49a3-80bd-e8fdd045185c}") };
CascadiaSettings settings{ til::u8u16(settingsJson) };
{ // just a profile (profile wins)
NewTerminalArgs args{};
args.Profile(L"profile0");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"profile0", settingsStruct.DefaultSettings().StartingTitle());
}
{ // profile and command line -> no promotion (profile wins)
NewTerminalArgs args{};
args.Profile(L"profile0");
args.Commandline(L"foo.exe");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"profile0", settingsStruct.DefaultSettings().StartingTitle());
}
{ // just a title -> it is propagated
NewTerminalArgs args{};
args.TabTitle(L"Analog Kid");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"Analog Kid", settingsStruct.DefaultSettings().StartingTitle());
}
{ // title and command line -> no promotion
NewTerminalArgs args{};
args.TabTitle(L"Digital Man");
args.Commandline(L"foo.exe");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"Digital Man", settingsStruct.DefaultSettings().StartingTitle());
}
{ // just a commandline -> promotion
NewTerminalArgs args{};
args.Commandline(L"foo.exe");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"foo.exe", settingsStruct.DefaultSettings().StartingTitle());
}
// various typesof commandline follow
{
NewTerminalArgs args{};
args.Commandline(L"foo.exe bar");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"foo.exe", settingsStruct.DefaultSettings().StartingTitle());
}
{
NewTerminalArgs args{};
args.Commandline(L"\"foo exe.exe\" bar");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"foo exe.exe", settingsStruct.DefaultSettings().StartingTitle());
}
{
NewTerminalArgs args{};
args.Commandline(L"\"\" grand designs");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"", settingsStruct.DefaultSettings().StartingTitle());
}
{
NewTerminalArgs args{};
args.Commandline(L" imagine a man");
const auto settingsStruct{ TerminalSettings::CreateWithNewTerminalArgs(settings, args, nullptr) };
VERIFY_ARE_EQUAL(L"", settingsStruct.DefaultSettings().StartingTitle());
}
}
Move TerminalSettings from TermApp to TerminalSettingsModel (#9318) This accomplishes the first step towards embedding a preview on the Profiles/ColorSchemes page, by moving the `TerminalSettings` object over to the Terminal Settings Model project. We'll leverage this in a later PR to construct an embedded terminal in the settings UI. `TerminalSettings` had to see a few more functions exposed in the IDL (including some inheritance stuff). Refresh the JSON to make TerminalSettings do it's thing across all the open terminals. References #9122 - Terminal Preview References #6800 - SUI Epic
2021-03-16 00:15:25 +01:00
}
Reference in a new issue Copy permalink