starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity
Files
1282d56a33bb15206fcb3a09d3bea0a33036f2cd
terminal/src/cascadia/TerminalSettingsModel/Resources/en-US/Resources.resw

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

990 lines
42 KiB
Plaintext
Raw Normal View History

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 09:56:59 -07:00
<?xml version="1.0" encoding="utf-8"?>
<root>
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
<!--
Microsoft ResX Schema
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 09:56:59 -07:00
Version 2.0
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
The primary goals of this format is to allow a simple XML format
that is mostly human readable. The generation and parsing of the
various data types are done through the TypeConverter classes
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 09:56:59 -07:00
associated with the data types.
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07: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 09:56:59 -07:00
Example:
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07: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 09:56:59 -07:00
... ado.net/XML headers & schema ...
<resheader name="resmimetype">text/microsoft-resx</resheader>
<resheader name="version">2.0</resheader>
<resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>
<resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>
<data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>
<data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>
<data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">
<value>[base64 mime encoded serialized .NET Framework object]</value>
</data>
<data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
<value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
<comment>This is a comment</comment>
</data>
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
There are any number of "resheader" rows that contain simple
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 09:56:59 -07:00
name/value pairs.
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
Each data row contains a name, and value. The row also contains a
type or mimetype. Type corresponds to a .NET class that support
text/value conversion through the TypeConverter architecture.
Classes that don't support this are serialized and stored with the
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 09:56:59 -07:00
mimetype set.
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
The mimetype is used for serialized objects, and tells the
ResXResourceReader how to depersist the object. This is currently not
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 09:56:59 -07:00
extensible. For a given mimetype the value must be set accordingly:
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
Note - application/x-microsoft.net.object.binary.base64 is the format
that the ResXResourceWriter will generate, however the reader can
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 09:56:59 -07:00
read any of the formats listed below.
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07: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 09:56:59 -07:00
mimetype: application/x-microsoft.net.object.binary.base64
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
value : The object must be serialized with
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 09:56:59 -07:00
: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
: and then encoded with base64 encoding.
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07: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 09:56:59 -07:00
mimetype: application/x-microsoft.net.object.soap.base64
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
value : The object must be serialized with
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 09:56:59 -07:00
: System.Runtime.Serialization.Formatters.Soap.SoapFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.bytearray.base64
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
value : The object must be serialized into a byte array
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 09:56:59 -07:00
: using a System.ComponentModel.TypeConverter
: and then encoded with base64 encoding.
-->
<xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" />
<xsd:element name="root" msdata:IsDataSet="true">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="metadata">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="name" use="required" type="xsd:string" />
<xsd:attribute name="type" type="xsd:string" />
<xsd:attribute name="mimetype" type="xsd:string" />
<xsd:attribute ref="xml:space" />
</xsd:complexType>
</xsd:element>
<xsd:element name="assembly">
<xsd:complexType>
<xsd:attribute name="alias" type="xsd:string" />
<xsd:attribute name="name" type="xsd:string" />
</xsd:complexType>
</xsd:element>
<xsd:element name="data">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
<xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" msdata:Ordinal="1" />
<xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
<xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
<xsd:attribute ref="xml:space" />
</xsd:complexType>
</xsd:element>
<xsd:element name="resheader">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<resheader name="resmimetype">
<value>text/microsoft-resx</value>
</resheader>
<resheader name="version">
<value>2.0</value>
</resheader>
<resheader name="reader">
<value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<resheader name="writer">
<value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<data name="SetColorSchemeParentCommandName" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Select color scheme...</value>
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 09:56:59 -07:00
</data>
<data name="NewTabParentCommandName" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>New tab...</value>
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 09:56:59 -07:00
</data>
<data name="SplitPaneParentCommandName" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Split pane...</value>
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 09:56:59 -07:00
</data>
Add a snippets pane (#17330) This adds a snippets pane, which can be a static pane with all your snippets (`sendInput` actions) in it. (See #17329) This pane has a treeview with these actions in it, that we can filter with a textbox at the top. Play buttons next to entries make it quick to run the command you found. Bound in the default actions with ```json { "command": { "action": "splitPane", "type": "snippets" }, "id": "Terminal.OpenSnippetsPane", "name": { "key": "SnippetsPaneCommandName" } }, ``` re: #1595 ---- TODO, from 06-04 bug bash * [x] Snippets pane doesn't display some "no snippets found" text if there aren't any yet * [x] open snippets pane; find a "send input"; click the play button on it; input is sent to active pane; begin typing * [x] I can open an infinite amount of suggestions panes * ~I'm closing this as by-design for now at least. Nothing stopping anyone from opening infinite of any kind of pane.~ * ~This would require kind of a lot of refactoring in this PR to mark a kind of pane as being a singleton or singleton-per-tab~ * Okay everyone hates infinite suggestions panes, so I got rid of that * [x] Ctrl+Shift+W should still work in the snippets pane even if focus isn't in textbox * [ ] open snippets pane; click on text box; press TAB key; * [ ] If you press TAB again, I have no idea where focus went * [x] some previews don't work. Like `^c` (`"input": "\u0003"`) * [x] nested items just give you a bit of extra space for no reason and it looks a little awkward * [x] UI Suggestion: add padding on the right side * [ ] [Accessibility] Narrator says "Clear buffer; Suggestions found 132" when you open the snippets pane - Note: this is probably Narrator reading out the command palette (since that's where I opened it from) - We should probably expect something like "Snippets", then (assuming focus is thrown into text box) "Type to filter snippets" or something like that
2024-07-08 13:26:07 -05:00
<data name="SnippetsPaneCommandName" xml:space="preserve">
<value>Open snippets pane</value>
<comment>This will open a pane with a list of the users's saved commands ("snippets") in it</comment>
</data>
Add "portable mode", where settings load from the install path (#15051) This pull request implements portable mode for Windows Terminal, which will make side by side deployment of different versions generally more feasible. Portable mode was specified in #15032. There are three broad categories of changes in this PR: 1. Changes to settings loading. 2. A new indicator in the settings UI plus a link to the portable mode docs. 3. A new application display name, `Terminal (Portable)`, which users will hopefully include in their bug reports. It's surprisingly small for how big a deal it is! Related to #15034 Closes #1386
2023-03-31 17:12:00 -05:00
<data name="ApplicationDisplayNamePortable" xml:space="preserve">
<value>Terminal (Portable)</value>
<comment>This display name is used when the Terminal application is running in a "portable" mode, where settings are not stored in a shared location.</comment>
</data>
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 09:56:59 -07:00
<data name="ApplicationDisplayNameUnpackaged" xml:space="preserve">
Rename "Windows Terminal" -> "Terminal" (#12264) This should be most of the surfaces that we really care about for displaying "Windows Terminal". There's a pile of other references in code, but I couldn't find any other resources that mention it. I left a lot of the references to Windows Terminal throughout. Seemed like it was fine to keep calling it that in most places, just these localized strings that are going to be displayed in the Shell that should be changed. Rough compare: ![image](https://user-images.githubusercontent.com/18356694/151248506-edf9a6ab-d93f-438f-8755-cdf6ae643736.png) The strings were also moved to the Context Menu resources file, because that's localized into more languages. @DHowett we may want to spin a full build to make sure this works and I didn't miss anything * [x] Closes #12091
2022-01-27 17:34:06 -06:00
<value>Terminal (Unpackaged)</value>
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 09:56:59 -07:00
<comment>This display name is used when the application's name cannot be determined</comment>
</data>
<data name="ApplicationVersionUnknown" xml:space="preserve">
<value>Unknown</value>
<comment>This is displayed when the version of the application cannot be determined</comment>
</data>
<data name="AdjustFontSizeCommandKey" xml:space="preserve">
<value>Adjust font size</value>
</data>
<data name="CloseOtherTabsCommandKey" xml:space="preserve">
<value>Close tabs other than index {0}</value>
<comment>{0} will be replaced with a number</comment>
</data>
<data name="CloseOtherTabsDefaultCommandKey" xml:space="preserve">
<value>Close all other tabs</value>
</data>
<data name="ClosePaneCommandKey" xml:space="preserve">
<value>Close pane</value>
</data>
Allow closing tabs by index (#10447) ## Summary of the Pull Request Updates the `closeTab` action to optionally take an index. ## PR Checklist * [x] Closes #7180 * [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: MicrosoftDocs/terminal#347 * [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 ## Validation Steps Performed Added the following configuration to `settings.json` and validated both key combinations behaved as expected. Also opened the command palette and ensured that the actions were displayed. ```json { "command": "closeTab", "keys": "ctrl+shift+delete" }, { "command": { "action": "closeTab", "index": 0 }, "keys": "ctrl+shift+end" } ```
2021-06-25 20:22:52 +01:00
<data name="CloseTabAtIndexCommandKey" xml:space="preserve">
<value>Close tab at index {0}</value>
<comment>{0} will be replaced with a number</comment>
</data>
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 09:56:59 -07:00
<data name="CloseTabCommandKey" xml:space="preserve">
<value>Close tab</value>
</data>
<data name="CloseTabsAfterCommandKey" xml:space="preserve">
<value>Close tabs after index {0}</value>
<comment>{0} will be replaced with a number</comment>
</data>
Create a new page for "Add new profile" in the SUI (#9352) - Whenever we add a new profile setting from now on we have to update `Profile::CopySettings` _and_ `CascadiaSettings::DuplicateProfile` 👎 Notes from bug bash (checked bugs have been resolved): - [ ] The duplicate list can be very long if you have profiles - [x] DH: "Create new" seems too vague. "New empty profile" or something seems a little clearer to me. - [x] There is no deduplication counter for name - [x] Crash when your settings file is corrupt and we had to fall back to the defaults and you duplicate a profile - [x] Crash due to #10003 ## PR Checklist * [x] Closes #9121
2021-05-04 21:15:25 -07:00
<data name="CopySuffix" xml:space="preserve">
<value>Copy</value>
<comment>The suffix we add to the name of a duplicated profile.</comment>
</data>
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-26 00:09:27 +02:00
<data name="MoveTabCommandKey" xml:space="preserve">
<value>Move tab {0}</value>
Updated strings of "Move tab" commands to include "left" and "right" (#19708) ## Summary of the Pull Request * As per the discussions in [#19228](https://github.com/microsoft/terminal/issues/19228), updated the command palette strings. * Similar change is done for the strings used in Terminal settings editor as well. ## PR Checklist Closes #19228
2026-01-13 00:54:57 +05:30
<comment>{0} will be replaced with a "forward (right)" / "backward (left)"</comment>
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-26 00:09:27 +02:00
</data>
Add support for moving panes and tabs between windows (#14866) _Lo! Harken to me, for I shall divulge the heart of the tab tear-out saga. Verily, this PR shall bestow upon thee the power to move tabs and panes between windows by means of pre-defined actions. Though be warned, it does not yet grant thee the power to drag and drop them as thou mayest desire. Yet, the same plumbing that underpins this work shall remain steadfast. Behold, the majority of this undertaking concerns the elevation of the RequestMoveContent event from the TerminalPage to the very summit of the Monarch. From thence, a great AttachContent method shall descend back to the lowest depths. Furthermore, there are minor revisions to TermControl that shall enable thee to better detach the content and attach it to a new one._ This is the most important part of the tab tear-out saga. This PR enables the user to move tabs and panes between windows using pre-defined actions. It does _not_ enable the user to drag/drop them yet, but the same fundamental plumbing will still apply. Most of the PR is plumbing the `RequestMoveContent` event up from the `TerminalPage` up to the `Monarch`, and then plumbing an `AttachContent` method back down. There are also small changes to `TermControl` to better support detaching the content and attaching to a new one. For testing, I recommend: ```json { "keys": "f1", "command": { "action": "moveTab", "window": "1" } }, { "keys": "f2", "command": { "action": "moveTab", "window": "2" } }, { "keys": "f3", "command": { "action": "movePane", "window": "1" } }, { "keys": "f4", "command": { "action": "movePane", "window": "2" } }, { "keys": "shift+f3", "command": { "action": "movePane", "window": "1", "index": 3 } }, { "keys": "shift+f4", "command": { "action": "movePane", "window": "2", "index": 3 } }, ``` * Related to #1256 * Related to #5000 --------- Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2023-03-30 09:37:53 -05:00
<data name="MoveTabToWindowCommandKey" xml:space="preserve">
<value>Move tab to window "{0}"</value>
<comment>{0} will be replaced with a user-specified name of a window</comment>
</data>
Add default bindings for "move tab/pane to a new window" (#15258) This was in pursuit of #15156. I need an ack from OP to make sure this is good enough. Related to #14957
2023-05-01 10:20:23 -05:00
<data name="MoveTabToNewWindowCommandKey" xml:space="preserve">
<value>Move tab to a new window</value>
</data>
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-26 00:09:27 +02:00
<data name="MoveTabDirectionForward" xml:space="preserve">
Updated strings of "Move tab" commands to include "left" and "right" (#19708) ## Summary of the Pull Request * As per the discussions in [#19228](https://github.com/microsoft/terminal/issues/19228), updated the command palette strings. * Similar change is done for the strings used in Terminal settings editor as well. ## PR Checklist Closes #19228
2026-01-13 00:54:57 +05:30
<value>forward (right)</value>
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-26 00:09:27 +02:00
</data>
<data name="MoveTabDirectionBackward" xml:space="preserve">
Updated strings of "Move tab" commands to include "left" and "right" (#19708) ## Summary of the Pull Request * As per the discussions in [#19228](https://github.com/microsoft/terminal/issues/19228), updated the command palette strings. * Similar change is done for the strings used in Terminal settings editor as well. ## PR Checklist Closes #19228
2026-01-13 00:54:57 +05:30
<value>backward (left)</value>
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-26 00:09:27 +02:00
</data>
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 09:56:59 -07:00
<data name="CloseTabsAfterDefaultCommandKey" xml:space="preserve">
<value>Close all tabs after the current tab</value>
</data>
<data name="CloseWindowCommandKey" xml:space="preserve">
<value>Close window</value>
</data>
Add an openSystemMenu keybinding (#11086) ## Summary of the Pull Request Basically undoes #10988 in favour of implementing it as described in #11018 ## PR Checklist * [x] Closes #11018 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [X] 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. * [x] I work here ## Validation Steps Performed - alt+space opens the system menu by default - when alt+space is bound, the keys do not get send to terminal - right-click on the tab bar didn't break (still opens system menu at the location of the cursor)
2021-09-10 11:25:43 -07:00
<data name="OpenSystemMenuCommandKey" xml:space="preserve">
<value>Open system menu</value>
</data>
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 09:56:59 -07:00
<data name="CommandPromptDisplayName" xml:space="preserve">
<value>Command Prompt</value>
<comment>This is the name of "Command Prompt", as localized in Windows. The localization here should match the one in the Windows product for "Command Prompt"</comment>
</data>
<data name="CopyTextAsSingleLineCommandKey" xml:space="preserve">
<value>Copy text as a single line</value>
</data>
<data name="CopyTextCommandKey" xml:space="preserve">
<value>Copy text</value>
</data>
<data name="DecreaseFontSizeCommandKey" xml:space="preserve">
<value>Decrease font size</value>
</data>
<data name="DecreaseFontSizeWithAmountCommandKey" xml:space="preserve">
<value>Decrease font size, amount: {0}</value>
<comment>{0} will be replaced with a positive number</comment>
</data>
<data name="DirectionDown" xml:space="preserve">
<value>down</value>
</data>
<data name="DirectionLeft" xml:space="preserve">
<value>left</value>
</data>
<data name="DirectionRight" xml:space="preserve">
<value>right</value>
</data>
<data name="DirectionUp" xml:space="preserve">
<value>up</value>
</data>
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 10:36:05 -08:00
<data name="DirectionPrevious" xml:space="preserve">
<value>previous</value>
</data>
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 09:56:59 -07:00
<data name="DuplicatePaneCommandKey" xml:space="preserve">
<value>Duplicate pane</value>
</data>
<data name="DuplicateTabCommandKey" xml:space="preserve">
<value>Duplicate tab</value>
</data>
<data name="ExecuteCommandlineCommandKey" xml:space="preserve">
<value>Run commandline "{0}" in this window</value>
<comment>{0} will be replaced with a user-defined commandline</comment>
</data>
<data name="FindCommandKey" xml:space="preserve">
<value>Find</value>
</data>
Add `findNext`, `findPrev` actions (#8917) This PR is a resurrection of #8522. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new action for navigating to the next & previous search results. These actions are unbound by default. These actions can be used from directly within the search dialog also, to immediately navigate the results. Furthermore, if you have a search started, and close the search box, then press this keybinding, _it will still perform the search_. So you can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep searching new results. Neat! If you dispatch the action on the key down, then dismiss a selection on a key up, we'll end up immediately destroying the selection when you release the bound key. That's annoying. It also bothers @carlos-zamora in #3758. However, I _think_ we can just only dismiss the selection on a key up. I _think_ that's fine. It _seems_ fine so far. We've got an entire release cycle to futz with it. ## Validation Steps Performed I've played with it all day and it seems _crisp_. Closes #7695 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 13:21:35 -06:00
<data name="FindNextCommandKey" xml:space="preserve">
<value>Find next search match</value>
</data>
<data name="FindPrevCommandKey" xml:space="preserve">
<value>Find previous search match</value>
</data>
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 09:56:59 -07:00
<data name="IncreaseFontSizeCommandKey" xml:space="preserve">
<value>Increase font size</value>
</data>
<data name="IncreaseFontSizeWithAmountCommandKey" xml:space="preserve">
<value>Increase font size, amount: {0}</value>
<comment>{0} will be replaced with a positive number</comment>
</data>
<data name="MoveFocusCommandKey" xml:space="preserve">
<value>Move focus</value>
</data>
<data name="MoveFocusWithArgCommandKey" xml:space="preserve">
<value>Move focus {0}</value>
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 10:36:05 -08:00
<comment>{0} will be replaced with one of the four directions "DirectionLeft", "DirectionRight", "DirectionUp", "DirectionDown"</comment>
</data>
<data name="MoveFocusToLastUsedPane" xml:space="preserve">
<value>Move focus to the last used pane</value>
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 09:56:59 -07:00
</data>
Add first pane movement for MoveFocus/SwapPane. (#11044) This commit adds the ability to target the first pane in the tree, always. I wasn't able to find an existing issue for this, it is just a personal feature for me. I won't be heartbroken if it does not get merged. As motivation, I frequently have setups where the thing I am primarily working on is a large pane on the left and everything else is in smaller panes positioned elsewhere. I like to have one hotkey where I can go to any pane and then make it the "primary" pane if I am changing what I am working on or need to focus on another set of code/documentation/etc. ## Validation Steps Performed Confirmed that the move focus and swap pane variants both affect the correct pane.
2021-08-26 13:58:56 -04:00
<data name="MoveFocusNextInOrder" xml:space="preserve">
<value>Move focus to the next pane in order</value>
</data>
<data name="MoveFocusPreviousInOrder" xml:space="preserve">
<value>Move focus to the previous pane in order</value>
</data>
<data name="MoveFocusFirstPane" xml:space="preserve">
<value>Move focus to the first pane</value>
</data>
Add the ability to interact with subtrees of panes (#11153) This commit adds the ability to interact with subtrees of panes. Have you ever thought that you don't have enough regression testing to do? Boy do I have the PR for you! This breaks all kinds of assumptions about what is or is not focused, largely complicated by the fact that a pane is not a proper control. I did my best to cover as many cases as I could, but I wouldn't be surprised if there are some things broken that I am unaware of. Done: - Add `parent` and `child` movement directions to move up and down the tree respectively - When a parent pane is selected it will have borders all around it in addition to any borders the children have. - Fix focus, swap, split, zoom, toggle orientation, resize, and move to all handle interacting with more than one pane. - Similarly the actions for font size changing, closing, read-only, clearing buffer, and changing color scheme will distribute to all children. - This technically leaves control focus on the original control in the focused subtree because panes aren't proper controls themselves. This is also used to make sure we go back down the same path with the `child` movement. - You can zoom a parent pane, and click between different zoomed sub-panes and it won't unzoom you until you use moveFocus or another action. This wasn't explicitly programmed behavior so it is probably buggy (I've quashed a couple at least). It is a natural consequence of showing multiple terminals and allowing you to focus a terminal and a parent separately, since changing the active pane directly does not unzoom. This also means there can be a disconnect between what pane is zoomed and what pane is active. ## Validation Steps Performed Tested focus movement, swapping, moving panes, and zooming. Closes #10733
2021-09-28 15:16:05 -04:00
<data name="MoveFocusParentPane" xml:space="preserve">
<value>Move focus to the parent pane</value>
</data>
<data name="MoveFocusChildPane" xml:space="preserve">
<value>Move focus to the child pane</value>
</data>
Move Pane to Tab (GH7075) (#10780) <!-- 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 Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [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 Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 12:41:17 -04:00
<data name="SwapPaneCommandKey" xml:space="preserve">
<value>Swap pane</value>
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638) <!-- 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 Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This work potentially touches on: #1000 #2398 and #4922 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality) * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [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 Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes. Work currently done: - Add boilerplate/infrastructure for argument parsing, hotkeys, event handling - Adds the `MovePane` function that finds the focused pane, and then tries to find a pane that is visually adjacent to according to direction. - First pass at the `SwapPanes` function that swaps the tree location of two panes - First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus` that search the tree for the currently focused pane, and then climbs back up the tree to try to find a sibling pane that is adjacent to it. - An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction. Next steps: - Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function. - Do we want default hotkeys for the new actions? <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 08:53:03 -04:00
</data>
Move Pane to Tab (GH7075) (#10780) <!-- 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 Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [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 Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 12:41:17 -04:00
<data name="SwapPaneWithArgCommandKey" xml:space="preserve">
<value>Swap pane {0}</value>
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638) <!-- 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 Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This work potentially touches on: #1000 #2398 and #4922 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality) * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [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 Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes. Work currently done: - Add boilerplate/infrastructure for argument parsing, hotkeys, event handling - Adds the `MovePane` function that finds the focused pane, and then tries to find a pane that is visually adjacent to according to direction. - First pass at the `SwapPanes` function that swaps the tree location of two panes - First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus` that search the tree for the currently focused pane, and then climbs back up the tree to try to find a sibling pane that is adjacent to it. - An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction. Next steps: - Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function. - Do we want default hotkeys for the new actions? <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 08:53:03 -04:00
<comment>{0} will be replaced with one of the four directions "DirectionLeft", "DirectionRight", "DirectionUp", "DirectionDown"</comment>
</data>
Move Pane to Tab (GH7075) (#10780) <!-- 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 Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [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 Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 12:41:17 -04:00
<data name="SwapPaneToLastUsedPane" xml:space="preserve">
<value>Swap panes with the last used pane</value>
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#10638) <!-- 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 Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This work potentially touches on: #1000 #2398 and #4922 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality) * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [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 Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes. Work currently done: - Add boilerplate/infrastructure for argument parsing, hotkeys, event handling - Adds the `MovePane` function that finds the focused pane, and then tries to find a pane that is visually adjacent to according to direction. - First pass at the `SwapPanes` function that swaps the tree location of two panes - First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus` that search the tree for the currently focused pane, and then climbs back up the tree to try to find a sibling pane that is adjacent to it. - An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction. Next steps: - Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function. - Do we want default hotkeys for the new actions? <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
2021-07-22 08:53:03 -04:00
</data>
Add first pane movement for MoveFocus/SwapPane. (#11044) This commit adds the ability to target the first pane in the tree, always. I wasn't able to find an existing issue for this, it is just a personal feature for me. I won't be heartbroken if it does not get merged. As motivation, I frequently have setups where the thing I am primarily working on is a large pane on the left and everything else is in smaller panes positioned elsewhere. I like to have one hotkey where I can go to any pane and then make it the "primary" pane if I am changing what I am working on or need to focus on another set of code/documentation/etc. ## Validation Steps Performed Confirmed that the move focus and swap pane variants both affect the correct pane.
2021-08-26 13:58:56 -04:00
<data name="SwapPaneNextInOrder" xml:space="preserve">
<value>Swap panes with the next pane in order</value>
</data>
<data name="SwapPanePreviousInOrder" xml:space="preserve">
<value>Swap panes with the previous pane in order</value>
</data>
<data name="SwapPaneFirstPane" xml:space="preserve">
<value>Swap panes with the first pane</value>
</data>
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 09:56:59 -07:00
<data name="NewTabCommandKey" xml:space="preserve">
<value>New tab</value>
</data>
<data name="NewWindowCommandKey" xml:space="preserve">
<value>New window</value>
</data>
Add an action for identifying windows (#9523) ## Summary of the Pull Request This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions: * `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default. ![identify-window-toast-000](https://user-images.githubusercontent.com/18356694/111529085-bf710580-872f-11eb-8880-b0b617596cfc.gif) * `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky. ![teaching-tip-dismiss-001](https://user-images.githubusercontent.com/18356694/111529292-fe06c000-872f-11eb-8d4a-5688e4ce1175.gif) That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382 Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows` ## References ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?" Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
2021-03-30 11:08:03 -05:00
<data name="IdentifyWindowCommandKey" xml:space="preserve">
<value>Identify window</value>
</data>
<data name="IdentifyWindowsCommandKey" xml:space="preserve">
<value>Identify windows</value>
</data>
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 09:56:59 -07:00
<data name="NextTabCommandKey" xml:space="preserve">
<value>Next tab</value>
</data>
<data name="OpenBothSettingsFilesCommandKey" xml:space="preserve">
Add "JSON" to the "Open settings file" command names (#13265) ![image](https://user-images.githubusercontent.com/18356694/173090336-3512ee36-ae8b-41d5-8823-09cb1354c7ef.png) * [x] Closes #13225
2022-06-10 11:41:13 -05:00
<value>Open both settings and default settings files (JSON)</value>
<comment>{Locked="JSON"}. "JSON" is the extension of the file that will be opened.</comment>
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 09:56:59 -07:00
</data>
<data name="OpenDefaultSettingsCommandKey" xml:space="preserve">
Add "JSON" to the "Open settings file" command names (#13265) ![image](https://user-images.githubusercontent.com/18356694/173090336-3512ee36-ae8b-41d5-8823-09cb1354c7ef.png) * [x] Closes #13225
2022-06-10 11:41:13 -05:00
<value>Open default settings file (JSON)</value>
<comment>{Locked="JSON"}. "JSON" is the extension of the file that will be opened.</comment>
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 09:56:59 -07:00
</data>
<data name="OpenNewTabDropdownCommandKey" xml:space="preserve">
<value>Open new tab dropdown</value>
</data>
<data name="OpenSettingsCommandKey" xml:space="preserve">
Add "JSON" to the "Open settings file" command names (#13265) ![image](https://user-images.githubusercontent.com/18356694/173090336-3512ee36-ae8b-41d5-8823-09cb1354c7ef.png) * [x] Closes #13225
2022-06-10 11:41:13 -05:00
<value>Open settings file (JSON)</value>
<comment>{Locked="JSON"}. "JSON" is the extension of the file that will be opened.</comment>
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 09:56:59 -07:00
</data>
Add action for opening settings directory in file explorer (#17690) Most of the logic is taken from the original PR (https://github.com/microsoft/terminal/pull/15417) and adapted to work with the palette. ## References and Relevant Issues [#12382](https://github.com/microsoft/terminal/issues/12382)
2024-12-05 04:20:13 -08:00
<data name="SettingsFileOpenInExplorerCommandKey" xml:space="preserve">
<value>Open the settings file directory</value>
</data>
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 09:56:59 -07:00
<data name="OpenTabColorPickerCommandKey" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Set tab color...</value>
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 09:56:59 -07:00
</data>
<data name="PasteTextCommandKey" xml:space="preserve">
<value>Paste</value>
</data>
<data name="PrevTabCommandKey" xml:space="preserve">
<value>Previous tab</value>
</data>
<data name="RenameTabCommandKey" xml:space="preserve">
<value>Rename tab to "{0}"</value>
<comment>{0} will be replaced with a user-defined string</comment>
</data>
<data name="ResetFontSizeCommandKey" xml:space="preserve">
<value>Reset font size</value>
</data>
<data name="ResetTabColorCommandKey" xml:space="preserve">
<value>Reset tab color</value>
</data>
<data name="ResetTabNameCommandKey" xml:space="preserve">
<value>Reset tab title</value>
</data>
Add `openTabRenamer` action (#7462) Adds a `ShortcutAction` to allow editing the tab title via the TextBox (just like double-clicking the tab, but triggered from a key binding or command palette). * This implements "scenario 3" outlined in zadjii-msft's comment: https://github.com/microsoft/terminal/pull/6557#issuecomment-646153274 * The `openTabRenamer` action name is taken from the discussion in this PR: https://github.com/microsoft/terminal/pull/6567#issuecomment-646319010 Related to #6256 (but doesn't address pane renaming)
2020-10-29 05:36:30 +10:00
<data name="OpenTabRenamerCommandKey" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Rename tab</value>
Add `openTabRenamer` action (#7462) Adds a `ShortcutAction` to allow editing the tab title via the TextBox (just like double-clicking the tab, but triggered from a key binding or command palette). * This implements "scenario 3" outlined in zadjii-msft's comment: https://github.com/microsoft/terminal/pull/6557#issuecomment-646153274 * The `openTabRenamer` action name is taken from the discussion in this PR: https://github.com/microsoft/terminal/pull/6567#issuecomment-646319010 Related to #6256 (but doesn't address pane renaming)
2020-10-29 05:36:30 +10:00
</data>
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 09:56:59 -07:00
<data name="ResizePaneCommandKey" xml:space="preserve">
<value>Resize pane</value>
</data>
<data name="ResizePaneWithArgCommandKey" xml:space="preserve">
<value>Resize pane {0}</value>
<comment>{0} will be replaced with one of the four directions "DirectionLeft", "DirectionRight", "DirectionUp", or "DirectionDown"</comment>
</data>
<data name="ScrollDownCommandKey" xml:space="preserve">
add rowsToScroll to scrollUp/Down w/ fallback to system default (#7924) - The number of lines to move upon scroll up scroll down can be defined in ScrollUp and ScrollDown commands (parameter is called "rowsToScroll"). - If the number are not provided, use the system default (the one we are using for mouse scrolls), rather than 1 line. ## Validation Steps Performed * Manual testing * Added custom bindings for scroll commands with different values, verified they and the default appear and behave as expected * Checked that invalid values are not allowed Closes #5078
2020-10-27 03:19:52 +02:00
<value>Scroll down</value>
</data>
<data name="ScrollDownSeveralRowsCommandKey" xml:space="preserve">
<value>Scroll down {0} line(s)</value>
<comment>{0} will be replaced with the number of lines to scroll"</comment>
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 09:56:59 -07:00
</data>
<data name="ScrollDownPageCommandKey" xml:space="preserve">
<value>Scroll down one page</value>
</data>
<data name="ScrollUpCommandKey" xml:space="preserve">
add rowsToScroll to scrollUp/Down w/ fallback to system default (#7924) - The number of lines to move upon scroll up scroll down can be defined in ScrollUp and ScrollDown commands (parameter is called "rowsToScroll"). - If the number are not provided, use the system default (the one we are using for mouse scrolls), rather than 1 line. ## Validation Steps Performed * Manual testing * Added custom bindings for scroll commands with different values, verified they and the default appear and behave as expected * Checked that invalid values are not allowed Closes #5078
2020-10-27 03:19:52 +02:00
<value>Scroll up</value>
</data>
<data name="ScrollUpSeveralRowsCommandKey" xml:space="preserve">
<value>Scroll up {0} line(s)</value>
<comment>{0} will be replaced with the number of lines to scroll"</comment>
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 09:56:59 -07:00
</data>
<data name="ScrollUpPageCommandKey" xml:space="preserve">
<value>Scroll up one page</value>
</data>
Add ScrollHome and ScrollEnd (#8459) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR adds shortcut action so that users can scroll. I used `UINT16_MAX` for `rowsToScroll`. <!-- 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 #7542 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2020-12-09 02:28:41 +09:00
<data name="ScrollToTopCommandKey" xml:space="preserve">
<value>Scroll to the top of history</value>
</data>
<data name="ScrollToBottomCommandKey" xml:space="preserve">
<value>Scroll to the bottom of history</value>
</data>
Experimental: add support for scrollbar marks (#12948) Adds support for marks in the scrollbar. These marks can be added in 3 ways: * Via the iterm2 `OSC 1337 ; SetMark` sequence * Via the `addMark` action * Automatically when the `experimental.autoMarkPrompts` per-profile setting is enabled. #11000 has more tracking for the big-picture for this feature, as well as additional follow-ups. This set of functionality seemed complete enough to send a review for now. That issue describes these how I wish these actions to look in the fullness of time. This is simply the v0.1 from the hackathon last month. #### Actions * `addMark`: add a mark to the buffer. If there's a selection, use place the mark covering at the selection. Otherwise, place the mark on the cursor row. - `color`: a color for the scrollbar mark. This is optional - defaults to the `foreground` color of the current scheme if omitted. * `scrollToMark` - `direction`: `["first", "previous", "next", "last"]` * `clearMark`: Clears marks at the current postition (either the selection if there is one, or the cursor position. * `clearAllMarks`: Don't think this needs explanation. #### Per-profile settings * `experimental.autoMarkPrompts`: `bool`, default `false`. * `experimental.showMarksOnScrollbar`: `bool` ## PR Checklist * [x] Closes #1527 * [x] Closes #6232 ## Detailed Description of the Pull Request / Additional comments This is basically hackathon code. It's experimental! That's okay! We'll figure the rest of the design in post. Theoretically, I should make these actions `experimental.` as well, but it seemed like since the only way to see these guys was via the `experimental.showMarksOnScrollbar` setting, you've already broken yourself into experimental jail, and you know what you're doing. Things that won't work as expected: * resizing, ESPECIALLY reflowing * Clearing the buffer with ED sequences / Clear Buffer I could theoretically add velocity around this in the `TermControl` layer. Always prevent marks from being visible, ignore all the actions. Marks could still be set by VT and automark, but they'd be useless. Next up priorities: * Making this work with the FinalTerm sequences * properly speccing * adding support for `showMarksOnScrollbar: flags(categories)`, so you can only display errors on the scrollbar * adding the `category` flag to the `addMark` action ## Validation Steps Performed I like using it quite a bit. The marks can get noisy if you have them emitted on every prompt and the buffer has 9000 lines. But that's the beautiful thing, the actions work even if the marks aren't visible, so you can still scroll between prompts. <details> <summary>Settings blob</summary> ```jsonc // actions { "keys": "ctrl+up", "command": { "action": "scrollToMark", "direction": "previous" }, "name": "Previous mark" }, { "keys": "ctrl+down", "command": { "action": "scrollToMark", "direction": "next" }, "name": "Next mark" }, { "keys": "ctrl+pgup", "command": { "action": "scrollToMark", "direction": "first" }, "name": "First mark" }, { "keys": "ctrl+pgdn", "command": { "action": "scrollToMark", "direction": "last" }, "name": "Last mark" }, { "command": { "action": "addMark" } }, { "command": { "action": "addMark", "color": "#ff00ff" } }, { "command": { "action": "addMark", "color": "#0000ff" } }, { "command": { "action": "clearAllMarks" } }, // profiles.defaults "experimental.autoMarkPrompts": true, "experimental.showMarksOnScrollbar": true, ``` </details>
2022-06-09 16:10:16 -05:00
<data name="ScrollToPreviousMarkCommandKey" xml:space="preserve">
Upgrade check-spelling to v0.0.20 (#13565) Upgrade check-spelling to [v0.0.20](https://github.com/check-spelling/check-spelling/releases/tag/v0.0.20) This upgrade includes a refresh of the workflow key new features: * the previous comment is collapsed * duplicate words are flagged (see `alone` and `the`) * forbidding patterns (see `nonexistent`, `preexisting`, and `greater than`) Each of these features can be tuned - comment collapsing is controlled by the `followup` bits in the workflow-- but I can't imagine why one would want to turn it off - duplicate words can be masked in `patterns.txt` (see `Guid` and `that`) - forbidding patterns (especially duplicates) is in `.github/actions/spelling/line_forbidden.patterns` Fwiw, I'm slowly moving towards not using `.txt` in filenames, but it's a long term project and I have a bunch of other goals for the near term. The refresh of advice is of course flexible -- I'm still evolving my default text. Note that the default now includes some `curl` and I'm still working on how I want to consume the output. I'm getting close to the point where I might be able to provide a tool that could reliably consume the output (including on Windows). This code has been used internally for a while, but I tested it for this repository here: https://github.com/check-spelling/terminal/pull/2
2022-07-22 14:01:32 -04:00
<value>Scroll to the previous mark</value>
Experimental: add support for scrollbar marks (#12948) Adds support for marks in the scrollbar. These marks can be added in 3 ways: * Via the iterm2 `OSC 1337 ; SetMark` sequence * Via the `addMark` action * Automatically when the `experimental.autoMarkPrompts` per-profile setting is enabled. #11000 has more tracking for the big-picture for this feature, as well as additional follow-ups. This set of functionality seemed complete enough to send a review for now. That issue describes these how I wish these actions to look in the fullness of time. This is simply the v0.1 from the hackathon last month. #### Actions * `addMark`: add a mark to the buffer. If there's a selection, use place the mark covering at the selection. Otherwise, place the mark on the cursor row. - `color`: a color for the scrollbar mark. This is optional - defaults to the `foreground` color of the current scheme if omitted. * `scrollToMark` - `direction`: `["first", "previous", "next", "last"]` * `clearMark`: Clears marks at the current postition (either the selection if there is one, or the cursor position. * `clearAllMarks`: Don't think this needs explanation. #### Per-profile settings * `experimental.autoMarkPrompts`: `bool`, default `false`. * `experimental.showMarksOnScrollbar`: `bool` ## PR Checklist * [x] Closes #1527 * [x] Closes #6232 ## Detailed Description of the Pull Request / Additional comments This is basically hackathon code. It's experimental! That's okay! We'll figure the rest of the design in post. Theoretically, I should make these actions `experimental.` as well, but it seemed like since the only way to see these guys was via the `experimental.showMarksOnScrollbar` setting, you've already broken yourself into experimental jail, and you know what you're doing. Things that won't work as expected: * resizing, ESPECIALLY reflowing * Clearing the buffer with ED sequences / Clear Buffer I could theoretically add velocity around this in the `TermControl` layer. Always prevent marks from being visible, ignore all the actions. Marks could still be set by VT and automark, but they'd be useless. Next up priorities: * Making this work with the FinalTerm sequences * properly speccing * adding support for `showMarksOnScrollbar: flags(categories)`, so you can only display errors on the scrollbar * adding the `category` flag to the `addMark` action ## Validation Steps Performed I like using it quite a bit. The marks can get noisy if you have them emitted on every prompt and the buffer has 9000 lines. But that's the beautiful thing, the actions work even if the marks aren't visible, so you can still scroll between prompts. <details> <summary>Settings blob</summary> ```jsonc // actions { "keys": "ctrl+up", "command": { "action": "scrollToMark", "direction": "previous" }, "name": "Previous mark" }, { "keys": "ctrl+down", "command": { "action": "scrollToMark", "direction": "next" }, "name": "Next mark" }, { "keys": "ctrl+pgup", "command": { "action": "scrollToMark", "direction": "first" }, "name": "First mark" }, { "keys": "ctrl+pgdn", "command": { "action": "scrollToMark", "direction": "last" }, "name": "Last mark" }, { "command": { "action": "addMark" } }, { "command": { "action": "addMark", "color": "#ff00ff" } }, { "command": { "action": "addMark", "color": "#0000ff" } }, { "command": { "action": "clearAllMarks" } }, // profiles.defaults "experimental.autoMarkPrompts": true, "experimental.showMarksOnScrollbar": true, ``` </details>
2022-06-09 16:10:16 -05:00
</data>
<data name="ScrollToNextMarkCommandKey" xml:space="preserve">
<value>Scroll to the next mark</value>
</data>
<data name="ScrollToFirstMarkCommandKey" xml:space="preserve">
<value>Scroll to the first mark</value>
</data>
<data name="ScrollToLastMarkCommandKey" xml:space="preserve">
<value>Scroll to the last mark</value>
</data>
<data name="AddMarkCommandKey" xml:space="preserve">
<value>Add a scroll mark</value>
</data>
<data name="AddMarkWithColorCommandKey" xml:space="preserve">
<value>Add a scroll mark, color:{0}</value>
<comment>{Locked="color"}. "color" is a literal parameter name that shouldn't be translated. {0} will be replaced with a color in hexadecimal format, like `#123456`</comment>
</data>
<data name="ClearMarkCommandKey" xml:space="preserve">
<value>Clear mark</value>
</data>
<data name="ClearAllMarksCommandKey" xml:space="preserve">
<value>Clear all marks</value>
</data>
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 09:56:59 -07:00
<data name="SendInputCommandKey" xml:space="preserve">
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
<value>Send input: "{0}"</value>
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 09:56:59 -07:00
<comment>{0} will be replaced with a string of input as defined by the user</comment>
</data>
<data name="SetColorSchemeCommandKey" xml:space="preserve">
<value>Set color scheme to {0}</value>
<comment>{0} will be replaced with the name of a color scheme as defined by the user.</comment>
</data>
<data name="SetTabColorCommandKey" xml:space="preserve">
<value>Set tab color to {0}</value>
<comment>{0} will be replaced with a color, displayed in hexadecimal (#RRGGBB) notation.</comment>
</data>
<data name="SplitHorizontalCommandKey" xml:space="preserve">
<value>Split pane horizontally</value>
</data>
Move Pane to Tab (GH7075) (#10780) <!-- 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 Add functionality to move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed. This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #4587 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #7075 * [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 Things done: - Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work. - Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls. - Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired. - Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early). - Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 . To do: - Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary. Next Steps: - In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI. - Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab). - Its been 10 years, I just really want to use concepts already. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 12:41:17 -04:00
<data name="MovePaneCommandKey" xml:space="preserve">
<value>Move pane</value>
</data>
Add default bindings for "move tab/pane to a new window" (#15258) This was in pursuit of #15156. I need an ack from OP to make sure this is good enough. Related to #14957
2023-05-01 10:20:23 -05:00
<data name="MovePaneToNewWindowCommandKey" xml:space="preserve">
<value>Move pane to new window</value>
</data>
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 09:56:59 -07:00
<data name="SplitPaneCommandKey" xml:space="preserve">
<value>Split pane</value>
</data>
<data name="SplitVerticalCommandKey" xml:space="preserve">
<value>Split pane vertically</value>
</data>
<data name="SwitchToTabCommandKey" xml:space="preserve">
<value>Switch to tab</value>
</data>
Clamp the `focusTab` action to the number of available tabs (#10651) ## Summary of the Pull Request When we perform a `focusTab` action, we currently do nothing if the parameter was greater than the number of tabs. This PR changes that behavior. Now, `focus-tab -t 999999` will always focus the last tab, instead of silently doing nothing. ## PR Checklist * [x] Closes #9369 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * [x] ran tests * [x] validated commandline manually
2021-07-22 08:48:36 -05:00
<data name="SwitchToLastTabCommandKey" xml:space="preserve">
<value>Switch to the last tab</value>
</data>
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 09:56:59 -07:00
<data name="TabSearchCommandKey" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Search for tab...</value>
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 09:56:59 -07:00
</data>
<data name="ToggleAlwaysOnTopCommandKey" xml:space="preserve">
<value>Toggle always on top mode</value>
</data>
<data name="ToggleCommandPaletteCommandKey" xml:space="preserve">
<value>Toggle command palette</value>
</data>
Add support for opening the Suggestions UI with recent commands (#14943) This adds support for a new action, `showSuggestions`, as described in #14864. This adds just one `source` currently, `recentCommands`. This requires shell integration to be enabled in the shell to work properly. When it is enabled, activating that action will invoke the suggestions UI as a palette, populated with `sendInput` actions for each of the user's recent commands. * These don't persist across reboots. * These are per-control. There's mild plans to remedy that in a follow-up, though that needs a bit more design consideration. Closes #14779
2023-08-15 08:48:09 -05:00
<data name="SuggestionsCommandKey" xml:space="preserve">
Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse (#16886) I changed the improper capitalization and misuse of ellipses mark (...) in the context menu and various other places. Fixes issues #16819 and #16846 ## PR Checklist - [ ] Closes #16846 - [x] Tests added/passed - NA - [x] Documentation updated - NA - If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx - [x] Schema updated (if necessary) - NA
2024-04-10 05:41:43 +05:30
<value>Open suggestions</value>
Add support for opening the Suggestions UI with recent commands (#14943) This adds support for a new action, `showSuggestions`, as described in #14864. This adds just one `source` currently, `recentCommands`. This requires shell integration to be enabled in the shell to work properly. When it is enabled, activating that action will invoke the suggestions UI as a palette, populated with `sendInput` actions for each of the user's recent commands. * These don't persist across reboots. * These are per-control. There's mild plans to remedy that in a follow-up, though that needs a bit more design consideration. Closes #14779
2023-08-15 08:48:09 -05:00
</data>
Add launchMode parameter to ToggleCommandPalette action (#8382) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8322 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated - https://github.com/MicrosoftDocs/terminal/pull/202 * [x] Schema updated. * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Added an optional launchMode parameter to "commandPalette" command. The values of the launchMode are either "action" (default) or "command line". ## Validation Steps Performed * Manual tests
2020-12-03 18:15:31 +02:00
<data name="ToggleCommandPaletteCommandLineModeCommandKey" xml:space="preserve">
<value>Toggle command palette in command line mode</value>
</data>
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 09:56:59 -07:00
<data name="ToggleFocusModeCommandKey" xml:space="preserve">
<value>Toggle focus mode</value>
<comment>"Focus mode" is a mode with minimal UI elements, for a distraction-free experience</comment>
</data>
Persist Runtime TabTitle and Maximize/Focus/Fullscreen states (#12073) This commit adds additional information to the persisted window layouts. - Runtime tab titles - Focus, Maximized, and Fullscreen modes. Also, - Adds actions for Set{Focus,FullScreen} that take a boolean to work in addition to the current Toggle{Focus, Fullscreen} actions. - Adds SetMaximized that takes a boolean. This adds the capability to maximize (resp restore) a window using standard terminal actions. This also involves hooking up a good amount of state tracking between the terminal page and the window to see when maximize state has changed so that it can be persisted. - These actions are not added to the default settings, but they could be. The intention is that they could assist with automation (and was originally) how I planned on persisting the state instead of augmenting the LaunchMode. - The fullscreen/maximized saving isn't perfect because we don't have a way to save the non-maximized/fullscreen size, so exiting the modes won't restore whatever the previous size was. References #9800 Closes #11878 Closes #11426
2022-01-10 11:21:05 -05:00
<data name="EnableFocusModeCommandKey" xml:space="preserve">
<value>Enable focus mode</value>
</data>
<data name="DisableFocusModeCommandKey" xml:space="preserve">
<value>Disable focus mode</value>
</data>
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 09:56:59 -07:00
<data name="ToggleFullscreenCommandKey" xml:space="preserve">
<value>Toggle fullscreen</value>
</data>
Persist Runtime TabTitle and Maximize/Focus/Fullscreen states (#12073) This commit adds additional information to the persisted window layouts. - Runtime tab titles - Focus, Maximized, and Fullscreen modes. Also, - Adds actions for Set{Focus,FullScreen} that take a boolean to work in addition to the current Toggle{Focus, Fullscreen} actions. - Adds SetMaximized that takes a boolean. This adds the capability to maximize (resp restore) a window using standard terminal actions. This also involves hooking up a good amount of state tracking between the terminal page and the window to see when maximize state has changed so that it can be persisted. - These actions are not added to the default settings, but they could be. The intention is that they could assist with automation (and was originally) how I planned on persisting the state instead of augmenting the LaunchMode. - The fullscreen/maximized saving isn't perfect because we don't have a way to save the non-maximized/fullscreen size, so exiting the modes won't restore whatever the previous size was. References #9800 Closes #11878 Closes #11426
2022-01-10 11:21:05 -05:00
<data name="EnableFullScreenCommandKey" xml:space="preserve">
<value>Enable fullscreen</value>
</data>
<data name="DisableFullScreenCommandKey" xml:space="preserve">
<value>Disable fullscreen</value>
</data>
<data name="EnableMaximizedCommandKey" xml:space="preserve">
<value>Maximize window</value>
</data>
<data name="DisableMaximizedCommandKey" xml:space="preserve">
<value>Restore maximized window</value>
</data>
Add the ability to toggle a pane's split direction (#10713) <!-- 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 Add the ability to toggle a pane's split direction - Switch from horizontal to vertical split (and vice versa) - Propogate new borders through to children. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #10665 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #10665 * [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. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Ran terminal, created multiple panes in different orientations, ran command through command palate and verified that they displayed properly in the new orientation.
2021-08-02 17:04:57 -04:00
<data name="ToggleSplitOrientationCommandKey" xml:space="preserve">
<value>Toggle pane split orientation</value>
</data>
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 09:56:59 -07:00
<data name="TogglePaneZoomCommandKey" xml:space="preserve">
<value>Toggle pane zoom</value>
</data>
Introduce read-only panes (#8867) ## Summary of the Pull Request Introduces read-only panes. When pane is marked as read-only: 1. Attempt to provide user input results in a warning 2. Attempt to close pane - shows dialog 3. Attempt to close hosting tab shows dialog 4. The hosting tab has no close button ## PR Checklist * [x] Closes #6981 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated - not yet. * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments 1. The readonly logic implemented in `TermControl` (and prevents any send input) 2. Special handling is required to allow key-bindings 3. The "close-readonly" protections are in TerminalPage. 4. The indication that the pane is readonly is done using lock glyph 5. The indication that the tab contains readonly pane is done by hiding the close button of the tab 6. The readonly mode is enabled by keyboard shortcut (the followup might add this to the context menu) ## Validation Steps Performed
2021-02-08 20:03:55 +02:00
<data name="TogglePaneReadOnlyCommandKey" xml:space="preserve">
<value>Toggle pane read-only mode</value>
</data>
Add options to enable and disable read only mode (#14995) ## Summary of the Pull Request PR adds functionality to enable or disable readOnly mode within panes. This functionality is different to toggling as if you call the same functionality twice, it will not toggle between states. ## References and Relevant Issues - Closes https://github.com/microsoft/terminal/issues/14415 - Documentation https://github.com/MicrosoftDocs/terminal/pull/645 ## Validation Steps Performed - Checked readOnly is enabled when command triggered - Checked readOnly is enabled when command triggered while read only already enabled - Checked readOnly is disabled when command triggered while read only is enabled - Checked readOnly stays disabled when command triggered while read only is disabled - Checked above with multiple tabs and split panes ## PR Checklist - [ ] Closes #14415 - [X] 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: https://github.com/MicrosoftDocs/terminal/pull/645 - [X] Schema updated (if necessary) --------- Co-authored-by: Mike Griese <migrie@microsoft.com>
2023-03-22 17:32:56 +00:00
<data name="EnablePaneReadOnlyCommandKey" xml:space="preserve">
<value>Enable pane read-only mode</value>
</data>
<data name="DisablePaneReadOnlyCommandKey" xml:space="preserve">
<value>Disable pane read-only mode</value>
</data>
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 14:40:22 -06:00
<data name="ToggleShaderEffectsCommandKey" xml:space="preserve">
<value>Toggle terminal visual effects</value>
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 09:56:59 -07:00
</data>
Add a keybinding to break straight into the debugger (#8498) Have you ever wanted to debug the Terminal, but weren't sure which of your Terminal windows was the one you needed to attach to? Now you don't need to worry! Simply execute the `breakIntoDebugger` action, and the Terminal will `DebugBreak()` for you! This requires that the user has set `"debugFeatures": true` Validated by adding a command: { "command": "breakIntoDebugger", "keys": "ctrl+alt+shift+f1", "name": "DebugBreak()" }, ...and verifying that it pops open the post-mortem debugger (windbg).
2020-12-04 17:54:59 -06:00
<data name="BreakIntoDebuggerCommandKey" xml:space="preserve">
<value>Break into the debugger</value>
</data>
Polish OpenSettings action for Settings UI and Profile page navigation on refresh (#8670) Performs a number of minor bugfixes related to the Settings UI: - b5370a1 Dropdown bug: - the dropdown would display the keybinding for the first `openSettings` found. So it would accidentally present and bind the one for the Settings UI. - 91eb49e autogenerated name for opening Settings UI: - the Settings UI keybinding would display "open settings file". This was updated to say "Open Settings UI". - 1cadbf4 Profile Page navigation crash: - the selected item off of a MUX navigation view returns a MUX NavViewItem (as opposed to WUX) - dd2f3e5 Hookup delete for Profile page navigation: - missed a spot where we were manually navigating to the Profile page. So it wasn't hooked up properly - 9fea6de Properly cast NavViewItem tags - When we update the NavigationView's menu items, we were casting the tags to `Model::Profile` instead of `Editor::ProfileViewModel`. ## References #6800 - Settings UI epic Fixes the following bug: > - [ ] JSON change --> crash > - open SUI --> open JSON --> edit retro effects in JSON --> save file --> cry because the app crashed ## Additional comments This was a part of some manual testing I performed on the Settings UI. More intricate bugs are being reported on #6800 and will be fixed in their own PR.
2021-01-04 16:14:51 -06:00
<data name="OpenSettingsUICommandKey" xml:space="preserve">
Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse (#16886) I changed the improper capitalization and misuse of ellipses mark (...) in the context menu and various other places. Fixes issues #16819 and #16846 ## PR Checklist - [ ] Closes #16846 - [x] Tests added/passed - NA - [x] Documentation updated - NA - If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx - [x] Schema updated (if necessary) - NA
2024-04-10 05:41:43 +05:30
<value>Open settings</value>
Polish OpenSettings action for Settings UI and Profile page navigation on refresh (#8670) Performs a number of minor bugfixes related to the Settings UI: - b5370a1 Dropdown bug: - the dropdown would display the keybinding for the first `openSettings` found. So it would accidentally present and bind the one for the Settings UI. - 91eb49e autogenerated name for opening Settings UI: - the Settings UI keybinding would display "open settings file". This was updated to say "Open Settings UI". - 1cadbf4 Profile Page navigation crash: - the selected item off of a MUX navigation view returns a MUX NavViewItem (as opposed to WUX) - dd2f3e5 Hookup delete for Profile page navigation: - missed a spot where we were manually navigating to the Profile page. So it wasn't hooked up properly - 9fea6de Properly cast NavViewItem tags - When we update the NavigationView's menu items, we were casting the tags to `Model::Profile` instead of `Editor::ProfileViewModel`. ## References #6800 - Settings UI epic Fixes the following bug: > - [ ] JSON change --> crash > - open SUI --> open JSON --> edit retro effects in JSON --> save file --> cry because the app crashed ## Additional comments This was a part of some manual testing I performed on the Settings UI. More intricate bugs are being reported on #6800 and will be fixed in their own PR.
2021-01-04 16:14:51 -06:00
</data>
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 11:00:04 -05:00
<data name="RenameWindowCommandKey" xml:space="preserve">
<value>Rename window to "{0}"</value>
<comment>{0} will be replaced with a user-defined string</comment>
</data>
<data name="ResetWindowNameCommandKey" xml:space="preserve">
<value>Reset window name</value>
</data>
Add support for "workspaces" based on window names (redux) (#20314) This adds a new feature to the Windows Terminal: "Workspaces" Workspaces are very shamelessly inspired by Edge workspaces of the same name. The core idea is that when users name a window and they close that window, we will persist that Windows layout and buffers, seperately from the rest of window restoration. So a user can open a named window, open some profiles, some panes, do some stuff in it, then close it, and we will keep that state around for the next time the user opens that window name. Unnamed windows still behave the same. If you close an unnamed window, and it's not the last window, then we won't persist the state of it. To facilitate restoring named windows, we add a `openWorkspace` action. This allows us to persist the open workspace action in the window layout restoration path. So when we deserialize the list of tab layouts, and open workspace action will tell us, hey, go retrieve this known workspace from the state.json, instead of trying to serialize the window state in two places. As demoed in the video, we add a flyout to list the windows that the user has open, and the named workspaces that they have saved. This allows users to quickly reopen previously closed workspaces, as well as quickly rename a window, thereby adding it to the list of saved workspaces. This button can also be hidden using the theme settings. Closes #17084 (this is a reboot of #20162, but with the event from #20311)
2026-06-16 16:59:17 -05:00
<data name="OpenWorkspaceCommandKey" xml:space="preserve">
<value>Open workspace "{0}"</value>
<comment>{0} will be replaced with the workspace name</comment>
</data>
<data name="OpenWorkspaceDefaultCommandKey" xml:space="preserve">
<value>Open workspace</value>
</data>
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 11:00:04 -05:00
<data name="OpenWindowRenamerCommandKey" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Rename window...</value>
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 11:00:04 -05:00
</data>
Add an action to display toast with the CWD of the Terminal (#15282) Adds an action to display a toast containing the Terminal's "virtual" CWD. As described in https://github.com/microsoft/terminal/issues/4637#issuecomment-1531979200. Useful for debugging #5506 et. al. I almost left it as a debug-only feature, but figured it would be helpful for others in the #4637 landscape of things.
2023-07-20 11:09:21 -05:00
<data name="DisplayWorkingDirectoryCommandKey" xml:space="preserve">
<value>Display Terminal's current working directory</value>
</data>
Add `globalSummon` action (#9854) Adds support for two new actions: * `globalSummon`, which can be used to activate a window using a _global_ (READ: OS-level) hotkey. - accepts an optional `name` argument. When provided, this will attempt to summon with the given name. When omitted, we'll try to summon the most recent window. * `quakeMode` which is `globalSummon` for the `_quake` window. These actions are stored in the actions array, but are read by the `WindowsTerminal` level and bound to the OS in `IslandWindow`. The monarch registers for these keybindings with the OS. When one is pressed, the monarch will recieve a `WM_HOTKEY` message. It'll use that to look up the corresponding action args. It'll use those to try and summon the right window. ## References * #8888: Quake mode megathread * #9274: Spec (**guys seriously i just need one more ✔️**) * #9785: The start of granting "\_quake" super powers ## PR Checklist * [x] Closes #653 - I'm gonna say this closes it for now, though we have _many_ follow-ups in #8888 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Validated that it works with `win` keys * Validated that it works without `win` keys * Validated that it hot-reloads * Validated that it moves to the new monarch * Validated that you can bind both `globalSummon` and `quakeMode` at the same time and do different things * Validated that you can bind `globalSummon` with a name and it creates that name if it doesn't already exist
2021-04-28 17:13:28 -05:00
<data name="GlobalSummonCommandKey" xml:space="preserve">
Replace Summon with Show/Hide for improved i18n (#12603) "Summon" was translated as a synonym for "citation" in Spanish instead of treating it as a RPG-related word. "Show/Hide" will hopefully allow an improved automatic translation in the future. Closes #10691
2022-03-04 19:39:58 +01:00
<value>Show/Hide the Terminal window</value>
Add `globalSummon` action (#9854) Adds support for two new actions: * `globalSummon`, which can be used to activate a window using a _global_ (READ: OS-level) hotkey. - accepts an optional `name` argument. When provided, this will attempt to summon with the given name. When omitted, we'll try to summon the most recent window. * `quakeMode` which is `globalSummon` for the `_quake` window. These actions are stored in the actions array, but are read by the `WindowsTerminal` level and bound to the OS in `IslandWindow`. The monarch registers for these keybindings with the OS. When one is pressed, the monarch will recieve a `WM_HOTKEY` message. It'll use that to look up the corresponding action args. It'll use those to try and summon the right window. ## References * #8888: Quake mode megathread * #9274: Spec (**guys seriously i just need one more ✔️**) * #9785: The start of granting "\_quake" super powers ## PR Checklist * [x] Closes #653 - I'm gonna say this closes it for now, though we have _many_ follow-ups in #8888 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Validated that it works with `win` keys * Validated that it works without `win` keys * Validated that it hot-reloads * Validated that it moves to the new monarch * Validated that you can bind both `globalSummon` and `quakeMode` at the same time and do different things * Validated that you can bind `globalSummon` with a name and it creates that name if it doesn't already exist
2021-04-28 17:13:28 -05:00
</data>
<data name="QuakeModeCommandKey" xml:space="preserve">
Replace Summon with Show/Hide for improved i18n (#12603) "Summon" was translated as a synonym for "citation" in Spanish instead of treating it as a RPG-related word. "Show/Hide" will hopefully allow an improved automatic translation in the future. Closes #10691
2022-03-04 19:39:58 +01:00
<value>Show/Hide Quake window</value>
<comment>Quake is a well-known computer game and isn't related to earthquakes, etc. See https://en.wikipedia.org/wiki/Quake_(video_game)</comment>
Add `globalSummon` action (#9854) Adds support for two new actions: * `globalSummon`, which can be used to activate a window using a _global_ (READ: OS-level) hotkey. - accepts an optional `name` argument. When provided, this will attempt to summon with the given name. When omitted, we'll try to summon the most recent window. * `quakeMode` which is `globalSummon` for the `_quake` window. These actions are stored in the actions array, but are read by the `WindowsTerminal` level and bound to the OS in `IslandWindow`. The monarch registers for these keybindings with the OS. When one is pressed, the monarch will recieve a `WM_HOTKEY` message. It'll use that to look up the corresponding action args. It'll use those to try and summon the right window. ## References * #8888: Quake mode megathread * #9274: Spec (**guys seriously i just need one more ✔️**) * #9785: The start of granting "\_quake" super powers ## PR Checklist * [x] Closes #653 - I'm gonna say this closes it for now, though we have _many_ follow-ups in #8888 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Validated that it works with `win` keys * Validated that it works without `win` keys * Validated that it hot-reloads * Validated that it moves to the new monarch * Validated that you can bind both `globalSummon` and `quakeMode` at the same time and do different things * Validated that you can bind `globalSummon` with a name and it creates that name if it doesn't already exist
2021-04-28 17:13:28 -05:00
</data>
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
2021-05-21 16:55:57 -05:00
<data name="FocusPaneCommandKey" xml:space="preserve">
<value>Focus pane {0}</value>
<comment>{0} will be replaced with a user-specified number</comment>
</data>
Add an `exportBuffer` action (#12097) This adds an action for the context menu entry we added in #11062. That PR added support for exporting the buffer, exclusively through the tab item's context menu. This adds an action that can additionally be bound, which also can export the buffer to a file. This action accepts a `path` param. If empty/ommitted, then the Terminal will prompt for the file to export the buffer to. * Does a part of #9700 * Spec in #11090, but I doubt this is contentious * [x] This will satisfy #12052 * [x] I work here * [x] docs added: https://github.com/MicrosoftDocs/terminal/pull/479
2022-01-12 10:58:38 -06:00
<data name="ExportBufferToPathCommandKey" xml:space="preserve">
<value>Export text to {0}</value>
<comment>{0} will be replaced with a user-specified file path</comment>
</data>
<data name="ExportBufferCommandKey" xml:space="preserve">
<value>Export text</value>
</data>
Implement and action for manually clearing the Terminal (and conpty) buffer (#10906) ## Summary of the Pull Request ![clear-buffer-000](https://user-images.githubusercontent.com/18356694/127570078-90c6089e-0430-4dfc-bcd4-a0cde20c9167.gif) This adds a new action, `clearBuffer`. It accepts 3 values for the `clear` type: * `"clear": "screen"`: Clear the terminal viewport content. Leaves the scrollback untouched. Moves the cursor row to the top of the viewport (unmodified). * `"clear": "scrollback"`: Clear the scrollback. Leaves the viewport untouched. * `"clear": "all"`: (**default**) Clear the scrollback and the visible viewport. Moves the cursor row to the top of the viewport (unmodified). "Clear Buffer" has also been added to `defaults.json`. ## References * From microsoft/vscode#75141 originally ## PR Checklist * [x] Closes #1193 * [x] Closes #1882 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This is a bit tricky, because we need to plumb it all the way through conpty to clear the buffer. If we don't, then conpty will immediately just redraw the screen. So this sends a signal to the attached conpty, and then waits for conpty to draw the updated, cleared, screen back to us. ## Validation Steps Performed * works for each of the three clear types as expected * tests pass. * works even with `ping -t 8.8.8.8` as you'd hope.
2021-09-02 09:59:42 -05:00
<data name="ClearAllCommandKey" xml:space="preserve">
Minor typos in 1.12 features in SUI (#11362) * [x] Fixes a bunch of the checkboxes in #11352 * [x] Fixes one of the boxes in #11353 * [x] The opacity warning -> error gibberish was fixed with the change to `DeserializationError` - `asCString` only works if the `JsonValue` is a string already.
2021-09-29 05:24:46 -05:00
<value>Clear buffer</value>
Implement and action for manually clearing the Terminal (and conpty) buffer (#10906) ## Summary of the Pull Request ![clear-buffer-000](https://user-images.githubusercontent.com/18356694/127570078-90c6089e-0430-4dfc-bcd4-a0cde20c9167.gif) This adds a new action, `clearBuffer`. It accepts 3 values for the `clear` type: * `"clear": "screen"`: Clear the terminal viewport content. Leaves the scrollback untouched. Moves the cursor row to the top of the viewport (unmodified). * `"clear": "scrollback"`: Clear the scrollback. Leaves the viewport untouched. * `"clear": "all"`: (**default**) Clear the scrollback and the visible viewport. Moves the cursor row to the top of the viewport (unmodified). "Clear Buffer" has also been added to `defaults.json`. ## References * From microsoft/vscode#75141 originally ## PR Checklist * [x] Closes #1193 * [x] Closes #1882 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This is a bit tricky, because we need to plumb it all the way through conpty to clear the buffer. If we don't, then conpty will immediately just redraw the screen. So this sends a signal to the attached conpty, and then waits for conpty to draw the updated, cleared, screen back to us. ## Validation Steps Performed * works for each of the three clear types as expected * tests pass. * works even with `ping -t 8.8.8.8` as you'd hope.
2021-09-02 09:59:42 -05:00
<comment>A command to clear the entirety of the Terminal output buffer</comment>
</data>
<data name="ClearViewportCommandKey" xml:space="preserve">
Minor typos in 1.12 features in SUI (#11362) * [x] Fixes a bunch of the checkboxes in #11352 * [x] Fixes one of the boxes in #11353 * [x] The opacity warning -> error gibberish was fixed with the change to `DeserializationError` - `asCString` only works if the `JsonValue` is a string already.
2021-09-29 05:24:46 -05:00
<value>Clear viewport</value>
Implement and action for manually clearing the Terminal (and conpty) buffer (#10906) ## Summary of the Pull Request ![clear-buffer-000](https://user-images.githubusercontent.com/18356694/127570078-90c6089e-0430-4dfc-bcd4-a0cde20c9167.gif) This adds a new action, `clearBuffer`. It accepts 3 values for the `clear` type: * `"clear": "screen"`: Clear the terminal viewport content. Leaves the scrollback untouched. Moves the cursor row to the top of the viewport (unmodified). * `"clear": "scrollback"`: Clear the scrollback. Leaves the viewport untouched. * `"clear": "all"`: (**default**) Clear the scrollback and the visible viewport. Moves the cursor row to the top of the viewport (unmodified). "Clear Buffer" has also been added to `defaults.json`. ## References * From microsoft/vscode#75141 originally ## PR Checklist * [x] Closes #1193 * [x] Closes #1882 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This is a bit tricky, because we need to plumb it all the way through conpty to clear the buffer. If we don't, then conpty will immediately just redraw the screen. So this sends a signal to the attached conpty, and then waits for conpty to draw the updated, cleared, screen back to us. ## Validation Steps Performed * works for each of the three clear types as expected * tests pass. * works even with `ping -t 8.8.8.8` as you'd hope.
2021-09-02 09:59:42 -05:00
<comment>A command to clear the active viewport of the Terminal</comment>
</data>
<data name="ClearScrollbackCommandKey" xml:space="preserve">
Minor typos in 1.12 features in SUI (#11362) * [x] Fixes a bunch of the checkboxes in #11352 * [x] Fixes one of the boxes in #11353 * [x] The opacity warning -> error gibberish was fixed with the change to `DeserializationError` - `asCString` only works if the `JsonValue` is a string already.
2021-09-29 05:24:46 -05:00
<value>Clear scrollback</value>
Implement and action for manually clearing the Terminal (and conpty) buffer (#10906) ## Summary of the Pull Request ![clear-buffer-000](https://user-images.githubusercontent.com/18356694/127570078-90c6089e-0430-4dfc-bcd4-a0cde20c9167.gif) This adds a new action, `clearBuffer`. It accepts 3 values for the `clear` type: * `"clear": "screen"`: Clear the terminal viewport content. Leaves the scrollback untouched. Moves the cursor row to the top of the viewport (unmodified). * `"clear": "scrollback"`: Clear the scrollback. Leaves the viewport untouched. * `"clear": "all"`: (**default**) Clear the scrollback and the visible viewport. Moves the cursor row to the top of the viewport (unmodified). "Clear Buffer" has also been added to `defaults.json`. ## References * From microsoft/vscode#75141 originally ## PR Checklist * [x] Closes #1193 * [x] Closes #1882 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This is a bit tricky, because we need to plumb it all the way through conpty to clear the buffer. If we don't, then conpty will immediately just redraw the screen. So this sends a signal to the attached conpty, and then waits for conpty to draw the updated, cleared, screen back to us. ## Validation Steps Performed * works for each of the three clear types as expected * tests pass. * works even with `ping -t 8.8.8.8` as you'd hope.
2021-09-02 09:59:42 -05:00
<comment>A command to clear the part of the buffer above the viewport</comment>
</data>
Use feature markers during terminal-by-default handoff (#13160) If we want to make Windows Terminal the default terminal under Windows, we'll have to make conhost "handoff" incoming connections by default. But this poses a problem: How can the seldomly updated conhost know whether the routinely updated Windows Terminal version is actually willing to accept such handoffs by default (it might be unwilling due to bugs, etc.)? This commit solves the issue by introducing: * A marker interface (`IDefaultTerminalMarker`): If it exists, Windows Terminal indicates its willingness to accept the handoff. * Turning the all-0 GUID from being synonymous for conhost, to being synonymous for "Let Windows decide". Without this we wouldn't be able to differentiate between users who consciously chose conhost as their default terminal, vs. users who want the standard behavior. ## Validation Steps Performed Testing fallback behavior: * Install "Terminal" 1.13 * Delete the 2 keys below `HKCU\Console\%%Startup` * Enable `Feature_AttemptHandoff` in `features.xml` Return `true` from `DefaultApp::CheckShouldTerminalBeDefault` * Replace `conhost.exe` and `console.dll` with `sfpcopy` after building * Launching `cmd.exe` launches as a conhost window ✅ (because "Terminal" 1.13 lacks the marker interface) * Open properties page in `conhost.exe` "Let Windows decide" is select by default ✅ * Changing the selection writes the new value ✅ Testing the new behavior: * Delete the 2 keys below `HKCU\Console\%%Startup` * Enable `Feature_AttemptHandoff` in `features.xml` Return `true` from `DefaultApp::CheckShouldTerminalBeDefault` * Use `CLSID_WindowsTerminalConsoleDev` and `CLSID_WindowsTerminalTerminalDev` for the initialization of `TerminalDelegationPair` * Replace `conhost.exe` and `console.dll` with `sfpcopy` after building * Deploy the "Terminal Dev" package * Launching `cmd.exe` launches "Terminal Dev" ✅ (because "Terminal Dev" has the marker interface) * Open the settings tab "Let Windows decide" is select by default ✅ * Changing the selection and saving writes the new value ✅
2022-06-07 21:31:02 +02:00
<data name="DefaultWindowsConsoleName" xml:space="preserve">
<value>Let Windows decide</value>
<comment>This is the default option if a user doesn't choose to override Microsoft's choice of a Terminal.</comment>
</data>
Implement UI for choosing default terminal inside Settings page (#9907) Implement dropdown menu for choosing a default terminal application from inside the Windows Terminal Settings UI ## PR Checklist * [x] Closes #9463 * [x] I work here. * [x] Manual tests passed * [x] https://github.com/MicrosoftDocs/terminal/issues/314 (and cross reference #9462) ## Detailed Description of the Pull Request / Additional comments - Adds dropdown menu and a template card for displaying the available default applications (using the same lookup code as the console property sheet `console.dll`) - Adds model to TSM for adapting the data for display and binding on XAML - Lookup occurs on every page reload. Persistence only happens on Save Changes. - Manifest changed for Terminal to add capability to opt-out of registry redirection so we can edit this setting ## Validation Steps Performed - [x] Flipped the menu and pressed Save Changes and launched cmd from run box... it moved between the two. - [x] Flipped system theme from light to dark and ensured secondary color looked good - [x] Flipped the status with a different mechanism (conhost propsheet) and then reopened settings page and confirmed it loaded the updated status
2021-04-28 03:43:30 -07:00
<data name="InboxWindowsConsoleAuthor" xml:space="preserve">
<value>Microsoft Corporation</value>
<comment>Paired with `InboxWindowsConsoleName`, this is the application author... which is us: Microsoft.</comment>
</data>
<data name="InboxWindowsConsoleName" xml:space="preserve">
<value>Windows Console Host</value>
<comment>Name describing the usage of the classic windows console as the terminal UI. (`conhost.exe`)</comment>
</data>
Add the ability to quit all terminal instances (#11143) Add the ability to quit all terminal instances. Doing this separately from the window layout saving ones to lessen the number of 1k+ line monsters I make y'all review. ## References #11083 ## PR Checklist * [x] Closes #11081 * [ ] 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. ## Detailed Description of the Pull Request / Additional comments - Warn the user before they do so to give a chance to cancel - Percolate a QuitAll event up to the monarch who then directs each peasant to clsoe. - Leave a window-layout-saving-sized hole to add that feature on top ## Validation Steps Performed - quit with one window (from the monarch) - quit from the monarch with multiple windows - quit from a peasant - cancel the quit dialog ![image](https://user-images.githubusercontent.com/6185249/132105775-3310f614-ce55-4454-9718-ef5c0d39fbd2.png)
2021-09-09 10:03:03 -04:00
<data name="QuitCommandKey" xml:space="preserve">
<value>Quit the Terminal</value>
</data>
Add `adjustOpacity` action (#12092) Adds an action which can be used to change the opacity at runtime. This is a follow up to some of the other work I had been doing around opacity and settings previewing at the end of the year. > edit: pseudo-spec > > * `adjustOpacity`: > * `"opacity"`: (**required**) an integer number to set the opacity to. > * `"relative"`: (defaults to `true`) > * If false, set the opacity to the given value, which should be between [0, 100]. > * If true, then use `opacity` as a relative adjustment to the current opacity. So the implementation would get the current opacity for this pane, then add this action's opacity to that value. Should be between [-100, 100] > > This would allow both setting exactly 25% opacity with an action, and binding an action that increases/decreases the opacity one {amount} It's preview-able too, which is neat. ![adjust-opacity-preview-001](https://user-images.githubusercontent.com/18356694/140785805-5eecf6ec-0933-40e4-bcba-41b88d25b6a8.gif) * [x] Closes #11205 * [x] I work here * [x] Docs updated: https://github.com/MicrosoftDocs/terminal/pull/477
2022-01-12 13:06:31 -06:00
<data name="SetOpacityParentCommandName" xml:space="preserve">
Add ellipses back in to some command names (#17715) In #16886, the key for the nested action got renamed from `Split Pane...` to `Split pane`. This accidentally caused a collision because now there's two actions with the same name! The settings model then prefers the user's action over the one defined in defaults.json, thus completely hiding the nested version. I tried to balance the stylistic recommendations from #16846 (mainly [this comment](https://github.com/microsoft/terminal/issues/16846#issuecomment-2005007519) since it gave some excellent examples) while trying to maintain muscle memory as much as possible (with similar substring sequences). There was also one case where we still used "the tab" so I removed the "the" for consistency. Side effect of #16886 which closed #16846 Closes #17294 Closes #17684
2024-08-21 11:13:39 -07:00
<value>Set background opacity...</value>
Add `adjustOpacity` action (#12092) Adds an action which can be used to change the opacity at runtime. This is a follow up to some of the other work I had been doing around opacity and settings previewing at the end of the year. > edit: pseudo-spec > > * `adjustOpacity`: > * `"opacity"`: (**required**) an integer number to set the opacity to. > * `"relative"`: (defaults to `true`) > * If false, set the opacity to the given value, which should be between [0, 100]. > * If true, then use `opacity` as a relative adjustment to the current opacity. So the implementation would get the current opacity for this pane, then add this action's opacity to that value. Should be between [-100, 100] > > This would allow both setting exactly 25% opacity with an action, and binding an action that increases/decreases the opacity one {amount} It's preview-able too, which is neat. ![adjust-opacity-preview-001](https://user-images.githubusercontent.com/18356694/140785805-5eecf6ec-0933-40e4-bcba-41b88d25b6a8.gif) * [x] Closes #11205 * [x] I work here * [x] Docs updated: https://github.com/MicrosoftDocs/terminal/pull/477
2022-01-12 13:06:31 -06:00
</data>
<data name="IncreaseOpacityCommandKey" xml:space="preserve">
<value>Increase background opacity by {0}%</value>
<comment>A command to change how transparent the background of the window is</comment>
</data>
<data name="DecreaseOpacityCommandKey" xml:space="preserve">
<value>Decrease background opacity by {0}%</value>
<comment>A command to change how transparent the background of the window is</comment>
</data>
<data name="AdjustOpacityCommandKey" xml:space="preserve">
<value>Set background opacity to {0}%</value>
<comment>A command to change how transparent the background of the window is</comment>
</data>
Add restore recently closed panes (#11471) <!-- 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 Add an action to restore the last closed pane or tab. When all you have is restoring last sessions everything looks like a `std::vector<ActionAndArgs>`. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #9800 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Partially closes #960 * [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. * [ ] 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 - Keep a buffer of panes/tabs that were closed recently in the form of a list of actions to remake it. - To restore the pane or tab just run the list of actions. - This (deliberately) does not restore the exact visual state as focus could have changed / new panes might have been created in the mean time. Mostly this means that restoring a pane will just attach to the currently focused pane instead of whatever its old neighbor was. - Buffer is limited to 100 entries which might as well be "infinite" by most reasonable standards, but prevents complaints about there being memory leaks in long running instances. - The action name could be potentially changed, but it felt unwieldy as "restoreLastClosedPaneOrTab". - This does not handle restoring the actual running contents of a pane. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2022-01-11 15:08:15 -05:00
<data name="RestoreLastClosedCommandKey" xml:space="preserve">
<value>Restore the last closed pane or tab</value>
</data>
Add ability to select all text in the buffer (#13045) Adds the `selectAll` action which can be used to select all text in the buffer (regardless of whether a selection is present). ## References #3663 - Mark Mode #4993 - [Scenario] Keyboard selection ## PR Checklist * [x] Closes #1469 * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments I've made it such that selecting the "entire buffer" really just selects up to the mutable viewport. This seems like a nice QOL improvement since there's generally nothing past that. When the user selects all, the viewport does not move. This is consistent with CMD behavior and is intended to allow the user to not lose context when selecting everything. A minor change had to be made to the DxRenderer because this uncovered an underflow issue. Basically, the selection rects were handed to the DxEngine relative to the viewport (which means that some had a negative y-value). At some point, those rects were stored into `size_t`s, resulting in an underflow issue. This caused the renderer to behave strangely when rendering the selection. Generally, these kinds of issues weren't really noticed because selection would always modify a portion of the viewport. Funny enough, in a way, this satisfies the "mark mode" scenario because the user now has a way to initiate a selection using only the keyboard. Though this isn't ideal, just a fun thing to point out (that's why I'm not closing the mark mode issue). ## Validation Steps Performed - Verified using DxEngine and AtlasEngine - select all --> keyboard selection --> start moving the top-left endpoint (and scroll to there) - select all --> do not scroll automatically
2022-05-06 13:06:49 -07:00
<data name="SelectAllCommandKey" xml:space="preserve">
<value>Select all text</value>
</data>
Introduce Mark Mode (#13053) ## Summary of the Pull Request Introduces a non-configurable version of mark mode to Windows Terminal. It has the following interactions defined: - <kbd>ctrl+shift+m</kbd> --> Enter Mark Mode - when in Mark Mode... - <kbd>ESC</kbd> --> Exit Mark Mode - arrow keys --> move "start" - <kbd>shift</kbd> + arrow keys --> anchor "start", move "end" - <kbd>ctrl+a</kbd> --> select all - when a selection is active... When in mark mode, the cursor does not blink. ## References #4993 - [Epic] Keyboard Selection ## PR Checklist * [X] Closes #715 * [X] Provides a resolution for #11985 ## Detailed Description of the Pull Request / Additional comments - `TermControl`: - `TermControl.cpp` just adds logic to prevent the cursor from blinking when in mark mode - `ControlCore` - in the same place we handle quick edit, we add an entry point to mark mode - `TerminalCore` - this leverages `UpdateSelection()` and other quick edit functions to make mark mode happen ## Validation Steps Performed - [x] Make selection, split pane, close pane - NOTE: A similar scenario caused a crash at one point. Really weird. Keep an eye on it. - [x] Cursor is off when in mark mode - [x] general movement/selection - [x] general movement/selection that forces the viewport to move - [x] In mark mode, selectAll... - [x] arrow keys --> move start - [x] shift + arrow keys --> move end - [x] (regardless of mark mode) if selection active, enter --> copy to clipboard
2022-05-20 16:04:53 -07:00
<data name="MarkModeCommandKey" xml:space="preserve">
<value>Toggle mark mode</value>
<comment>A command that will toggle "mark mode". This is a mode in the application where the user can mark the text by selecting portions of the text.</comment>
</data>
Introduce `toggleBlockSelection` action (#13219) ## Summary of the Pull Request This introduced the `toggleBlockSelection` action to allow users to create a block selection using only the keyboard. This is not bound to any keys by default, however it is added to the command palette. ## References #4993 - Epic #5804 - Spec ## Validation Steps Performed - [X] Mark mode always starts in line selection mode - [X] Mouse selections are always in line selection mode by default - [X] Can toggle block selection for an existing selection (regardless of how it was created) - [X] The selection is copied properly (aka, no rendering issues)
2022-06-07 03:55:17 -07:00
<data name="ToggleBlockSelectionCommandKey" xml:space="preserve">
<value>Toggle block selection</value>
</data>
Introduce `switchSelectionEndpoint` action (#13370) ## Summary of the Pull Request Introduces the `switchSelectionEndpoint` action which switches whichever selection endpoint is targeted when a selection is present. For example, if you are targeting "start", `switchSelectionEndpoint` makes it so that now you are targeting "end". This also updates the selection markers appropriately. ## References Spec - #5804 #13358 Closes #3663 ## Detailed Description of the Pull Request / Additional comments Most of the code is just standard code of adding a new action. Other than that, we have... - if there is no selection, the action fails and the keybinding is passed through (similar to `copy()`) - when we update the selection endpoint, we need to also update the "pivot". This ensures that future calls of `UpdateSelection()` respect this swap. - [Corner Case] if the cursor is being moved, we make it so that you basically "anchored" an endpoint and you don't have to hold shift anymore.
2022-06-30 18:44:39 -07:00
<data name="SwitchSelectionEndpointCommandKey" xml:space="preserve">
<value>Switch selection endpoint</value>
</data>
Implement EnableColorSelection (#13429) ## Summary of the Pull Request As described in #9583, this change implements the legacy conhost "EnableColorSelection" feature. ## Detailed Description of the Pull Request / Additional comments @zadjii-msft was super nice and provided the outline/plumbing (WinRT classes and such) as a hackathon-type project (thank you!)--a "SelectionColor" runtimeclass, a ColorSelection method on the ControlCore runtimeclass, associated plumbing through the layers; plus the action-and-args plumbing to allow hooking up a basic "ColorSelection" action, which allows you to put actions in your settings JSON like so: ```json { "command": { "action": "experimental.colorSelection", "foreground": "#0f3" }, "keys": "alt+4" }, ``` On top of that foundation, I added a couple of things: * The ability to specify indexes for colors, in addition to RGB and RRGGBB colors. - It's a bit hacky, because there are some conversions that fight against sneaking an "I'm an index" flag in the alpha channel. * A new "matchMode" parameter on the action, allowing you to say if you want to only color the current selection ("0") or all matches ("1"). - I made it an int, because I'd like to enable at least one other "match mode" later, but it requires me/someone to fix up search.cpp to handle regex first. - Search used an old UIA "ColorSelection" method which was previously `E_NOTIMPL`, but is now wired up. Don't know what/if anything else uses this. * An uber-toggle setting, "EnableColorSelection", which allows you to set a single `bool` in your settings JSON, to light up all the keybindings you would expect from the legacy "EnableColorSelection" feature: - alt+[0..9]: color foreground - alt+shift+[0..9]: color foreground, all matches - ctrl+[0..9]: color background - ctrl+shift+[0..9]: color background, all matches * A few of the actions cannot be properly invoked via their keybindings, due to #13124. `*!*` But they work if you do them from the command palette. * If you have "`EnableColorSelection : true`" in your settings JSON, but then specify a different action in your JSON that uses the same key binding as a color selection keybinding, your custom one wins, which I think is the right thing. * I fixed what I think was a bug in search.cpp, which also affected the legacy EnableColorSelection feature: due to a non-inclusive coordinate comparison, you were not allowed to color a single character; but I see no reason why that should be disallowed. Now you can make all your `X`s red if you like. "Soft" spots: * I was a bit surprised at some of the helpers I had to provide in textBuffer.cpp. Perhaps there are existing methods that I didn't find? * Localization? Because there are so many (40!) actions, I went to some trouble to try to provide nice command/arg descriptions. But I don't know how localization works… <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9583 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed *(what would be the right place to add tests for this?)* * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. *(is this needed?)* * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx ## Validation Steps Performed Just manual testing.
2022-08-31 16:54:29 -07:00
<data name="ColorSelection_allMatches" xml:space="preserve">
<value>all matches</value>
<comment>This is used in the description of an action which changes the color of selected text, to indicate that not only the selected text will be colored, but also all matching text.</comment>
</data>
<data name="ColorSelection_fg_action" xml:space="preserve">
<value>Color selection, foreground: {0}{1}</value>
<comment>This is the description of an action which changes the color of selected text. {0}: the color. {1}: empty string OR a clause indicating that all matching text will be colored (ColorSelection_allMatches).</comment>
</data>
<data name="ColorSelection_bg_action" xml:space="preserve">
<value>Color selection, background: {0}{1}</value>
<comment>This is the description of an action which changes the background color of selected text. {0}: the color. {1}: empty string OR a clause indicating that all matching text will be colored (ColorSelection_allMatches).</comment>
</data>
<data name="ColorSelection_fg_bg_action" xml:space="preserve">
<value>Color selection, foreground: {0}, background: {1}{2}</value>
<comment>This is the description of an action which changes the color of selected text and the background. {0}: the foreground color. {1}: the background color. {2}: empty string OR a clause indicating that all matching text will be colored (ColorSelection_allMatches).</comment>
</data>
<data name="ColorSelection_default_action" xml:space="preserve">
<value>Color selection, (default foreground/background){0}</value>
<comment>This is the description of an action which changes the color of selected text and the background to the default colors. {0}: empty string OR a clause indicating that all matching text will be colored (ColorSelection_allMatches).</comment>
</data>
<data name="ColorSelection_defaultColor" xml:space="preserve">
<value>[default]</value>
<comment>This is used in the description of an action which changes the color of selected text, as a placeholder for a color, to indicate that the default (foreground or background) color will be used.</comment>
</data>
<data name="ColorSelection_Black" xml:space="preserve">
<value>black</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Red" xml:space="preserve">
<value>red</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Green" xml:space="preserve">
<value>green</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Yellow" xml:space="preserve">
<value>yellow</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Blue" xml:space="preserve">
<value>blue</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Purple" xml:space="preserve">
<value>purple</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_Cyan" xml:space="preserve">
<value>cyan</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_White" xml:space="preserve">
<value>white</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightBlack" xml:space="preserve">
<value>bright black</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightRed" xml:space="preserve">
<value>bright red</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightGreen" xml:space="preserve">
<value>bright green</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightYellow" xml:space="preserve">
<value>bright yellow</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightBlue" xml:space="preserve">
<value>bright blue</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightPurple" xml:space="preserve">
<value>bright purple</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightCyan" xml:space="preserve">
<value>bright cyan</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
<data name="ColorSelection_BrightWhite" xml:space="preserve">
<value>bright white</value>
<comment>A color used in the "ColorSelection" action.</comment>
</data>
Introduce ExpandSelectionToWord action (#13765) ## Summary of the Pull Request Introduces a new action `expandSelectionToWord()` which expands the beginning and end of the selection to encompass the word(s) it's on. This was implemented as a conditional keybinding where the key chord is passed through to the terminal if no selection is active (similar to `copy()`). It is not bound to anything by default. ## PR Checklist * [x] Closes #8274 * [x] Schema updated. ## Validation Steps Performed - Scenario in #8274: - search for some text in the find dialog - ESC to close the dialog - execute `expandSelectionToWord()` - the new selection encompasses the whole word - mark mode - move onto a word - execute `expandSelectionToWord()` - mouse selection (same as above) - select a portion of two words --> new selection fully encompasses both words
2022-08-31 12:06:05 -07:00
<data name="ExpandSelectionToWordCommandKey" xml:space="preserve">
<value>Expand selection to word</value>
</data>
Add an action for manually invoking the control context menu (#15254) Adds ``` { "command": "showContextMenu", "keys": "menu" }, ``` as a default action. This will manually invoke the control context menu (from #14775), even with the setting disabled. As discussed with Dustin.
2023-05-10 22:32:27 -05:00
<data name="ShowContextMenuCommandKey" xml:space="preserve">
<value>Show context menu</value>
</data>
Add action for closing all unfocused panes (#13547) This PR introduces a new action for closing all unfocused / other panes within a tab. **Edit (17-08-2022):** Read-only panes are ignored when this action is being used (i.e., left open). ![gif](https://user-images.githubusercontent.com/27634653/180733229-0c8e6427-c586-4fe1-b6fd-a2b1c94734e5.gif) ## Validation Steps Performed The action was manually tested by applying it to various 'compositions' of panes. This includes tests on read-only panes. Closes #12216
2022-08-26 19:27:04 +02:00
<data name="CloseOtherPanesCommandKey" xml:space="preserve">
<value>Close all other panes</value>
</data>
Add support for broadcasting to all panes in a tab (#14393) Resurrection of #9222. Spec draft in #9365. Consensus from community feedback is that the whole of that spec is _nice to have_, but what REALLY matters is just broadcasting to all the panes in a tab. So, in the interest of best serving our community, I'm pushing this out as the initial implementation, before we figure out the rest of design. Regardless of how we choose to implement the rest of the features detailed in the spec, the UX for this part of the feature remains the same. This PR adds a new action: `toggleBroadcastInput`. Performing this action starts broadcasting to all panes in this tab. Keystrokes in one pane will be sent to all panes in the tab. An icon in the tab is used to indicate when this mode is active. Furthermore, the borders of all panes will be highlighted with `SystemAccentColorDark2`/`SystemAccentColorLight2` (depending on the theme), to indicate they're also active. * [x] Closes #2634. - (we should lick a reserved thread for follow-ups) Co-authored-by: Don-Vito khvitaly@gmail.com
2023-07-19 10:45:25 -05:00
<data name="ToggleBroadcastInputCommandKey" xml:space="preserve">
<value>Toggle broadcast input to all panes</value>
<comment>When enabled, input will go to all panes in this tab simultaneously</comment>
</data>
Add an action for immediately restarting a connection (#15241) Adds an action for immediately restarting the connection. I suspect most folks that wanted #3726 will be happy just with the <kbd>enter</kbd> solution from #14060, but this will work without having to `exit` the client. Just, relaunch whatever the commandline is. Easy peasy. Closes #3726. Obsoletes #14549
2023-04-28 17:50:12 -05:00
<data name="RestartConnectionKey" xml:space="preserve">
Tab menu: show "restart" + maintain items' enable state (#19972) ## Summary of the Pull Request Changes how/when we display the "restart connection" item in the tab's context menu. Now, we always display it, but it's disabled if we're not in a terminal tab. Applies similar enable/disable logic to the rest of the menu items. Previous to this, they just wouldn't do anything (which is fair, they didn't make any sense). ## Validation Steps Performed Check tab's menu in following scenarios: ✅ terminal pane ✅ settings tab ✅ snippets pane Closes #18891
2026-04-29 11:54:43 -07:00
<value>Restart session</value>
Add an action for immediately restarting a connection (#15241) Adds an action for immediately restarting the connection. I suspect most folks that wanted #3726 will be happy just with the <kbd>enter</kbd> solution from #14060, but this will work without having to `exit` the client. Just, relaunch whatever the commandline is. Easy peasy. Closes #3726. Obsoletes #14549
2023-04-28 17:50:12 -05:00
</data>
Add an experimental "scratchpad pane", for testing (#16171) ## Summary of the Pull Request Builds upon #16170. This PR simply adds a singly type of non-terminal pane - a "scratchpad pane". This is literally just a single text box, in a pane. It's on the `{ "command": "experimental.openScratchpad" }` action. ## References and Relevant Issues See: #997 ## Detailed Description of the Pull Request / Additional comments I also put it behind velocity so it won't even go into preview while this bakes. This is really just here to demonstrate that this works, and is viable. The next PR is much more interesting. ## Validation Steps Performed Screenshot below. ## other PRs * #16170 * #16171 <-- you are here * #16172
2024-03-26 10:56:31 -07:00
<data name="OpenScratchpadKey" xml:space="preserve">
<value>Open scratchpad</value>
</data>
Add the ability to select a whole command (or its output) (#14807) Adds two new commands, `selectOutput` and `selectCommand`. These don't do much without shell integration enabled, unfortunately. If you do enable it, however, you can use these commands to quickly navigate the history to select whole commands (or their output). Some sample JSON: ```json { "keys": "ctrl+shift+<", "command": { "action": "selectCommand", "direction": "prev" } }, { "keys": "ctrl+shift+>", "command": { "action": "selectCommand", "direction": "next" } }, { "keys": "ctrl+shift+[", "command": { "action": "selectOutput", "direction": "prev" } }, { "keys": "ctrl+shift+]", "command": { "action": "selectOutput", "direction": "next" } }, ``` **Demo gifs** in https://github.com/microsoft/terminal/issues/4588#issuecomment-1352042789 closes #4588 Tested manually. <details> <summary>CMD.exe user? It's dangerous to go alone! Take this.</summary> Surely, there's a simpler way to do it, this is adapted from my own script. ```cmd prompt $e]133;D$e\$e]133;A$e\$e\$e]9;9;$P$e\$e[30;107m[$T]$e[97;46m$g$P$e[36;49m$g$e[0m$e[K$_$e[0m$e[94m%username%$e[0m@$e[32m%computername%$e[0m$G$e]133;B$e\ ``` </details>
2023-04-20 07:34:58 -05:00
<data name="SelectOutputNextCommandKey" xml:space="preserve">
<value>Select next command output</value>
</data>
<data name="SelectOutputPreviousCommandKey" xml:space="preserve">
<value>Select previous command output</value>
</data>
<data name="SelectCommandNextCommandKey" xml:space="preserve">
<value>Select next command</value>
</data>
<data name="SelectCommandPreviousCommandKey" xml:space="preserve">
<value>Select previous command</value>
</data>
Add an action to search the web for selected text (#15539) This PR adds a `searchWeb` command to search the selected text on the web. Arguments: - `queryUrl`: URL of the web page to launch (the selected text will be inserted where the first `%s` is found in the query string) To make the search text more "compact" and handle multi-line selections, I'm concatenating the selected lines and replacing consecutive whitespaces with a single space (we may change this with something more clever in case). ## Validation Steps Performed Manual testing with single, multi-line, block selections. Closes #10175 --------- Co-authored-by: Marco Pelagatti <marco.pelagatti@iongroup.com> Co-authored-by: Mike Griese <migrie@microsoft.com>
2023-06-21 19:24:45 +02:00
<data name="SearchForTextCommandKey" xml:space="preserve">
<value>Search {0}</value>
<comment>{0} will be replaced with a user-specified URL to a web page</comment>
</data>
<data name="SearchWebCommandKey" xml:space="preserve">
<value>Search the web for selected text</value>
<comment>This will open a web browser to search for some user-selected text</comment>
</data>
Add an `openAbout` action. (#15990) Just as it says on the label. Closes #15986
2023-09-18 11:55:05 -05:00
<data name="OpenAboutCommandKey" xml:space="preserve">
<value>Open about dialog</value>
<comment>This will open the "about" dialog, to display version info and other documentation</comment>
</data>
Add ability to save input action from command line (#16513) Hi wanted to make an attempt at [12857](https://github.com/microsoft/terminal/issues/12857). This still needs work but I think the initial version is ready to be reviewed. ## Summary of the Pull Request Mostly copied from: https://github.com/microsoft/terminal/compare/6f5b9fb...1cde67ac466e19394eea1eb3a41405513d160a6f - Save to disk - If command line is empty use selection - Show toast - No UI. Trying out the different options now. ## PR Checklist - [ ] Closes #12857 - [ ] Tests added/passed - [ ] Documentation updated - If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx - [ ] Schema updated (if necessary) --------- Co-authored-by: Mike Griese <migrie@microsoft.com>
2024-07-02 07:27:20 -04:00
<data name="SaveSnippetNamePrefix" xml:space="preserve">
<value>Save Snippet</value>
</data>
Add action for Quick Fix and key binding for Suggestions (#17502) Adds a keybinding to open the quick fix menu, if one is available. When the action is used, we also open up the button (if it was collapsed) because that looks nice. The `showSuggestions` action is bound to `ctrl+shift+period` by default to align with VS' "quick actions" feature and VS Code's "quick fix" feature. This was chosen over binding to `quickFix` because it's more helpful. The quick fix button is a route for users that prefer to use the mouse. If users want to add a keybinding to activate the `quickFix` button, they can do that now. This PR also performs a bit of miscellaneous polish from the bug bash. This includes: - the suggestions UI now presents quick fixes first - scrolling may result in the button being drawn in the wrong place - The bug was tracked down this line: `TermControl::CursorPositionInDips()` --> `_core.CursorPosition()` --> `Terminal::GetViewportRelativeCursorPosition()`. The mutable viewport there does _not_ update when the user scrolls. Thus, the button would be drawn on the same position _on the screen_ even though we scrolled. To fix this, I include the `_scrollOffset` in the calculation. The only other place this function is used is with the suggestions UI, which does _not_ update the UIs position as we scroll (but if we're interested in doing that, we can now). Closes #17377
2024-07-17 15:28:30 -07:00
<data name="QuickFixCommandKey" xml:space="preserve">
<value>Open quick fix menu</value>
</data>
Open current working directory action. (#18013) ## Summary of the Pull Request Added open current directory action. ## References and Relevant Issues Need to set this: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed - Ensure shell has been configured - Run "Open current working directory" action in command palette - File explorer opens the correct directory ## PR Checklist - [x] Closes #12859 - [ ] Tests added/passed - [ ] Documentation updated - If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx - [ ] Schema updated (if necessary)
2024-12-05 07:18:45 -05:00
<data name="OpenCWDCommandKey" xml:space="preserve">
<value>Open current working directory</value>
</data>
Add support for "workspaces" based on window names (redux) (#20314) This adds a new feature to the Windows Terminal: "Workspaces" Workspaces are very shamelessly inspired by Edge workspaces of the same name. The core idea is that when users name a window and they close that window, we will persist that Windows layout and buffers, seperately from the rest of window restoration. So a user can open a named window, open some profiles, some panes, do some stuff in it, then close it, and we will keep that state around for the next time the user opens that window name. Unnamed windows still behave the same. If you close an unnamed window, and it's not the last window, then we won't persist the state of it. To facilitate restoring named windows, we add a `openWorkspace` action. This allows us to persist the open workspace action in the window layout restoration path. So when we deserialize the list of tab layouts, and open workspace action will tell us, hey, go retrieve this known workspace from the state.json, instead of trying to serialize the window state in two places. As demoed in the video, we add a flyout to list the windows that the user has open, and the named workspaces that they have saved. This allows users to quickly reopen previously closed workspaces, as well as quickly rename a window, thereby adding it to the list of saved workspaces. This button can also be hidden using the theme settings. Closes #17084 (this is a reboot of #20162, but with the event from #20311)
2026-06-16 16:59:17 -05:00
<data name="WorkspacesCommandKey" xml:space="preserve">
<value>Workspaces...</value>
</data>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
<data name="CloseTab" xml:space="preserve">
<value>Close tab</value>
</data>
<data name="SendInput" xml:space="preserve">
<value>Send input</value>
</data>
<data name="SetFocusMode" xml:space="preserve">
<value>Set focus mode</value>
</data>
<data name="SetFullScreen" xml:space="preserve">
<value>Set full screen</value>
</data>
<data name="SetMaximized" xml:space="preserve">
<value>Set maximized</value>
</data>
<data name="SetColorScheme" xml:space="preserve">
<value>Set color scheme</value>
</data>
<data name="CloseOtherTabs" xml:space="preserve">
<value>Close other tabs</value>
</data>
<data name="CloseTabsAfter" xml:space="preserve">
<value>Close tabs after</value>
</data>
<data name="MoveTab" xml:space="preserve">
<value>Move tab</value>
</data>
<data name="FindMatch" xml:space="preserve">
<value>Find match</value>
</data>
<data name="SearchForText" xml:space="preserve">
<value>Search for text</value>
</data>
<data name="FocusPane" xml:space="preserve">
<value>Focus pane</value>
</data>
<data name="ExportBuffer" xml:space="preserve">
<value>Export buffer</value>
</data>
<data name="ClearBuffer" xml:space="preserve">
<value>Clear buffer</value>
</data>
<data name="MultipleActions" xml:space="preserve">
<value>Multiple actions</value>
</data>
<data name="AdjustOpacity" xml:space="preserve">
<value>Adjust opacity</value>
</data>
<data name="SelectCommand" xml:space="preserve">
<value>Select command</value>
</data>
<data name="SelectOutput" xml:space="preserve">
<value>Select output</value>
</data>
<data name="Suggestions" xml:space="preserve">
<value>Suggestions</value>
</data>
<data name="ColorSelection" xml:space="preserve">
<value>Color selection</value>
</data>
Add an Extensions page to the Settings UI (#18559) This pull request adds an Extensions page to the Settings UI, which lets you enable/disable extensions and see how they affect your settings (i.e. adding/modifying profiles and adding color schemes). This page is specifically designed for fragment extensions and dynamic profile generators, but can be expanded on in the future as we develop a more advanced extensions model. App extensions extract the name and icon from the extension package and display it in the UI. Dynamic profile generators extract the name and icon from the generator and display it in the UI. We prefer to use the display name for breadcrumbs when possible. A "NEW" badge was added to the Extensions page's `NavigationViewItem` to highlight that it's new. It goes away once the user visits it. ## Detailed Description of the Pull Request / Additional comments - Settings Model changes: - `FragmentSettings` represents a parsed json fragment extension. - `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to track profiles and color schemes added/modified - `ExtensionPackage` bundles the `FragmentSettings` together. This is how we represent multiple JSON files in one extension. - `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon` - `ExtensionPackage`s created from app extensions extract the `DisplayName` and `Icon` from the extension - `ApplicationState` is used to track which badges have been dismissed and prevent them from appearing again - a `std::unordered_set` is used to keep track of the dismissed badges, but we only expose a get and append function via the IDL to interact with it - Editor changes - view models: - `ExtensionsViewModel` operates as the main view model for the page. - `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used to reference specific components of fragments. They also provide support for navigating to the linked profile or color scheme via the settings UI! - `ExtensionPackageViewModel` is a VM for a group of extensions exposed by a single source. This is mainly needed because a single source can have multiple JSON fragments in it. This is used for the navigators on the main page. Can be extended to provide additional information (i.e. package logo, package name, etc.) - `CurrentExtensionPackage` is used to track which extension package is currently in view, if applicable (similar to how the new tab menu page works) - Editor changes - views: - `Extensions.xaml` uses _a lot_ of data templates. These are reused in `ItemsControl`s to display extension components. - `ExtensionPackageTemplateSelector` is used to display `ExtensionPackage`s with metadata vs simple ones that just have a source (i.e. Git) - Added a `NewInfoBadge` style that is just an InfoBadge with "New" in it instead of a number or an icon. Based on https://github.com/microsoft/PowerToys/pull/36939 - The visibility is bound to a `get` call to the `ApplicationState` conducted via the `ExtensionsPageViewModel`. The VM is also responsible for updating the state. - Lazy loading extension objects - Since most instances of Terminal won't actually open the settings UI, it doesn't make sense to create all the extension objects upon startup. Instead, we defer creating those objects until the user actually navigates to the Extensions page. This is most of the work that happened in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used specifically to load and create the extension objects. ## Validation Steps ✅ Keyboard navigation feels right ✅ Screen reader reads all info on screen properly ✅ Accessibility Insights FastPass found no issues ✅ "Discard changes" retains subpage, but removes any changes ✅ Extensions page nav item displays a badge if page hasn't been visited ✅ The badge is dismissed when the user visits the page ## Follow-ups - Streamline a process for adding extensions from the new page - Long-term, we can reuse the InfoBadge system and make the following minor changes: - `SettingContainer`: display the badge and add logic to read/write `ApplicationState` appropriately (similarly to above) - `XPageViewModel`: - count all the badges that will be displayed and expose/bind that to `InfoBadge.Value` - If a whole page is new, we can just style the badge using the `NewInfoBadge` style
2025-05-28 12:03:02 -07:00
<data name="WslDistroGeneratorDisplayName" xml:space="preserve">
<value>WSL Distribution Profile Generator</value>
<comment>The display name of a dynamic profile generator for WSL distros</comment>
</data>
<data name="PowershellCoreProfileGeneratorDisplayName" xml:space="preserve">
<value>PowerShell Profile Generator</value>
<comment>The display name of a dynamic profile generator for PowerShell</comment>
</data>
<data name="AzureCloudShellGeneratorDisplayName" xml:space="preserve">
<value>Azure Cloud Shell Profile Generator</value>
<comment>The display name of a dynamic profile generator for Azure Cloud Shell</comment>
</data>
<data name="VisualStudioGeneratorDisplayName" xml:space="preserve">
<value>Visual Studio Profile Generator</value>
<comment>The display name of a dynamic profile generator for Visual Studio</comment>
</data>
<data name="SshHostGeneratorDisplayName" xml:space="preserve">
<value>SSH Host Profile Generator</value>
<comment>The display name of a dynamic profile generator for SSH hosts</comment>
</data>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
<data name="DismissSelectionActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Dismiss selection</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SingleLineActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Single line</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="WithControlSequencesActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>With control sequences</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="CopyFormattingActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Copy formatting</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="TabIndexActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Tab index</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="WindowActionArgumentLocalized" xml:space="preserve">
<value>Window</value>
</data>
<data name="ResizeDirectionActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Resize direction</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="FocusDirectionActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Focus direction</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="DirectionActionArgumentLocalized" xml:space="preserve">
<value>Direction</value>
</data>
<data name="DeltaActionArgumentLocalized" xml:space="preserve">
<value>Delta</value>
</data>
<data name="InputActionArgumentLocalized" xml:space="preserve">
<value>Input</value>
</data>
<data name="TargetActionArgumentLocalized" xml:space="preserve">
<value>Target</value>
</data>
<data name="IsFocusModeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Is focus mode</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="IsMaximizedActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Is maximized</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="IsFullScreenActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Is full screen</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SchemeNameActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Scheme name</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="TabColorActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Tab color</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="TitleActionArgumentLocalized" xml:space="preserve">
<value>Title</value>
</data>
<data name="CommandlineActionArgumentLocalized" xml:space="preserve">
<value>Commandline</value>
</data>
<data name="IndexActionArgumentLocalized" xml:space="preserve">
<value>Index</value>
</data>
<data name="RowsToScrollActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Rows to scroll</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="ColorActionArgumentLocalized" xml:space="preserve">
<value>Color</value>
</data>
<data name="LaunchModeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Launch mode</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="NameActionArgumentLocalized" xml:space="preserve">
<value>Name</value>
</data>
<data name="KeyChordActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Key chord</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SourceActionArgumentLocalized" xml:space="preserve">
<value>Source</value>
</data>
<data name="UseCommandlineActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Use commandline</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SwitcherModeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Switcher mode</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="QueryUrlActionArgumentLocalized" xml:space="preserve">
<value>Query URL</value>
</data>
<data name="DesktopActionArgumentLocalized" xml:space="preserve">
<value>Desktop</value>
</data>
<data name="MonitorActionArgumentLocalized" xml:space="preserve">
<value>Monitor</value>
</data>
<data name="ToggleVisibilityActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Toggle visibility</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="DropdownDurationActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Dropdown duration</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="IdActionArgumentLocalized" xml:space="preserve">
<value>Id</value>
</data>
<data name="PathActionArgumentLocalized" xml:space="preserve">
<value>Path</value>
</data>
<data name="ClearActionArgumentLocalized" xml:space="preserve">
<value>Clear</value>
</data>
<data name="OpacityActionArgumentLocalized" xml:space="preserve">
<value>Opacity</value>
</data>
<data name="RelativeActionArgumentLocalized" xml:space="preserve">
<value>Relative</value>
</data>
<data name="ForegroundActionArgumentLocalized" xml:space="preserve">
<value>Foreground</value>
</data>
<data name="BackgroundActionArgumentLocalized" xml:space="preserve">
<value>Background</value>
</data>
<data name="MatchModeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Match mode</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="StartingDirectoryActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Starting directory</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="TabTitleActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Tab title</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="ProfileIndexActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Profile index</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="ProfileActionArgumentLocalized" xml:space="preserve">
<value>Profile</value>
</data>
<data name="SuppressApplicationTitleActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Suppress application title</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="ColorSchemeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Color scheme</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="ElevateActionArgumentLocalized" xml:space="preserve">
<value>Elevate</value>
</data>
<data name="ReloadEnvironmentVariablesActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Reload environment variables</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SplitDirectionActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Split direction</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SplitModeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Split mode</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
<data name="SplitSizeActionArgumentLocalized" xml:space="preserve">
Use sentence case for actions' additional argument resource strings (#19861) From the feedback received in #19822, update the multi-word additional argument resource entries to use sentence case.
2026-02-12 18:25:08 -08:00
<value>Split size</value>
Add reflection to the ActionArgs in the settings model (#18915) Implements reflection to the various ActionArg types in the settings model, which allows these structs to provide information about themselves (i.e. what args they contain and what types they are). This is necessary as a pre-requisite for the Settings Editor to display and modify these arg values. ## Detailed Description of the Pull Request / Additional comments * The `IActionArgs` interface now has additional methods: * Get the number of args * Get/Set an arg at a specific index * Get a vector of arg descriptions; the arg description contains: * name of the arg * type of the arg * whether the arg is required * a tag, this is to cover special cases (for example the ColorScheme argument is technically of type "string", but only allows specific values) * All the macros in `ActionArgsMagic` have been updated to support the new interface * `ActionMap` has been updated to support adding/editing/deleting actions and keybindings from outside the SettingsModel * It also handles ID change requests for commands * EnumMappings have been added to various ActionArg enums that weren't there before ## Validation Steps Performed Bug bashed in conjunction with #18917
2025-09-03 13:36:10 -07:00
</data>
</root>
Reference in New Issue Copy Permalink