maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/TerminalApp/Resources/en-US/Resources.resw

627 lines
30 KiB
Plaintext
Raw Normal View History

Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
<?xml version="1.0" encoding="utf-8"?>
<root>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
<!--
Microsoft ResX Schema
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
Version 2.0
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01: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
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
associated with the data types.
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
Example:
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02: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>
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
There are any number of "resheader" rows that contain simple
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
name/value pairs.
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01: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
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
mimetype set.
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
The mimetype is used for serialized objects, and tells the
ResXResourceReader how to depersist the object. This is currently not
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
extensible. For a given mimetype the value must be set accordingly:
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Note - application/x-microsoft.net.object.binary.base64 is the format
that the ResXResourceWriter will generate, however the reader can
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
read any of the formats listed below.
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
mimetype: application/x-microsoft.net.object.binary.base64
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
value : The object must be serialized with
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
: and then encoded with base64 encoding.
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
mimetype: application/x-microsoft.net.object.soap.base64
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
value : The object must be serialized with
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
: System.Runtime.Serialization.Formatters.Soap.SoapFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.bytearray.base64
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
value : The object must be serialized into a byte array
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02: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="InitialJsonParseErrorText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Settings could not be loaded from file. Check for syntax errors, including trailing commas.</value>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
</data>
<data name="MissingDefaultProfileText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Could not find your default profile in your list of profiles - using the first profile. Check to make sure the "defaultProfile" matches the GUID of one of your profiles.</value>
<comment>{Locked="\"defaultProfile\""}</comment>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
</data>
<data name="DuplicateProfileText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Found multiple profiles with the same GUID in your settings file - ignoring duplicates. Make sure each profile's GUID is unique.</value>
Add a warning when a profile has an unknown color scheme (#3033) Add a warning when the user sets their colorScheme to a scheme that doesn't exist. When that occurs, we'll set their color table to the campbell scheme, to prevent it from being just entirely black. This commit also switches scheme storage to a map keyed on name. Closes #2547
2019-10-15 07:02:52 +02:00
</data>
<data name="UnknownColorSchemeText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Found a profile with an invalid "colorScheme". Defaulting that profile to the default colors. Make sure that when setting a "colorScheme", the value matches the "name" of a color scheme in the "schemes" list.</value>
<comment>{Locked="\"colorScheme\"","\"name\"","\"schemes\""}</comment>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
</data>
<data name="NoProfilesText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>No profiles were found in your settings.</value>
Add validation for hiding all the profiles (#2800) fixes #2794
2019-09-19 18:54:36 +02:00
</data>
<data name="AllProfilesHiddenText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>All profiles were hidden in your settings. You must have at least one non-hidden profile.</value>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
</data>
<data name="ReloadJsonParseErrorText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Settings could not be reloaded from file. Check for syntax errors, including trailing commas.</value>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
</data>
<data name="UsingDefaultSettingsText" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Temporarily using the Windows Terminal default settings.</value>
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
</data>
<data name="InitialJsonParseErrorTitle" xml:space="preserve">
<value>Failed to load settings</value>
</data>
Add Warnings during settings load (#2422) * Warn the user when their settings are bad The start of work on #1348 * Display an error dialog for errors during validation * Polish for PR * Add a ton of tests * Polish the _GetMessageText bits * Add code to check for duplicate profiles * Verify that many warnings work at the same time * comments y'all * Apply fixes for dustin's thoughts from PR * Add a proper exception type, use an array instead of a map * PR Fixes * Fix x86 build break * Add a bit on "using the defaults" when we encountering an exception * remove a redundant variable * guid->GUID * Address Michael's PR comments * Clean up this error text, and catch exceptions better * Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 23:21:43 +02:00
<data name="SettingsValidateErrorTitle" xml:space="preserve">
<value>Encountered errors while loading user settings</value>
</data>
Warn the user if the keyboard service is disabled (#8095) ## Summary of the Pull Request ![kb-service-disabled](https://user-images.githubusercontent.com/18356694/97578533-eb792d80-19be-11eb-9b13-b771327a72a0.png) With this PR, the Terminal will check to make sure the "Touch, Keyboard and Handwriting Panel Service" is enabled at startup. If it isn't, then the Terminal won't be able to receive keyboard input (see #4448 and the 20 linked issues to that one). ## References * See #4448 for more details ## PR Checklist * [x] Closes #7886 * [ ] Should this make #4448 not-open as well? * [x] I work here * [n/a] Tests added/passed * [x] Docs: https://github.com/MicrosoftDocs/terminal/pull/168 ## Validation Steps Performed I manually set the service to "Disabled", restarted the machine, verified the dialog opens (and that I'm unable to type in the Terminal), then re-set the service to automatic and rebooted, and the dialog doesn't appear.
2020-11-04 22:44:53 +01:00
<data name="KeyboardServiceDisabledDialog.PrimaryButtonText" xml:space="preserve">
<value>OK</value>
</data>
<data name="KeyboardServiceDisabledDialog.Title" xml:space="preserve">
<value>Warning:</value>
</data>
<data name="KeyboardServiceWarningText" xml:space="preserve">
<value>The "{0}" isn't running on your machine. This can prevent the Terminal from receiving keyboard input.</value>
<comment>{0} will be replaced with the OS-localized name of the TabletInputService</comment>
</data>
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
<data name="Ok" xml:space="preserve">
OK (#3675) [OK](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/o/ok-okay)! OK?
2019-11-25 15:01:33 +01:00
<value>OK</value>
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
</data>
<data name="ReloadJsonParseErrorTitle" xml:space="preserve">
<value>Failed to reload settings</value>
</data>
<data name="FeedbackUriValue" xml:space="preserve">
Change aka.ms links to fwlinks (#5223)
2020-04-03 01:19:03 +02:00
<value>https://go.microsoft.com/fwlink/?linkid=2125419</value>
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<comment>{Locked}This is a FWLink, so it will be localized with the fwlink tool</comment>
Move TerminalApp's resources into the TerminalApp project (#1972) * Move TerminalApp's resources into the TerminalApp project This commit also introduces a scoped resource accessor, lightly taken from microsoft-ui-xaml. It also moves all static UI strings out of App.cpp and into localizable resources. Fixes #792.
2019-07-23 20:29:38 +02:00
</data>
<data name="AboutMenuItem" xml:space="preserve">
<value>About</value>
</data>
<data name="FeedbackMenuItem" xml:space="preserve">
<value>Feedback</value>
</data>
<data name="SettingsMenuItem" xml:space="preserve">
<value>Settings</value>
</data>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
<data name="Cancel" xml:space="preserve">
<value>Cancel</value>
</data>
<data name="CloseAll" xml:space="preserve">
<value>Close all</value>
</data>
<data name="CloseWindowWarningTitle" xml:space="preserve">
<value>Do you want to close all tabs?</value>
</data>
Add Close... option to Tab context menu (#7728) <!-- 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 a "Close..." option to the tab context menu, with nested entries to close tabs to the right and close other tabs (actions already available) ![immagine](https://user-images.githubusercontent.com/1140981/94178005-c7e03600-fe9a-11ea-9f87-c6f4895d4cf3.png) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5524 * [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 First contribution :slightly_smiling_face: Tried to follow some suggestions from https://github.com/microsoft/terminal/issues/1912#issuecomment-667079311 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2020-10-15 13:40:44 +02:00
<data name="TabCloseSubMenu" xml:space="preserve">
<value>Close...</value>
</data>
<data name="TabCloseAfter" xml:space="preserve">
<value>Close Tabs to the Right</value>
</data>
<data name="TabCloseOther" xml:space="preserve">
<value>Close Other Tabs</value>
</data>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
<data name="TabClose" xml:space="preserve">
Add Close... option to Tab context menu (#7728) <!-- 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 a "Close..." option to the tab context menu, with nested entries to close tabs to the right and close other tabs (actions already available) ![immagine](https://user-images.githubusercontent.com/1140981/94178005-c7e03600-fe9a-11ea-9f87-c6f4895d4cf3.png) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5524 * [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 First contribution :slightly_smiling_face: Tried to follow some suggestions from https://github.com/microsoft/terminal/issues/1912#issuecomment-667079311 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
2020-10-15 13:40:44 +02:00
<value>Close Tab</value>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
</data>
<data name="TabColorChoose" xml:space="preserve">
<value>Color...</value>
</data>
<data name="TabColorCustomButton.Content" xml:space="preserve">
<value>Custom...</value>
</data>
<data name="TabColorClearButton.Content" xml:space="preserve">
<value>Reset</value>
</data>
Enable tab renaming at runtime from the UI (#5775) ## Summary of the Pull Request Adds support for setting, from the UI, a runtime override for the tab title text. The user can use this to effectively "rename" a tab. If set, the tab will _always_ use the runtime override string. If the user has multiple panes with different titles in a pane, then the tab's override text will be used _regardless_ of which pane was focused when the tab was renamed. The override text can be removed by just deleting the entire contents of the box. Then, the tab will revert to using the terminal's usual title. ## References * Wouldn't be possible without the context menu from #3789 * Focus doesn't return to the active terminal after hitting <kbd>enter</kbd>/<kbd>esc</kbd>, but that's tracked by #5750 ## PR Checklist * [x] Closes #1079 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## TODO * [x] `Tab::SetTabText` might be able to be greatly simplified/removed? * [x] I'm _pretty sure_ if they set an override title, we won't bubble that up to set the window title. * [x] I'm unsure how this behaves when the terminal's title changes _while_ the TextBox is visible. I don't think it should change the current contents of the box, but it might currently. * [ ] **for discussion**: If the user doesn't actually change the text of the tab, then we probably shouldn't set the override text, right? - EX: if they open the box and the text is "cmd", and immediately hit <kbd>enter</kbd>, then run `title foo`, should the text change to "foo" or stay "cmd"? ## Detailed Description of the Pull Request / Additional comments ![image](https://user-images.githubusercontent.com/18356694/81230615-713f9180-8fb7-11ea-8945-6681eec02a4f.png) ![image](https://user-images.githubusercontent.com/18356694/81230640-7ac8f980-8fb7-11ea-9e6b-22f0e0ed128a.png) ![image](https://user-images.githubusercontent.com/18356694/81230665-86b4bb80-8fb7-11ea-90f0-16d4ffb60d89.png) ![image](https://user-images.githubusercontent.com/18356694/81230686-9207e700-8fb7-11ea-94a9-f3f5a59be139.png) ![image](https://user-images.githubusercontent.com/18356694/81230732-a350f380-8fb7-11ea-9901-6dd4f36154f1.png) ![image](https://user-images.githubusercontent.com/18356694/81230746-a8ae3e00-8fb7-11ea-94fa-d2578f9241a7.png) ![image](https://user-images.githubusercontent.com/18356694/81230787-bc59a480-8fb7-11ea-8edf-2bd7fad343fc.png) ![image](https://user-images.githubusercontent.com/18356694/81230851-dc896380-8fb7-11ea-98c1-918b943543e4.png)
2020-05-28 23:06:17 +02:00
<data name="RenameTabText" xml:space="preserve">
<value>Rename Tab</value>
</data>
Introduce duplicate tab menu (#9388) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9373 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already.
2021-03-08 13:16:56 +01:00
<data name="DuplicateTabText" xml:space="preserve">
<value>Duplicate Tab</value>
</data>
Fix crash related to unparseable/invalid media resource paths (#4194) WT crashes when an unparseable/invalid `backgroundImage` or `icon` resource path is provided in `profiles.json`. This PR averts the crash by the validating and correcting resource paths as a part of the `_ValidateSettings()` function in `CascadiaSettings`. `_ValidateSettings()` is run on start up and any time `profiles.json` is changed, so a user can not change a file path and avoid the validation step. When a bad `backgroundImage` or `icon` resource path is detected, a warning screen will be presented. References #4002, which identified a consistent repro for the crash. To validate the resource, a `Windows::Foundation::Uri` object is constructed with the path. The ctor will throw if the resource path is invalid. Whether or not this validation method is robust enough is a subject worth review. The correction method for when a bad resource path is detected is to reset the `std::optional<winrt::hstring>` holding the file path. The text in the warning display was cribbed from the text used when an invalid `colorScheme` is used. Whether or not the case of a bad background image file path warrants a warning display is a subject worth review. Ensured the repro steps in #4002 did not trigger a crash. Additionally, some potential backdoor paths to a crash were tested: - Deleting the file of a validated background image file path - Changing the actual file name of a validated background image file path - Replacing the file of a validated background image file path with a non-image file (of the same name) - Using a non-image file as a background image In all the above cases WT does not crash, and instead defaults to the background color specified in the profile's `colorScheme`. This PR does not implement this recovery behavior (existing error catching code does). Closes #2329
2020-01-17 02:48:37 +01:00
<data name="InvalidBackgroundImage" xml:space="preserve">
<value>Found a profile with an invalid "backgroundImage". Defaulting that profile to have no background image. Make sure that when setting a "backgroundImage", the value is a valid file path to an image.</value>
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<comment>{Locked="\"backgroundImage\""}</comment>
Fix crash related to unparseable/invalid media resource paths (#4194) WT crashes when an unparseable/invalid `backgroundImage` or `icon` resource path is provided in `profiles.json`. This PR averts the crash by the validating and correcting resource paths as a part of the `_ValidateSettings()` function in `CascadiaSettings`. `_ValidateSettings()` is run on start up and any time `profiles.json` is changed, so a user can not change a file path and avoid the validation step. When a bad `backgroundImage` or `icon` resource path is detected, a warning screen will be presented. References #4002, which identified a consistent repro for the crash. To validate the resource, a `Windows::Foundation::Uri` object is constructed with the path. The ctor will throw if the resource path is invalid. Whether or not this validation method is robust enough is a subject worth review. The correction method for when a bad resource path is detected is to reset the `std::optional<winrt::hstring>` holding the file path. The text in the warning display was cribbed from the text used when an invalid `colorScheme` is used. Whether or not the case of a bad background image file path warrants a warning display is a subject worth review. Ensured the repro steps in #4002 did not trigger a crash. Additionally, some potential backdoor paths to a crash were tested: - Deleting the file of a validated background image file path - Changing the actual file name of a validated background image file path - Replacing the file of a validated background image file path with a non-image file (of the same name) - Using a non-image file as a background image In all the above cases WT does not crash, and instead defaults to the background color specified in the profile's `colorScheme`. This PR does not implement this recovery behavior (existing error catching code does). Closes #2329
2020-01-17 02:48:37 +01:00
</data>
<data name="InvalidIcon" xml:space="preserve">
<value>Found a profile with an invalid "icon". Defaulting that profile to have no icon. Make sure that when setting an "icon", the value is a valid file path to an image.</value>
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<comment>{Locked="\"icon\""} The word "icon" in quotes is locked, the word icon OUTSIDE of quotes should be localized.</comment>
Fix crash related to unparseable/invalid media resource paths (#4194) WT crashes when an unparseable/invalid `backgroundImage` or `icon` resource path is provided in `profiles.json`. This PR averts the crash by the validating and correcting resource paths as a part of the `_ValidateSettings()` function in `CascadiaSettings`. `_ValidateSettings()` is run on start up and any time `profiles.json` is changed, so a user can not change a file path and avoid the validation step. When a bad `backgroundImage` or `icon` resource path is detected, a warning screen will be presented. References #4002, which identified a consistent repro for the crash. To validate the resource, a `Windows::Foundation::Uri` object is constructed with the path. The ctor will throw if the resource path is invalid. Whether or not this validation method is robust enough is a subject worth review. The correction method for when a bad resource path is detected is to reset the `std::optional<winrt::hstring>` holding the file path. The text in the warning display was cribbed from the text used when an invalid `colorScheme` is used. Whether or not the case of a bad background image file path warrants a warning display is a subject worth review. Ensured the repro steps in #4002 did not trigger a crash. Additionally, some potential backdoor paths to a crash were tested: - Deleting the file of a validated background image file path - Changing the actual file name of a validated background image file path - Replacing the file of a validated background image file path with a non-image file (of the same name) - Using a non-image file as a background image In all the above cases WT does not crash, and instead defaults to the background color specified in the profile's `colorScheme`. This PR does not implement this recovery behavior (existing error catching code does). Closes #2329
2020-01-17 02:48:37 +01:00
</data>
Add warning messages for bad keybindings (#4746) ## Summary of the Pull Request Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs: * #4239 - If the user has supplied more than one key chord in their `"keys"` array. * #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user - currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus` ## References When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning. ## PR Checklist * [x] Closes #4239 * [x] Closes #3522 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ![image](https://user-images.githubusercontent.com/18356694/75593132-f18ec700-5a49-11ea-9d26-6acd0d28b0b7.png) ## Validation Steps Performed Tested manually, added tests.
2020-03-05 22:06:58 +01:00
<data name="AtLeastOneKeybindingWarning" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Warnings were found while parsing your keybindings:</value>
Add warning messages for bad keybindings (#4746) ## Summary of the Pull Request Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs: * #4239 - If the user has supplied more than one key chord in their `"keys"` array. * #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user - currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus` ## References When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning. ## PR Checklist * [x] Closes #4239 * [x] Closes #3522 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ![image](https://user-images.githubusercontent.com/18356694/75593132-f18ec700-5a49-11ea-9d26-6acd0d28b0b7.png) ## Validation Steps Performed Tested manually, added tests.
2020-03-05 22:06:58 +01:00
</data>
<data name="TooManyKeysForChord" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>&#x2022; Found a keybinding with too many strings for the "keys" array. There should only be one string value in the "keys" array.</value>
<comment>{Locked="\"keys\"","&#x2022;"} This glyph is a bullet, used in a bulleted list.</comment>
Add warning messages for bad keybindings (#4746) ## Summary of the Pull Request Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs: * #4239 - If the user has supplied more than one key chord in their `"keys"` array. * #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user - currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus` ## References When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning. ## PR Checklist * [x] Closes #4239 * [x] Closes #3522 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ![image](https://user-images.githubusercontent.com/18356694/75593132-f18ec700-5a49-11ea-9d26-6acd0d28b0b7.png) ## Validation Steps Performed Tested manually, added tests.
2020-03-05 22:06:58 +01:00
</data>
Invalidate nested command with no valid subcommands (#9495) Currently, when loading command with sub-commands that fail to parse, we result with command that: * Is not considered nested (has no sub-commands) * Has no action of its own The commit contains a few changes: 1. Protection in the dispatch that will prevent NPE 2. Change in the command parsing that will no load a command if all its sub-commands failed to parse 3. We will add a warning in this case (the solution is somewhat hacky, due to the hack that was there previously) When such command is passed to a dispatch we crash with NPE. Closes #9448
2021-03-15 17:34:06 +01:00
<data name="FailedToParseSubCommands" xml:space="preserve">
<value>&#x2022; Failed to parse all subcommands of nested command.</value>
</data>
Add warning messages for bad keybindings (#4746) ## Summary of the Pull Request Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs: * #4239 - If the user has supplied more than one key chord in their `"keys"` array. * #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user - currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus` ## References When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning. ## PR Checklist * [x] Closes #4239 * [x] Closes #3522 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ![image](https://user-images.githubusercontent.com/18356694/75593132-f18ec700-5a49-11ea-9d26-6acd0d28b0b7.png) ## Validation Steps Performed Tested manually, added tests.
2020-03-05 22:06:58 +01:00
<data name="MissingRequiredParameter" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>&#x2022; Found a keybinding that was missing a required parameter value. This keybinding will be ignored.</value>
<comment>{Locked="&#x2022;"} This glyph is a bullet, used in a bulleted list.</comment>
Add warning messages for bad keybindings (#4746) ## Summary of the Pull Request Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs: * #4239 - If the user has supplied more than one key chord in their `"keys"` array. * #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user - currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus` ## References When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning. ## PR Checklist * [x] Closes #4239 * [x] Closes #3522 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ![image](https://user-images.githubusercontent.com/18356694/75593132-f18ec700-5a49-11ea-9d26-6acd0d28b0b7.png) ## Validation Steps Performed Tested manually, added tests.
2020-03-05 22:06:58 +01:00
</data>
Add a warning about using the `globals` property (#5597) This property was deprecated in 0.11. We probably should have also added a warning message to help the community figure out that this property is gone and won't work anymore. This PR adds that warning. * I'm not going to list the enormous number of duped threads _wait yes I am_ * #5581 * #5547 * #5555 * #5557 * #5573 * #5532 * #5527 * #5535 * #5510 * #5511 * #5512 * #5513 * #5516 * #5515 * #5521 * This literally isn't even all of them * [x] Also mainly related to #5458 * [x] I work here * [x] Tests added/passed
2020-04-28 00:20:18 +02:00
<data name="LegacyGlobalsProperty" xml:space="preserve">
<value>The "globals" property is deprecated - your settings might need updating. </value>
<comment>{Locked="\"globals\""} </comment>
</data>
<data name="LegacyGlobalsPropertyHrefUrl" xml:space="preserve">
<value>https://go.microsoft.com/fwlink/?linkid=2128258</value>
<comment>{Locked}This is a FWLink, so it will be localized with the fwlink tool</comment>
</data>
<data name="LegacyGlobalsPropertyHrefLabel" xml:space="preserve">
<value>For more info, see this web page.</value>
</data>
Add support for iterable, nested commands (#6856) ## Summary of the Pull Request This PR adds support for both _nested_ and _iterable_ commands in the Command palette. ![nested-commands-000](https://user-images.githubusercontent.com/18356694/87072916-2d991c00-c1e2-11ea-8917-a70e8b8b9803.gif) * **Nested commands**: These are commands that include additional sub-commands. When the user selects on of these, the palette will update to only show the nested commands. * **Iterable commands**: These are commands what allow the user to define only a single command, which is repeated once for every profile. (in the future, also repeated for color schemes, themes, etc.) The above gif uses the following json: ```json { "name": "Split Pane...", "commands": [ { "iterateOn": "profiles", "name": "Split with ${profile.name}...", "commands": [ { "command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" } }, { "command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" } }, { "command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" } } ] } ] }, ``` ## References ## PR Checklist * [x] Closes #3994 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - Sure does, but we'll finish polishing this first. ## Detailed Description of the Pull Request / Additional comments We've now gotta keep the original json for a command around, so that once we know what all the profiles will be, we can expand the commands that need it. We've also got to parse commands recursively, because they might have any number of child commands. These together made the command parsing a _lot_ more complicated, but it feels good so far. ## Validation Steps Performed * wrote a bunch of tests * Played with it a bunch
2020-08-13 23:22:46 +02:00
<data name="FailedToParseCommandJson" xml:space="preserve">
<value>Failed to expand a command with "iterateOn" set. This command will be ignored.</value>
<comment>{Locked="\"iterateOn\""} </comment>
</data>
Raise warning on invalid color scheme in commands (#8147) Show a validation warning when someone sets a `setColorScheme` action with an invalid scheme In the setting validation phase, scan all commands for all the "set color scheme" actions, and check each of them has a valid scheme. If any of them has an invalid scheme name, raise a warning. Do not check iterable commands that will be expanded to valid color schemes. ## Validation Steps Performed - Added tests to LocalTests_SettingsModel - Manual tests, add commands to settings.json with invalid color scheme and check the warning pops up. Try simple and nested commands. Closes #7221
2020-12-01 23:28:00 +01:00
<data name="InvalidColorSchemeInCmd" xml:space="preserve">
<value>Found a command with an invalid "colorScheme". This command will be ignored. Make sure that when setting a "colorScheme", the value matches the "name" of a color scheme in the "schemes" list.</value>
<comment>{Locked="\"colorScheme\"","\"name\"","\"schemes\""}</comment>
</data>
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543) ## Summary of the Pull Request Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one. This also adds the param to the `split-pane` subcommand. ### Examples | commandline | result | | -- | -- | | `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) | | `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) | | `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) | ## PR Checklist * [x] Closes #6298 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#208 ## Detailed Description of the Pull Request / Additional comments I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version. ## Validation Steps Performed Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
<data name="InvalidSplitSize" xml:space="preserve">
<value>Found a "splitPane" command with an invalid "size". This command will be ignored. Make sure the size is between 0 and 1, exclusive.</value>
<comment>{Locked="\"splitPane\"","\"size\""}</comment>
</data>
Introduce startupActions in settings (#8770) Procedural solution for https://github.com/microsoft/terminal/issues/756. Introduces a `startupActions` global setting. This setting is as string with the same format as actions in command line arguments. It is used only if command line arguments were not provided (aka running pure wt.exe). The setting allows implicit new-tabs. In the case of invalid syntax we show the warning dialog and ignore the setting. The documentation PR is here: https://github.com/MicrosoftDocs/terminal/pull/217
2021-01-15 19:30:11 +01:00
<data name="FailedToParseStartupActions" xml:space="preserve">
<value>Failed to parse "startupActions".</value>
<comment>{Locked="\"startupActions\""}</comment>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdCommandArgDesc" xml:space="preserve">
<value>An optional command, with arguments, to be spawned in the new tab or pane</value>
</data>
<data name="CmdFocusTabDesc" xml:space="preserve">
<value>Move focus to another tab</value>
</data>
<data name="CmdFocusTabNextArgDesc" xml:space="preserve">
<value>Move focus to the next tab</value>
</data>
`wt.exe`: Add support for "short" sub-commands (#6576) This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`, and `focus-tab`, respectively. These do exactly the same thing as their long for counterparts, but are just shorter, for those of us who type slower than a fifth grader 👀 Now you can do ``` wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ; nt -p \"Ubuntu\" ; ft -t 0 ``` instead of ``` new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ; focus-tab -t 0 ``` The pattern I'm using here is that each of these subcommands now has a little helper lambda that actually sets up the subcommand with the required arguments, and we just call that lambda twice, once for the long-form of the command, and again for the short. I imagine that in the future, we won't necessarily have short-forms for every subcommands, so if there are future conflicts we'd have to figure that out pre-emptively, but these all seem like they'll need a short form. Closes #5466
2020-07-14 20:50:32 +02:00
<data name="CmdFTDesc" xml:space="preserve">
<value>An alias for the "focus-tab" subcommand.</value>
<comment>{Locked="\"focus-tab\""}</comment>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdFocusTabPrevArgDesc" xml:space="preserve">
<value>Move focus to the previous tab</value>
</data>
<data name="CmdFocusTabTargetArgDesc" xml:space="preserve">
<value>Move focus the tab at the given index</value>
</data>
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543) ## Summary of the Pull Request Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one. This also adds the param to the `split-pane` subcommand. ### Examples | commandline | result | | -- | -- | | `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) | | `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) | | `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) | ## PR Checklist * [x] Closes #6298 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#208 ## Detailed Description of the Pull Request / Additional comments I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version. ## Validation Steps Performed Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
<data name="CmdSplitPaneSizeArgDesc" xml:space="preserve">
<value>Specify the size as a percentage of the parent pane. Valid values are between (0,1), exclusive.</value>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdNewTabDesc" xml:space="preserve">
<value>Create a new tab</value>
</data>
`wt.exe`: Add support for "short" sub-commands (#6576) This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`, and `focus-tab`, respectively. These do exactly the same thing as their long for counterparts, but are just shorter, for those of us who type slower than a fifth grader 👀 Now you can do ``` wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ; nt -p \"Ubuntu\" ; ft -t 0 ``` instead of ``` new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ; focus-tab -t 0 ``` The pattern I'm using here is that each of these subcommands now has a little helper lambda that actually sets up the subcommand with the required arguments, and we just call that lambda twice, once for the long-form of the command, and again for the short. I imagine that in the future, we won't necessarily have short-forms for every subcommands, so if there are future conflicts we'd have to figure that out pre-emptively, but these all seem like they'll need a short form. Closes #5466
2020-07-14 20:50:32 +02:00
<data name="CmdNTDesc" xml:space="preserve">
<value>An alias for the "new-tab" subcommand.</value>
<comment>{Locked="\"new-tab\""}</comment>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdProfileArgDesc" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Open with the given profile. Accepts either the name or GUID of a profile</value>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
</data>
<data name="CmdSplitPaneDesc" xml:space="preserve">
<value>Create a new split pane</value>
</data>
`wt.exe`: Add support for "short" sub-commands (#6576) This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`, and `focus-tab`, respectively. These do exactly the same thing as their long for counterparts, but are just shorter, for those of us who type slower than a fifth grader 👀 Now you can do ``` wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ; nt -p \"Ubuntu\" ; ft -t 0 ``` instead of ``` new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ; focus-tab -t 0 ``` The pattern I'm using here is that each of these subcommands now has a little helper lambda that actually sets up the subcommand with the required arguments, and we just call that lambda twice, once for the long-form of the command, and again for the short. I imagine that in the future, we won't necessarily have short-forms for every subcommands, so if there are future conflicts we'd have to figure that out pre-emptively, but these all seem like they'll need a short form. Closes #5466
2020-07-14 20:50:32 +02:00
<data name="CmdSPDesc" xml:space="preserve">
<value>An alias for the "split-pane" subcommand.</value>
<comment>{Locked="\"split-pane\""}</comment>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdSplitPaneHorizontalArgDesc" xml:space="preserve">
<value>Create the new pane as a horizontal split (think [-])</value>
</data>
<data name="CmdSplitPaneVerticalArgDesc" xml:space="preserve">
<value>Create the new pane as a vertical split (think [|])</value>
</data>
Add splitMode to the args for split-pane (as -D for duplicate) (#9652) Closes #9579
2021-03-30 00:06:05 +02:00
<data name="CmdSplitPaneDuplicateArgDesc" xml:space="preserve">
<value>Create the new pane by duplicating the profile of the focused pane</value>
</data>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
<data name="CmdStartingDirArgDesc" xml:space="preserve">
Fix localizability issues in Windows Terminal (#5339) Loc issues are given to us through the internal bug tracker. * Lock some strings, or parts of strings, that should not be localized. * Switch to positional format parameters * Remove the forced newlines in the warning resources; insert them at runtime Fixes MSFT:25936156.
2020-04-14 22:48:46 +02:00
<value>Open in the given directory instead of the profile's set "startingDirectory"</value>
<comment>{Locked="\"startingDirectory\""}</comment>
Kill NEEDS_LOC and move cmdline descriptions into resources (#4402) Fixes #4155. ## Validation steps ``` Summary: Total=23, Passed=22, Failed=1, Blocked=0, Not Run=0, Skipped=0 ``` The failing test is the same one as before. It is not germane to this pull request.
2020-01-31 02:13:38 +01:00
</data>
Add support for `--title` to the `wt.exe` commandline args (#6296) ## Summary of the Pull Request Adds support for setting the terminal `title` with the commandline argument `--title <title>`. ## PR Checklist * [x] Closes #6183 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - probably does, yea ## Detailed Description of the Pull Request / Additional comments * I wasn't sure how we felt about `-t` being the short version of this argument, so I left it out. If we're cool with that, adding it wouldn't be hard. ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/83450866-afe03480-a41b-11ea-84e7-9134474fdd7a.png)
2020-06-02 20:52:08 +02:00
<data name="CmdTitleArgDesc" xml:space="preserve">
<value>Open the terminal with the provided title instead of the profile's set "title"</value>
<comment>{Locked="\"title\""}</comment>
</data>
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
<data name="CmdTabColorArgDesc" xml:space="preserve">
<value>Open the tab with the specified color, in #rrggbb format</value>
</data>
Allow configuring suppressApplicationTitle in new tab/pane/window commands (#9392) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9345 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated - not yet, will be once conceptually approved * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Introduce optional `suppressApplicationTitle` in to `NewTerminalArgs`. When set (either to true or false) overrides profile configuration. Introduce `--suppressApplicationTitle` flag to command line arguments. When provided for sub=command, sets the value in the relevant `NewTerminalArgs` to `true`
2021-03-08 16:23:50 +01:00
<data name="CmdSuppressApplicationTitleDesc" xml:space="preserve">
<value>Open the tab with tabTitle overriding default title and suppressing title change messages from the application</value>
<comment>{Locked="\"tabTitle\""}</comment>
</data>
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
<data name="CmdColorSchemeArgDesc" xml:space="preserve">
<value>Open the tab with the specified color scheme, instead of the profile's set "colorScheme"</value>
<comment>{Locked="\"colorScheme\""}</comment>
</data>
Add support for displaying the version with `wt --version` (#5501) ## Summary of the Pull Request Here's 3000 words: ![image](https://user-images.githubusercontent.com/18356694/80125877-e2af2700-8557-11ea-809a-63e50d76fe2b.png) ![image](https://user-images.githubusercontent.com/18356694/80125882-e5aa1780-8557-11ea-8f73-2e50c409b76d.png) ![image](https://user-images.githubusercontent.com/18356694/80125886-e8a50800-8557-11ea-8d28-6d1694c57c0c.png) ## References * #4632 ## PR Checklist * [x] Closes #5494 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-05-04 22:56:15 +02:00
<data name="CmdVersionDesc" xml:space="preserve">
<value>Display the application version</value>
</data>
Add support for `--fullscreen`, `--maximized` (#6139) ## Summary of the Pull Request Adds two new flags to the `wt.exe` alias: * `--maximized,-M`: Launch the new Terminal window maximized. This flag cannot be combined with `--fullscreen`. * `--fullscreen,-F`: Launch the new Terminal window fullscreen. This flag cannot be combined with `--maximized`. ## References * This builds on the work done in #6060. * The cmdline args megathread: #4632 ## PR Checklist * [x] Closes #5801 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * I had to move the commandline arg parsing up a layer from `TerminalPage` to `AppLogic`, because `AppLogic` controls the Terminal's settings, including launch mode settings. This seems like a reasonable change, to put both the settings from the file and the commandline in the same place. - **Most of the diff is that movement of code** * _"What happens when you try to pass both flags, like `wtd -M -F new-tab`?"_: ![image](https://user-images.githubusercontent.com/18356694/82679939-3cffde00-9c11-11ea-8d88-03ec7db83e59.png) ## Validation Steps Performed * Ran a bunch of commandlines to see what happened.
2020-06-01 23:57:30 +02:00
<data name="CmdMaximizedDesc" xml:space="preserve">
<value>Launch the window maximized</value>
</data>
<data name="CmdFullscreenDesc" xml:space="preserve">
<value>Launch the window in fullscreen mode</value>
</data>
Add a `move-focus` subcommand (#8546) ## Summary of the Pull Request Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`. ## References * Will surely conflict with #8183 * Is goodness even in the world where #5464 exists ## PR Checklist * [x] Closes #6580 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#209 ## Detailed Description of the Pull Request / Additional comments Bear with me, I wrote this before paternity leave, so code might be a bit stale. Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order. This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime? ## Validation Steps Performed Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
2021-01-11 19:37:05 +01:00
<data name="CmdMoveFocusDesc" xml:space="preserve">
<value>Move focus to the adjacent pane in the specified direction</value>
</data>
<data name="CmdMFDesc" xml:space="preserve">
<value>An alias for the "move-focus" subcommand.</value>
<comment>{Locked="\"move-focus\""}</comment>
</data>
<data name="CmdMoveFocusDirectionArgDesc" xml:space="preserve">
<value>The direction to move focus in</value>
</data>
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
<data name="CmdFocusDesc" xml:space="preserve">
<value>Launch the window in focus mode</value>
</data>
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
<data name="CmdWindowTargetArgDesc" xml:space="preserve">
<value>Specify a terminal window to run the given commandline in. "0" always refers to the current window. </value>
</data>
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
<data name="NewTabSplitButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.HelpText" xml:space="preserve">
<value>Press the button to open a new terminal tab with your default profile. Open the flyout to select which profile you want to open.</value>
</data>
<data name="NewTabSplitButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name" xml:space="preserve">
<value>New Tab</value>
</data>
Inform user that holding alt opens a new pane (#7866) Adds a tooltip to the new tab button and menu to let the user know that holding alt will open a new pane instead. Fixes #7851 Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
2020-10-13 02:14:02 +02:00
<data name="NewTabRun.Text" xml:space="preserve">
<value>Open a new tab</value>
</data>
<data name="NewPaneRun.Text" xml:space="preserve">
<value>Alt+Click to split the current window</value>
Add tooltip text to New Tab/Min/Max/Close (#5484) <!-- 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 Tooltip texts is an important element of each software! Added tooltip text to close button, minimize, restore down, and new tab. Moved from original. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References Connected to #5355 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [X] Closes #5355 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [X] No Docs * [ ] 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: #5355 <!-- 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 I'm pretty sure most ppl know what a tooltip text is, but for those who don't, it's a text that tells you what a button does when you over the button with your mouse.
2020-05-01 00:45:56 +02:00
</data>
Allow shift+click on a profile to open a new window (#9429) <!-- 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 Shift+click on a profile to open a new wt window with that profile. Or, shift+click on the '+' button to open a new wt window with the default profile. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9395 * [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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manual testing
2021-03-10 19:32:54 +01:00
<data name="NewWindowRun.Text" xml:space="preserve">
<value>Shift+Click to open a new window</value>
</data>
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
<data name="WindowCloseButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name" xml:space="preserve">
<value>Close</value>
</data>
Add tooltip text to New Tab/Min/Max/Close (#5484) <!-- 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 Tooltip texts is an important element of each software! Added tooltip text to close button, minimize, restore down, and new tab. Moved from original. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References Connected to #5355 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [X] Closes #5355 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [X] No Docs * [ ] 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: #5355 <!-- 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 I'm pretty sure most ppl know what a tooltip text is, but for those who don't, it's a text that tells you what a button does when you over the button with your mouse.
2020-05-01 00:45:56 +02:00
<data name="WindowCloseButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Close</value>
</data>
Polish AutomationProperties and UIA Tree Navigation (#4805) AutomationProperties of interest in this PR include... - Name: the name of a UI element (generally used as the main identifier for it) - HelpText: an additional description for a more complex UI element - AccessibilityView[1] - Raw: hide from the UIA tree. Only navigate to this if you know what you're doing - Control: a control without any content in it. Basically, a point at which the user can make a decision as to how to navigate the tree or invoke an action. - Content: a control that also has content to present to the user. I set a few more AutomationProperties throughout Windows Terminal... - MinMaxClose Control: hidden (we can/should rely on the true buttons that we are hiding) - SplitButton: Name and Help text (currently ignored due to #4804, but having it in the resource file won't cause any problems) - SearchBox: added a more specific name to the close button - BackgroundImage: hide it ## References A few additional work items have been created for tracking... - SplitButton: https://github.com/microsoft/terminal/issues/4804 ## PR Checklist * [X] Closes #2099 * [X] Closes #2102 ## Validation Steps Performed Verified using Accessibility Insights and Inspect.exe [1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
2020-03-05 23:32:46 +01:00
<data name="WindowMaximizeButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name" xml:space="preserve">
<value>Maximize</value>
</data>
<data name="WindowMinimizeButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name" xml:space="preserve">
<value>Minimize</value>
</data>
Add tooltip text to New Tab/Min/Max/Close (#5484) <!-- 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 Tooltip texts is an important element of each software! Added tooltip text to close button, minimize, restore down, and new tab. Moved from original. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References Connected to #5355 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [X] Closes #5355 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [X] No Docs * [ ] 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: #5355 <!-- 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 I'm pretty sure most ppl know what a tooltip text is, but for those who don't, it's a text that tells you what a button does when you over the button with your mouse.
2020-05-01 00:45:56 +02:00
<data name="WindowMinimizeButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Minimize</value>
</data>
Convert the About and Close All Tabs dialogs to xaml (#5140) ## Summary of the Pull Request This pull request replaces about a hundred lines of manual xaml DOM code with a few lines of actual xaml, and wires up bound properties and event handlers in the good and correct way. As part of this change, I've replaced the giant TextBlock in the about dialog with StackPanels, and replaced the Hyperlinks with HyperlinkButtons. This is in line with other platform applications. URLs are _not_ localizable resources, so I moved them into the about dialog's xaml. Per #5138, we'll likely change them so that they get localization for "free" (dispatching based on the browser's language, without having to localize the URL in the application).
2020-03-27 22:00:32 +01:00
<data name="AboutDialog.Title" xml:space="preserve">
<value>About</value>
</data>
<data name="AboutDialog.CloseButtonText" xml:space="preserve">
<value>OK</value>
</data>
<data name="AboutDialog_VersionLabel.Text" xml:space="preserve">
<value>Version:</value>
<comment>This is the heading for a version number label</comment>
</data>
<data name="AboutDialog_GettingStartedLink.Content" xml:space="preserve">
<value>Getting Started</value>
<comment>A hyperlink name for a guide on how to get started using Terminal</comment>
</data>
<data name="AboutDialog_DocumentationLink.Content" xml:space="preserve">
<value>Documentation</value>
<comment>A hyperlink name for user documentation</comment>
</data>
<data name="AboutDialog_ReleaseNotesLink.Content" xml:space="preserve">
<value>Release Notes</value>
<comment>A hyperlink name for the Terminal's release notes</comment>
</data>
<data name="AboutDialog_PrivacyPolicyLink.Content" xml:space="preserve">
<value>Privacy Policy</value>
<comment>A hyperlink name for the Terminal's privacy policy</comment>
</data>
Add a Third-Party notices link to the about dialog (#5508) ## Summary of the Pull Request This PR will add a link to the version of `NOTICE.md` in GitHub at the commit that the build was on. It uses the same approach for generating our settings files, where we'll create a header file with the commit hash assigned to a `wstring_view` during build time. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5139 * [x] CLA signed. * [x] Tests added/passed <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed The link is there and goes to the expected `NOTICE.md`.
2020-04-28 22:22:44 +02:00
<data name="AboutDialog_ThirdPartyNoticesLink.Content" xml:space="preserve">
<value>Third-Party Notices</value>
<comment>A hyperlink name for the Terminal's third-party notices</comment>
</data>
Convert the About and Close All Tabs dialogs to xaml (#5140) ## Summary of the Pull Request This pull request replaces about a hundred lines of manual xaml DOM code with a few lines of actual xaml, and wires up bound properties and event handlers in the good and correct way. As part of this change, I've replaced the giant TextBlock in the about dialog with StackPanels, and replaced the Hyperlinks with HyperlinkButtons. This is in line with other platform applications. URLs are _not_ localizable resources, so I moved them into the about dialog's xaml. Per #5138, we'll likely change them so that they get localization for "free" (dispatching based on the browser's language, without having to localize the URL in the application).
2020-03-27 22:00:32 +01:00
<data name="CloseAllDialog.CloseButtonText" xml:space="preserve">
<value>Cancel</value>
</data>
<data name="CloseAllDialog.PrimaryButtonText" xml:space="preserve">
<value>Close all</value>
</data>
<data name="CloseAllDialog.Title" xml:space="preserve">
<value>Do you want to close all tabs?</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 19:03:55 +01:00
<data name="CloseReadOnlyDialog.CloseButtonText" xml:space="preserve">
Fix read-only tab dialog to cancel tab closing when dismissed (#9573) Currently dismissing "are you sure you wish to close read-only tab or pane" dialog by pressing `ESC` will not abort tab closing (aka the tab will be closed!) The reason for this, is that we cancel, only if the "Cancel" is pressed (aka result=PrimaryButton, while ESC returns result=None). This PR fixes this, by doing what we usually do: * Putting Cancel in the CloseButton (which is also triggered by ESC) * Aborting the action if the result is not a Primary Button However, since we want Cancel to be a default action, we set CloseButton to be the DefaultButton in XAML
2021-03-22 12:02:30 +01:00
<value>Cancel</value>
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 19:03:55 +01:00
</data>
<data name="CloseReadOnlyDialog.PrimaryButtonText" xml:space="preserve">
Fix read-only tab dialog to cancel tab closing when dismissed (#9573) Currently dismissing "are you sure you wish to close read-only tab or pane" dialog by pressing `ESC` will not abort tab closing (aka the tab will be closed!) The reason for this, is that we cancel, only if the "Cancel" is pressed (aka result=PrimaryButton, while ESC returns result=None). This PR fixes this, by doing what we usually do: * Putting Cancel in the CloseButton (which is also triggered by ESC) * Aborting the action if the result is not a Primary Button However, since we want Cancel to be a default action, we set CloseButton to be the DefaultButton in XAML
2021-03-22 12:02:30 +01:00
<value>Close anyway</value>
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 19:03:55 +01:00
</data>
<data name="CloseReadOnlyDialog.Title" xml:space="preserve">
<value>Warning</value>
</data>
<data name="CloseReadOnlyDialog.Content" xml:space="preserve">
<value>You are about to close a read-only terminal. Do you wish to continue?</value>
</data>
Add settings to warn about large or multiline pastes (#6631) Before sending calling the `HandleClipboardData` member function on the `PasteFromClipboardEventArgs` object when we receive a request from the `TermControl` to send it the clipboard's text content, we now display a warning to let the user choose whether to continue or not if the text is larger than 5 KiB or contains the _new line_ character, which can be a security issue if the user is pasting the text in a shell. These warnings can be disabled with the `largePasteWarning` and `multiLinePasteWarning` global settings respectively. Closes #2349
2020-07-01 21:43:28 +02:00
<data name="LargePasteDialog.CloseButtonText" xml:space="preserve">
<value>Cancel</value>
</data>
<data name="LargePasteDialog.Content" xml:space="preserve">
<value>You are about to paste text that is longer than 5 KiB. Do you wish to continue?</value>
</data>
<data name="LargePasteDialog.PrimaryButtonText" xml:space="preserve">
<value>Paste anyway</value>
</data>
<data name="LargePasteDialog.Title" xml:space="preserve">
<value>Warning</value>
</data>
<data name="MultiLinePasteDialog.CloseButtonText" xml:space="preserve">
<value>Cancel</value>
</data>
Show clipboard contents in multiple line paste warning dialog (#8744) When we display a dialog to warn the user that they are doing a multi-line paste, we show the clipboard contents The contents are shown in a scroll viewer with a fixed maximum height. Closes #7997
2021-01-13 00:00:27 +01:00
<data name="MultiLineWarningText.Text" xml:space="preserve">
Add settings to warn about large or multiline pastes (#6631) Before sending calling the `HandleClipboardData` member function on the `PasteFromClipboardEventArgs` object when we receive a request from the `TermControl` to send it the clipboard's text content, we now display a warning to let the user choose whether to continue or not if the text is larger than 5 KiB or contains the _new line_ character, which can be a security issue if the user is pasting the text in a shell. These warnings can be disabled with the `largePasteWarning` and `multiLinePasteWarning` global settings respectively. Closes #2349
2020-07-01 21:43:28 +02:00
<value>You are about to paste text that contains multiple lines. If you paste this text into your shell, it may result in the unexpected execution of commands. Do you wish to continue?</value>
</data>
<data name="MultiLinePasteDialog.PrimaryButtonText" xml:space="preserve">
<value>Paste anyway</value>
</data>
<data name="MultiLinePasteDialog.Title" xml:space="preserve">
<value>Warning</value>
</data>
Add support for the Command Palette (#6635) ## Summary of the Pull Request ![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif) This adds a first iteration on the command palette. Notable missing features are: * Commandline mode: This will be a follow-up PR, following the merge of #6537 * nested and iterable commands: These will additionally be a follow-up PR. This is also additionally based off the addenda in #6532. This does not bind a key for the palette by default. That will be done when the above follow-ups are completed. ## References * #2046 - The original command palette thread * #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work * #5674 and #6532 - specs * #6537 - related ## PR Checklist * [x] Closes #2046 - incidentally also closes #6645 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - delaying this until it's more polished. ## Detailed Description of the Pull Request / Additional comments * There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`. ## Validation Steps Performed * I've been playing with this for months. * Tests * Selfhost with the team
2020-06-26 22:38:02 +02:00
<data name="CommandPalette_SearchBox.PlaceholderText" xml:space="preserve">
<value>Type a command name...</value>
</data>
<data name="CommandPalette_NoMatchesText.Text" xml:space="preserve">
<value>No matching commands</value>
</data>
Command Palette: announce various mode and state changes to UIA (#9582) This commit introduces a few different announcements to the command palette. When you delete the `>`, it will announce that you have entered "command-line mode". When you reintroduce the `>`, it will announce that you are in "action search mode." When you enter a nested command, it will announce that you are looking at "more options for new tab..." or "more options for select color scheme...". When you search and find nothing, it will announce that there were no matching commands (or tabs!) Related to #7907.
2021-03-23 14:24:27 +01:00
<data name="CommandPaletteModeAnnouncement_ActionMode" xml:space="preserve">
<value>Action search mode</value>
<comment>This text will be read aloud using assistive technologies when the command palette switches into action (command search) mode.</comment>
</data>
<data name="CommandPaletteModeAnnouncement_TabSearchSwitchMode" xml:space="preserve">
<value>Tab title mode</value>
<comment>This text will be read aloud using assistive technologies when the command palette switches into a mode that filters tab names.</comment>
</data>
<data name="CommandPaletteModeAnnouncement_CommandlineMode" xml:space="preserve">
<value>Command-line mode</value>
<comment>This text will be read aloud using assistive technologies when the command palette switches into the raw commandline parsing mode.</comment>
</data>
<data name="CommandPalette_NestedCommandAnnouncement" xml:space="preserve">
<value>More options for "{}"</value>
<comment>This text will be read aloud using assistive technologies when the user selects a command that has additional options. The {} will be expanded to the name of the command containing more options.</comment>
</data>
Introduce parsed command line text to command palette (#8515) This commit introduces another optional text block in palette that will be shown in the command line mode (above the history). This text block will either contain a list of parsed command lines or a description why the parsing failed Closes #8344 Closes #7284
2020-12-16 03:03:13 +01:00
<data name="CommandPalette_ParsedCommandLine" xml:space="preserve">
<value>Executing command line will invoke the following commands:</value>
Add help text to 'more options' in command palette (#9271) Similar to #9262. This creates another data template specifically for command palette items that open up more options. We leverage the localization key from #9262 to apply help text to this template automatically. Using the data template approach, we now have no need for the `HasNestedComandsVisibilityConverter`, so that set of files is now deleted. The logic to detect nested commands was moved to the template selector. ## Validation Steps Performed Tested using NVDA. Addresses #7908 better
2021-02-24 21:02:09 +01:00
<comment>Will be followed by a list of strings describing parsed commands</comment>
Introduce parsed command line text to command palette (#8515) This commit introduces another optional text block in palette that will be shown in the command line mode (above the history). This text block will either contain a list of parsed command lines or a description why the parsing failed Closes #8344 Closes #7284
2020-12-16 03:03:13 +01:00
</data>
<data name="CommandPalette_FailedParsingCommandLine" xml:space="preserve">
<value>Failed parsing command line:</value>
</data>
Advanced Tab Switcher (#6732) ![TabSwitchingv2](https://user-images.githubusercontent.com/57155886/88237962-5505d500-cc35-11ea-8384-d91699155067.gif) ## Summary of the Pull Request This PR adds the Advanced Tab Switcher (ATS) to Terminal. It'll work similarly to VSCode's tab switcher. Because this implementation rides off a lot of the Command Palette's XAML code, it'll look just like the Command Palette, and also have support for tab title search. ## References #3753 - ATS Spec Closes #1502
2020-08-11 16:03:12 +02:00
<data name="CommandPaletteControlName" xml:space="preserve">
<value>Command Palette</value>
</data>
<data name="TabSwitcherControlName" xml:space="preserve">
<value>Tab Switcher</value>
</data>
<data name="TabSwitcher_SearchBoxText" xml:space="preserve">
<value>Type a tab name...</value>
</data>
<data name="TabSwitcher_NoMatchesText" xml:space="preserve">
<value>No matching tab name</value>
</data>
Add support for Commandline Mode to the CmdPal (#7293) ## Summary of the Pull Request Adds support for "commandline mode" to the command palette. ![cmdpal-commandline-mode](https://user-images.githubusercontent.com/18356694/90263053-bbd17500-de14-11ea-8726-fee48fec5888.gif) This allows the user to start typing a `wt.exe` commandline directly in the command palette, to run that commandline directly in the current window. This allows the user input something like `> nt -p Ubuntu ; sp -p ssh` and open up a new tab and split it _in the current window_. ## References * cmdpal megathread: #5400 * Kinda related to #4472 * built with the `wt` action from #6537 ## PR Checklist * [x] Closes #6677 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated - sure does, when the cmdpal docs are written in the first place :P ## Validation Steps Performed Tested manually
2020-08-24 23:39:07 +02:00
<data name="CmdPalCommandlinePrompt" xml:space="preserve">
<value>Enter a wt commandline to run</value>
<comment>{Locked="wt"} </comment>
</data>
Add tooltip text to Color Buttons (#6498) This commit adds tooltip text to every color button in the tab color picker.
2020-07-01 21:58:53 +02:00
<data name="CrimsonColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Crimson</value>
</data>
<data name="SteelBlueColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Steel Blue</value>
</data>
<data name="MediumSeaGreenColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Medium Sea Green</value>
Add actions missing in schema, descriptions for `toggleRetroEffect` (#6806) ## Summary of the Pull Request In the wake of #6635, a couple things got missed in merges: * `toggleRetroEffect` didn't get into the schema, nor did `renameTab` or `commandPalette`. * `toggleRetroEffect` also didn't get a name Furthermore, I thought it might be a good idea to start sticking commands into `bindings` even without `keys`. So I tried doing that for `opentabColorPicker` and `toggleRetroEffect`, and found immediately that the labels for the key chord still appear even when the text is empty. So I added some XAML magic to hide those when the text is empty. ## References * #6762 * #6691 * #6557 * #6635 ## PR Checklist * [x] Closes #6762 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * See also: https://docs.microsoft.com/en-us/windows/uwp/data-binding/data-binding-quickstart#formatting-or-converting-data-values-for-display - make sure to switch to C++/WinRT at the top! ## Validation Steps Performed Removed all my manual actions, ran the Terminal: ![image](https://user-images.githubusercontent.com/18356694/86652356-f5a79400-bfa9-11ea-9131-5b7d3e835e19.png)
2020-07-07 23:46:16 +02:00
</data>
Add tooltip text to Color Buttons (#6498) This commit adds tooltip text to every color button in the tab color picker.
2020-07-01 21:58:53 +02:00
<data name="DarkOrangeColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Dark Orange</value>
</data>
<data name="MediumVioletRedColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Medium Violet Red</value>
Add actions missing in schema, descriptions for `toggleRetroEffect` (#6806) ## Summary of the Pull Request In the wake of #6635, a couple things got missed in merges: * `toggleRetroEffect` didn't get into the schema, nor did `renameTab` or `commandPalette`. * `toggleRetroEffect` also didn't get a name Furthermore, I thought it might be a good idea to start sticking commands into `bindings` even without `keys`. So I tried doing that for `opentabColorPicker` and `toggleRetroEffect`, and found immediately that the labels for the key chord still appear even when the text is empty. So I added some XAML magic to hide those when the text is empty. ## References * #6762 * #6691 * #6557 * #6635 ## PR Checklist * [x] Closes #6762 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * See also: https://docs.microsoft.com/en-us/windows/uwp/data-binding/data-binding-quickstart#formatting-or-converting-data-values-for-display - make sure to switch to C++/WinRT at the top! ## Validation Steps Performed Removed all my manual actions, ran the Terminal: ![image](https://user-images.githubusercontent.com/18356694/86652356-f5a79400-bfa9-11ea-9131-5b7d3e835e19.png)
2020-07-07 23:46:16 +02:00
</data>
Add tooltip text to Color Buttons (#6498) This commit adds tooltip text to every color button in the tab color picker.
2020-07-01 21:58:53 +02:00
<data name="DodgerBlueColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Dodger Blue</value>
</data>
<data name="LimeGreenColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Lime Green</value>
</data>
<data name="YellowColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Yellow</value>
</data>
<data name="BlueVioletColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Blue Violet</value>
</data>
<data name="SlateBlueColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Slate Blue</value>
</data>
<data name="LimeColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Lime</value>
</data>
<data name="TanColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Tan</value>
</data>
<data name="MagentaColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Magenta</value>
</data>
<data name="CyanColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Cyan</value>
</data>
<data name="SkyBlueColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Sky Blue</value>
</data>
<data name="DarkGrayColorButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Dark Gray</value>
</data>
Open up content dialogs for invalid URIs and unsupported schemes (#7523) If a user clicks a link that is either invalid (cannot be parsed) or has a scheme we do not support (like file or mailto (for now)), we open up a dialog box telling them the issue. References #5001
2020-09-11 02:55:36 +02:00
<data name="InvalidUriText" xml:space="preserve">
<value>This link is invalid:</value>
</data>
<data name="UnsupportedSchemeText" xml:space="preserve">
<value>This link type is currently not supported:</value>
</data>
<data name="CouldNotOpenUriDialog.PrimaryButtonText" xml:space="preserve">
<value>Cancel</value>
</data>
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<data name="SettingsTab" xml:space="preserve">
<value>Settings</value>
</data>
Display a warning for when we fail to write to the settings file (#7950) We wrap the call to `_WriteSettings` in `CascadiaSettingsSerialization.cpp` in a try/catch block, and if we catch an error we append a warning telling the user to check the permissions on their settings file. Closes #7727
2020-10-23 02:21:07 +02:00
<data name="FailedToWriteToSettings" xml:space="preserve">
<value>We could not write to your settings file. Check the permissions on that file to ensure that the read-only flag is not set and that write access is granted.</value>
</data>
Enable moving back to the root level in the command palette (#8051) This commit adds functionality so that users can move back from sub menu whenever they want. As a result, users no longer have to close command palette and open it again to get all commands again. Closes #7910
2020-11-05 01:19:52 +01:00
<data name="ParentCommandBackButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name" xml:space="preserve">
<value>Back</value>
</data>
<data name="ParentCommandBackButton.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip" xml:space="preserve">
<value>Back</value>
</data>
Warn when font isn't found and another is chosen (#8207) Display a warning message when the DirectX renderer resolves a font that isn't the one you selected to warn that it couldn't be found. Also I wrote the dialog event chain out of `TermControl` to be reusable in the future for other messages the control might want to tell a host about and various levels. ## Validation Steps Performed - Manual validation, setting bad font name, fixing font name with `settings.json`. Closes #1017
2020-11-11 03:24:06 +01:00
<data name="ControlNoticeDialog.PrimaryButtonText" xml:space="preserve">
<value>OK</value>
</data>
<data name="NoticeDebug" xml:space="preserve">
<value>Debug</value>
</data>
<data name="NoticeError" xml:space="preserve">
<value>Error</value>
</data>
<data name="NoticeInfo" xml:space="preserve">
<value>Information</value>
</data>
<data name="NoticeWarning" xml:space="preserve">
<value>Warning</value>
</data>
Show clipboard contents in multiple line paste warning dialog (#8744) When we display a dialog to warn the user that they are doing a multi-line paste, we show the clipboard contents The contents are shown in a scroll viewer with a fixed maximum height. Closes #7997
2021-01-13 00:00:27 +01:00
<data name="ClipboardTextHeader.Text" xml:space="preserve">
<value>Clipboard contents (preview):</value>
</data>
[PICK] Cherry-pick loc key from 83d35c119
2021-02-24 03:57:57 +01:00
<data name="CommandPalette_MoreOptions.[using:Windows.UI.Xaml.Automation]AutomationProperties.HelpText" xml:space="preserve">
<value>More options</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 18:08:03 +02:00
<data name="WindowIdLabel" xml:space="preserve">
<value>Window</value>
<comment>This is displayed as a label for a number, like "Window: 10"</comment>
</data>
<data name="UnnamedWindowName" xml:space="preserve">
<value>unnamed window</value>
<comment>text used to identify when a window hasn't been assigned a name by the user</comment>
</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 18:00:04 +02:00
<data name="WindowRenamer.Subtitle" xml:space="preserve">
<value>Enter a new name:</value>
</data>
<data name="WindowRenamer.ActionButtonContent" xml:space="preserve">
<value>OK</value>
</data>
<data name="WindowRenamer.CloseButtonContent" xml:space="preserve">
<value>Cancel</value>
</data>
<data name="RenameFailedToast.Title" xml:space="preserve">
<value>Failed to rename window</value>
</data>
<data name="RenameFailedToast.Subtitle" xml:space="preserve">
<value>Another window with that name already exists</value>
</data>
Display correct tooltip when window is maximized (#9412) ## Summary of the Pull Request Instead of displaying "Maximize" in the tooltip for the maximize/restore button even when the window is maximized, it now displays "Restore Down". ## References Fixes #5693 ## PR Checklist * [X] Closes #5693 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [X] Tests added/passed ## Validation Steps Performed Tested manually.
2021-03-09 18:41:29 +01:00
<data name="WindowMaximizeButtonToolTip" xml:space="preserve">
<value>Maximize</value>
</data>
<data name="WindowRestoreDownButtonToolTip" xml:space="preserve">
<value>Restore Down</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 18:00:04 +02:00
</root>
Reference in a new issue Copy permalink