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

64 lines
2 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.
import "ColorScheme.idl";
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
import "KeyMapping.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
import "Command.idl";
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,
};
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;
String UnparsedDefaultProfile();
Int32 InitialRows;
Int32 InitialCols;
Boolean AlwaysShowTabs;
Boolean ShowTitleInTitlebar;
Boolean ConfirmCloseAllTabs;
Windows.UI.Xaml.ElementTheme Theme;
Microsoft.UI.Xaml.Controls.TabViewWidthMode TabWidthMode;
Boolean ShowTabsInTitlebar;
String WordDelimiters;
Boolean CopyOnSelect;
Microsoft.Terminal.TerminalControl.CopyFormat CopyFormatting;
Boolean WarnAboutLargePaste;
Boolean WarnAboutMultiLinePaste;
LaunchPosition InitialPosition;
LaunchMode LaunchMode;
Boolean SnapToGridOnResize;
Boolean ForceFullRepaintRendering;
Boolean SoftwareRendering;
Boolean ForceVTInput;
Boolean DebugFeaturesEnabled;
Boolean StartOnUserLogin;
Boolean AlwaysOnTop;
Boolean UseTabSwitcher;
Add an animation to pane entrance/exit (#7364) Adds an entrance animation when panes are created. This animation can be disabled with the `disableAnimations` global setting. Although the XAML animation documentation was pretty heavy on the _do it in XAML_ route, our panes are created pretty much entirely in code, so we've got to create the animations in code as well. 200ms as the duration of the animation was picked _super_ arbitrarily. 300ms felt too long, and 166ms felt like it was only visible for a single frame. see also: * [Motion in practice](https://docs.microsoft.com/en-us/windows/uwp/design/motion/motion-in-practice) * [This example](https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Xaml.Media.Animation.Storyboard?view=winrt-19041#examples) what what I ended up using, albeit ported to cppwinrt. * [`Timeline.AllowDependentAnimations`](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.media.animation.timeline.allowdependentanimations?view=winrt-19041#Windows_UI_Xaml_Media_Animation_Timeline_AllowDependentAnimations) * [easing functions](https://docs.microsoft.com/en-us/windows/uwp/design/motion/key-frame-and-easing-function-animations#easing-functions) ## Validation Steps Performed Man have I been opening panes Closes #1001 Closes #7366
2020-10-10 01:06:40 +02:00
Boolean DisableAnimations;
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);
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
KeyMapping KeyMap();
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, Command> Commands();
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