2020-08-28 05:49:16 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
2021-02-20 00:50:52 +01:00
|
|
|
#include "IInheritable.idl.h"
|
|
|
|
|
|
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";
|
2020-08-28 05:49:16 +02:00
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
namespace Microsoft.Terminal.Settings.Model
|
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;
|
|
|
|
|
};
|
|
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
enum LaunchMode
|
|
|
|
|
{
|
|
|
|
|
DefaultMode,
|
|
|
|
|
MaximizedMode,
|
|
|
|
|
FullscreenMode,
|
2020-10-15 00:19:51 +02:00
|
|
|
FocusMode,
|
|
|
|
|
MaximizedFocusMode,
|
2020-10-06 18:56:59 +02:00
|
|
|
};
|
|
|
|
|
|
2021-02-19 22:09:17 +01:00
|
|
|
enum WindowingMode
|
|
|
|
|
{
|
|
|
|
|
UseNew,
|
|
|
|
|
UseAnyExisting,
|
|
|
|
|
UseExisting,
|
|
|
|
|
};
|
|
|
|
|
|
Persist window layout on window close (#10972)
This commit adds initial support for saving window layout on application
close.
Done:
- Add user setting for if tabs should be maintained.
- Added events to track the number of open windows for the monarch, and
then save if you are the last window closing.
- Saves layout when the user explicitly hits the "Close Window" button.
- If the user manually closed all of their tabs (through the tab x
button or through closing all panes on the tab) then remove any saved
state.
- Saves in the ApplicationState file a list of actions the terminal can
perform to restore its layout and the window size/position
information.
- This saves an action to focus the correct pane, but this won't
actually work without #10978. Note that if you have a pane zoomed, it
does still zoom the correct pane, but when you unzoom it will have a
different pane selected.
Todo:
- multiple windows? Right now it can only handle loading/saving one
window.
- PR #11083 will save multiple windows.
- This also sometimes runs into the existing bug where multiple tabs
appear to be focused on opening.
Next Steps:
- The business logic of when the save is triggered can be adjusted as
necessary.
- Right now I am taking the pragmatic approach and just saving the state
as an array of objects, but only ever populate it with 1, that way
saving multiple windows in the future could be added without breaking
schema compatibility. Selfishly I'm hoping that handling multiple
windows could be spun off into another pr/feature for now.
- One possible thing that can maybe be done is that the commandline can
be augmented with a "--saved ##" attribute that would load from the
nth saved state if it exists. e.g. if there are 3 saved windows, on
first load it can spawn three wt --saved {0,1,2} that would reopen the
windows? This way there also exists a way to load a copy of a previous
window (if it is in the saved state).
- Is the application state something that is planned to be public/user
editable? In theory the user could since it is just json, but I don't
know what it buys them over just modifying their settings and
startupActions.
Validation Steps Performed:
- The happy path: open terminal -> set setting to true -> close terminal
-> reopen and see tabs. Tested with powershell/cmd/wsl windows.
- That closing all panes/tabs on their own will remove the saved
session.
- Open multiple windows, close windows and confirm that the last window
closed saves its state.
The generated file stores a sequence of actions that will be executed to
restore the terminal to its saved form.
References #8324
This is also one of the items on microsoft/terminal#5000
Closes #766
2021-09-09 00:44:53 +02:00
|
|
|
enum FirstWindowPreference
|
|
|
|
|
{
|
|
|
|
|
DefaultProfile,
|
|
|
|
|
PersistedWindowLayout,
|
|
|
|
|
};
|
|
|
|
|
|
2020-08-28 05:49:16 +02:00
|
|
|
[default_interface] runtimeclass GlobalAppSettings {
|
|
|
|
|
Guid DefaultProfile;
|
2021-08-04 00:25:23 +02:00
|
|
|
|
|
|
|
|
void SetInvertedDisableAnimationsValue(Boolean invertedDisableAnimationsValue);
|
|
|
|
|
|
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);
|
2021-06-11 01:24:21 +02:00
|
|
|
INHERITABLE_SETTING(String, Language);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_SETTING(Windows.UI.Xaml.ElementTheme, Theme);
|
|
|
|
|
INHERITABLE_SETTING(Microsoft.UI.Xaml.Controls.TabViewWidthMode, TabWidthMode);
|
2021-08-23 18:40:25 +02:00
|
|
|
INHERITABLE_SETTING(Boolean, UseAcrylicInTabRow);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_SETTING(Boolean, ShowTabsInTitlebar);
|
|
|
|
|
INHERITABLE_SETTING(String, WordDelimiters);
|
|
|
|
|
INHERITABLE_SETTING(Boolean, CopyOnSelect);
|
2021-02-22 21:08:49 +01:00
|
|
|
INHERITABLE_SETTING(Boolean, InputServiceWarning);
|
2021-03-17 21:47:24 +01:00
|
|
|
INHERITABLE_SETTING(Microsoft.Terminal.Control.CopyFormat, CopyFormatting);
|
2021-02-20 00:50:52 +01:00
|
|
|
INHERITABLE_SETTING(Boolean, WarnAboutLargePaste);
|
|
|
|
|
INHERITABLE_SETTING(Boolean, WarnAboutMultiLinePaste);
|
|
|
|
|
INHERITABLE_SETTING(LaunchPosition, InitialPosition);
|
|
|
|
|
INHERITABLE_SETTING(Boolean, CenterOnLaunch);
|
Persist window layout on window close (#10972)
This commit adds initial support for saving window layout on application
close.
Done:
- Add user setting for if tabs should be maintained.
- Added events to track the number of open windows for the monarch, and
then save if you are the last window closing.
- Saves layout when the user explicitly hits the "Close Window" button.
- If the user manually closed all of their tabs (through the tab x
button or through closing all panes on the tab) then remove any saved
state.
- Saves in the ApplicationState file a list of actions the terminal can
perform to restore its layout and the window size/position
information.
- This saves an action to focus the correct pane, but this won't
actually work without #10978. Note that if you have a pane zoomed, it
does still zoom the correct pane, but when you unzoom it will have a
different pane selected.
Todo:
- multiple windows? Right now it can only handle loading/saving one
window.
- PR #11083 will save multiple windows.
- This also sometimes runs into the existing bug where multiple tabs
appear to be focused on opening.
Next Steps:
- The business logic of when the save is triggered can be adjusted as
necessary.
- Right now I am taking the pragmatic approach and just saving the state
as an array of objects, but only ever populate it with 1, that way
saving multiple windows in the future could be added without breaking
schema compatibility. Selfishly I'm hoping that handling multiple
windows could be spun off into another pr/feature for now.
- One possible thing that can maybe be done is that the commandline can
be augmented with a "--saved ##" attribute that would load from the
nth saved state if it exists. e.g. if there are 3 saved windows, on
first load it can spawn three wt --saved {0,1,2} that would reopen the
windows? This way there also exists a way to load a copy of a previous
window (if it is in the saved state).
- Is the application state something that is planned to be public/user
editable? In theory the user could since it is just json, but I don't
know what it buys them over just modifying their settings and
startupActions.
Validation Steps Performed:
- The happy path: open terminal -> set setting to true -> close terminal
-> reopen and see tabs. Tested with powershell/cmd/wsl windows.
- That closing all panes/tabs on their own will remove the saved
session.
- Open multiple windows, close windows and confirm that the last window
closed saves its state.
The generated file stores a sequence of actions that will be executed to
restore the terminal to its saved form.
References #8324
This is also one of the items on microsoft/terminal#5000
Closes #766
2021-09-09 00:44:53 +02:00
|
|
|
INHERITABLE_SETTING(FirstWindowPreference, FirstWindowPreference);
|
2021-02-20 00:50:52 +01:00
|
|
|
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);
|
2021-04-24 00:36:51 +02:00
|
|
|
INHERITABLE_SETTING(Boolean, TrimBlockSelection);
|
2021-05-17 06:20:09 +02:00
|
|
|
INHERITABLE_SETTING(Boolean, DetectURLs);
|
2021-09-14 18:12:40 +02:00
|
|
|
INHERITABLE_SETTING(Boolean, MinimizeToNotificationArea);
|
|
|
|
|
INHERITABLE_SETTING(Boolean, AlwaysShowNotificationIcon);
|
Reduce usage of Json::Value throughout Terminal.Settings.Model (#11184)
This commit reduces the code surface that interacts with raw JSON data,
reducing code complexity and improving maintainability.
Files that needed to be changed drastically were additionally
cleaned up to remove any code cruft that has accrued over time.
In order to facility this the following changes were made:
* Move JSON handling from `CascadiaSettings` into `SettingsLoader`
This allows us to use STL containers for data model instances.
For instance profiles are now added to a hashmap for O(1) lookup.
* JSON parsing within `SettingsLoader` doesn't differentiate between user,
inbox and fragment JSON data, reducing code complexity and size.
It also centralizes common concerns, like profile deduplication and
ensuring that all profiles are assigned a GUID.
* Direct JSON modification, like the insertion of dynamic profiles into
settings.json were removed. This vastly reduces code complexity,
but unfortunately removes support for comments in JSON on first start.
* `ColorScheme`s cannot be layered. As such its `LayerJson` API was replaced
with `FromJson`, allowing us to remove JSON-based color scheme validation.
* `Profile`s used to test their wish to layer using `ShouldBeLayered`, which
was replaced with a GUID-based hashmap lookup on previously parsed profiles.
Further changes were made as improvements upon the previous changes:
* Compact the JSON files embedded binary, saving 28kB
* Prevent double-initialization of the color table in `ColorScheme`
* Making `til::color` getters `constexpr`, allow better optimizations
The result is a reduction of:
* 48kB binary size for the Settings.Model.dll
* 5-10% startup duration
* 26% code for the `CascadiaSettings` class
* 1% overall code in this project
Furthermore this results in the following breaking changes:
* The long deprecated "globals" settings object will not be detected and no
warning will be created during load.
* The initial creation of a new settings.json will not produce helpful comments.
Both cases are caused by the removal of manual JSON handling and the
move to representing the settings file with model objects instead
## PR Checklist
* [x] Closes #5276
* [x] Closes #7421
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Out-of-box-experience is identical to before ✔️
(Except for the settings.json file lacking comments.)
* Existing user settings load correctly ✔️
* New WSL instances are added to user settings ✔️
* New fragments are added to user settings ✔️
* All profiles are assigned GUIDs ✔️
2021-09-22 18:27:31 +02:00
|
|
|
INHERITABLE_SETTING(IVector<String>, DisabledProfileSources);
|
2020-08-28 05:49:16 +02:00
|
|
|
|
2020-09-14 22:38:56 +02:00
|
|
|
Windows.Foundation.Collections.IMapView<String, ColorScheme> ColorSchemes();
|
2020-08-28 05:49:16 +02:00
|
|
|
void AddColorScheme(ColorScheme scheme);
|
2020-12-18 00:14:07 +01:00
|
|
|
void RemoveColorScheme(String schemeName);
|
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; };
|
2020-08-28 05:49:16 +02:00
|
|
|
}
|
|
|
|
|
}
|
