maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/TerminalSettingsModel/GlobalAppSettings.idl

81 lines
3.1 KiB
Plaintext
Raw Normal View History

Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
Introduce setting override tracking and update SettingContainer (#9079) This PR adds improved override message generation for inheritance in SUI. The settings model now has an `OriginTag` to be able to denote where a `Profile` came from. This tag is used in the `SettingContainer` to generate a more specific override message. ## References #6800 - SUI Epic #8919 - SUI Inheritance PR #8804 - SUI Inheritance (old issue) ## Detailed Description of the Pull Request / Additional comments - **Terminal Settings Model** - Introduced `PROJECTED_SETTING` as a macro to more easily declare the functions for each setting - Introduced `<setting>OverrideSource` which finds the `Profile` that has \<setting\> defined - Introduced `OriginTag Profile::Origin {Custom, InBox, Generated}` to trace where a profile came from - `DefaultProfileUtils` creates profiles for profile generators. So that now sets the `Origin` tag to `Generated` - `CascadiaSettings::LoadDefaults()` tags all profiles created as `InBox`. - The view model had to ingest the API change to be able to interact with `<setting>OverrideSource` - **Override Message Generation** - The reset button now has a more specific tooltip - The reset button now only appears if base layer is being overridden - We use the settings model changes to determine the message to display for the target ## Validation Steps Performed Tested the following cases: - overrides nothing (inherited setting) - overrides value inherited from... - base layer - a profile generator - in-box profile - global settings should not have this feature
2021-02-20 00:50:52 +01:00
#include "IInheritable.idl.h"
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
import "ColorScheme.idl";
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
import "ActionMap.idl";
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
namespace Microsoft.Terminal.Settings.Model
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
{
// MIDL 3 allows for structs to hold nullable types
// Though IReference is a WinRT object, MIDL 3
// handles all of the ownership logic for us.
// Docs: https://docs.microsoft.com/en-us/uwp/midl-3/intro#types
struct LaunchPosition
{
Windows.Foundation.IReference<Int64> X;
Windows.Foundation.IReference<Int64> Y;
};
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
enum LaunchMode
{
DefaultMode,
MaximizedMode,
FullscreenMode,
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
FocusMode,
MaximizedFocusMode,
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
};
Add support for the `windowingBehavior` setting (#9118) Adds support for the `windowingBehavior` global setting. This setting controls how mutiple instances of `wt` behave in the absence of the `-w` parameter. This setting has three values: * `"useNew"`: (default) Multiple `wt` invocations (without the `-w` param) always create new windows. * `"useAnyExisting"`: When starting a new `wt`, we'll instead default to any existing windows. `wt -w -1` will still create new windows. * `"useExisting"`: Similar to `useAnyExisting`, but limits to windows on the current desktop. The IVirtualDesktopManager interface is _very_ limited. Hence why we have to track the HWNDs manually, and ask if they're on the current desktop. ## Validation Steps Performed I've been playing with it for a week now. References #5000 References projects/5 References #8898 Spec'd in #8135 Closes #2227 Closes https://github.com/microsoft/terminal/projects/5#card-51431448 Closes https://github.com/microsoft/terminal/projects/5#card-51431433
2021-02-19 22:09:17 +01:00
enum WindowingMode
{
UseNew,
UseAnyExisting,
UseExisting,
};
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
[default_interface] runtimeclass GlobalAppSettings {
Guid DefaultProfile;
Introduce setting override tracking and update SettingContainer (#9079) This PR adds improved override message generation for inheritance in SUI. The settings model now has an `OriginTag` to be able to denote where a `Profile` came from. This tag is used in the `SettingContainer` to generate a more specific override message. ## References #6800 - SUI Epic #8919 - SUI Inheritance PR #8804 - SUI Inheritance (old issue) ## Detailed Description of the Pull Request / Additional comments - **Terminal Settings Model** - Introduced `PROJECTED_SETTING` as a macro to more easily declare the functions for each setting - Introduced `<setting>OverrideSource` which finds the `Profile` that has \<setting\> defined - Introduced `OriginTag Profile::Origin {Custom, InBox, Generated}` to trace where a profile came from - `DefaultProfileUtils` creates profiles for profile generators. So that now sets the `Origin` tag to `Generated` - `CascadiaSettings::LoadDefaults()` tags all profiles created as `InBox`. - The view model had to ingest the API change to be able to interact with `<setting>OverrideSource` - **Override Message Generation** - The reset button now has a more specific tooltip - The reset button now only appears if base layer is being overridden - We use the settings model changes to determine the message to display for the target ## Validation Steps Performed Tested the following cases: - overrides nothing (inherited setting) - overrides value inherited from... - base layer - a profile generator - in-box profile - global settings should not have this feature
2021-02-20 00:50:52 +01:00
INHERITABLE_SETTING(String, UnparsedDefaultProfile);
INHERITABLE_SETTING(Int32, InitialRows);
INHERITABLE_SETTING(Int32, InitialCols);
INHERITABLE_SETTING(Boolean, AlwaysShowTabs);
INHERITABLE_SETTING(Boolean, ShowTitleInTitlebar);
INHERITABLE_SETTING(Boolean, ConfirmCloseAllTabs);
Add a language switcher using PrimaryLanguageOverride (#10309) ## Summary of the Pull Request This PR adds a global "language" setting, which may be set to any supported BCP 47 tag. Additionally a ComboBox is added to the settings UI under "Appearance", listing all languages with their localized names. This PR introduces one new issue: If you change the language while the app is running, the UI will be in a torn state, as not all UI elements refresh automatically if the `PrimaryLanguageOverride` is changed. ## PR Checklist * [x] Closes #5497 * [x] I work here * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated ## Validation Steps Performed * UI language changes when changing the "language" in settings.json before starting WT / while WT is running. ✔️ * "language" field is removed from settings.json if "Use system default" is selected. ✔️ * "language" field is added or updated in settings.json if any other language is selected. ✔️ * Removes qps- languages if debugFeatures is false. ✔️ * Correctly refreshes all UI elements with the new language. ❌
2021-06-11 01:24:21 +02:00
INHERITABLE_SETTING(String, Language);
Introduce setting override tracking and update SettingContainer (#9079) This PR adds improved override message generation for inheritance in SUI. The settings model now has an `OriginTag` to be able to denote where a `Profile` came from. This tag is used in the `SettingContainer` to generate a more specific override message. ## References #6800 - SUI Epic #8919 - SUI Inheritance PR #8804 - SUI Inheritance (old issue) ## Detailed Description of the Pull Request / Additional comments - **Terminal Settings Model** - Introduced `PROJECTED_SETTING` as a macro to more easily declare the functions for each setting - Introduced `<setting>OverrideSource` which finds the `Profile` that has \<setting\> defined - Introduced `OriginTag Profile::Origin {Custom, InBox, Generated}` to trace where a profile came from - `DefaultProfileUtils` creates profiles for profile generators. So that now sets the `Origin` tag to `Generated` - `CascadiaSettings::LoadDefaults()` tags all profiles created as `InBox`. - The view model had to ingest the API change to be able to interact with `<setting>OverrideSource` - **Override Message Generation** - The reset button now has a more specific tooltip - The reset button now only appears if base layer is being overridden - We use the settings model changes to determine the message to display for the target ## Validation Steps Performed Tested the following cases: - overrides nothing (inherited setting) - overrides value inherited from... - base layer - a profile generator - in-box profile - global settings should not have this feature
2021-02-20 00:50:52 +01:00
INHERITABLE_SETTING(Windows.UI.Xaml.ElementTheme, Theme);
INHERITABLE_SETTING(Microsoft.UI.Xaml.Controls.TabViewWidthMode, TabWidthMode);
INHERITABLE_SETTING(Boolean, ShowTabsInTitlebar);
INHERITABLE_SETTING(String, WordDelimiters);
INHERITABLE_SETTING(Boolean, CopyOnSelect);
Control 'Touch Keyboard and Handwriting Panel Service' warning (#9015) Add a setting to turn off the warning if 'Touch Keyboard and Handwriting Panel Service' is disabled. The service might not start in some case, and it doesn't affect the input in some computer. This PR turn off the warning even if the service is disabled. The setting name is "inputServiceWarning". ## Validation Steps Performed I manually set the service to "Disabled", restarted the Terminal, verified the warning up, then set "inputServiceWarning" to false and restarted the Terminal, and the warning didn't appear. References #8095 References https://github.com/microsoft/terminal/issues/7886#issuecomment-729350169
2021-02-22 21:08:49 +01:00
INHERITABLE_SETTING(Boolean, InputServiceWarning);
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
INHERITABLE_SETTING(Microsoft.Terminal.Control.CopyFormat, CopyFormatting);
Introduce setting override tracking and update SettingContainer (#9079) This PR adds improved override message generation for inheritance in SUI. The settings model now has an `OriginTag` to be able to denote where a `Profile` came from. This tag is used in the `SettingContainer` to generate a more specific override message. ## References #6800 - SUI Epic #8919 - SUI Inheritance PR #8804 - SUI Inheritance (old issue) ## Detailed Description of the Pull Request / Additional comments - **Terminal Settings Model** - Introduced `PROJECTED_SETTING` as a macro to more easily declare the functions for each setting - Introduced `<setting>OverrideSource` which finds the `Profile` that has \<setting\> defined - Introduced `OriginTag Profile::Origin {Custom, InBox, Generated}` to trace where a profile came from - `DefaultProfileUtils` creates profiles for profile generators. So that now sets the `Origin` tag to `Generated` - `CascadiaSettings::LoadDefaults()` tags all profiles created as `InBox`. - The view model had to ingest the API change to be able to interact with `<setting>OverrideSource` - **Override Message Generation** - The reset button now has a more specific tooltip - The reset button now only appears if base layer is being overridden - We use the settings model changes to determine the message to display for the target ## Validation Steps Performed Tested the following cases: - overrides nothing (inherited setting) - overrides value inherited from... - base layer - a profile generator - in-box profile - global settings should not have this feature
2021-02-20 00:50:52 +01:00
INHERITABLE_SETTING(Boolean, WarnAboutLargePaste);
INHERITABLE_SETTING(Boolean, WarnAboutMultiLinePaste);
INHERITABLE_SETTING(LaunchPosition, InitialPosition);
INHERITABLE_SETTING(Boolean, CenterOnLaunch);
INHERITABLE_SETTING(LaunchMode, LaunchMode);
INHERITABLE_SETTING(Boolean, SnapToGridOnResize);
INHERITABLE_SETTING(Boolean, ForceFullRepaintRendering);
INHERITABLE_SETTING(Boolean, SoftwareRendering);
INHERITABLE_SETTING(Boolean, ForceVTInput);
INHERITABLE_SETTING(Boolean, DebugFeaturesEnabled);
INHERITABLE_SETTING(Boolean, StartOnUserLogin);
INHERITABLE_SETTING(Boolean, AlwaysOnTop);
INHERITABLE_SETTING(TabSwitcherMode, TabSwitcherMode);
INHERITABLE_SETTING(Boolean, DisableAnimations);
INHERITABLE_SETTING(String, StartupActions);
INHERITABLE_SETTING(Boolean, FocusFollowMouse);
INHERITABLE_SETTING(WindowingMode, WindowingBehavior);
Make whitespace trimming in block selection configurable (#9807) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9706 * [x] CLA signed. * [ ] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/313 * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Added global flag named `trimBlockSelection` set to `false` by default. The setting was added to Interactions menu of the SUI.
2021-04-24 00:36:51 +02:00
INHERITABLE_SETTING(Boolean, TrimBlockSelection);
Add a setting to disable URL detection (#10022) <!-- 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 a global setting, `experimental.detectHyperlinks`, that controls whether we automatically detect links and make them clickable. Default is set to true. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9981 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed When `detectHyperlinks` is set to false, links do not underline on hover and are not clickable.
2021-05-17 06:20:09 +02:00
INHERITABLE_SETTING(Boolean, DetectURLs);
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
Introduce KeyMapping and Move TerminalSettings construction (#7537) `KeyMapping` was introduced to break up `AppKeyBindings`. `KeyMapping` records the keybindings from the JSON and lets you query them. `AppKeyBindings` now just holds a `ShortcutActionDispatcher` to run actions, and a `KeyMapping` to record/query your existing keybindings. This refactor allows `KeyMapping` to be moved to the TerminalSettingsModel, and `ShortcutActionDispatcher` and `AppKeyBindings` will stay in TerminalApp. `AppKeyBindings` had to be passed down to a terminal via `TerminalSettings`. Since each settings object had its own responsibility to update/create a `TerminalSettings` object, I moved all of that logic to `TerminalSettings`. This helps with the TerminalSettingsModel refactor, and makes the construction of `TerminalSettings` a bit cleaner and more centralized. ## References #885 - this is all in preparation for the TerminalSettingsModel ## Validation Steps Performed - [x] Tests passed - [X] Deployment succeeded
2020-09-14 22:38:56 +02:00
Windows.Foundation.Collections.IMapView<String, ColorScheme> ColorSchemes();
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
void AddColorScheme(ColorScheme scheme);
Add UI for adding, renaming, and deleting a color scheme (#8403) Introduces the following UI controls to the ColorSchemes page: - "Add new" button - next to dropdown selector - adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have) - "Rename" Button - next to the selector - replaces the ComboBox with a TextBox and the accept/cancel buttons appear - "Delete" button - bottom of the page - opens flyout, when confirmed, deletes the current color scheme and selects another one This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button. ## References #1564 - Settings UI #6800 - Settings UI Completion Epic ## Detailed Description of the Pull Request / Additional comments **Color Schemes:** - Deleting a color scheme selects another one from the list available - Rename replaces the combobox with a textbox to allow editing - The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined - In-box color schemes cannot be deleted **Profile:** - Deleting a profile selects another one from the list available - the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template - The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles ## Validation Steps Performed **Color Schemes - Add New** ✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes) ✅ The new color scheme can be renamed/deleted/modified **Color Schemes - Rename** ✅ You cannot rename an in-box color scheme ✅ The rename button has a tooltip ✅ Clicking the rename button replaces the combobox with a textbox ✅ Accept --> changes name ✅ Cancel --> does not change the name ✅ accepting/cancelling the rename operation updates the combo box appropriately **Color Schemes - Delete** ✅ Clicking delete produces a flyout to confirm deletion ✅ Deleting a color scheme removes it from the list and select the one under it ✅ Deleting the last color scheme selects the last available color scheme after it's deleted ✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it **Profile- Delete** ✅ Base layer presents a disclaimer at the top, and hides the delete button ✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button ✅ Clicking delete produces a flyout to confirm deletion ✅ Regular profiles have a delete button that is styled appropriately ✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one) ## Demo Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651. Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
2020-12-18 00:14:07 +01:00
void RemoveColorScheme(String schemeName);
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
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
ActionMap ActionMap { get; };
Make GlobalAppSettings a WinRT object (#7349) GlobalAppSettings is now a WinRT object in the TerminalApp project. ## References #7141 - GlobalAppSettings is a settings object #885 - this new settings object will be moved to a new TerminalSettingsModel project ## PR Checklist * [x] Tests passed ## Detailed Description of the Pull Request / Additional comments This one was probably the easiest thus far. The only weird thing is how we handle InitialPosition. Today, we lose a little bit of fidelity when we convert from LaunchPosition (int) --> Point (float) --> RECT (long). The current change converts LaunchPosition (optional<long>) --> InitialPosition (long) --> RECT (long). NOTE: Though I could use LaunchPosition to go directly from TermApp to AppHost, I decided to introduce InitialPosition because LaunchPosition will be a part of TerminalSettingsModel soon. ## Validation Steps Performed - [x] Tests passed - [x] Deployment succeeded
2020-08-28 05:49:16 +02:00
}
}
Reference in a new issue Copy permalink