mirror of
https://github.com/microsoft/terminal.git
synced 2026-04-07 14:50:55 +00:00
Compare commits
7 Commits
dev/duhowe
...
dev/miniks
| Author | SHA1 | Date | |
|---|---|---|---|
|
1faadec541 | ||
|
|
d693e9ea0e | ||
|
65d4fc6d76 | ||
|
|
40e1e18b84 | ||
|
|
919bd417f3 | ||
|
|
0cdd752004 | ||
|
4435e6ac0a |
@@ -1,19 +1,17 @@
|
||||
|
||||
AccessModifierOffset: -4
|
||||
AlignAfterOpenBracket: Align
|
||||
AllowAllArgumentsOnNextLine: true
|
||||
AlignConsecutiveMacros: false
|
||||
#AllowAllArgumentsOnNextLine: false
|
||||
AlignConsecutiveAssignments: false
|
||||
AlignConsecutiveDeclarations: false
|
||||
AllowAllConstructorInitializersOnNextLine: true
|
||||
#AllowAllConstructorInitializersOnNextLine: false
|
||||
AlignEscapedNewlines: Left
|
||||
AlignOperands: true
|
||||
AlignTrailingComments: false
|
||||
AllowAllParametersOfDeclarationOnNextLine: false
|
||||
AllowShortBlocksOnASingleLine: Never
|
||||
AllowShortFunctionsOnASingleLine: Inline
|
||||
AllowShortCaseLabelsOnASingleLine: false
|
||||
AllowShortIfStatementsOnASingleLine: Never
|
||||
AllowShortIfStatementsOnASingleLine: false
|
||||
#AllowShortLambdasOnASingleLine: Inline
|
||||
AllowShortLoopsOnASingleLine: false
|
||||
AlwaysBreakAfterReturnType: None
|
||||
@@ -22,7 +20,6 @@ AlwaysBreakTemplateDeclarations: Yes
|
||||
BinPackArguments: false
|
||||
BinPackParameters: false
|
||||
BraceWrapping:
|
||||
AfterCaseLabel: true
|
||||
AfterClass: true
|
||||
AfterControlStatement: true
|
||||
AfterEnum: true
|
||||
@@ -50,7 +47,6 @@ ConstructorInitializerAllOnOneLineOrOnePerLine: true
|
||||
ConstructorInitializerIndentWidth: 4
|
||||
ContinuationIndentWidth: 4
|
||||
Cpp11BracedListStyle: false
|
||||
DeriveLineEnding: true
|
||||
DerivePointerAlignment: false
|
||||
FixNamespaceComments: false
|
||||
IncludeBlocks: Regroup
|
||||
@@ -77,7 +73,7 @@ ReflowComments: false
|
||||
SortIncludes: false
|
||||
SortUsingDeclarations: true
|
||||
SpaceAfterCStyleCast: false
|
||||
SpaceAfterLogicalNot: false
|
||||
#SpaceAfterLogicalNot: false
|
||||
SpaceAfterTemplateKeyword: false
|
||||
SpaceBeforeAssignmentOperators: true
|
||||
SpaceBeforeCpp11BracedList: false
|
||||
@@ -92,6 +88,6 @@ SpacesInCStyleCastParentheses: false
|
||||
SpacesInContainerLiterals: false
|
||||
SpacesInParentheses: false
|
||||
SpacesInSquareBrackets: false
|
||||
Standard: Latest
|
||||
Standard: Cpp11
|
||||
TabWidth: 4
|
||||
UseTab: Never
|
||||
|
||||
12
.github/ISSUE_TEMPLATE/config.yml
vendored
12
.github/ISSUE_TEMPLATE/config.yml
vendored
@@ -1,12 +0,0 @@
|
||||
blank_issues_enabled: true
|
||||
|
||||
contact_links:
|
||||
- name: Microsoft Security Response Center 🔐
|
||||
url: https://msrc.microsoft.com/create-report
|
||||
about: Please report security vulnerabilities here.
|
||||
- name: Windows Terminal Documentation issue 📄
|
||||
url: https://github.com/MicrosoftDocs/terminal/issues/new
|
||||
about: Report issues with the documentation for the Windows Terminal (in docs.microsoft.com/windows/terminal)
|
||||
- name: Console Documentation issue 📄
|
||||
url: https://github.com/MicrosoftDocs/console-docs/issues/new
|
||||
about: Report issues with the documentation for the Console (in docs.microsoft.com/windows/console)
|
||||
3
.github/PULL_REQUEST_TEMPLATE.md
vendored
3
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -9,8 +9,7 @@
|
||||
* [ ] Closes #xxx
|
||||
* [ ] 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.
|
||||
* [ ] Requires documentation to be 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 -->
|
||||
|
||||
42
.github/linters/.markdown-lint.yml
vendored
42
.github/linters/.markdown-lint.yml
vendored
@@ -1,42 +0,0 @@
|
||||
---
|
||||
###########################
|
||||
###########################
|
||||
## Markdown Linter rules ##
|
||||
###########################
|
||||
###########################
|
||||
|
||||
# Linter rules doc:
|
||||
# - https://github.com/DavidAnson/markdownlint
|
||||
#
|
||||
# Note:
|
||||
# To comment out a single error:
|
||||
# <!-- markdownlint-disable -->
|
||||
# any violations you want
|
||||
# <!-- markdownlint-restore -->
|
||||
#
|
||||
# To run the linter locally:
|
||||
# 1. install the npm package:
|
||||
# `npm install -g markdownlint-cli`
|
||||
# 2. Then run it in the root of the repo with
|
||||
# `markdownlint -c .github\linters\.markdown-lint.yml ./*.md`
|
||||
|
||||
###############
|
||||
# Rules by id #
|
||||
###############
|
||||
MD004: false # Unordered list style
|
||||
MD007:
|
||||
indent: 2 # Unordered list indentation
|
||||
MD013:
|
||||
line_length: 400 # Line length 80 is far to short
|
||||
MD024: false # Allow multiple headings with same content
|
||||
MD026:
|
||||
punctuation: ".,;:!。，；:" # List of not allowed
|
||||
MD029: false # Ordered list item prefix
|
||||
MD033: false # Allow inline HTML
|
||||
MD036: false # Emphasis used instead of a heading
|
||||
MD040: false # Allow ``` blocks in md files with no language specified
|
||||
|
||||
#################
|
||||
# Rules by tags #
|
||||
#################
|
||||
blank_lines: false # Error on blank lines
|
||||
@@ -14,7 +14,7 @@ The point of doing all this work in public is to ensure that we are holding ours
|
||||
|
||||
The team triages new issues several times a week. During triage, the team uses labels to categorize, manage, and drive the project workflow.
|
||||
|
||||
We employ [a bot engine](https://github.com/microsoft/terminal/blob/main/doc/bot.md) to help us automate common processes within our workflow.
|
||||
We employ [a bot engine](https://github.com/microsoft/terminal/blob/master/doc/bot.md) to help us automate common processes within our workflow.
|
||||
|
||||
We drive the bot by tagging issues with specific labels which cause the bot engine to close issues, merge branches, etc. This bot engine helps us keep the repo clean by automating the process of notifying appropriate parties if/when information/follow-up is needed, and closing stale issues/PRs after reminders have remained unanswered for several days.
|
||||
|
||||
@@ -140,13 +140,6 @@ Once you've discussed your proposed feature/fix/etc. with a team member, and you
|
||||
1. Create & push a feature branch
|
||||
1. Create a [Draft Pull Request (PR)](https://github.blog/2019-02-14-introducing-draft-pull-requests/)
|
||||
1. Work on your changes
|
||||
1. Build and see if it works. Consult [How to build OpenConsole](./doc/building.md) if you have problems.
|
||||
|
||||
### Testing
|
||||
|
||||
Testing is a key component in the development workflow. Both Windows Terminal and Windows Console use TAEF(the Test Authoring and Execution Framework) as the main framework for testing.
|
||||
|
||||
If your changes affect existing test cases, or you're working on brand new features and also the accompanying test cases, see [TAEF](./doc/TAEF.md) for more information about how to validate your work locally.
|
||||
|
||||
### Code Review
|
||||
|
||||
@@ -156,7 +149,7 @@ When you'd like the team to take a look, (even if the work is not yet fully-comp
|
||||
|
||||
### Merge
|
||||
|
||||
Once your code has been reviewed and approved by the requisite number of team members, it will be merged into the main branch. Once merged, your PR will be automatically closed.
|
||||
Once your code has been reviewed and approved by the requisite number of team members, it will be merged into the master branch. Once merged, your PR will be automatically closed.
|
||||
|
||||
---
|
||||
|
||||
|
||||
73
NOTICE.md
73
NOTICE.md
@@ -2,7 +2,7 @@
|
||||
Do Not Translate or Localize
|
||||
|
||||
This software incorporates material from third parties. Microsoft makes certain
|
||||
open source code available at [http://3rdpartysource.microsoft.com](http://3rdpartysource.microsoft.com), or you may
|
||||
open source code available at http://3rdpartysource.microsoft.com, or you may
|
||||
send a check or money order for US $5.00, including the product name, the open
|
||||
source component name, and version number, to:
|
||||
|
||||
@@ -20,7 +20,7 @@ General Public License.
|
||||
|
||||
## jsoncpp
|
||||
|
||||
**Source**: [https://github.com/open-source-parsers/jsoncpp](https://github.com/open-source-parsers/jsoncpp)
|
||||
**Source**: https://github.com/open-source-parsers/jsoncpp
|
||||
|
||||
### License
|
||||
|
||||
@@ -48,9 +48,39 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
```
|
||||
|
||||
## telnetpp
|
||||
|
||||
**Source**: https://github.com/KazDragon/telnetpp
|
||||
|
||||
### License
|
||||
|
||||
```
|
||||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2015-2017 Matthew Chaplain a.k.a KazDragon
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
```
|
||||
|
||||
## chromium/base/numerics
|
||||
|
||||
**Source**: [https://github.com/chromium/chromium/tree/master/base/numerics](https://github.com/chromium/chromium/tree/master/base/numerics)
|
||||
**Source**: https://github.com/chromium/chromium/tree/master/base/numerics
|
||||
|
||||
### License
|
||||
|
||||
@@ -86,7 +116,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
## kimwalisch/libpopcnt
|
||||
|
||||
**Source**: [https://github.com/kimwalisch/libpopcnt](https://github.com/kimwalisch/libpopcnt)
|
||||
**Source**: https://github.com/kimwalisch/libpopcnt
|
||||
|
||||
### License
|
||||
|
||||
@@ -122,7 +152,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
## dynamic_bitset
|
||||
|
||||
**Source**: [https://github.com/pinam45/dynamic_bitset](https://github.com/pinam45/dynamic_bitset)
|
||||
**Source**: https://github.com/pinam45/dynamic_bitset
|
||||
|
||||
### License
|
||||
|
||||
@@ -151,9 +181,9 @@ SOFTWARE.
|
||||
|
||||
```
|
||||
|
||||
## \{fmt\}
|
||||
## {fmt}
|
||||
|
||||
**Source**: [https://github.com/fmtlib/fmt](https://github.com/fmtlib/fmt)
|
||||
**Source**: https://github.com/fmtlib/fmt
|
||||
|
||||
### License
|
||||
|
||||
@@ -188,32 +218,3 @@ of this Software are embedded into a machine-executable object form of such
|
||||
source code, you may redistribute such embedded portions in such object form
|
||||
without including the above copyright and permission notices.
|
||||
```
|
||||
|
||||
## interval_tree
|
||||
|
||||
**Source**: [https://github.com/ekg/IntervalTree](https://github.com/ekg/IntervalTree)
|
||||
|
||||
### License
|
||||
|
||||
```
|
||||
Copyright (c) 2011 Erik Garrison
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
|
||||
of the Software, and to permit persons to whom the Software is furnished to do
|
||||
so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
|
||||
```
|
||||
|
||||
@@ -8,12 +8,7 @@
|
||||
<!--<add key="Static Package Dependencies" value="dep\packages" />-->
|
||||
|
||||
<!-- Use our own NuGet Feed -->
|
||||
<add key="TerminalDependencies" value="https://pkgs.dev.azure.com/ms/terminal/_packaging/TerminalDependencies/nuget/v3/index.json" />
|
||||
|
||||
<!-- Temporarily? use the feeds from our friends in MUX for Helix test stuff -->
|
||||
<add key="dotnetfeed" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
|
||||
<add key="dnceng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
|
||||
<add key="MUX-Dependencies" value="https://pkgs.dev.azure.com/ms/microsoft-ui-xaml/_packaging/MUX-Dependencies/nuget/v3/index.json" />
|
||||
<add key="Windows Terminal NuGet Feed" value="https://terminalnuget.blob.core.windows.net/feed/index.json" />
|
||||
|
||||
<!-- Internal NuGet feeds that may not be accessible outside Microsoft corporate network -->
|
||||
<!--<add key="TAEF - internal" value="https://microsoft.pkgs.visualstudio.com/DefaultCollection/_packaging/Taef/nuget/v3/index.json" />
|
||||
|
||||
706
OpenConsole.sln
706
OpenConsole.sln
File diff suppressed because it is too large
Load Diff
247
README.md
247
README.md
@@ -6,26 +6,22 @@ This repository contains the source code for:
|
||||
* [Windows Terminal Preview](https://aka.ms/terminal-preview)
|
||||
* The Windows console host (`conhost.exe`)
|
||||
* Components shared between the two projects
|
||||
* [ColorTool](https://github.com/microsoft/terminal/tree/main/src/tools/ColorTool)
|
||||
* [Sample projects](https://github.com/microsoft/terminal/tree/main/samples)
|
||||
that show how to consume the Windows Console APIs
|
||||
* [ColorTool](https://github.com/Microsoft/Terminal/tree/master/src/tools/ColorTool)
|
||||
* [Sample projects](https://github.com/Microsoft/Terminal/tree/master/samples) that show how to consume the Windows Console APIs
|
||||
|
||||
Related repositories include:
|
||||
|
||||
* [Windows Terminal Documentation](https://docs.microsoft.com/windows/terminal)
|
||||
([Repo: Contribute to the docs](https://github.com/MicrosoftDocs/terminal))
|
||||
* [Windows Terminal Documentation](https://docs.microsoft.com/windows/terminal) ([Repo: Contribute to the docs](https://github.com/MicrosoftDocs/terminal))
|
||||
* [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs)
|
||||
* [Cascadia Code Font](https://github.com/Microsoft/Cascadia-Code)
|
||||
|
||||
## Installing and running Windows Terminal
|
||||
|
||||
> 🔴 Note: Windows Terminal requires Windows 10 1903 (build 18362) or later
|
||||
> 👉 Note: Windows Terminal requires Windows 10 1903 (build 18362) or later
|
||||
|
||||
### Microsoft Store [Recommended]
|
||||
|
||||
Install the [Windows Terminal from the Microsoft Store][store-install-link].
|
||||
This allows you to always be on the latest version when we release new builds
|
||||
with automatic upgrades.
|
||||
Install the [Windows Terminal from the Microsoft Store][store-install-link]. This allows you to always be on the latest version when we release new builds with automatic upgrades.
|
||||
|
||||
This is our preferred method.
|
||||
|
||||
@@ -33,21 +29,16 @@ This is our preferred method.
|
||||
|
||||
#### Via GitHub
|
||||
|
||||
For users who are unable to install Terminal from the Microsoft Store, Terminal
|
||||
builds can be manually downloaded from this repository's [Releases
|
||||
page](https://github.com/microsoft/terminal/releases).
|
||||
For users who are unable to install Terminal from the Microsoft Store, Terminal builds can be manually downloaded from this repository's [Releases page](https://github.com/microsoft/terminal/releases).
|
||||
|
||||
> 🔴 Note: If you install Terminal manually:
|
||||
> ⚠ Note: If you install Terminal manually:
|
||||
>
|
||||
> * Terminal will not auto-update when new builds are released so you will need
|
||||
> to regularly install the latest Terminal release to receive all the latest
|
||||
> fixes and improvements!
|
||||
> * Be sure to install the [Desktop Bridge VC++ v14 Redistributable Package](https://www.microsoft.com/en-us/download/details.aspx?id=53175) otherwise Terminal may not install and/or run and may crash at startup
|
||||
> * Terminal will not auto-update when new builds are released so you will need to regularly install the latest Terminal release to receive all the latest fixes and improvements!
|
||||
|
||||
#### Via Windows Package Manager CLI (aka winget)
|
||||
|
||||
[winget](https://github.com/microsoft/winget-cli) users can download and install
|
||||
the latest Terminal release by installing the `Microsoft.WindowsTerminal`
|
||||
package:
|
||||
[winget](https://github.com/microsoft/winget-cli) users can download and install the latest Terminal release by installing the `Microsoft.WindowsTerminal` package:
|
||||
|
||||
```powershell
|
||||
winget install --id=Microsoft.WindowsTerminal -e
|
||||
@@ -55,8 +46,7 @@ winget install --id=Microsoft.WindowsTerminal -e
|
||||
|
||||
#### Via Chocolatey (unofficial)
|
||||
|
||||
[Chocolatey](https://chocolatey.org) users can download and install the latest
|
||||
Terminal release by installing the `microsoft-windows-terminal` package:
|
||||
[Chocolatey](https://chocolatey.org) users can download and install the latest Terminal release by installing the `microsoft-windows-terminal` package:
|
||||
|
||||
```powershell
|
||||
choco install microsoft-windows-terminal
|
||||
@@ -68,144 +58,66 @@ To upgrade Windows Terminal using Chocolatey, run the following:
|
||||
choco upgrade microsoft-windows-terminal
|
||||
```
|
||||
|
||||
If you have any issues when installing/upgrading the package please go to the
|
||||
[Windows Terminal package
|
||||
page](https://chocolatey.org/packages/microsoft-windows-terminal) and follow the
|
||||
[Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
|
||||
|
||||
#### Via Scoop (unofficial)
|
||||
|
||||
[Scoop](https://scoop.sh) users can download and install the latest Terminal
|
||||
release by installing the `windows-terminal` package:
|
||||
|
||||
```powershell
|
||||
scoop bucket add extras
|
||||
scoop install windows-terminal
|
||||
```
|
||||
|
||||
To update Windows Terminal using Scoop, run the following:
|
||||
|
||||
```powershell
|
||||
scoop update windows-terminal
|
||||
```
|
||||
|
||||
If you have any issues when installing/updating the package, please search for
|
||||
or report the same on the [issues
|
||||
page](https://github.com/lukesampson/scoop-extras/issues) of Scoop Extras bucket
|
||||
repository.
|
||||
If you have any issues when installing/upgrading the package please go to the [Windows Terminal package page](https://chocolatey.org/packages/microsoft-windows-terminal) and follow the [Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
|
||||
|
||||
---
|
||||
|
||||
## Windows Terminal 2.0 Roadmap
|
||||
|
||||
The plan for delivering Windows Terminal 2.0 [is described
|
||||
here](/doc/terminal-v2-roadmap.md) and will be updated as the project proceeds.
|
||||
|
||||
## Project Build Status
|
||||
|
||||
Project|Build Status
|
||||
---|---
|
||||
Terminal|[](https://dev.azure.com/ms/terminal/_build?definitionId=136)
|
||||
ColorTool|
|
||||
Terminal|[](https://dev.azure.com/ms/Terminal/_build?definitionId=136)
|
||||
ColorTool|
|
||||
|
||||
---
|
||||
|
||||
## Terminal & Console Overview
|
||||
|
||||
Please take a few minutes to review the overview below before diving into the
|
||||
code:
|
||||
Please take a few minutes to review the overview below before diving into the code:
|
||||
|
||||
### Windows Terminal
|
||||
|
||||
Windows Terminal is a new, modern, feature-rich, productive terminal application
|
||||
for command-line users. It includes many of the features most frequently
|
||||
requested by the Windows command-line community including support for tabs, rich
|
||||
text, globalization, configurability, theming & styling, and more.
|
||||
Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more.
|
||||
|
||||
The Terminal will also need to meet our goals and measures to ensure it remains
|
||||
fast and efficient, and doesn't consume vast amounts of memory or power.
|
||||
The Terminal will also need to meet our goals and measures to ensure it remains fast and efficient, and doesn't consume vast amounts of memory or power.
|
||||
|
||||
### The Windows Console Host
|
||||
|
||||
The Windows Console host, `conhost.exe`, is Windows' original command-line user
|
||||
experience. It also hosts Windows' command-line infrastructure and the Windows
|
||||
Console API server, input engine, rendering engine, user preferences, etc. The
|
||||
console host code in this repository is the actual source from which the
|
||||
`conhost.exe` in Windows itself is built.
|
||||
The Windows Console host, `conhost.exe`, is Windows' original command-line user experience. It also hosts Windows' command-line infrastructure and the Windows Console API server, input engine, rendering engine, user preferences, etc. The console host code in this repository is the actual source from which the `conhost.exe` in Windows itself is built.
|
||||
|
||||
Since taking ownership of the Windows command-line in 2014, the team added
|
||||
several new features to the Console, including background transparency,
|
||||
line-based selection, support for [ANSI / Virtual Terminal
|
||||
sequences](https://en.wikipedia.org/wiki/ANSI_escape_code), [24-bit
|
||||
color](https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/),
|
||||
a [Pseudoconsole
|
||||
("ConPTY")](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/),
|
||||
and more.
|
||||
Since taking ownership of the Windows command-line in 2014, the team added several new features to the Console, including background transparency, line-based selection, support for [ANSI / Virtual Terminal sequences](https://en.wikipedia.org/wiki/ANSI_escape_code), [24-bit color](https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/), a [Pseudoconsole ("ConPTY")](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/), and more.
|
||||
|
||||
However, because Windows Console's primary goal is to maintain backward
|
||||
compatibility, we have been unable to add many of the features the community
|
||||
(and the team) have been wanting for the last several years including tabs,
|
||||
unicode text, and emoji.
|
||||
However, because Windows Console's primary goal is to maintain backward compatibility, we have been unable to add many of the features the community (and the team) have been wanting for the last several years including tabs, unicode text, and emoji.
|
||||
|
||||
These limitations led us to create the new Windows Terminal.
|
||||
|
||||
> You can read more about the evolution of the command-line in general, and the
|
||||
> Windows command-line specifically in [this accompanying series of blog
|
||||
> posts](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/)
|
||||
> on the Command-Line team's blog.
|
||||
> You can read more about the evolution of the command-line in general, and the Windows command-line specifically in [this accompanying series of blog posts](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/) on the Command-Line team's blog.
|
||||
|
||||
### Shared Components
|
||||
|
||||
While overhauling Windows Console, we modernized its codebase considerably,
|
||||
cleanly separating logical entities into modules and classes, introduced some
|
||||
key extensibility points, replaced several old, home-grown collections and
|
||||
containers with safer, more efficient [STL
|
||||
containers](https://docs.microsoft.com/en-us/cpp/standard-library/stl-containers?view=vs-2019),
|
||||
and made the code simpler and safer by using Microsoft's [Windows Implementation
|
||||
Libraries - WIL](https://github.com/Microsoft/wil).
|
||||
While overhauling Windows Console, we modernized its codebase considerably, cleanly separating logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient [STL containers](https://docs.microsoft.com/en-us/cpp/standard-library/stl-containers?view=vs-2019), and made the code simpler and safer by using Microsoft's [Windows Implementation Libraries - WIL](https://github.com/Microsoft/wil).
|
||||
|
||||
This overhaul resulted in several of Console's key components being available
|
||||
for re-use in any terminal implementation on Windows. These components include a
|
||||
new DirectWrite-based text layout and rendering engine, a text buffer capable of
|
||||
storing both UTF-16 and UTF-8, a VT parser/emitter, and more.
|
||||
This overhaul resulted in several of Console's key components being available for re-use in any terminal implementation on Windows. These components include a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, a VT parser/emitter, and more.
|
||||
|
||||
### Creating the new Windows Terminal
|
||||
|
||||
When we started planning the new Windows Terminal application, we explored and
|
||||
evaluated several approaches and technology stacks. We ultimately decided that
|
||||
our goals would be best met by continuing our investment in our C++ codebase,
|
||||
which would allow us to reuse several of the aforementioned modernized
|
||||
components in both the existing Console and the new Terminal. Further, we
|
||||
realized that this would allow us to build much of the Terminal's core itself as
|
||||
a reusable UI control that others can incorporate into their own applications.
|
||||
When we started planning the new Windows Terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by continuing our investment in our C++ codebase, which would allow us to reuse several of the aforementioned modernized components in both the existing Console and the new Terminal. Further, we realized that this would allow us to build much of the Terminal's core itself as a reusable UI control that others can incorporate into their own applications.
|
||||
|
||||
The result of this work is contained within this repo and delivered as the
|
||||
Windows Terminal application you can download from the Microsoft Store, or
|
||||
[directly from this repo's
|
||||
releases](https://github.com/microsoft/terminal/releases).
|
||||
The result of this work is contained within this repo and delivered as the Windows Terminal application you can download from the Microsoft Store, or [directly from this repo's releases](https://github.com/microsoft/terminal/releases).
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
For more information about Windows Terminal, you may find some of these
|
||||
resources useful and interesting:
|
||||
For more information about Windows Terminal, you may find some of these resources useful and interesting:
|
||||
|
||||
* [Command-Line Blog](https://devblogs.microsoft.com/commandline)
|
||||
* [Command-Line Backgrounder Blog
|
||||
Series](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/)
|
||||
* Windows Terminal Launch: [Terminal "Sizzle
|
||||
Video"](https://www.youtube.com/watch?v=8gw0rXPMMPE&list=PLEHMQNlPj-Jzh9DkNpqipDGCZZuOwrQwR&index=2&t=0s)
|
||||
* Windows Terminal Launch: [Build 2019
|
||||
Session](https://www.youtube.com/watch?v=KMudkRcwjCw)
|
||||
* Run As Radio: [Show 645 - Windows Terminal with Richard
|
||||
Turner](http://www.runasradio.com/Shows/Show/645)
|
||||
* Azure Devops Podcast: [Episode 54 - Kayla Cinnamon and Rich Turner on DevOps
|
||||
on the Windows
|
||||
Terminal](http://azuredevopspodcast.clear-measure.com/kayla-cinnamon-and-rich-turner-on-devops-on-the-windows-terminal-team-episode-54)
|
||||
* Microsoft Ignite 2019 Session: [The Modern Windows Command Line: Windows
|
||||
Terminal -
|
||||
BRK3321](https://myignite.techcommunity.microsoft.com/sessions/81329?source=sessions)
|
||||
* [Command-Line Backgrounder Blog Series](https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/)
|
||||
* Windows Terminal Launch: [Terminal "Sizzle Video"](https://www.youtube.com/watch?v=8gw0rXPMMPE&list=PLEHMQNlPj-Jzh9DkNpqipDGCZZuOwrQwR&index=2&t=0s)
|
||||
* Windows Terminal Launch: [Build 2019 Session](https://www.youtube.com/watch?v=KMudkRcwjCw)
|
||||
* Run As Radio: [Show 645 - Windows Terminal with Richard Turner](http://www.runasradio.com/Shows/Show/645)
|
||||
* Azure Devops Podcast: [Episode 54 - Kayla Cinnamon and Rich Turner on DevOps on the Windows Terminal](http://azuredevopspodcast.clear-measure.com/kayla-cinnamon-and-rich-turner-on-devops-on-the-windows-terminal-team-episode-54)
|
||||
* Microsoft Ignite 2019 Session: [The Modern Windows Command Line: Windows Terminal - BRK3321](https://myignite.techcommunity.microsoft.com/sessions/81329?source=sessions)
|
||||
|
||||
---
|
||||
|
||||
@@ -215,72 +127,48 @@ resources useful and interesting:
|
||||
|
||||
Cause: You're launching the incorrect solution in Visual Studio.
|
||||
|
||||
Solution: Make sure you're building & deploying the `CascadiaPackage` project in
|
||||
Visual Studio.
|
||||
Solution: Make sure you're building & deploying the `CascadiaPackage` project in Visual Studio.
|
||||
|
||||
> ⚠ Note: `OpenConsole.exe` is just a locally-built `conhost.exe`, the classic
|
||||
> Windows Console that hosts Windows' command-line infrastructure. OpenConsole
|
||||
> is used by Windows Terminal to connect to and communicate with command-line
|
||||
> applications (via
|
||||
> [ConPty](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/)).
|
||||
> ⚠ Note: `OpenConsole.exe` is just a locally-built `conhost.exe`, the classic Windows Console that hosts Windows' command-line infrastructure. OpenConsole is used by Windows Terminal to connect to and communicate with command-line applications (via [ConPty](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/)).
|
||||
|
||||
---
|
||||
|
||||
## Documentation
|
||||
|
||||
All project documentation is located at aka.ms/terminal-docs. If you would like
|
||||
to contribute to the documentation, please submit a pull request on the [Windows
|
||||
Terminal Documentation repo](https://github.com/MicrosoftDocs/terminal).
|
||||
All project documentation is located at aka.ms/terminal-docs. If you would like to contribute to the documentation, please submit a pull request on the [Windows Terminal Documentation repo](https://github.com/MicrosoftDocs/terminal).
|
||||
|
||||
---
|
||||
|
||||
## Contributing
|
||||
|
||||
We are excited to work alongside you, our amazing community, to build and
|
||||
enhance Windows Terminal\!
|
||||
We are excited to work alongside you, our amazing community, to build and enhance Windows Terminal\!
|
||||
|
||||
***BEFORE you start work on a feature/fix***, please read & follow our
|
||||
[Contributor's
|
||||
Guide](https://github.com/microsoft/terminal/blob/main/CONTRIBUTING.md) to
|
||||
help avoid any wasted or duplicate effort.
|
||||
***BEFORE you start work on a feature/fix***, please read & follow our [Contributor's Guide](https://github.com/microsoft/terminal/blob/master/CONTRIBUTING.md) to help avoid any wasted or duplicate effort.
|
||||
|
||||
## Communicating with the Team
|
||||
|
||||
The easiest way to communicate with the team is via GitHub issues.
|
||||
|
||||
Please file new issues, feature requests and suggestions, but **DO search for
|
||||
similar open/closed pre-existing issues before creating a new issue.**
|
||||
Please file new issues, feature requests and suggestions, but **DO search for similar open/closed pre-existing issues before creating a new issue.**
|
||||
|
||||
If you would like to ask a question that you feel doesn't warrant an issue
|
||||
(yet), please reach out to us via Twitter:
|
||||
If you would like to ask a question that you feel doesn't warrant an issue (yet), please reach out to us via Twitter:
|
||||
|
||||
* Kayla Cinnamon, Program Manager:
|
||||
[@cinnamon\_msft](https://twitter.com/cinnamon_msft)
|
||||
* Kayla Cinnamon, Program Manager: [@cinnamon\_msft](https://twitter.com/cinnamon_msft)
|
||||
* Dustin Howett, Engineering Lead: [@dhowett](https://twitter.com/DHowett)
|
||||
* Michael Niksa, Senior Developer:
|
||||
[@michaelniksa](https://twitter.com/MichaelNiksa)
|
||||
* Michael Niksa, Senior Developer: [@michaelniksa](https://twitter.com/MichaelNiksa)
|
||||
* Mike Griese, Developer: [@zadjii](https://twitter.com/zadjii)
|
||||
* Carlos Zamora, Developer: [@cazamor_msft](https://twitter.com/cazamor_msft)
|
||||
* Leon Liang, Developer: [@leonmsft](https://twitter.com/leonmsft)
|
||||
* Pankaj Bhojwani, Developer
|
||||
|
||||
## Developer Guidance
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* You must be running Windows 1903 (build >= 10.0.18362.0) or later to run
|
||||
Windows Terminal
|
||||
* You must [enable Developer Mode in the Windows Settings
|
||||
app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development)
|
||||
to locally install and run Windows Terminal
|
||||
* You must have the [Windows 10 1903
|
||||
SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk)
|
||||
installed
|
||||
* You must have at least [VS
|
||||
2019](https://visualstudio.microsoft.com/downloads/) installed
|
||||
* You must install the following Workloads via the VS Installer. Note: Opening
|
||||
the solution in VS 2019 will [prompt you to install missing components
|
||||
automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/):
|
||||
* You must be running Windows 1903 (build >= 10.0.18362.0) or later to run Windows Terminal
|
||||
* You must [enable Developer Mode in the Windows Settings app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development) to locally install and run Windows Terminal
|
||||
* You must have the [Windows 10 1903 SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk) installed
|
||||
* You must have at least [VS 2019](https://visualstudio.microsoft.com/downloads/) installed
|
||||
* You must install the following Workloads via the VS Installer. Note: Opening the solution in VS 2019 will [prompt you to install missing components automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/):
|
||||
* Desktop Development with C++
|
||||
* Universal Windows Platform Development
|
||||
* **The following Individual Components**
|
||||
@@ -288,17 +176,13 @@ If you would like to ask a question that you feel doesn't warrant an issue
|
||||
|
||||
## Building the Code
|
||||
|
||||
This repository uses [git
|
||||
submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) for some of its
|
||||
dependencies. To make sure submodules are restored or updated, be sure to run
|
||||
the following prior to building:
|
||||
This repository uses [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) for some of its dependencies. To make sure submodules are restored or updated, be sure to run the following prior to building:
|
||||
|
||||
```shell
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
OpenConsole.sln may be built from within Visual Studio or from the command-line
|
||||
using a set of convenience scripts & tools in the **/tools** directory:
|
||||
OpenConsole.sln may be built from within Visual Studio or from the command-line using a set of convenience scripts & tools in the **/tools** directory:
|
||||
|
||||
### Building in PowerShell
|
||||
|
||||
@@ -317,42 +201,31 @@ bcz
|
||||
|
||||
## Running & Debugging
|
||||
|
||||
To debug the Windows Terminal in VS, right click on `CascadiaPackage` (in the
|
||||
Solution Explorer) and go to properties. In the Debug menu, change "Application
|
||||
process" and "Background task process" to "Native Only".
|
||||
To debug the Windows Terminal in VS, right click on `CascadiaPackage` (in the Solution Explorer) and go to properties. In the Debug menu, change "Application process" and "Background task process" to "Native Only".
|
||||
|
||||
You should then be able to build & debug the Terminal project by hitting
|
||||
<kbd>F5</kbd>.
|
||||
You should then be able to build & debug the Terminal project by hitting <kbd>F5</kbd>.
|
||||
|
||||
> 👉 You will _not_ be able to launch the Terminal directly by running the
|
||||
> WindowsTerminal.exe. For more details on why, see
|
||||
> [#926](https://github.com/microsoft/terminal/issues/926),
|
||||
> [#4043](https://github.com/microsoft/terminal/issues/4043)
|
||||
> 👉 You will _not_ be able to launch the Terminal directly by running the WindowsTerminal.exe. For more details on why, see [#926](https://github.com/microsoft/terminal/issues/926), [#4043](https://github.com/microsoft/terminal/issues/4043)
|
||||
|
||||
### Coding Guidance
|
||||
|
||||
Please review these brief docs below about our coding practices.
|
||||
|
||||
> 👉 If you find something missing from these docs, feel free to contribute to
|
||||
> any of our documentation files anywhere in the repository (or write some new
|
||||
> ones!)
|
||||
> 👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or write some new ones!)
|
||||
|
||||
This is a work in progress as we learn what we'll need to provide people in
|
||||
order to be effective contributors to our project.
|
||||
This is a work in progress as we learn what we'll need to provide people in order to be effective contributors to our project.
|
||||
|
||||
* [Coding Style](https://github.com/microsoft/terminal/blob/main/doc/STYLE.md)
|
||||
* [Code Organization](https://github.com/microsoft/terminal/blob/main/doc/ORGANIZATION.md)
|
||||
* [Exceptions in our legacy codebase](https://github.com/microsoft/terminal/blob/main/doc/EXCEPTIONS.md)
|
||||
* [Helpful smart pointers and macros for interfacing with Windows in WIL](https://github.com/microsoft/terminal/blob/main/doc/WIL.md)
|
||||
* [Coding Style](https://github.com/Microsoft/Terminal/blob/master/doc/STYLE.md)
|
||||
* [Code Organization](https://github.com/Microsoft/Terminal/blob/master/doc/ORGANIZATION.md)
|
||||
* [Exceptions in our legacy codebase](https://github.com/Microsoft/Terminal/blob/master/doc/EXCEPTIONS.md)
|
||||
* [Helpful smart pointers and macros for interfacing with Windows in WIL](https://github.com/Microsoft/Terminal/blob/master/doc/WIL.md)
|
||||
|
||||
---
|
||||
|
||||
## Code of Conduct
|
||||
# Code of Conduct
|
||||
|
||||
This project has adopted the [Microsoft Open Source Code of
|
||||
Conduct][conduct-code]. For more information see the [Code of Conduct
|
||||
FAQ][conduct-FAQ] or contact [opencode@microsoft.com][conduct-email] with any
|
||||
additional questions or comments.
|
||||
This project has adopted the [Microsoft Open Source Code of Conduct][conduct-code].
|
||||
For more information see the [Code of Conduct FAQ][conduct-FAQ] or contact [opencode@microsoft.com][conduct-email] with any additional questions or comments.
|
||||
|
||||
[conduct-code]: https://opensource.microsoft.com/codeofconduct/
|
||||
[conduct-FAQ]: https://opensource.microsoft.com/codeofconduct/faq/
|
||||
|
||||
17
SUPPORT.md
17
SUPPORT.md
@@ -1,17 +0,0 @@
|
||||
# Support
|
||||
|
||||
## How to file issues and get help
|
||||
|
||||
This project uses [GitHub issues][gh-issue] to [track bugs][gh-bug] and [feature requests][gh-feature]. Please search the existing issues before filing new issues to avoid duplicates. For new topics, file your bug or feature request as a new issue.
|
||||
|
||||
For help and questions about using this project, please look at the [docs site for Windows Terminal][docs] and our [Contributor's Guide][contributor] if you want to work on Windows Terminal.
|
||||
|
||||
## Microsoft Support Policy
|
||||
|
||||
Support for Windows Terminal is limited to the resources listed above.
|
||||
|
||||
[gh-issue]: https://github.com/microsoft/terminal/issues/new/choose
|
||||
[gh-bug]: https://github.com/microsoft/terminal/issues/new?assignees=&labels=Issue-Bug&template=bug_report.md&title=
|
||||
[gh-feature]: https://github.com/microsoft/terminal/issues/new?assignees=&labels=Issue-Feature&template=Feature_Request.md&title=
|
||||
[docs]: https://docs.microsoft.com/windows/terminal
|
||||
[contributor]: https://github.com/microsoft/terminal/blob/main/CONTRIBUTING.md
|
||||
@@ -1,32 +0,0 @@
|
||||
function GetAzureDevOpsBaseUri
|
||||
{
|
||||
Param(
|
||||
[string]$CollectionUri,
|
||||
[string]$TeamProject
|
||||
)
|
||||
|
||||
return $CollectionUri + $TeamProject
|
||||
}
|
||||
|
||||
function GetQueryTestRunsUri
|
||||
{
|
||||
Param(
|
||||
[string]$CollectionUri,
|
||||
[string]$TeamProject,
|
||||
[string]$BuildUri,
|
||||
[switch]$IncludeRunDetails
|
||||
)
|
||||
|
||||
if ($IncludeRunDetails)
|
||||
{
|
||||
$includeRunDetailsParameter = "&includeRunDetails=true"
|
||||
}
|
||||
else
|
||||
{
|
||||
$includeRunDetailsParameter = ""
|
||||
}
|
||||
|
||||
$baseUri = GetAzureDevOpsBaseUri -CollectionUri $CollectionUri -TeamProject $TeamProject
|
||||
$queryUri = "$baseUri/_apis/test/runs?buildUri=$BuildUri$includeRunDetailsParameter&api-version=5.0"
|
||||
return $queryUri
|
||||
}
|
||||
@@ -1,28 +0,0 @@
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttSingleRerunInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttMultipleRerunInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$XUnitOutputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$TestNamePrefix
|
||||
)
|
||||
|
||||
# Ideally these would be passed as parameters to the script. However ps makes it difficult to deal with string literals containing '&', so we just
|
||||
# read the values directly from the environment variables
|
||||
$helixResultsContainerUri = $Env:HELIX_RESULTS_CONTAINER_URI
|
||||
$helixResultsContainerRsas = $Env:HELIX_RESULTS_CONTAINER_RSAS
|
||||
|
||||
$rerunPassesRequiredToAvoidFailure = $env:rerunPassesRequiredToAvoidFailure
|
||||
|
||||
Add-Type -Language CSharp -ReferencedAssemblies System.Xml,System.Xml.Linq,System.Runtime.Serialization,System.Runtime.Serialization.Json (Get-Content $PSScriptRoot\HelixTestHelpers.cs -Raw)
|
||||
|
||||
$testResultParser = [HelixTestHelpers.TestResultParser]::new($TestNamePrefix, $helixResultsContainerUri, $helixResultsContainerRsas)
|
||||
$testResultParser.ConvertWttLogToXUnitLog($WttInputPath, $WttSingleRerunInputPath, $WttMultipleRerunInputPath, $XUnitOutputPath, $rerunPassesRequiredToAvoidFailure)
|
||||
@@ -1,112 +0,0 @@
|
||||
$scriptDirectory = $script:MyInvocation.MyCommand.Path | Split-Path -Parent
|
||||
|
||||
# List all processes to aid debugging:
|
||||
Write-Host "All processes running:"
|
||||
Get-Process
|
||||
|
||||
tasklist /svc
|
||||
|
||||
# Add this test directory as an exclusion for Windows Defender
|
||||
Write-Host "Add $scriptDirectory as Exclusion Path"
|
||||
Add-MpPreference -ExclusionPath $scriptDirectory
|
||||
Write-Host "Add $($env:HELIX_CORRELATION_PAYLOAD) as Exclusion Path"
|
||||
Add-MpPreference -ExclusionPath $env:HELIX_CORRELATION_PAYLOAD
|
||||
Get-MpPreference
|
||||
Get-MpComputerStatus
|
||||
|
||||
|
||||
# Minimize all windows:
|
||||
$shell = New-Object -ComObject "Shell.Application"
|
||||
$shell.minimizeall()
|
||||
|
||||
# Kill any instances of Windows Security Alert:
|
||||
$windowTitleToMatch = "*Windows Security Alert*"
|
||||
$procs = Get-Process | Where {$_.MainWindowTitle -like "*Windows Security Alert*"}
|
||||
foreach ($proc in $procs)
|
||||
{
|
||||
Write-Host "Found process with '$windowTitleToMatch' title: $proc"
|
||||
$proc.Kill();
|
||||
}
|
||||
|
||||
# Kill processes by name that are known to interfere with our tests:
|
||||
$processNamesToStop = @("Microsoft.Photos", "WinStore.App", "SkypeApp", "SkypeBackgroundHost", "OneDriveSetup", "OneDrive")
|
||||
foreach($procName in $processNamesToStop)
|
||||
{
|
||||
Write-Host "Attempting to kill $procName if it is running"
|
||||
Stop-Process -ProcessName $procName -Verbose -ErrorAction Ignore
|
||||
}
|
||||
Write-Host "All processes running after attempting to kill unwanted processes:"
|
||||
Get-Process
|
||||
|
||||
tasklist /svc
|
||||
|
||||
$platform = $env:testbuildplatform
|
||||
if(!$platform)
|
||||
{
|
||||
$platform = "x86"
|
||||
}
|
||||
|
||||
function UninstallApps {
|
||||
Param([string[]]$appsToUninstall)
|
||||
|
||||
foreach($pkgName in $appsToUninstall)
|
||||
{
|
||||
foreach($pkg in (Get-AppxPackage $pkgName).PackageFullName)
|
||||
{
|
||||
Write-Output "Removing: $pkg"
|
||||
Remove-AppxPackage $pkg
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function UninstallTestApps {
|
||||
Param([string[]]$appsToUninstall)
|
||||
|
||||
foreach($pkgName in $appsToUninstall)
|
||||
{
|
||||
foreach($pkg in (Get-AppxPackage $pkgName).PackageFullName)
|
||||
{
|
||||
Write-Output "Removing: $pkg"
|
||||
Remove-AppxPackage $pkg
|
||||
}
|
||||
|
||||
# Sometimes an app can get into a state where it is no longer returned by Get-AppxPackage, but it is still present
|
||||
# which prevents other versions of the app from being installed.
|
||||
# To handle this, we can directly call Remove-AppxPackage against the full name of the package. However, without
|
||||
# Get-AppxPackage to find the PackageFullName, we just have to manually construct the name.
|
||||
$packageFullName = "$($pkgName)_1.0.0.0_$($platform)__8wekyb3d8bbwe"
|
||||
Write-Host "Removing $packageFullName if installed"
|
||||
Remove-AppPackage $packageFullName -ErrorVariable appxerror -ErrorAction SilentlyContinue
|
||||
if($appxerror)
|
||||
{
|
||||
foreach($error in $appxerror)
|
||||
{
|
||||
# In most cases, Remove-AppPackage will fail due to the package not being found. Don't treat this as an error.
|
||||
if(!($error.Exception.Message -match "0x80073CF1"))
|
||||
{
|
||||
Write-Error $error
|
||||
}
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Host "Successfully removed $packageFullName"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Write-Host "Uninstall AppX packages that are known to cause issues with our tests"
|
||||
UninstallApps("*Skype*", "*Windows.Photos*")
|
||||
|
||||
Write-Host "Uninstall any of our test apps that may have been left over from previous test runs"
|
||||
UninstallTestApps("NugetPackageTestApp", "NugetPackageTestAppCX", "IXMPTestApp", "MUXControlsTestApp")
|
||||
|
||||
Write-Host "Uninstall MUX Framework package that may have been left over from previous test runs"
|
||||
# We don't want to uninstall all versions of the MUX Framework package, as there may be other apps preinstalled on the system
|
||||
# that depend on it. We only uninstall the Framework package that corresponds to the version of MUX that we are testing.
|
||||
[xml]$versionData = (Get-Content "version.props")
|
||||
$versionMajor = $versionData.GetElementsByTagName("MUXVersionMajor").'#text'
|
||||
$versionMinor = $versionData.GetElementsByTagName("MUXVersionMinor").'#text'
|
||||
UninstallApps("Microsoft.UI.Xaml.$versionMajor.$versionMinor")
|
||||
|
||||
Get-Process
|
||||
@@ -1,336 +0,0 @@
|
||||
[CmdLetBinding()]
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$TestFile,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$OutputProjFile,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$JobTestSuiteName,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$TaefPath,
|
||||
|
||||
[string]$TaefQuery
|
||||
)
|
||||
|
||||
Class TestCollection
|
||||
{
|
||||
[string]$Name
|
||||
[string]$SetupMethodName
|
||||
[string]$TeardownMethodName
|
||||
[System.Collections.Generic.Dictionary[string, string]]$Properties
|
||||
|
||||
TestCollection()
|
||||
{
|
||||
if ($this.GetType() -eq [TestCollection])
|
||||
{
|
||||
throw "This class should never be instantiated directly; it should only be derived from."
|
||||
}
|
||||
}
|
||||
|
||||
TestCollection([string]$name)
|
||||
{
|
||||
$this.Init($name)
|
||||
}
|
||||
|
||||
hidden Init([string]$name)
|
||||
{
|
||||
$this.Name = $name
|
||||
$this.Properties = @{}
|
||||
}
|
||||
}
|
||||
|
||||
Class Test : TestCollection
|
||||
{
|
||||
Test([string]$name)
|
||||
{
|
||||
$this.Init($name)
|
||||
}
|
||||
}
|
||||
|
||||
Class TestClass : TestCollection
|
||||
{
|
||||
[System.Collections.Generic.List[Test]]$Tests
|
||||
|
||||
TestClass([string]$name)
|
||||
{
|
||||
$this.Init($name)
|
||||
$this.Tests = @{}
|
||||
}
|
||||
}
|
||||
|
||||
Class TestModule : TestCollection
|
||||
{
|
||||
[System.Collections.Generic.List[TestClass]]$TestClasses
|
||||
|
||||
TestModule([string]$name)
|
||||
{
|
||||
$this.Init($name)
|
||||
$this.TestClasses = @{}
|
||||
}
|
||||
}
|
||||
|
||||
function Parse-TestInfo([string]$taefOutput)
|
||||
{
|
||||
enum LineType
|
||||
{
|
||||
None
|
||||
TestModule
|
||||
TestClass
|
||||
Test
|
||||
Setup
|
||||
Teardown
|
||||
Property
|
||||
}
|
||||
|
||||
[string]$testModuleIndentation = " "
|
||||
[string]$testClassIndentation = " "
|
||||
[string]$testIndentation = " "
|
||||
[string]$setupBeginning = "Setup: "
|
||||
[string]$teardownBeginning = "Teardown: "
|
||||
[string]$propertyBeginning = "Property["
|
||||
|
||||
function Get-LineType([string]$line)
|
||||
{
|
||||
if ($line.Contains($setupBeginning))
|
||||
{
|
||||
return [LineType]::Setup;
|
||||
}
|
||||
elseif ($line.Contains($teardownBeginning))
|
||||
{
|
||||
return [LineType]::Teardown;
|
||||
}
|
||||
elseif ($line.Contains($propertyBeginning))
|
||||
{
|
||||
return [LineType]::Property;
|
||||
}
|
||||
elseif ($line.StartsWith($testModuleIndentation) -and -not $line.StartsWith("$testModuleIndentation "))
|
||||
{
|
||||
return [LineType]::TestModule;
|
||||
}
|
||||
elseif ($line.StartsWith($testClassIndentation) -and -not $line.StartsWith("$testClassIndentation "))
|
||||
{
|
||||
return [LineType]::TestClass;
|
||||
}
|
||||
elseif ($line.StartsWith($testIndentation) -and -not $line.StartsWith("$testIndentation "))
|
||||
{
|
||||
return [LineType]::Test;
|
||||
}
|
||||
else
|
||||
{
|
||||
return [LineType]::None;
|
||||
}
|
||||
}
|
||||
|
||||
[string[]]$lines = $taefOutput.Split(@([Environment]::NewLine, "`n"), [StringSplitOptions]::RemoveEmptyEntries)
|
||||
[System.Collections.Generic.List[TestModule]]$testModules = @()
|
||||
|
||||
[TestModule]$currentTestModule = $null
|
||||
[TestClass]$currentTestClass = $null
|
||||
[Test]$currentTest = $null
|
||||
|
||||
[TestCollection]$lastTestCollection = $null
|
||||
|
||||
foreach ($rawLine in $lines)
|
||||
{
|
||||
[LineType]$lineType = (Get-LineType $rawLine)
|
||||
|
||||
# We don't need the whitespace around the line anymore, so we'll discard it to make things easier.
|
||||
[string]$line = $rawLine.Trim()
|
||||
|
||||
if ($lineType -eq [LineType]::TestModule)
|
||||
{
|
||||
if ($currentTest -ne $null -and $currentTestClass -ne $null)
|
||||
{
|
||||
$currentTestClass.Tests.Add($currentTest)
|
||||
}
|
||||
|
||||
if ($currentTestClass -ne $null -and $currentTestModule -ne $null)
|
||||
{
|
||||
$currentTestModule.TestClasses.Add($currentTestClass)
|
||||
}
|
||||
|
||||
if ($currentTestModule -ne $null)
|
||||
{
|
||||
$testModules.Add($currentTestModule)
|
||||
}
|
||||
|
||||
$currentTestModule = [TestModule]::new($line)
|
||||
$currentTestClass = $null
|
||||
$currentTest = $null
|
||||
$lastTestCollection = $currentTestModule
|
||||
}
|
||||
elseif ($lineType -eq [LineType]::TestClass)
|
||||
{
|
||||
if ($currentTest -ne $null -and $currentTestClass -ne $null)
|
||||
{
|
||||
$currentTestClass.Tests.Add($currentTest)
|
||||
}
|
||||
|
||||
if ($currentTestClass -ne $null -and $currentTestModule -ne $null)
|
||||
{
|
||||
$currentTestModule.TestClasses.Add($currentTestClass)
|
||||
}
|
||||
|
||||
$currentTestClass = [TestClass]::new($line)
|
||||
$currentTest = $null
|
||||
$lastTestCollection = $currentTestClass
|
||||
}
|
||||
elseif ($lineType -eq [LineType]::Test)
|
||||
{
|
||||
if ($currentTest -ne $null -and $currentTestClass -ne $null)
|
||||
{
|
||||
$currentTestClass.Tests.Add($currentTest)
|
||||
}
|
||||
|
||||
$currentTest = [Test]::new($line)
|
||||
$lastTestCollection = $currentTest
|
||||
}
|
||||
elseif ($lineType -eq [LineType]::Setup)
|
||||
{
|
||||
if ($lastTestCollection -ne $null)
|
||||
{
|
||||
$lastTestCollection.SetupMethodName = $line.Replace($setupBeginning, "")
|
||||
}
|
||||
}
|
||||
elseif ($lineType -eq [LineType]::Teardown)
|
||||
{
|
||||
if ($lastTestCollection -ne $null)
|
||||
{
|
||||
$lastTestCollection.TeardownMethodName = $line.Replace($teardownBeginning, "")
|
||||
}
|
||||
}
|
||||
elseif ($lineType -eq [LineType]::Property)
|
||||
{
|
||||
if ($lastTestCollection -ne $null)
|
||||
{
|
||||
foreach ($match in [Regex]::Matches($line, "Property\[(.*)\]\s+=\s+(.*)"))
|
||||
{
|
||||
[string]$propertyKey = $match.Groups[1].Value;
|
||||
[string]$propertyValue = $match.Groups[2].Value;
|
||||
$lastTestCollection.Properties.Add($propertyKey, $propertyValue);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if ($currentTest -ne $null -and $currentTestClass -ne $null)
|
||||
{
|
||||
$currentTestClass.Tests.Add($currentTest)
|
||||
}
|
||||
|
||||
if ($currentTestClass -ne $null -and $currentTestModule -ne $null)
|
||||
{
|
||||
$currentTestModule.TestClasses.Add($currentTestClass)
|
||||
}
|
||||
|
||||
if ($currentTestModule -ne $null)
|
||||
{
|
||||
$testModules.Add($currentTestModule)
|
||||
}
|
||||
|
||||
return $testModules
|
||||
}
|
||||
|
||||
Write-Verbose "TaefQuery = $TaefQuery"
|
||||
|
||||
$TaefSelectQuery = ""
|
||||
$TaefQueryToAppend = ""
|
||||
if($TaefQuery)
|
||||
{
|
||||
$TaefSelectQuery = "/select:`"$TaefQuery`""
|
||||
$TaefQueryToAppend = " and $TaefQuery"
|
||||
}
|
||||
Write-Verbose "TaefSelectQuery = $TaefSelectQuery"
|
||||
|
||||
|
||||
$taefExe = "$TaefPath\te.exe"
|
||||
[string]$taefOutput = & "$taefExe" /listproperties $TaefSelectQuery $TestFile | Out-String
|
||||
|
||||
[System.Collections.Generic.List[TestModule]]$testModules = (Parse-TestInfo $taefOutput)
|
||||
|
||||
$projFileContent = @"
|
||||
<Project>
|
||||
<ItemGroup>
|
||||
"@
|
||||
|
||||
foreach ($testModule in $testModules)
|
||||
{
|
||||
foreach ($testClass in $testModules.TestClasses)
|
||||
{
|
||||
Write-Host "Generating Helix work item for test class $($testClass.Name)..."
|
||||
[System.Collections.Generic.List[string]]$testSuiteNames = @()
|
||||
|
||||
$testSuiteExists = $false
|
||||
$suitelessTestExists = $false
|
||||
|
||||
foreach ($test in $testClass.Tests)
|
||||
{
|
||||
# A test method inherits its 'TestSuite' property from its TestClass
|
||||
if (!$test.Properties.ContainsKey("TestSuite") -and $testClass.Properties.ContainsKey("TestSuite"))
|
||||
{
|
||||
$test.Properties["TestSuite"] = $testClass.Properties["TestSuite"]
|
||||
}
|
||||
|
||||
if ($test.Properties.ContainsKey("TestSuite"))
|
||||
{
|
||||
[string]$testSuite = $test.Properties["TestSuite"]
|
||||
|
||||
if (-not $testSuiteNames.Contains($testSuite))
|
||||
{
|
||||
Write-Host " Found test suite $testSuite. Generating Helix work item for it as well."
|
||||
$testSuiteNames.Add($testSuite)
|
||||
}
|
||||
|
||||
$testSuiteExists = $true
|
||||
}
|
||||
else
|
||||
{
|
||||
$suitelessTestExists = $true
|
||||
}
|
||||
}
|
||||
|
||||
$testClassSelectPattern = "$($testClass.Name).*"
|
||||
if($testClass.Name.Contains("::"))
|
||||
{
|
||||
$testClassSelectPattern = "$($testClass.Name)::*"
|
||||
}
|
||||
$testNameQuery= "(@Name='$testClassSelectPattern')"
|
||||
|
||||
$workItemName = $testClass.Name
|
||||
# Native tests use '::' as a separator, which is not valid for workItem names.
|
||||
$workItemName = $workItemName -replace "::", "-"
|
||||
|
||||
if ($suitelessTestExists)
|
||||
{
|
||||
$projFileContent += @"
|
||||
|
||||
<HelixWorkItem Include="$($workItemName)" Condition="'`$(TestSuite)'=='$($JobTestSuiteName)'">
|
||||
<Timeout>00:30:00</Timeout>
|
||||
<Command>call %HELIX_CORRELATION_PAYLOAD%\runtests.cmd /select:"(@Name='$($testClass.Name)*'$(if ($testSuiteExists) { "and not @TestSuite='*'" }))$($TaefQueryToAppend)"</Command>
|
||||
</HelixWorkItem>
|
||||
"@
|
||||
}
|
||||
|
||||
foreach ($testSuiteName in $testSuiteNames)
|
||||
{
|
||||
$projFileContent += @"
|
||||
|
||||
<HelixWorkItem Include="$($workItemName)-$testSuiteName" Condition="'`$(TestSuite)'=='$($JobTestSuiteName)'">
|
||||
<Timeout>00:30:00</Timeout>
|
||||
<Command>call %HELIX_CORRELATION_PAYLOAD%\runtests.cmd /select:"(@Name='$($testClass.Name)*' and @TestSuite='$testSuiteName')$($TaefQueryToAppend)"</Command>
|
||||
</HelixWorkItem>
|
||||
"@
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
$projFileContent += @"
|
||||
|
||||
</ItemGroup>
|
||||
</Project>
|
||||
"@
|
||||
|
||||
Set-Content $OutputProjFile $projFileContent -NoNewline -Encoding UTF8
|
||||
@@ -1,669 +0,0 @@
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using System.IO;
|
||||
using System.Linq;
|
||||
using System.Runtime.Serialization;
|
||||
using System.Runtime.Serialization.Json;
|
||||
using System.Text;
|
||||
using System.Xml.Linq;
|
||||
|
||||
namespace HelixTestHelpers
|
||||
{
|
||||
public class TestResult
|
||||
{
|
||||
public TestResult()
|
||||
{
|
||||
Screenshots = new List<string>();
|
||||
RerunResults = new List<TestResult>();
|
||||
}
|
||||
|
||||
public string Name { get; set; }
|
||||
public string SourceWttFile { get; set; }
|
||||
public bool Passed { get; set; }
|
||||
public bool CleanupPassed { get; set; }
|
||||
public TimeSpan ExecutionTime { get; set; }
|
||||
public string Details { get; set; }
|
||||
|
||||
public List<string> Screenshots { get; private set; }
|
||||
public List<TestResult> RerunResults { get; private set; }
|
||||
|
||||
// Returns true if the test pass rate is sufficient to avoid being counted as a failure.
|
||||
public bool PassedOrUnreliable(int requiredNumberOfPasses)
|
||||
{
|
||||
if(Passed)
|
||||
{
|
||||
return true;
|
||||
}
|
||||
else
|
||||
{
|
||||
if(RerunResults.Count == 1)
|
||||
{
|
||||
return RerunResults[0].Passed;
|
||||
}
|
||||
else
|
||||
{
|
||||
return RerunResults.Where(r => r.Passed).Count() >= requiredNumberOfPasses;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
//
|
||||
// Azure DevOps doesn't currently provide a way to directly report sub-results for tests that failed at least once
|
||||
// that were run multiple times. To get around that limitation, we'll mark the test as "Skip" since
|
||||
// that's the only non-pass/fail result we can return, and will then report the information about the
|
||||
// runs in the "reason" category for the skipped test. In order to save space, we'll make the following
|
||||
// optimizations for size:
|
||||
//
|
||||
// 1. Serialize as JSON, which is more compact than XML;
|
||||
// 2. Don't serialize values that we don't need;
|
||||
// 3. Store the URL prefix and suffix for the blob storage URL only once instead of
|
||||
// storing every log and screenshot URL in its entirety; and
|
||||
// 4. Store a list of unique error messages and then index into that instead of
|
||||
// storing every error message in its entirety.
|
||||
//
|
||||
// #4 is motivated by the fact that if a test fails multiple times, it probably failed for the same reason
|
||||
// each time, in which case we'd just be repeating ourselves if we stored every error message each time.
|
||||
//
|
||||
// TODO (https://github.com/dotnet/arcade/issues/2773): Once we're able to directly report things in a
|
||||
// more granular fashion than just a binary pass/fail result, we should do that.
|
||||
//
|
||||
[DataContract]
|
||||
internal class JsonSerializableTestResults
|
||||
{
|
||||
[DataMember]
|
||||
internal string blobPrefix;
|
||||
|
||||
[DataMember]
|
||||
internal string blobSuffix;
|
||||
|
||||
[DataMember]
|
||||
internal string[] errors;
|
||||
|
||||
[DataMember]
|
||||
internal JsonSerializableTestResult[] results;
|
||||
}
|
||||
|
||||
[DataContract]
|
||||
internal class JsonSerializableTestResult
|
||||
{
|
||||
[DataMember]
|
||||
internal string outcome;
|
||||
|
||||
[DataMember]
|
||||
internal int duration;
|
||||
|
||||
[DataMember(EmitDefaultValue = false)]
|
||||
internal string log;
|
||||
|
||||
[DataMember(EmitDefaultValue = false)]
|
||||
internal string[] screenshots;
|
||||
|
||||
[DataMember(EmitDefaultValue = false)]
|
||||
internal int errorIndex;
|
||||
}
|
||||
|
||||
public class TestPass
|
||||
{
|
||||
public TimeSpan TestPassExecutionTime { get; set; }
|
||||
public List<TestResult> TestResults { get; set; }
|
||||
|
||||
public static TestPass ParseTestWttFile(string fileName, bool cleanupFailuresAreRegressions, bool truncateTestNames)
|
||||
{
|
||||
using (var stream = File.OpenRead(fileName))
|
||||
{
|
||||
var doc = XDocument.Load(stream);
|
||||
var testResults = new List<TestResult>();
|
||||
var testExecutionTimeMap = new Dictionary<string, List<double>>();
|
||||
|
||||
TestResult currentResult = null;
|
||||
long frequency = 0;
|
||||
long startTime = 0;
|
||||
long stopTime = 0;
|
||||
bool inTestCleanup = false;
|
||||
|
||||
bool shouldLogToTestDetails = false;
|
||||
|
||||
long testPassStartTime = 0;
|
||||
long testPassStopTime = 0;
|
||||
|
||||
Func<XElement, bool> isScopeData = (elt) =>
|
||||
{
|
||||
return
|
||||
elt.Element("Data") != null &&
|
||||
elt.Element("Data").Element("WexContext") != null &&
|
||||
(
|
||||
elt.Element("Data").Element("WexContext").Value == "Cleanup" ||
|
||||
elt.Element("Data").Element("WexContext").Value == "TestScope" ||
|
||||
elt.Element("Data").Element("WexContext").Value == "TestScope" ||
|
||||
elt.Element("Data").Element("WexContext").Value == "ClassScope" ||
|
||||
elt.Element("Data").Element("WexContext").Value == "ModuleScope"
|
||||
);
|
||||
};
|
||||
|
||||
Func<XElement, bool> isModuleOrClassScopeStart = (elt) =>
|
||||
{
|
||||
return
|
||||
elt.Name == "Msg" &&
|
||||
elt.Element("Data") != null &&
|
||||
elt.Element("Data").Element("StartGroup") != null &&
|
||||
elt.Element("Data").Element("WexContext") != null &&
|
||||
(elt.Element("Data").Element("WexContext").Value == "ClassScope" ||
|
||||
elt.Element("Data").Element("WexContext").Value == "ModuleScope");
|
||||
};
|
||||
|
||||
Func<XElement, bool> isModuleScopeEnd = (elt) =>
|
||||
{
|
||||
return
|
||||
elt.Name == "Msg" &&
|
||||
elt.Element("Data") != null &&
|
||||
elt.Element("Data").Element("EndGroup") != null &&
|
||||
elt.Element("Data").Element("WexContext") != null &&
|
||||
elt.Element("Data").Element("WexContext").Value == "ModuleScope";
|
||||
};
|
||||
|
||||
Func<XElement, bool> isClassScopeEnd = (elt) =>
|
||||
{
|
||||
return
|
||||
elt.Name == "Msg" &&
|
||||
elt.Element("Data") != null &&
|
||||
elt.Element("Data").Element("EndGroup") != null &&
|
||||
elt.Element("Data").Element("WexContext") != null &&
|
||||
elt.Element("Data").Element("WexContext").Value == "ClassScope";
|
||||
};
|
||||
|
||||
int testsExecuting = 0;
|
||||
foreach (XElement element in doc.Root.Elements())
|
||||
{
|
||||
// Capturing the frequency data to record accurate
|
||||
// timing data.
|
||||
if (element.Name == "RTI")
|
||||
{
|
||||
frequency = Int64.Parse(element.Attribute("Frequency").Value);
|
||||
}
|
||||
|
||||
// It's possible for a test to launch another test. If that happens, we won't modify the
|
||||
// current result. Instead, we'll continue operating like normal and expect that we get two
|
||||
// EndTests nodes before our next StartTests. We'll check that we've actually got a stop time
|
||||
// before creating a new result. This will result in the two results being squashed
|
||||
// into one result of the outer test that ran the inner one.
|
||||
if (element.Name == "StartTest")
|
||||
{
|
||||
testsExecuting++;
|
||||
if (testsExecuting == 1)
|
||||
{
|
||||
string testName = element.Attribute("Title").Value;
|
||||
|
||||
if (truncateTestNames)
|
||||
{
|
||||
const string xamlNativePrefix = "Windows::UI::Xaml::Tests::";
|
||||
const string xamlManagedPrefix = "Windows.UI.Xaml.Tests.";
|
||||
if (testName.StartsWith(xamlNativePrefix))
|
||||
{
|
||||
testName = testName.Substring(xamlNativePrefix.Length);
|
||||
}
|
||||
else if (testName.StartsWith(xamlManagedPrefix))
|
||||
{
|
||||
testName = testName.Substring(xamlManagedPrefix.Length);
|
||||
}
|
||||
}
|
||||
|
||||
currentResult = new TestResult() { Name = testName, SourceWttFile = fileName, Passed = true, CleanupPassed = true };
|
||||
testResults.Add(currentResult);
|
||||
startTime = Int64.Parse(element.Descendants("WexTraceInfo").First().Attribute("TimeStamp").Value);
|
||||
inTestCleanup = false;
|
||||
shouldLogToTestDetails = true;
|
||||
stopTime = 0;
|
||||
}
|
||||
}
|
||||
else if (currentResult != null && element.Name == "EndTest")
|
||||
{
|
||||
testsExecuting--;
|
||||
|
||||
// If any inner test fails, we'll still fail the outer
|
||||
currentResult.Passed &= element.Attribute("Result").Value == "Pass";
|
||||
|
||||
// Only gather execution data if this is the outer test we ran initially
|
||||
if (testsExecuting == 0)
|
||||
{
|
||||
stopTime = Int64.Parse(element.Descendants("WexTraceInfo").First().Attribute("TimeStamp").Value);
|
||||
if (!testExecutionTimeMap.Keys.Contains(currentResult.Name))
|
||||
testExecutionTimeMap[currentResult.Name] = new List<double>();
|
||||
testExecutionTimeMap[currentResult.Name].Add((double)(stopTime - startTime) / frequency);
|
||||
currentResult.ExecutionTime = TimeSpan.FromSeconds(testExecutionTimeMap[currentResult.Name].Average());
|
||||
|
||||
startTime = 0;
|
||||
inTestCleanup = true;
|
||||
}
|
||||
}
|
||||
else if (currentResult != null &&
|
||||
(isModuleOrClassScopeStart(element) || isModuleScopeEnd(element) || isClassScopeEnd(element)))
|
||||
{
|
||||
shouldLogToTestDetails = false;
|
||||
inTestCleanup = false;
|
||||
}
|
||||
|
||||
// Log-appending methods.
|
||||
if (currentResult != null && element.Name == "Error")
|
||||
{
|
||||
if (shouldLogToTestDetails)
|
||||
{
|
||||
currentResult.Details += "\r\n[Error]: " + element.Attribute("UserText").Value;
|
||||
if (element.Attribute("File") != null && element.Attribute("File").Value != "")
|
||||
{
|
||||
currentResult.Details += (" [File " + element.Attribute("File").Value);
|
||||
if (element.Attribute("Line") != null)
|
||||
currentResult.Details += " Line: " + element.Attribute("Line").Value;
|
||||
currentResult.Details += "]";
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
// The test cleanup errors will often come after the test claimed to have
|
||||
// 'passed'. We treat them as errors as well.
|
||||
if (inTestCleanup)
|
||||
{
|
||||
currentResult.CleanupPassed = false;
|
||||
currentResult.Passed = false;
|
||||
// In stress mode runs, this test will run n times before cleanup is run. If the cleanup
|
||||
// fails, we want to fail every test.
|
||||
if (cleanupFailuresAreRegressions)
|
||||
{
|
||||
foreach (var result in testResults.Where(res => res.Name == currentResult.Name))
|
||||
{
|
||||
result.Passed = false;
|
||||
result.CleanupPassed = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (currentResult != null && element.Name == "Warn")
|
||||
{
|
||||
if (shouldLogToTestDetails)
|
||||
{
|
||||
currentResult.Details += "\r\n[Warn]: " + element.Attribute("UserText").Value;
|
||||
}
|
||||
|
||||
if (element.Attribute("File") != null && element.Attribute("File").Value != "")
|
||||
{
|
||||
currentResult.Details += (" [File " + element.Attribute("File").Value);
|
||||
if (element.Attribute("Line") != null)
|
||||
currentResult.Details += " Line: " + element.Attribute("Line").Value;
|
||||
currentResult.Details += "]";
|
||||
}
|
||||
}
|
||||
|
||||
if (currentResult != null && element.Name == "Msg")
|
||||
{
|
||||
var dataElement = element.Element("Data");
|
||||
if (dataElement != null)
|
||||
{
|
||||
var supportingInfo = dataElement.Element("SupportingInfo");
|
||||
if (supportingInfo != null)
|
||||
{
|
||||
var screenshots = supportingInfo.Elements("Item")
|
||||
.Where(item => GetAttributeValue(item, "Name") == "Screenshot")
|
||||
.Select(item => GetAttributeValue(item, "Value"));
|
||||
|
||||
foreach(var screenshot in screenshots)
|
||||
{
|
||||
string fileNameSuffix = string.Empty;
|
||||
|
||||
if (fileName.Contains("_rerun_multiple"))
|
||||
{
|
||||
fileNameSuffix = "_rerun_multiple";
|
||||
}
|
||||
else if (fileName.Contains("_rerun"))
|
||||
{
|
||||
fileNameSuffix = "_rerun";
|
||||
}
|
||||
|
||||
currentResult.Screenshots.Add(screenshot.Replace(".jpg", fileNameSuffix + ".jpg"));
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
testPassStartTime = Int64.Parse(doc.Root.Descendants("WexTraceInfo").First().Attribute("TimeStamp").Value);
|
||||
testPassStopTime = Int64.Parse(doc.Root.Descendants("WexTraceInfo").Last().Attribute("TimeStamp").Value);
|
||||
|
||||
var testPassTime = TimeSpan.FromSeconds((double)(testPassStopTime - testPassStartTime) / frequency);
|
||||
|
||||
foreach (TestResult testResult in testResults)
|
||||
{
|
||||
if (testResult.Details != null)
|
||||
{
|
||||
testResult.Details = testResult.Details.Trim();
|
||||
}
|
||||
}
|
||||
|
||||
var testpass = new TestPass
|
||||
{
|
||||
TestPassExecutionTime = testPassTime,
|
||||
TestResults = testResults
|
||||
};
|
||||
|
||||
return testpass;
|
||||
}
|
||||
}
|
||||
|
||||
public static TestPass ParseTestWttFileWithReruns(string fileName, string singleRerunFileName, string multipleRerunFileName, bool cleanupFailuresAreRegressions, bool truncateTestNames)
|
||||
{
|
||||
TestPass testPass = ParseTestWttFile(fileName, cleanupFailuresAreRegressions, truncateTestNames);
|
||||
TestPass singleRerunTestPass = File.Exists(singleRerunFileName) ? ParseTestWttFile(singleRerunFileName, cleanupFailuresAreRegressions, truncateTestNames) : null;
|
||||
TestPass multipleRerunTestPass = File.Exists(multipleRerunFileName) ? ParseTestWttFile(multipleRerunFileName, cleanupFailuresAreRegressions, truncateTestNames) : null;
|
||||
|
||||
List<TestResult> rerunTestResults = new List<TestResult>();
|
||||
|
||||
if (singleRerunTestPass != null)
|
||||
{
|
||||
rerunTestResults.AddRange(singleRerunTestPass.TestResults);
|
||||
}
|
||||
|
||||
if (multipleRerunTestPass != null)
|
||||
{
|
||||
rerunTestResults.AddRange(multipleRerunTestPass.TestResults);
|
||||
}
|
||||
|
||||
// For each failed test result, we'll check to see whether the test passed at least once upon rerun.
|
||||
// If so, we'll set PassedOnRerun to true to flag the fact that this is an unreliable test
|
||||
// rather than a genuine test failure.
|
||||
foreach (TestResult failedTestResult in testPass.TestResults.Where(r => !r.Passed))
|
||||
{
|
||||
failedTestResult.RerunResults.AddRange(rerunTestResults.Where(r => r.Name == failedTestResult.Name));
|
||||
}
|
||||
|
||||
return testPass;
|
||||
}
|
||||
|
||||
private static string GetAttributeValue(XElement element, string attributeName)
|
||||
{
|
||||
if(element.Attribute(attributeName) != null)
|
||||
{
|
||||
return element.Attribute(attributeName).Value;
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
public static class FailedTestDetector
|
||||
{
|
||||
public static void OutputFailedTestQuery(string wttInputPath)
|
||||
{
|
||||
var testPass = TestPass.ParseTestWttFile(wttInputPath, cleanupFailuresAreRegressions: true, truncateTestNames: false);
|
||||
|
||||
List<string> failedTestNames = new List<string>();
|
||||
|
||||
foreach (var result in testPass.TestResults)
|
||||
{
|
||||
if (!result.Passed)
|
||||
{
|
||||
failedTestNames.Add(result.Name);
|
||||
}
|
||||
}
|
||||
|
||||
if (failedTestNames.Count > 0)
|
||||
{
|
||||
string failedTestSelectQuery = "(@Name='";
|
||||
|
||||
for (int i = 0; i < failedTestNames.Count; i++)
|
||||
{
|
||||
failedTestSelectQuery += failedTestNames[i];
|
||||
|
||||
if (i < failedTestNames.Count - 1)
|
||||
{
|
||||
failedTestSelectQuery += "' or @Name='";
|
||||
}
|
||||
}
|
||||
|
||||
failedTestSelectQuery += "')";
|
||||
|
||||
Console.WriteLine(failedTestSelectQuery);
|
||||
}
|
||||
else
|
||||
{
|
||||
Console.WriteLine("");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
public class TestResultParser
|
||||
{
|
||||
private string testNamePrefix;
|
||||
private string helixResultsContainerUri;
|
||||
private string helixResultsContainerRsas;
|
||||
|
||||
public TestResultParser(string testNamePrefix, string helixResultsContainerUri, string helixResultsContainerRsas)
|
||||
{
|
||||
this.testNamePrefix = testNamePrefix;
|
||||
this.helixResultsContainerUri = helixResultsContainerUri;
|
||||
this.helixResultsContainerRsas = helixResultsContainerRsas;
|
||||
}
|
||||
|
||||
public Dictionary<string, string> GetSubResultsJsonByMethodName(string wttInputPath, string wttSingleRerunInputPath, string wttMultipleRerunInputPath)
|
||||
{
|
||||
Dictionary<string, string> subResultsJsonByMethod = new Dictionary<string, string>();
|
||||
TestPass testPass = TestPass.ParseTestWttFileWithReruns(wttInputPath, wttSingleRerunInputPath, wttMultipleRerunInputPath, cleanupFailuresAreRegressions: true, truncateTestNames: false);
|
||||
|
||||
foreach (var result in testPass.TestResults)
|
||||
{
|
||||
var methodName = result.Name.Substring(result.Name.LastIndexOf('.') + 1);
|
||||
|
||||
if (!result.Passed)
|
||||
{
|
||||
// If a test failed, we'll have rerun it multiple times. We'll record the results of each run
|
||||
// formatted as JSON.
|
||||
JsonSerializableTestResults serializableResults = new JsonSerializableTestResults();
|
||||
serializableResults.blobPrefix = helixResultsContainerUri;
|
||||
serializableResults.blobSuffix = helixResultsContainerRsas;
|
||||
|
||||
List<string> errorList = new List<string>();
|
||||
errorList.Add(result.Details);
|
||||
|
||||
foreach (TestResult rerunResult in result.RerunResults)
|
||||
{
|
||||
errorList.Add(rerunResult.Details);
|
||||
}
|
||||
|
||||
serializableResults.errors = errorList.Distinct().Where(s => s != null).ToArray();
|
||||
|
||||
var reason = new XElement("reason");
|
||||
List<JsonSerializableTestResult> serializableResultList = new List<JsonSerializableTestResult>();
|
||||
serializableResultList.Add(ConvertToSerializableResult(result, serializableResults.errors));
|
||||
|
||||
foreach (TestResult rerunResult in result.RerunResults)
|
||||
{
|
||||
serializableResultList.Add(ConvertToSerializableResult(rerunResult, serializableResults.errors));
|
||||
}
|
||||
|
||||
serializableResults.results = serializableResultList.ToArray();
|
||||
|
||||
using (MemoryStream stream = new MemoryStream())
|
||||
{
|
||||
DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(JsonSerializableTestResults));
|
||||
serializer.WriteObject(stream, serializableResults);
|
||||
stream.Position = 0;
|
||||
|
||||
using (StreamReader streamReader = new StreamReader(stream))
|
||||
{
|
||||
subResultsJsonByMethod.Add(methodName, streamReader.ReadToEnd());
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return subResultsJsonByMethod;
|
||||
}
|
||||
|
||||
public void ConvertWttLogToXUnitLog(string wttInputPath, string wttSingleRerunInputPath, string wttMultipleRerunInputPath, string xunitOutputPath, int requiredPassRateThreshold)
|
||||
{
|
||||
TestPass testPass = TestPass.ParseTestWttFileWithReruns(wttInputPath, wttSingleRerunInputPath, wttMultipleRerunInputPath, cleanupFailuresAreRegressions: true, truncateTestNames: false);
|
||||
var results = testPass.TestResults;
|
||||
|
||||
int resultCount = results.Count;
|
||||
int passedCount = results.Where(r => r.Passed).Count();
|
||||
|
||||
// Since we re-run tests on failure, we'll mark every test that failed at least once as "skipped" rather than "failed".
|
||||
// If the test failed sufficiently often enough for it to count as a failed test (determined by a property on the
|
||||
// Azure DevOps job), we'll later mark it as failed during test results processing.
|
||||
|
||||
int failedCount = results.Where(r => !r.PassedOrUnreliable(requiredPassRateThreshold)).Count();
|
||||
int skippedCount = results.Where(r => !r.Passed && r.PassedOrUnreliable(requiredPassRateThreshold)).Count();
|
||||
|
||||
var root = new XElement("assemblies");
|
||||
|
||||
var assembly = new XElement("assembly");
|
||||
assembly.SetAttributeValue("name", "MUXControls.Test.dll");
|
||||
assembly.SetAttributeValue("test-framework", "TAEF");
|
||||
assembly.SetAttributeValue("run-date", DateTime.Now.ToString("yyyy-MM-dd"));
|
||||
|
||||
// This doesn't need to be completely accurate since it's not exposed anywhere.
|
||||
// If we need accurate an start time we can probably calculate it from the te.wtl file, but for
|
||||
// now this is fine.
|
||||
assembly.SetAttributeValue("run-time", (DateTime.Now - testPass.TestPassExecutionTime).ToString("hh:mm:ss"));
|
||||
|
||||
assembly.SetAttributeValue("total", resultCount);
|
||||
assembly.SetAttributeValue("passed", passedCount);
|
||||
assembly.SetAttributeValue("failed", failedCount);
|
||||
assembly.SetAttributeValue("skipped", skippedCount);
|
||||
|
||||
assembly.SetAttributeValue("time", (int)testPass.TestPassExecutionTime.TotalSeconds);
|
||||
assembly.SetAttributeValue("errors", 0);
|
||||
root.Add(assembly);
|
||||
|
||||
var collection = new XElement("collection");
|
||||
collection.SetAttributeValue("total", resultCount);
|
||||
collection.SetAttributeValue("passed", passedCount);
|
||||
collection.SetAttributeValue("failed", failedCount);
|
||||
collection.SetAttributeValue("skipped", skippedCount);
|
||||
collection.SetAttributeValue("name", "Test collection");
|
||||
collection.SetAttributeValue("time", (int)testPass.TestPassExecutionTime.TotalSeconds);
|
||||
assembly.Add(collection);
|
||||
|
||||
foreach (var result in results)
|
||||
{
|
||||
var test = new XElement("test");
|
||||
test.SetAttributeValue("name", testNamePrefix + "." + result.Name);
|
||||
|
||||
var className = GetTestClassName(result.Name);
|
||||
var methodName = GetTestMethodName(result.Name);
|
||||
test.SetAttributeValue("type", className);
|
||||
test.SetAttributeValue("method", methodName);
|
||||
|
||||
test.SetAttributeValue("time", result.ExecutionTime.TotalSeconds);
|
||||
|
||||
string resultString = string.Empty;
|
||||
|
||||
if (result.Passed)
|
||||
{
|
||||
resultString = "Pass";
|
||||
}
|
||||
else if(result.PassedOrUnreliable(requiredPassRateThreshold))
|
||||
{
|
||||
resultString = "Skip";
|
||||
}
|
||||
else
|
||||
{
|
||||
resultString = "Fail";
|
||||
}
|
||||
|
||||
|
||||
test.SetAttributeValue("result", resultString);
|
||||
|
||||
if (!result.Passed)
|
||||
{
|
||||
// If a test failed, we'll have rerun it multiple times.
|
||||
// We'll save the subresults to a JSON text file that we'll upload to the helix results container -
|
||||
// this allows it to be as long as we want, whereas the reason field in Azure DevOps has a 4000 character limit.
|
||||
string subResultsFileName = methodName + "_subresults.json";
|
||||
string subResultsFilePath = Path.Combine(Path.GetDirectoryName(wttInputPath), subResultsFileName);
|
||||
|
||||
if (result.PassedOrUnreliable(requiredPassRateThreshold))
|
||||
{
|
||||
var reason = new XElement("reason");
|
||||
reason.Add(new XCData(GetUploadedFileUrl(subResultsFileName, helixResultsContainerUri, helixResultsContainerRsas)));
|
||||
test.Add(reason);
|
||||
}
|
||||
else
|
||||
{
|
||||
var failure = new XElement("failure");
|
||||
var message = new XElement("message");
|
||||
message.Add(new XCData(GetUploadedFileUrl(subResultsFileName, helixResultsContainerUri, helixResultsContainerRsas)));
|
||||
failure.Add(message);
|
||||
test.Add(failure);
|
||||
}
|
||||
}
|
||||
collection.Add(test);
|
||||
}
|
||||
|
||||
File.WriteAllText(xunitOutputPath, root.ToString());
|
||||
}
|
||||
|
||||
private JsonSerializableTestResult ConvertToSerializableResult(TestResult rerunResult, string[] uniqueErrors)
|
||||
{
|
||||
var serializableResult = new JsonSerializableTestResult();
|
||||
|
||||
serializableResult.outcome = rerunResult.Passed ? "Passed" : "Failed";
|
||||
serializableResult.duration = (int)Math.Round(rerunResult.ExecutionTime.TotalMilliseconds);
|
||||
|
||||
if (!rerunResult.Passed)
|
||||
{
|
||||
serializableResult.log = Path.GetFileName(rerunResult.SourceWttFile);
|
||||
|
||||
if (rerunResult.Screenshots.Any())
|
||||
{
|
||||
List<string> screenshots = new List<string>();
|
||||
|
||||
foreach (var screenshot in rerunResult.Screenshots)
|
||||
{
|
||||
screenshots.Add(Path.GetFileName(screenshot));
|
||||
}
|
||||
|
||||
serializableResult.screenshots = screenshots.ToArray();
|
||||
}
|
||||
|
||||
// To conserve space, we'll log the index of the error to index in a list of unique errors rather than
|
||||
// jotting down every single error in its entirety. We'll add one to the result so we can avoid
|
||||
// serializing this property when it has the default value of 0.
|
||||
serializableResult.errorIndex = Array.IndexOf(uniqueErrors, rerunResult.Details) + 1;
|
||||
}
|
||||
|
||||
return serializableResult;
|
||||
}
|
||||
|
||||
private string GetUploadedFileUrl(string filePath, string helixResultsContainerUri, string helixResultsContainerRsas)
|
||||
{
|
||||
var filename = Path.GetFileName(filePath);
|
||||
return string.Format("{0}/{1}{2}", helixResultsContainerUri, filename, helixResultsContainerRsas);
|
||||
}
|
||||
|
||||
private string GetTestNameSeparator(string testname)
|
||||
{
|
||||
var separatorString = ".";
|
||||
if (!testname.Contains(separatorString))
|
||||
{
|
||||
separatorString = "::";
|
||||
}
|
||||
return separatorString;
|
||||
}
|
||||
|
||||
private string GetTestMethodName(string fullyQualifiedName)
|
||||
{
|
||||
var separatorString = GetTestNameSeparator(fullyQualifiedName);
|
||||
var methodName = fullyQualifiedName.Substring(fullyQualifiedName.LastIndexOf(separatorString) + separatorString.Length);
|
||||
|
||||
return methodName;
|
||||
}
|
||||
|
||||
private string GetTestClassName(string fullyQualifiedName)
|
||||
{
|
||||
var separatorString = GetTestNameSeparator(fullyQualifiedName);
|
||||
var className = fullyQualifiedName.Substring(0, fullyQualifiedName.LastIndexOf(separatorString));
|
||||
|
||||
return className;
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,12 +0,0 @@
|
||||
# Displaying progress is unnecessary and is just distracting.
|
||||
$ProgressPreference = "SilentlyContinue"
|
||||
|
||||
$dependencyFiles = Get-ChildItem -Filter "*Microsoft.VCLibs.*.appx"
|
||||
|
||||
foreach ($file in $dependencyFiles)
|
||||
{
|
||||
Write-Host "Adding dependency $($file)..."
|
||||
|
||||
Add-AppxPackage $file
|
||||
|
||||
}
|
||||
@@ -1,8 +0,0 @@
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttInputPath
|
||||
)
|
||||
|
||||
Add-Type -Language CSharp -ReferencedAssemblies System.Xml,System.Xml.Linq,System.Runtime.Serialization,System.Runtime.Serialization.Json (Get-Content $PSScriptRoot\HelixTestHelpers.cs -Raw)
|
||||
|
||||
[HelixTestHelpers.FailedTestDetector]::OutputFailedTestQuery($WttInputPath)
|
||||
@@ -1,32 +0,0 @@
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttSingleRerunInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$WttMultipleRerunInputPath,
|
||||
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$TestNamePrefix
|
||||
)
|
||||
|
||||
# Ideally these would be passed as parameters to the script. However ps makes it difficult to deal with string literals containing '&', so we just
|
||||
# read the values directly from the environment variables
|
||||
$helixResultsContainerUri = $Env:HELIX_RESULTS_CONTAINER_URI
|
||||
$helixResultsContainerRsas = $Env:HELIX_RESULTS_CONTAINER_RSAS
|
||||
|
||||
Add-Type -Language CSharp -ReferencedAssemblies System.Xml,System.Xml.Linq,System.Runtime.Serialization,System.Runtime.Serialization.Json (Get-Content $PSScriptRoot\HelixTestHelpers.cs -Raw)
|
||||
|
||||
$testResultParser = [HelixTestHelpers.TestResultParser]::new($TestNamePrefix, $helixResultsContainerUri, $helixResultsContainerRsas)
|
||||
[System.Collections.Generic.Dictionary[string, string]]$subResultsJsonByMethodName = $testResultParser.GetSubResultsJsonByMethodName($WttInputPath, $WttSingleRerunInputPath, $WttMultipleRerunInputPath)
|
||||
|
||||
$subResultsJsonDirectory = [System.IO.Path]::GetDirectoryName($WttInputPath)
|
||||
|
||||
foreach ($methodName in $subResultsJsonByMethodName.Keys)
|
||||
{
|
||||
$subResultsJson = $subResultsJsonByMethodName[$methodName]
|
||||
$subResultsJsonPath = [System.IO.Path]::Combine($subResultsJsonDirectory, $methodName + "_subresults.json")
|
||||
Out-File $subResultsJsonPath -Encoding utf8 -InputObject $subResultsJson
|
||||
}
|
||||
@@ -1,131 +0,0 @@
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[int]$MinimumExpectedTestsExecutedCount,
|
||||
|
||||
[string]$AccessToken = $env:SYSTEM_ACCESSTOKEN,
|
||||
[string]$CollectionUri = $env:SYSTEM_COLLECTIONURI,
|
||||
[string]$TeamProject = $env:SYSTEM_TEAMPROJECT,
|
||||
[string]$BuildUri = $env:BUILD_BUILDURI,
|
||||
[bool]$CheckJobAttempt
|
||||
)
|
||||
|
||||
$azureDevOpsRestApiHeaders = @{
|
||||
"Accept"="application/json"
|
||||
"Authorization"="Basic $([System.Convert]::ToBase64String([System.Text.ASCIIEncoding]::ASCII.GetBytes(":$AccessToken")))"
|
||||
}
|
||||
|
||||
. "$PSScriptRoot/AzurePipelinesHelperScripts.ps1"
|
||||
|
||||
Write-Host "Checking test results..."
|
||||
|
||||
$queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri -IncludeRunDetails
|
||||
Write-Host "queryUri = $queryUri"
|
||||
|
||||
$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
[System.Collections.Generic.List[string]]$failingTests = @()
|
||||
[System.Collections.Generic.List[string]]$unreliableTests = @()
|
||||
[System.Collections.Generic.List[string]]$unexpectedResultTest = @()
|
||||
|
||||
[System.Collections.Generic.List[string]]$namesOfProcessedTestRuns = @()
|
||||
$totalTestsExecutedCount = 0
|
||||
|
||||
# We assume that we only have one testRun with a given name that we care about
|
||||
# We only process the last testRun with a given name (based on completedDate)
|
||||
# The name of a testRun is set to the Helix queue that it was run on (e.g. windows.10.amd64.client19h1.xaml)
|
||||
# If we have multiple test runs on the same queue that we care about, we will need to re-visit this logic
|
||||
foreach ($testRun in ($testRuns.value | Sort-Object -Property "completedDate" -Descending))
|
||||
{
|
||||
if ($CheckJobAttempt)
|
||||
{
|
||||
if ($namesOfProcessedTestRuns -contains $testRun.name)
|
||||
{
|
||||
Write-Host "Skipping test run '$($testRun.name)', since we have already processed a test run of that name."
|
||||
continue
|
||||
}
|
||||
}
|
||||
|
||||
Write-Host "Processing results from test run '$($testRun.name)'"
|
||||
$namesOfProcessedTestRuns.Add($testRun.name)
|
||||
|
||||
$totalTestsExecutedCount += $testRun.totalTests
|
||||
|
||||
$testRunResultsUri = "$($testRun.url)/results?api-version=5.0"
|
||||
$testResults = Invoke-RestMethod -Uri "$($testRun.url)/results?api-version=5.0" -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
|
||||
foreach ($testResult in $testResults.value)
|
||||
{
|
||||
$shortTestCaseTitle = $testResult.testCaseTitle -replace "[a-zA-Z0-9]+.[a-zA-Z0-9]+.Windows.UI.Xaml.Tests.MUXControls.",""
|
||||
|
||||
if ($testResult.outcome -eq "Failed")
|
||||
{
|
||||
if (-not $failingTests.Contains($shortTestCaseTitle))
|
||||
{
|
||||
$failingTests.Add($shortTestCaseTitle)
|
||||
}
|
||||
}
|
||||
elseif ($testResult.outcome -eq "Warning")
|
||||
{
|
||||
if (-not $unreliableTests.Contains($shortTestCaseTitle))
|
||||
{
|
||||
$unreliableTests.Add($shortTestCaseTitle)
|
||||
}
|
||||
}
|
||||
elseif ($testResult.outcome -ne "Passed")
|
||||
{
|
||||
# We should only see tests with result "Passed", "Failed" or "Warning"
|
||||
if (-not $unexpectedResultTest.Contains($shortTestCaseTitle))
|
||||
{
|
||||
$unexpectedResultTest.Add($shortTestCaseTitle)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if ($unreliableTests.Count -gt 0)
|
||||
{
|
||||
Write-Host @"
|
||||
##vso[task.logissue type=warning;]Unreliable tests:
|
||||
##vso[task.logissue type=warning;]$($unreliableTests -join "$([Environment]::NewLine)##vso[task.logissue type=warning;]")
|
||||
|
||||
"@
|
||||
}
|
||||
|
||||
if ($failingTests.Count -gt 0)
|
||||
{
|
||||
Write-Host @"
|
||||
##vso[task.logissue type=error;]Failing tests:
|
||||
##vso[task.logissue type=error;]$($failingTests -join "$([Environment]::NewLine)##vso[task.logissue type=error;]")
|
||||
|
||||
"@
|
||||
}
|
||||
|
||||
if ($unexpectedResultTest.Count -gt 0)
|
||||
{
|
||||
Write-Host @"
|
||||
##vso[task.logissue type=error;]Tests with unexpected results:
|
||||
##vso[task.logissue type=error;]$($unexpectedResultTest -join "$([Environment]::NewLine)##vso[task.logissue type=error;]")
|
||||
|
||||
"@
|
||||
}
|
||||
|
||||
if($totalTestsExecutedCount -lt $MinimumExpectedTestsExecutedCount)
|
||||
{
|
||||
Write-Host "Expected at least $MinimumExpectedTestsExecutedCount tests to be executed."
|
||||
Write-Host "Actual executed test count is: $totalTestsExecutedCount"
|
||||
Write-Host "##vso[task.complete result=Failed;]"
|
||||
}
|
||||
elseif ($failingTests.Count -gt 0)
|
||||
{
|
||||
Write-Host "At least one test failed."
|
||||
Write-Host "##vso[task.complete result=Failed;]"
|
||||
}
|
||||
elseif ($unreliableTests.Count -gt 0)
|
||||
{
|
||||
Write-Host "All tests eventually passed, but some initially failed."
|
||||
Write-Host "##vso[task.complete result=Succeeded;]"
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Host "All tests passed."
|
||||
Write-Host "##vso[task.complete result=Succeeded;]"
|
||||
}
|
||||
@@ -1,54 +0,0 @@
|
||||
[CmdLetBinding()]
|
||||
Param(
|
||||
[string]$Platform,
|
||||
[string]$Configuration,
|
||||
[string]$ArtifactName='drop'
|
||||
)
|
||||
|
||||
$payloadDir = "HelixPayload\$Configuration\$Platform"
|
||||
|
||||
$repoDirectory = Join-Path (Split-Path -Parent $script:MyInvocation.MyCommand.Path) "..\..\"
|
||||
$nugetPackagesDir = Join-Path (Split-Path -Parent $script:MyInvocation.MyCommand.Path) "packages"
|
||||
|
||||
# Create the payload directory. Remove it if it already exists.
|
||||
If(test-path $payloadDir)
|
||||
{
|
||||
Remove-Item $payloadDir -Recurse
|
||||
}
|
||||
New-Item -ItemType Directory -Force -Path $payloadDir
|
||||
|
||||
# Copy files from nuget packages
|
||||
Copy-Item "$nugetPackagesDir\microsoft.windows.apps.test.1.0.181203002\lib\netcoreapp2.1\*.dll" $payloadDir
|
||||
Copy-Item "$nugetPackagesDir\taef.redist.wlk.10.57.200731005-develop\build\Binaries\$Platform\*" $payloadDir
|
||||
Copy-Item "$nugetPackagesDir\taef.redist.wlk.10.57.200731005-develop\build\Binaries\$Platform\CoreClr\*" $payloadDir
|
||||
New-Item -ItemType Directory -Force -Path "$payloadDir\.NETCoreApp2.1\"
|
||||
Copy-Item "$nugetPackagesDir\runtime.win-$Platform.microsoft.netcore.app.2.1.0\runtimes\win-$Platform\lib\netcoreapp2.1\*" "$payloadDir\.NETCoreApp2.1\"
|
||||
Copy-Item "$nugetPackagesDir\runtime.win-$Platform.microsoft.netcore.app.2.1.0\runtimes\win-$Platform\native\*" "$payloadDir\.NETCoreApp2.1\"
|
||||
|
||||
function Copy-If-Exists
|
||||
{
|
||||
Param($source, $destinationDir)
|
||||
|
||||
if (Test-Path $source)
|
||||
{
|
||||
Write-Host "Copy from '$source' to '$destinationDir'"
|
||||
Copy-Item -Force $source $destinationDir
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Host "'$source' does not exist."
|
||||
}
|
||||
}
|
||||
|
||||
# Copy files from the 'drop' artifact dir
|
||||
Copy-Item "$repoDirectory\Artifacts\$ArtifactName\$Configuration\$Platform\Test\*" $payloadDir -Recurse
|
||||
|
||||
# Copy files from the repo
|
||||
New-Item -ItemType Directory -Force -Path "$payloadDir"
|
||||
Copy-Item "build\helix\ConvertWttLogToXUnit.ps1" "$payloadDir"
|
||||
Copy-Item "build\helix\OutputFailedTestQuery.ps1" "$payloadDir"
|
||||
Copy-Item "build\helix\OutputSubResultsJsonFiles.ps1" "$payloadDir"
|
||||
Copy-Item "build\helix\HelixTestHelpers.cs" "$payloadDir"
|
||||
Copy-Item "build\helix\runtests.cmd" $payloadDir
|
||||
Copy-Item "build\helix\InstallTestAppDependencies.ps1" "$payloadDir"
|
||||
Copy-Item "build\Helix\EnsureMachineState.ps1" "$payloadDir"
|
||||
@@ -1,112 +0,0 @@
|
||||
Param(
|
||||
[string]$AccessToken = $env:SYSTEM_ACCESSTOKEN,
|
||||
[string]$HelixAccessToken = $env:HelixAccessToken,
|
||||
[string]$CollectionUri = $env:SYSTEM_COLLECTIONURI,
|
||||
[string]$TeamProject = $env:SYSTEM_TEAMPROJECT,
|
||||
[string]$BuildUri = $env:BUILD_BUILDURI,
|
||||
[string]$OutputFolder = "HelixOutput"
|
||||
)
|
||||
|
||||
$helixLinkFile = "$OutputFolder\LinksToHelixTestFiles.html"
|
||||
|
||||
$accessTokenParam = ""
|
||||
if($HelixAccessToken)
|
||||
{
|
||||
$accessTokenParam = "?access_token=$HelixAccessToken"
|
||||
}
|
||||
|
||||
function Generate-File-Links
|
||||
{
|
||||
Param ([Array[]]$files,[string]$sectionName)
|
||||
if($files.Count -gt 0)
|
||||
{
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<div class=$sectionName>"
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<h4>$sectionName</h4>"
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<ul>"
|
||||
foreach($file in $files)
|
||||
{
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<li><a href=$($file.Link)>$($file.Name)</a></li>"
|
||||
}
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "</ul>"
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "</div>"
|
||||
}
|
||||
}
|
||||
|
||||
#Create output directory
|
||||
New-Item $OutputFolder -ItemType Directory
|
||||
|
||||
$azureDevOpsRestApiHeaders = @{
|
||||
"Accept"="application/json"
|
||||
"Authorization"="Basic $([System.Convert]::ToBase64String([System.Text.ASCIIEncoding]::ASCII.GetBytes(":$AccessToken")))"
|
||||
}
|
||||
|
||||
. "$PSScriptRoot/AzurePipelinesHelperScripts.ps1"
|
||||
|
||||
$queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri -IncludeRunDetails
|
||||
Write-Host "queryUri = $queryUri"
|
||||
|
||||
$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
$webClient = New-Object System.Net.WebClient
|
||||
[System.Collections.Generic.List[string]]$workItems = @()
|
||||
|
||||
foreach ($testRun in $testRuns.value)
|
||||
{
|
||||
$testResults = Invoke-RestMethod -Uri "$($testRun.url)/results?api-version=5.0" -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
$isTestRunNameShown = $false
|
||||
|
||||
foreach ($testResult in $testResults.value)
|
||||
{
|
||||
if ("comment" -in $testResult)
|
||||
{
|
||||
$info = ConvertFrom-Json $testResult.comment
|
||||
$helixJobId = $info.HelixJobId
|
||||
$helixWorkItemName = $info.HelixWorkItemName
|
||||
|
||||
$workItem = "$helixJobId-$helixWorkItemName"
|
||||
|
||||
if (-not $workItems.Contains($workItem))
|
||||
{
|
||||
$workItems.Add($workItem)
|
||||
$filesQueryUri = "https://helix.dot.net/api/2019-06-17/jobs/$helixJobId/workitems/$helixWorkItemName/files$accessTokenParam"
|
||||
$files = Invoke-RestMethod -Uri $filesQueryUri -Method Get
|
||||
|
||||
$screenShots = $files | where { $_.Name.EndsWith(".jpg") }
|
||||
$dumps = $files | where { $_.Name.EndsWith(".dmp") }
|
||||
$pgcFiles = $files | where { $_.Name.EndsWith(".pgc") }
|
||||
if ($screenShots.Count + $dumps.Count + $pgcFiles.Count -gt 0)
|
||||
{
|
||||
if(-Not $isTestRunNameShown)
|
||||
{
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<h2>$($testRun.name)</h2>"
|
||||
$isTestRunNameShown = $true
|
||||
}
|
||||
Out-File -FilePath $helixLinkFile -Append -InputObject "<h3>$helixWorkItemName</h3>"
|
||||
Generate-File-Links $screenShots "Screenshots"
|
||||
Generate-File-Links $dumps "CrashDumps"
|
||||
Generate-File-Links $pgcFiles "PGC files"
|
||||
$misc = $files | where { ($screenShots -NotContains $_) -And ($dumps -NotContains $_) -And ($visualTreeVerificationFiles -NotContains $_) -And ($pgcFiles -NotContains $_) }
|
||||
Generate-File-Links $misc "Misc"
|
||||
|
||||
foreach($pgcFile in $pgcFiles)
|
||||
{
|
||||
$flavorPath = $pgcFile.Name.Split('.')[0]
|
||||
$archPath = $pgcFile.Name.Split('.')[1]
|
||||
$fileName = $pgcFile.Name.Remove(0, $flavorPath.length + $archPath.length + 2)
|
||||
$fullPath = "$OutputFolder\PGO\$flavorPath\$archPath"
|
||||
$destination = "$fullPath\$fileName"
|
||||
|
||||
Write-Host "Copying $($pgcFile.Name) to $destination"
|
||||
|
||||
if (-Not (Test-Path $fullPath))
|
||||
{
|
||||
New-Item $fullPath -ItemType Directory
|
||||
}
|
||||
|
||||
$link = "$($pgcFile.Link)$accessTokenParam"
|
||||
$webClient.DownloadFile($link, $destination)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,18 +0,0 @@
|
||||
<Project Sdk="Microsoft.DotNet.Helix.Sdk" DefaultTargets="Test">
|
||||
<PropertyGroup>
|
||||
<HelixSource>pr/terminal/$(BUILD_SOURCEBRANCH)/</HelixSource>
|
||||
<EnableXUnitReporter>true</EnableXUnitReporter>
|
||||
<EnableAzurePipelinesReporter>true</EnableAzurePipelinesReporter>
|
||||
<FailOnMissionControlTestFailure>true</FailOnMissionControlTestFailure>
|
||||
<HelixPreCommands>$(HelixPreCommands);set testnameprefix=$(Configuration).$(Platform);set testbuildplatform=$(Platform);set rerunPassesRequiredToAvoidFailure=$(rerunPassesRequiredToAvoidFailure)</HelixPreCommands>
|
||||
<OutputPath>..\..\bin\$(Platform)\$(Configuration)\</OutputPath>
|
||||
</PropertyGroup>
|
||||
|
||||
<ItemGroup>
|
||||
<HelixCorrelationPayload Include="..\..\HelixPayload\$(Configuration)\$(Platform)" />
|
||||
</ItemGroup>
|
||||
|
||||
<!-- These .proj files are generated by the build machine prior to running tests via GenerateTestProjFile.ps1. -->
|
||||
<Import Project="$(ProjFilesPath)\RunTestsInHelix-TerminalAppLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
|
||||
<Import Project="$(ProjFilesPath)\RunTestsInHelix-HostTestsUIA.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
|
||||
</Project>
|
||||
@@ -1,135 +0,0 @@
|
||||
[CmdLetBinding()]
|
||||
Param(
|
||||
[Parameter(Mandatory = $true)]
|
||||
[int]$RerunPassesRequiredToAvoidFailure,
|
||||
|
||||
[string]$AccessToken = $env:SYSTEM_ACCESSTOKEN,
|
||||
[string]$CollectionUri = $env:SYSTEM_COLLECTIONURI,
|
||||
[string]$TeamProject = $env:SYSTEM_TEAMPROJECT,
|
||||
[string]$BuildUri = $env:BUILD_BUILDURI
|
||||
)
|
||||
|
||||
. "$PSScriptRoot/AzurePipelinesHelperScripts.ps1"
|
||||
|
||||
|
||||
$azureDevOpsRestApiHeaders = @{
|
||||
"Accept"="application/json"
|
||||
"Authorization"="Basic $([System.Convert]::ToBase64String([System.Text.ASCIIEncoding]::ASCII.GetBytes(":$AccessToken")))"
|
||||
}
|
||||
|
||||
$queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri
|
||||
Write-Host "queryUri = $queryUri"
|
||||
|
||||
# To account for unreliable tests, we'll iterate through all of the tests associated with this build, check to see any tests that were unreliable
|
||||
# (denoted by being marked as "skipped"), and if so, we'll instead mark those tests with a warning and enumerate all of the attempted runs
|
||||
# with their pass/fail states as well as any relevant error messages for failed attempts.
|
||||
$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
|
||||
$timesSeenByRunName = @{}
|
||||
|
||||
foreach ($testRun in $testRuns.value)
|
||||
{
|
||||
$testRunResultsUri = "$($testRun.url)/results?api-version=5.0"
|
||||
|
||||
Write-Host "Marking test run `"$($testRun.name)`" as in progress so we can change its results to account for unreliable tests."
|
||||
Invoke-RestMethod -Uri "$($testRun.url)?api-version=5.0" -Method Patch -Body (ConvertTo-Json @{ "state" = "InProgress" }) -Headers $azureDevOpsRestApiHeaders -ContentType "application/json" | Out-Null
|
||||
|
||||
Write-Host "Retrieving test results..."
|
||||
$testResults = Invoke-RestMethod -Uri $testRunResultsUri -Method Get -Headers $azureDevOpsRestApiHeaders
|
||||
|
||||
foreach ($testResult in $testResults.value)
|
||||
{
|
||||
$testNeedsSubResultProcessing = $false
|
||||
if ($testResult.outcome -eq "NotExecuted")
|
||||
{
|
||||
$testNeedsSubResultProcessing = $true
|
||||
}
|
||||
elseif($testResult.outcome -eq "Failed")
|
||||
{
|
||||
$testNeedsSubResultProcessing = $testResult.errorMessage -like "*_subresults.json*"
|
||||
}
|
||||
|
||||
if ($testNeedsSubResultProcessing)
|
||||
{
|
||||
Write-Host " Test $($testResult.testCaseTitle) was detected as unreliable. Updating..."
|
||||
|
||||
# The errorMessage field contains a link to the JSON-encoded rerun result data.
|
||||
$rerunResults = ConvertFrom-Json (New-Object System.Net.WebClient).DownloadString($testResult.errorMessage)
|
||||
[System.Collections.Generic.List[System.Collections.Hashtable]]$rerunDataList = @()
|
||||
$attemptCount = 0
|
||||
$passCount = 0
|
||||
$totalDuration = 0
|
||||
|
||||
foreach ($rerun in $rerunResults.results)
|
||||
{
|
||||
$rerunData = @{
|
||||
"displayName" = "Attempt #$($attemptCount + 1) - $($testResult.testCaseTitle)";
|
||||
"durationInMs" = $rerun.duration;
|
||||
"outcome" = $rerun.outcome;
|
||||
}
|
||||
|
||||
if ($rerun.outcome -eq "Passed")
|
||||
{
|
||||
$passCount++
|
||||
}
|
||||
|
||||
if ($attemptCount -gt 0)
|
||||
{
|
||||
$rerunData["sequenceId"] = $attemptCount
|
||||
}
|
||||
|
||||
Write-Host " Attempt #$($attemptCount + 1): $($rerun.outcome)"
|
||||
|
||||
if ($rerun.outcome -ne "Passed")
|
||||
{
|
||||
$screenshots = "$($rerunResults.blobPrefix)/$($rerun.screenshots -join @"
|
||||
$($rerunResults.blobSuffix)
|
||||
$($rerunResults.blobPrefix)
|
||||
"@)$($rerunResults.blobSuffix)"
|
||||
|
||||
# We subtract 1 from the error index because we added 1 so we could use 0
|
||||
# as a default value not injected into the JSON in order to keep its size down.
|
||||
# We did this because there's a maximum size enforced for the errorMessage parameter
|
||||
# in the Azure DevOps REST API.
|
||||
$fullErrorMessage = @"
|
||||
Log: $($rerunResults.blobPrefix)/$($rerun.log)$($rerunResults.blobSuffix)
|
||||
|
||||
Screenshots:
|
||||
$screenshots
|
||||
|
||||
Error log:
|
||||
$($rerunResults.errors[$rerun.errorIndex - 1])
|
||||
"@
|
||||
|
||||
$rerunData["errorMessage"] = $fullErrorMessage
|
||||
}
|
||||
|
||||
$attemptCount++
|
||||
$totalDuration += $rerun.duration
|
||||
$rerunDataList.Add($rerunData)
|
||||
}
|
||||
|
||||
$overallOutcome = "Warning"
|
||||
|
||||
if ($attemptCount -eq 2)
|
||||
{
|
||||
Write-Host " Test $($testResult.testCaseTitle) passed on the immediate rerun, so we'll mark it as unreliable."
|
||||
}
|
||||
elseif ($passCount -gt $RerunPassesRequiredToAvoidFailure)
|
||||
{
|
||||
Write-Host " Test $($testResult.testCaseTitle) passed on $passCount of $attemptCount attempts, which is greater than or equal to the $RerunPassesRequiredToAvoidFailure passes required to avoid being marked as failed. Marking as unreliable."
|
||||
}
|
||||
else
|
||||
{
|
||||
Write-Host " Test $($testResult.testCaseTitle) passed on only $passCount of $attemptCount attempts, which is less than the $RerunPassesRequiredToAvoidFailure passes required to avoid being marked as failed. Marking as failed."
|
||||
$overallOutcome = "Failed"
|
||||
}
|
||||
|
||||
$updateBody = ConvertTo-Json @(@{ "id" = $testResult.id; "outcome" = $overallOutcome; "errorMessage" = " "; "durationInMs" = $totalDuration; "subResults" = $rerunDataList; "resultGroupType" = "rerun" }) -Depth 5
|
||||
Invoke-RestMethod -Uri $testRunResultsUri -Method Patch -Headers $azureDevOpsRestApiHeaders -Body $updateBody -ContentType "application/json" | Out-Null
|
||||
}
|
||||
}
|
||||
|
||||
Write-Host "Finished updates. Re-marking test run `"$($testRun.name)`" as completed."
|
||||
Invoke-RestMethod -Uri "$($testRun.url)?api-version=5.0" -Method Patch -Body (ConvertTo-Json @{ "state" = "Completed" }) -Headers $azureDevOpsRestApiHeaders -ContentType "application/json" | Out-Null
|
||||
}
|
||||
@@ -1,5 +0,0 @@
|
||||
{
|
||||
"msbuild-sdks": {
|
||||
"Microsoft.DotNet.Helix.Sdk": "5.0.0-beta.20277.5"
|
||||
}
|
||||
}
|
||||
@@ -1,8 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<packages>
|
||||
<package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
|
||||
<package id="TAEF.Redist.Wlk" version="10.57.200731005-develop" targetFramework="native" />
|
||||
<package id="microsoft.windows.apps.test" version="1.0.181203002" targetFramework="native" />
|
||||
<package id="runtime.win-x86.microsoft.netcore.app" version="2.1.0" targetFramework="native" />
|
||||
<package id="runtime.win-x64.microsoft.netcore.app" version="2.1.0" targetFramework="native" />
|
||||
</packages>
|
||||
@@ -1,32 +0,0 @@
|
||||
This directory contains code and configuration files to run WinUI tests in Helix.
|
||||
|
||||
Helix is a cloud hosted test execution environment which is accessed via the Arcade SDK.
|
||||
More details:
|
||||
* [Arcade](https://github.com/dotnet/arcade)
|
||||
* [Helix](https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.Helix/Sdk)
|
||||
|
||||
WinUI tests are scheduled in Helix by the Azure DevOps Pipeline: [RunHelixTests.yml](../RunHelixTests.yml).
|
||||
|
||||
The workflow is as follows:
|
||||
1. NuGet Restore is called on the packages.config in this directory. This downloads any runtime dependencies
|
||||
that are needed to run tests.
|
||||
2. PrepareHelixPayload.ps1 is called. This copies the necessary files from various locations into a Helix
|
||||
payload directory. This directory is what will get sent to the Helix machines.
|
||||
3. RunTestsInHelix.proj is executed. This proj has a dependency on
|
||||
[Microsoft.DotNet.Helix.Sdk](https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.Helix/Sdk)
|
||||
which it uses to publish the Helix payload directory and to schedule the Helix Work Items. The WinUI tests
|
||||
are parallelized into multiple Helix Work Items.
|
||||
4. Each Helix Work Item calls [runtests.cmd](runtests.cmd) with a specific query to pass to
|
||||
[TAEF](https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/) which runs the tests.
|
||||
5. If a test is detected to have failed, we run it again, first once, then eight more times if it fails again.
|
||||
If it fails all ten times, we report the test as failed; otherwise, we report it as unreliable,
|
||||
which will show up as a warning, but which will not fail the build. When a test is reported as unreliable,
|
||||
we include the results for each individual run via a JSON string in the original test's errorMessage field.
|
||||
6. TAEF produces logs in WTT format. Helix is able to process logs in XUnit format. We run
|
||||
[ConvertWttLogToXUnit.ps1](ConvertWttLogToXUnit.ps1) to convert the logs into the necessary format.
|
||||
7. RunTestsInHelix.proj has EnableAzurePipelinesReporter set to true. This allows the XUnit formatted test
|
||||
results to be reported back to the Azure DevOps Pipeline.
|
||||
8. We process unreliable tests once all tests have been reported by reading the JSON string from the
|
||||
errorMessage field and calling the Azure DevOps REST API to modify the unreliable tests to have sub-results
|
||||
added to the test and to mark the test as "warning", which will enable people to see exactly how the test
|
||||
failed in runs where it did.
|
||||
@@ -1,106 +0,0 @@
|
||||
setlocal ENABLEDELAYEDEXPANSION
|
||||
|
||||
echo %TIME%
|
||||
|
||||
robocopy %HELIX_CORRELATION_PAYLOAD% . /s /NP > NUL
|
||||
|
||||
echo %TIME%
|
||||
|
||||
reg add HKLM\Software\Policies\Microsoft\Windows\Appx /v AllowAllTrustedApps /t REG_DWORD /d 1 /f
|
||||
|
||||
rem enable dump collection for our test apps:
|
||||
rem note, this script is run from a 32-bit cmd, but we need to set the native reg-key
|
||||
FOR %%A IN (TestHostApp.exe,te.exe,te.processhost.exe,conhost.exe,OpenConsole.exe,WindowsTerminal.exe) DO (
|
||||
%systemroot%\sysnative\cmd.exe /c reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\%%A" /v DumpFolder /t REG_EXPAND_SZ /d %HELIX_DUMP_FOLDER% /f
|
||||
%systemroot%\sysnative\cmd.exe /c reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\%%A" /v DumpType /t REG_DWORD /d 2 /f
|
||||
%systemroot%\sysnative\cmd.exe /c reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\%%A" /v DumpCount /t REG_DWORD /d 10 /f
|
||||
)
|
||||
|
||||
echo %TIME%
|
||||
|
||||
:: kill dhandler, which is a tool designed to handle unexpected windows appearing. But since our tests are
|
||||
:: expected to show UI we don't want it running.
|
||||
taskkill -f -im dhandler.exe
|
||||
|
||||
echo %TIME%
|
||||
powershell -ExecutionPolicy Bypass .\EnsureMachineState.ps1
|
||||
echo %TIME%
|
||||
powershell -ExecutionPolicy Bypass .\InstallTestAppDependencies.ps1
|
||||
echo %TIME%
|
||||
|
||||
set testBinaryCandidates=TerminalApp.LocalTests.dll Conhost.UIA.Tests.dll
|
||||
set testBinaries=
|
||||
for %%B in (%testBinaryCandidates%) do (
|
||||
if exist %%B (
|
||||
set "testBinaries=!testBinaries! %%B"
|
||||
)
|
||||
)
|
||||
|
||||
echo %TIME%
|
||||
te.exe %testBinaries% /enablewttlogging /unicodeOutput:false /sessionTimeout:0:15 /testtimeout:0:10 /screenCaptureOnError %*
|
||||
echo %TIME%
|
||||
|
||||
powershell -ExecutionPolicy Bypass Get-Process
|
||||
|
||||
move te.wtl te_original.wtl
|
||||
|
||||
copy /y te_original.wtl %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
copy /y WexLogFileOutput\*.jpg %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
for /f "tokens=* delims=" %%a in ('dir /b *.pgc') do ren "%%a" "%testnameprefix%.%%~na.pgc"
|
||||
copy /y *.pgc %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
|
||||
set FailedTestQuery=
|
||||
for /F "tokens=* usebackq" %%I IN (`powershell -ExecutionPolicy Bypass .\OutputFailedTestQuery.ps1 te_original.wtl`) DO (
|
||||
set FailedTestQuery=%%I
|
||||
)
|
||||
|
||||
rem The first time, we'll just re-run failed tests once. In many cases, tests fail very rarely, such that
|
||||
rem a single re-run will be sufficient to detect many unreliable tests.
|
||||
if "%FailedTestQuery%" == "" goto :SkipReruns
|
||||
|
||||
echo %TIME%
|
||||
te.exe %testBinaries% /enablewttlogging /unicodeOutput:false /sessionTimeout:0:15 /testtimeout:0:10 /screenCaptureOnError /select:"%FailedTestQuery%"
|
||||
echo %TIME%
|
||||
|
||||
move te.wtl te_rerun.wtl
|
||||
|
||||
copy /y te_rerun.wtl %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
copy /y WexLogFileOutput\*.jpg %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
|
||||
rem If there are still failing tests remaining, we'll run them eight more times, so they'll have been run a total of ten times.
|
||||
rem If any tests fail all ten times, we can be pretty confident that these are actual test failures rather than unreliable tests.
|
||||
if not exist te_rerun.wtl goto :SkipReruns
|
||||
|
||||
set FailedTestQuery=
|
||||
for /F "tokens=* usebackq" %%I IN (`powershell -ExecutionPolicy Bypass .\OutputFailedTestQuery.ps1 te_rerun.wtl`) DO (
|
||||
set FailedTestQuery=%%I
|
||||
)
|
||||
|
||||
if "%FailedTestQuery%" == "" goto :SkipReruns
|
||||
|
||||
echo %TIME%
|
||||
te.exe %testBinaries% /enablewttlogging /unicodeOutput:false /sessionTimeout:0:15 /testtimeout:0:10 /screenCaptureOnError /testmode:Loop /LoopTest:8 /select:"%FailedTestQuery%"
|
||||
echo %TIME%
|
||||
|
||||
powershell -ExecutionPolicy Bypass Get-Process
|
||||
|
||||
move te.wtl te_rerun_multiple.wtl
|
||||
|
||||
copy /y te_rerun_multiple.wtl %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
copy /y WexLogFileOutput\*.jpg %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
powershell -ExecutionPolicy Bypass .\CopyVisualTreeVerificationFiles.ps1
|
||||
|
||||
:SkipReruns
|
||||
|
||||
powershell -ExecutionPolicy Bypass Get-Process
|
||||
|
||||
echo %TIME%
|
||||
powershell -ExecutionPolicy Bypass .\OutputSubResultsJsonFiles.ps1 te_original.wtl te_rerun.wtl te_rerun_multiple.wtl %testnameprefix%
|
||||
powershell -ExecutionPolicy Bypass .\ConvertWttLogToXUnit.ps1 te_original.wtl te_rerun.wtl te_rerun_multiple.wtl testResults.xml %testnameprefix%
|
||||
echo %TIME%
|
||||
|
||||
copy /y *_subresults.json %HELIX_WORKITEM_UPLOAD_ROOT%
|
||||
|
||||
type testResults.xml
|
||||
|
||||
echo %TIME%
|
||||
@@ -1,5 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<packages>
|
||||
<package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
|
||||
<package id="TAEF.Redist.Wlk" version="10.57.200731005-develop" targetFramework="native" />
|
||||
</packages>
|
||||
@@ -2,8 +2,7 @@ trigger:
|
||||
batch: true
|
||||
branches:
|
||||
include:
|
||||
- main
|
||||
- feature/*
|
||||
- master
|
||||
paths:
|
||||
exclude:
|
||||
- doc/*
|
||||
@@ -13,8 +12,7 @@ trigger:
|
||||
pr:
|
||||
branches:
|
||||
include:
|
||||
- main
|
||||
- feature/*
|
||||
- master
|
||||
paths:
|
||||
exclude:
|
||||
- doc/*
|
||||
@@ -49,6 +47,7 @@ stages:
|
||||
- stage: Build_x86
|
||||
displayName: Build x86
|
||||
dependsOn: []
|
||||
condition: not(eq(variables['Build.Reason'], 'PullRequest'))
|
||||
jobs:
|
||||
- template: ./templates/build-console-ci.yml
|
||||
parameters:
|
||||
|
||||
@@ -8,9 +8,7 @@ jobs:
|
||||
variables:
|
||||
BuildConfiguration: AuditMode
|
||||
BuildPlatform: ${{ parameters.platform }}
|
||||
pool: "windevbuildagents"
|
||||
# The public pool is also an option!
|
||||
# pool: { vmImage: windows-2019 }
|
||||
pool: { vmImage: windows-2019 }
|
||||
|
||||
steps:
|
||||
- checkout: self
|
||||
|
||||
@@ -2,8 +2,6 @@ parameters:
|
||||
configuration: 'Release'
|
||||
platform: ''
|
||||
additionalBuildArguments: ''
|
||||
minimumExpectedTestsExecutedCount: 10 # Sanity check for minimum expected tests to be reported
|
||||
rerunPassesRequiredToAvoidFailure: 5
|
||||
|
||||
jobs:
|
||||
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
|
||||
@@ -11,27 +9,9 @@ jobs:
|
||||
variables:
|
||||
BuildConfiguration: ${{ parameters.configuration }}
|
||||
BuildPlatform: ${{ parameters.platform }}
|
||||
pool: "windevbuildagents"
|
||||
# The public pool is also an option!
|
||||
# pool: { vmImage: windows-2019 }
|
||||
pool: { vmImage: windows-2019 }
|
||||
|
||||
steps:
|
||||
- template: build-console-steps.yml
|
||||
parameters:
|
||||
additionalBuildArguments: ${{ parameters.additionalBuildArguments }}
|
||||
|
||||
- template: helix-runtests-job.yml
|
||||
parameters:
|
||||
name: 'RunTestsInHelix'
|
||||
dependsOn: Build${{ parameters.platform }}${{ parameters.configuration }}
|
||||
condition: and(succeeded(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest'))))
|
||||
testSuite: 'DevTestSuite'
|
||||
rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
|
||||
|
||||
- template: helix-processtestresults-job.yml
|
||||
parameters:
|
||||
dependsOn:
|
||||
- RunTestsInHelix
|
||||
condition: and(succeededOrFailed(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest'))))
|
||||
rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
|
||||
minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
|
||||
@@ -1,6 +1,5 @@
|
||||
parameters:
|
||||
additionalBuildArguments: ''
|
||||
testLogPath: '$(Build.BinariesDirectory)\$(BuildPlatform)\$(BuildConfiguration)\testsOnBuildMachine.wtl'
|
||||
|
||||
steps:
|
||||
- checkout: self
|
||||
@@ -8,29 +7,23 @@ steps:
|
||||
clean: true
|
||||
|
||||
- task: NuGetToolInstaller@0
|
||||
displayName: 'Use NuGet 5.2.0'
|
||||
displayName: Ensure NuGet 4.8.1
|
||||
inputs:
|
||||
versionSpec: 5.2.0
|
||||
versionSpec: 4.8.1
|
||||
|
||||
- task: VisualStudioTestPlatformInstaller@1
|
||||
displayName: Ensure VSTest Platform
|
||||
|
||||
# In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
|
||||
# This should be `task: NuGetCommand@2`
|
||||
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
|
||||
displayName: Restore NuGet packages for solution
|
||||
displayName: Restore NuGet packages
|
||||
inputs:
|
||||
command: restore
|
||||
feedsToUse: config
|
||||
configPath: NuGet.config
|
||||
restoreSolution: OpenConsole.sln
|
||||
restoreDirectory: '$(Build.SourcesDirectory)\packages'
|
||||
|
||||
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
|
||||
displayName: Restore NuGet packages for extraneous build actions
|
||||
inputs:
|
||||
command: restore
|
||||
feedsToUse: config
|
||||
configPath: NuGet.config
|
||||
restoreSolution: build/packages.config
|
||||
restoreDirectory: '$(Build.SourcesDirectory)\packages'
|
||||
|
||||
- task: VSBuild@1
|
||||
displayName: 'Build solution **\OpenConsole.sln'
|
||||
@@ -73,7 +66,7 @@ steps:
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\scripts\Run-Tests.ps1
|
||||
arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
|
||||
arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
|
||||
condition: and(succeeded(), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
|
||||
|
||||
- task: PowerShell@2
|
||||
@@ -81,41 +74,9 @@ steps:
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\scripts\Run-Tests.ps1
|
||||
arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
|
||||
arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
|
||||
condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
|
||||
|
||||
- task: PowerShell@2
|
||||
displayName: 'Convert Test Logs from WTL to xUnit format'
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\ConvertWttLogToXUnit.ps1
|
||||
arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
|
||||
condition: or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86'))
|
||||
|
||||
- task: PublishTestResults@2
|
||||
displayName: 'Upload converted test logs'
|
||||
inputs:
|
||||
testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
|
||||
testResultsFiles: '**/onBuildMachineResults.xml'
|
||||
#searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
|
||||
#mergeTestResults: false # Optional
|
||||
#failTaskOnFailedTests: false # Optional
|
||||
testRunTitle: 'On Build Machine Tests' # Optional
|
||||
buildPlatform: $(BuildPlatform) # Optional
|
||||
buildConfiguration: $(BuildConfiguration) # Optional
|
||||
#publishRunAttachments: true # Optional
|
||||
|
||||
- task: CopyFiles@2
|
||||
displayName: 'Copy result logs to Artifacts'
|
||||
inputs:
|
||||
Contents: |
|
||||
**/*.wtl
|
||||
**/*onBuildMachineResults.xml
|
||||
${{ parameters.testLogPath }}
|
||||
TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
|
||||
OverWrite: true
|
||||
flattenFolders: true
|
||||
|
||||
- task: CopyFiles@2
|
||||
displayName: 'Copy *.appx/*.msix to Artifacts (Non-PR builds only)'
|
||||
inputs:
|
||||
@@ -129,22 +90,9 @@ steps:
|
||||
flattenFolders: true
|
||||
condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
|
||||
|
||||
- task: CopyFiles@2
|
||||
displayName: 'Copy outputs needed for test runs to Artifacts'
|
||||
inputs:
|
||||
Contents: |
|
||||
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.exe
|
||||
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.dll
|
||||
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.xml
|
||||
**/Microsoft.VCLibs.*.appx
|
||||
**/TestHostApp/*
|
||||
TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
|
||||
OverWrite: true
|
||||
flattenFolders: true
|
||||
condition: and(and(succeeded(), eq(variables['BuildPlatform'], 'x64')), ne(variables['Build.Reason'], 'PullRequest'))
|
||||
|
||||
- task: PublishBuildArtifacts@1
|
||||
displayName: 'Publish All Build Artifacts'
|
||||
displayName: 'Publish Artifact (appx) (Non-PR builds only)'
|
||||
inputs:
|
||||
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
|
||||
ArtifactName: 'drop'
|
||||
PathtoPublish: '$(Build.ArtifactStagingDirectory)/appx'
|
||||
ArtifactName: 'appx-$(BuildConfiguration)'
|
||||
condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
parameters:
|
||||
condition: ''
|
||||
testFilePath: ''
|
||||
outputProjFileName: ''
|
||||
testSuite: ''
|
||||
taefQuery: ''
|
||||
|
||||
steps:
|
||||
- task: powershell@2
|
||||
displayName: 'Create ${{ parameters.outputProjFileName }}'
|
||||
condition: ${{ parameters.condition }}
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\GenerateTestProjFile.ps1
|
||||
arguments: -TestFile '${{ parameters.testFilePath }}' -OutputProjFile '$(Build.ArtifactStagingDirectory)\${{ parameters.outputProjFileName }}' -JobTestSuiteName '${{ parameters.testSuite }}' -TaefPath '$(Build.SourcesDirectory)\build\Helix\packages\taef.redist.wlk.10.57.200731005-develop\build\Binaries\x86' -TaefQuery '${{ parameters.taefQuery }}'
|
||||
@@ -1,68 +0,0 @@
|
||||
parameters:
|
||||
condition: 'succeededOrFailed()'
|
||||
dependsOn: ''
|
||||
rerunPassesRequiredToAvoidFailure: 5
|
||||
minimumExpectedTestsExecutedCount: 10
|
||||
checkJobAttempt: false
|
||||
pgoArtifact: ''
|
||||
|
||||
jobs:
|
||||
- job: ProcessTestResults
|
||||
condition: ${{ parameters.condition }}
|
||||
dependsOn: ${{ parameters.dependsOn }}
|
||||
pool:
|
||||
vmImage: 'windows-2019'
|
||||
timeoutInMinutes: 120
|
||||
variables:
|
||||
helixOutputFolder: $(Build.SourcesDirectory)\HelixOutput
|
||||
|
||||
steps:
|
||||
- task: powershell@2
|
||||
displayName: 'UpdateUnreliableTests.ps1'
|
||||
condition: succeededOrFailed()
|
||||
env:
|
||||
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\UpdateUnreliableTests.ps1
|
||||
arguments: -RerunPassesRequiredToAvoidFailure '${{ parameters.rerunPassesRequiredToAvoidFailure }}'
|
||||
|
||||
- task: powershell@2
|
||||
displayName: 'OutputTestResults.ps1'
|
||||
condition: succeededOrFailed()
|
||||
env:
|
||||
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\OutputTestResults.ps1
|
||||
arguments: -MinimumExpectedTestsExecutedCount '${{ parameters.minimumExpectedTestsExecutedCount }}' -CheckJobAttempt $${{ parameters.checkJobAttempt }}
|
||||
|
||||
- task: powershell@2
|
||||
displayName: 'ProcessHelixFiles.ps1'
|
||||
condition: succeededOrFailed()
|
||||
env:
|
||||
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
|
||||
HelixAccessToken: $(HelixApiAccessToken)
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\ProcessHelixFiles.ps1
|
||||
arguments: -OutputFolder '$(helixOutputFolder)'
|
||||
|
||||
- ${{if ne(parameters.pgoArtifact, '') }}:
|
||||
- script: move /y $(helixOutputFolder)\PGO $(Build.ArtifactStagingDirectory)
|
||||
displayName: 'Move pgc files to PGO artifact'
|
||||
|
||||
- task: PublishBuildArtifacts@1
|
||||
displayName: 'Publish Helix files'
|
||||
condition: succeededOrFailed()
|
||||
inputs:
|
||||
PathtoPublish: $(helixOutputFolder)
|
||||
artifactName: drop
|
||||
|
||||
- ${{if ne(parameters.pgoArtifact, '') }}:
|
||||
- task: PublishBuildArtifacts@1
|
||||
displayName: 'Publish pgc files'
|
||||
condition: succeededOrFailed()
|
||||
inputs:
|
||||
PathtoPublish: $(Build.ArtifactStagingDirectory)\PGO\Release
|
||||
artifactName: ${{ parameters.pgoArtifact }}
|
||||
@@ -1,131 +0,0 @@
|
||||
parameters:
|
||||
name: 'RunTestsInHelix'
|
||||
dependsOn: ''
|
||||
condition: ''
|
||||
testSuite: ''
|
||||
# If a Pipeline runs this template more than once, this parameter should be unique per build flavor to differentiate the
|
||||
# the different test runs:
|
||||
helixType: 'test/devtest'
|
||||
artifactName: 'drop'
|
||||
maxParallel: 4
|
||||
rerunPassesRequiredToAvoidFailure: 5
|
||||
taefQuery: ''
|
||||
# if 'useBuildOutputFromBuildId' is set, we will default to using a build from this pipeline:
|
||||
useBuildOutputFromPipeline: $(System.DefinitionId)
|
||||
matrix:
|
||||
# Release_x86:
|
||||
# buildPlatform: 'x86'
|
||||
# buildConfiguration: 'release'
|
||||
# openHelixTargetQueues: 'windows.10.amd64.client19h1.open.xaml'
|
||||
# closedHelixTargetQueues: 'windows.10.amd64.client19h1.xaml'
|
||||
Release_x64:
|
||||
buildPlatform: 'x64'
|
||||
buildConfiguration: 'release'
|
||||
openHelixTargetQueues: 'windows.10.amd64.client19h1.open.xaml'
|
||||
closedHelixTargetQueues: 'windows.10.amd64.client19h1.xaml'
|
||||
|
||||
jobs:
|
||||
- job: ${{ parameters.name }}
|
||||
dependsOn: ${{ parameters.dependsOn }}
|
||||
condition: ${{ parameters.condition }}
|
||||
pool:
|
||||
vmImage: 'windows-2019'
|
||||
timeoutInMinutes: 120
|
||||
strategy:
|
||||
maxParallel: ${{ parameters.maxParallel }}
|
||||
matrix: ${{ parameters.matrix }}
|
||||
variables:
|
||||
artifactsDir: $(Build.SourcesDirectory)\Artifacts
|
||||
taefPath: $(Build.SourcesDirectory)\build\Helix\packages\taef.redist.wlk.10.57.200731005-develop\build\Binaries\$(buildPlatform)
|
||||
helixCommonArgs: '/binaryLogger:$(Build.SourcesDirectory)/${{parameters.name}}.$(buildPlatform).$(buildConfiguration).binlog /p:HelixBuild=$(Build.BuildId).$(buildPlatform).$(buildConfiguration) /p:Platform=$(buildPlatform) /p:Configuration=$(buildConfiguration) /p:HelixType=${{parameters.helixType}} /p:TestSuite=${{parameters.testSuite}} /p:ProjFilesPath=$(Build.ArtifactStagingDirectory) /p:rerunPassesRequiredToAvoidFailure=${{parameters.rerunPassesRequiredToAvoidFailure}}'
|
||||
|
||||
|
||||
steps:
|
||||
- task: CmdLine@1
|
||||
displayName: 'Display build machine environment variables'
|
||||
inputs:
|
||||
filename: 'set'
|
||||
|
||||
- task: NuGetToolInstaller@0
|
||||
displayName: 'Use NuGet 5.2.0'
|
||||
inputs:
|
||||
versionSpec: 5.2.0
|
||||
|
||||
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
|
||||
displayName: 'NuGet restore build/Helix/packages.config'
|
||||
inputs:
|
||||
restoreSolution: build/Helix/packages.config
|
||||
feedsToUse: config
|
||||
nugetConfigPath: nuget.config
|
||||
restoreDirectory: packages
|
||||
|
||||
- task: DownloadBuildArtifacts@0
|
||||
condition:
|
||||
and(succeeded(),eq(variables['useBuildOutputFromBuildId'],''))
|
||||
inputs:
|
||||
artifactName: ${{ parameters.artifactName }}
|
||||
downloadPath: '$(artifactsDir)'
|
||||
|
||||
- task: DownloadBuildArtifacts@0
|
||||
condition:
|
||||
and(succeeded(),ne(variables['useBuildOutputFromBuildId'],''))
|
||||
inputs:
|
||||
buildType: specific
|
||||
buildVersionToDownload: specific
|
||||
project: $(System.TeamProjectId)
|
||||
pipeline: ${{ parameters.useBuildOutputFromPipeline }}
|
||||
buildId: $(useBuildOutputFromBuildId)
|
||||
artifactName: ${{ parameters.artifactName }}
|
||||
downloadPath: '$(artifactsDir)'
|
||||
|
||||
- task: CmdLine@1
|
||||
displayName: 'Display Artifact Directory payload contents'
|
||||
inputs:
|
||||
filename: 'dir'
|
||||
arguments: '/s $(artifactsDir)'
|
||||
|
||||
- task: powershell@2
|
||||
displayName: 'PrepareHelixPayload.ps1'
|
||||
inputs:
|
||||
targetType: filePath
|
||||
filePath: build\Helix\PrepareHelixPayload.ps1
|
||||
arguments: -Platform '$(buildPlatform)' -Configuration '$(buildConfiguration)' -ArtifactName '${{ parameters.artifactName }}'
|
||||
|
||||
- task: CmdLine@1
|
||||
displayName: 'Display Helix payload contents'
|
||||
inputs:
|
||||
filename: 'dir'
|
||||
arguments: '/s $(Build.SourcesDirectory)\HelixPayload'
|
||||
|
||||
- template: helix-createprojfile-steps.yml
|
||||
parameters:
|
||||
condition: and(succeeded(),ne('${{ parameters.testSuite }}','NugetTestSuite'))
|
||||
testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\TerminalApp.LocalTests.dll'
|
||||
outputProjFileName: 'RunTestsInHelix-TerminalAppLocalTests.proj'
|
||||
testSuite: '${{ parameters.testSuite }}'
|
||||
taefQuery: ${{ parameters.taefQuery }}
|
||||
|
||||
- template: helix-createprojfile-steps.yml
|
||||
parameters:
|
||||
condition: and(succeeded(),ne('${{ parameters.testSuite }}','NugetTestSuite'))
|
||||
testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\Conhost.UIA.Tests.dll'
|
||||
outputProjFileName: 'RunTestsInHelix-HostTestsUIA.proj'
|
||||
testSuite: '${{ parameters.testSuite }}'
|
||||
taefQuery: ${{ parameters.taefQuery }}
|
||||
|
||||
- task: PublishBuildArtifacts@1
|
||||
displayName: 'Publish generated .proj files'
|
||||
inputs:
|
||||
PathtoPublish: $(Build.ArtifactStagingDirectory)
|
||||
artifactName: ${{ parameters.artifactName }}
|
||||
|
||||
- task: DotNetCoreCLI@2
|
||||
displayName: 'Run tests in Helix (open queues)'
|
||||
env:
|
||||
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
|
||||
inputs:
|
||||
command: custom
|
||||
projects: build\Helix\RunTestsInHelix.proj
|
||||
custom: msbuild
|
||||
arguments: '$(helixCommonArgs) /p:IsExternal=true /p:Creator=Terminal /p:HelixTargetQueues=$(openHelixTargetQueues)'
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
||||
<PropertyGroup>
|
||||
<_WTBrandingPreprocessorToken Condition="'$(WindowsTerminalBranding)'=='Preview'">WT_BRANDING_PREVIEW</_WTBrandingPreprocessorToken>
|
||||
<_WTBrandingPreprocessorToken Condition="'$(WindowsTerminalBranding)'=='Release'">WT_BRANDING_RELEASE</_WTBrandingPreprocessorToken>
|
||||
<_WTBrandingPreprocessorToken Condition="'$(_WTBrandingPreprocessorToken)'==''">WT_BRANDING_DEV</_WTBrandingPreprocessorToken>
|
||||
</PropertyGroup>
|
||||
|
||||
<ItemDefinitionGroup>
|
||||
<ClCompile>
|
||||
<PreprocessorDefinitions>$(_WTBrandingPreprocessorToken);%(PreprocessorDefinitions)</PreprocessorDefinitions>
|
||||
</ClCompile>
|
||||
|
||||
<ResourceCompile>
|
||||
<PreprocessorDefinitions>$(_WTBrandingPreprocessorToken);%(PreprocessorDefinitions)</PreprocessorDefinitions>
|
||||
</ResourceCompile>
|
||||
</ItemDefinitionGroup>
|
||||
</Project>
|
||||
@@ -1,38 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<Project DefaultTargets="Build" ToolsVersion="16.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
||||
<PropertyGroup>
|
||||
</PropertyGroup>
|
||||
|
||||
<Target Name="BeforeGenerateProjectPriFile" DependsOnTargets="OpenConsoleCollectWildcardPRIFiles" />
|
||||
|
||||
<!--
|
||||
The vcxproj system does not support wildcards at the root level of a project.
|
||||
This poses a problem, as we want to include resw files that are not checked into the
|
||||
repository. Since they're usually localized and stored in directories named after
|
||||
their languages, we can't exactly explicitly simultaneously list them all and remain
|
||||
sane. We want to use wildcards to make our lives easier.
|
||||
|
||||
This rule takes OCResourceDirectory items and includes all resw files that live
|
||||
underneath them.
|
||||
|
||||
** TIRED **
|
||||
(does not work because of wildcards)
|
||||
<PRIResource Include="Resources/*/Resources.resw" />
|
||||
|
||||
** WIRED **
|
||||
(keep the en-US resource in the project, because it is checked in and VS will show it)
|
||||
<PRIResource Include="Resources/en-US/Resources.resw" />
|
||||
<OCResourceDirectory Include="Resources" />
|
||||
-->
|
||||
<Target Name="OpenConsoleCollectWildcardPRIFiles">
|
||||
<CreateItem Include="@(OCResourceDirectory->'%(Identity)\**\*.resw')">
|
||||
<Output TaskParameter="Include" ItemName="_OCFoundPRIFiles" />
|
||||
</CreateItem>
|
||||
<ItemGroup>
|
||||
<_OCFoundPRIFiles Include="@(PRIResource)" />
|
||||
<PRIResource Remove="@(PRIResource)" />
|
||||
<PRIResource Include="@(_OCFoundPRIFiles->Distinct())" />
|
||||
</ItemGroup>
|
||||
<Message Text="$(ProjectName) (wildcard PRIs) -> @(PRIResource)" />
|
||||
</Target>
|
||||
</Project>
|
||||
@@ -1,15 +0,0 @@
|
||||
[CmdLetBinding()]
|
||||
Param(
|
||||
[Parameter(Mandatory=$true, Position=0)][string]$BuildPlatform,
|
||||
[Parameter(Mandatory=$true, Position=1)][string]$RationalizedPlatform,
|
||||
[Parameter(Mandatory=$true, Position=2)][string]$Configuration
|
||||
)
|
||||
|
||||
|
||||
$i = Get-Item .\packages\MuxCustomBuild*
|
||||
$wtt = Join-Path -Path $i[0].FullName -ChildPath (Join-Path -Path 'tools' -ChildPath (Join-Path -Path $BuildPlatform -ChildPath 'wttlog.dll'))
|
||||
$dest = Join-Path -Path .\bin -ChildPath (Join-Path -Path $RationalizedPlatform -ChildPath ($Configuration))
|
||||
copy $wtt $dest
|
||||
|
||||
|
||||
Exit 0
|
||||
@@ -2,24 +2,12 @@
|
||||
Param(
|
||||
[Parameter(Mandatory=$true, Position=0)][string]$MatchPattern,
|
||||
[Parameter(Mandatory=$true, Position=1)][string]$Platform,
|
||||
[Parameter(Mandatory=$true, Position=2)][string]$Configuration,
|
||||
[Parameter(Mandatory=$false, Position=3)][string]$LogPath
|
||||
[Parameter(Mandatory=$true, Position=2)][string]$Configuration
|
||||
)
|
||||
|
||||
$testdlls = Get-ChildItem -Path ".\bin\$Platform\$Configuration" -Recurse -Filter $MatchPattern
|
||||
|
||||
|
||||
$args = @();
|
||||
|
||||
if ($LogPath)
|
||||
{
|
||||
$args += '/enablewttlogging';
|
||||
$args += '/appendwttlogging';
|
||||
$args += "/logFile:$LogPath";
|
||||
Write-Host "Wtt Logging Enabled";
|
||||
}
|
||||
|
||||
&".\bin\$Platform\$Configuration\te.exe" $args $testdlls.FullName
|
||||
&".\bin\$Platform\$Configuration\te.exe" $testdlls.FullName
|
||||
|
||||
if ($lastexitcode -Ne 0) { Exit $lastexitcode }
|
||||
|
||||
|
||||
@@ -101,15 +101,6 @@ Try {
|
||||
Throw "Failed to find cpprest142_2_10.dll -- check the WAP packaging project"
|
||||
}
|
||||
|
||||
If (($null -eq (Get-Item "$AppxPackageRootPath\wtd.exe" -EA:Ignore)) -And
|
||||
($null -eq (Get-Item "$AppxPackageRootPath\wt.exe" -EA:Ignore))) {
|
||||
Throw "Failed to find wt.exe/wtd.exe -- check the WAP packaging project"
|
||||
}
|
||||
|
||||
If ($null -eq (Get-Item "$AppxPackageRootPath\OpenConsole.exe" -EA:Ignore)) {
|
||||
Throw "Failed to find OpenConsole.exe -- check the WAP packaging project"
|
||||
}
|
||||
|
||||
} Finally {
|
||||
Remove-Item -Recurse -Force $AppxPackageRootPath
|
||||
}
|
||||
|
||||
@@ -36,7 +36,6 @@
|
||||
".db",
|
||||
".wrn",
|
||||
".rec",
|
||||
".err",
|
||||
".xlsx"
|
||||
".err"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
<XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
|
||||
<XesBaseYearForStoreVersion>2020</XesBaseYearForStoreVersion>
|
||||
<VersionMajor>1</VersionMajor>
|
||||
<VersionMinor>6</VersionMinor>
|
||||
<VersionMinor>1</VersionMinor>
|
||||
<VersionInfoProductName>Windows Terminal</VersionInfoProductName>
|
||||
</PropertyGroup>
|
||||
</Project>
|
||||
|
||||
4440
dep/CLI11/CLI11.hpp
4440
dep/CLI11/CLI11.hpp
File diff suppressed because it is too large
Load Diff
@@ -1,5 +1,5 @@
|
||||
# CLI11
|
||||
|
||||
Taken from [release v1.9.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.0), source commit
|
||||
[dd0d8e4](https://github.com/CLIUtils/CLI11/commit/dd0d8e4fe729e5b1110232c7a5c9566dad884686)
|
||||
Taken from [release v1.8.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.8.0), source commit
|
||||
[13becad](https://github.com/CLIUtils/CLI11/commit/13becaddb657eacd090537719a669d66d393b8b2)
|
||||
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
{"Registrations":[
|
||||
{
|
||||
"component": {
|
||||
"type": "git",
|
||||
"git": {
|
||||
"repositoryUrl": "https://github.com/CLIUtils/CLI11",
|
||||
"commitHash": "dd0d8e4fe729e5b1110232c7a5c9566dad884686"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"Version": 1
|
||||
}
|
||||
2
dep/gsl
2
dep/gsl
Submodule dep/gsl updated: 0f6dbc9e29...7e99e76c97
@@ -2,15 +2,6 @@
|
||||
|
||||
[Amalgamated](https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated)
|
||||
from source commit
|
||||
[6aba23f](https://github.com/open-source-parsers/jsoncpp/commit/6aba23f4a8628d599a9ef7fa4811c4ff6e4070e2),
|
||||
release 1.9.3.
|
||||
[ddabf50](https://github.com/open-source-parsers/jsoncpp/commit/ddabf50f72cf369bf652a95c4d9fe31a1865a781),
|
||||
release 1.8.4.
|
||||
|
||||
> Generating amalgamated source and header JsonCpp is provided with a script to
|
||||
> generate a single header and a single source file to ease inclusion into an
|
||||
> existing project. The amalgamated source can be generated at any time by
|
||||
> running the following command from the top-directory (this requires Python
|
||||
> 3.4+):
|
||||
>
|
||||
> ```
|
||||
> python amalgamate.py
|
||||
> ```
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
{"Registrations":[
|
||||
{
|
||||
"component": {
|
||||
"type": "git",
|
||||
"git": {
|
||||
"repositoryUrl": "https://github.com/open-source-parsers/jsoncpp",
|
||||
"commitHash": "6aba23f4a8628d599a9ef7fa4811c4ff6e4070e2"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"Version": 1
|
||||
}
|
||||
@@ -79,151 +79,6 @@ license you like.
|
||||
/// to prevent private header inclusion.
|
||||
#define JSON_IS_AMALGAMATION
|
||||
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
// Beginning of content of file: include/json/version.h
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
|
||||
#ifndef JSON_VERSION_H_INCLUDED
|
||||
#define JSON_VERSION_H_INCLUDED
|
||||
|
||||
// Note: version must be updated in three places when doing a release. This
|
||||
// annoying process ensures that amalgamate, CMake, and meson all report the
|
||||
// correct version.
|
||||
// 1. /meson.build
|
||||
// 2. /include/json/version.h
|
||||
// 3. /CMakeLists.txt
|
||||
// IMPORTANT: also update the SOVERSION!!
|
||||
|
||||
#define JSONCPP_VERSION_STRING "1.9.3"
|
||||
#define JSONCPP_VERSION_MAJOR 1
|
||||
#define JSONCPP_VERSION_MINOR 9
|
||||
#define JSONCPP_VERSION_PATCH 3
|
||||
#define JSONCPP_VERSION_QUALIFIER
|
||||
#define JSONCPP_VERSION_HEXA \
|
||||
((JSONCPP_VERSION_MAJOR << 24) | (JSONCPP_VERSION_MINOR << 16) | \
|
||||
(JSONCPP_VERSION_PATCH << 8))
|
||||
|
||||
#ifdef JSONCPP_USING_SECURE_MEMORY
|
||||
#undef JSONCPP_USING_SECURE_MEMORY
|
||||
#endif
|
||||
#define JSONCPP_USING_SECURE_MEMORY 0
|
||||
// If non-zero, the library zeroes any memory that it has allocated before
|
||||
// it frees its memory.
|
||||
|
||||
#endif // JSON_VERSION_H_INCLUDED
|
||||
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
// End of content of file: include/json/version.h
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
// Beginning of content of file: include/json/allocator.h
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
|
||||
// Copyright 2007-2010 Baptiste Lepilleur and The JsonCpp Authors
|
||||
// Distributed under MIT license, or public domain if desired and
|
||||
// recognized in your jurisdiction.
|
||||
// See file LICENSE for detail or copy at http://jsoncpp.sourceforge.net/LICENSE
|
||||
|
||||
#ifndef JSON_ALLOCATOR_H_INCLUDED
|
||||
#define JSON_ALLOCATOR_H_INCLUDED
|
||||
|
||||
#include <cstring>
|
||||
#include <memory>
|
||||
|
||||
#pragma pack(push, 8)
|
||||
|
||||
namespace Json {
|
||||
template <typename T> class SecureAllocator {
|
||||
public:
|
||||
// Type definitions
|
||||
using value_type = T;
|
||||
using pointer = T*;
|
||||
using const_pointer = const T*;
|
||||
using reference = T&;
|
||||
using const_reference = const T&;
|
||||
using size_type = std::size_t;
|
||||
using difference_type = std::ptrdiff_t;
|
||||
|
||||
/**
|
||||
* Allocate memory for N items using the standard allocator.
|
||||
*/
|
||||
pointer allocate(size_type n) {
|
||||
// allocate using "global operator new"
|
||||
return static_cast<pointer>(::operator new(n * sizeof(T)));
|
||||
}
|
||||
|
||||
/**
|
||||
* Release memory which was allocated for N items at pointer P.
|
||||
*
|
||||
* The memory block is filled with zeroes before being released.
|
||||
* The pointer argument is tagged as "volatile" to prevent the
|
||||
* compiler optimizing out this critical step.
|
||||
*/
|
||||
void deallocate(volatile pointer p, size_type n) {
|
||||
std::memset(p, 0, n * sizeof(T));
|
||||
// free using "global operator delete"
|
||||
::operator delete(p);
|
||||
}
|
||||
|
||||
/**
|
||||
* Construct an item in-place at pointer P.
|
||||
*/
|
||||
template <typename... Args> void construct(pointer p, Args&&... args) {
|
||||
// construct using "placement new" and "perfect forwarding"
|
||||
::new (static_cast<void*>(p)) T(std::forward<Args>(args)...);
|
||||
}
|
||||
|
||||
size_type max_size() const { return size_t(-1) / sizeof(T); }
|
||||
|
||||
pointer address(reference x) const { return std::addressof(x); }
|
||||
|
||||
const_pointer address(const_reference x) const { return std::addressof(x); }
|
||||
|
||||
/**
|
||||
* Destroy an item in-place at pointer P.
|
||||
*/
|
||||
void destroy(pointer p) {
|
||||
// destroy using "explicit destructor"
|
||||
p->~T();
|
||||
}
|
||||
|
||||
// Boilerplate
|
||||
SecureAllocator() {}
|
||||
template <typename U> SecureAllocator(const SecureAllocator<U>&) {}
|
||||
template <typename U> struct rebind { using other = SecureAllocator<U>; };
|
||||
};
|
||||
|
||||
template <typename T, typename U>
|
||||
bool operator==(const SecureAllocator<T>&, const SecureAllocator<U>&) {
|
||||
return true;
|
||||
}
|
||||
|
||||
template <typename T, typename U>
|
||||
bool operator!=(const SecureAllocator<T>&, const SecureAllocator<U>&) {
|
||||
return false;
|
||||
}
|
||||
|
||||
} // namespace Json
|
||||
|
||||
#pragma pack(pop)
|
||||
|
||||
#endif // JSON_ALLOCATOR_H_INCLUDED
|
||||
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
// End of content of file: include/json/allocator.h
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
// Beginning of content of file: include/json/config.h
|
||||
// //////////////////////////////////////////////////////////////////////
|
||||
@@ -235,14 +90,19 @@ bool operator!=(const SecureAllocator<T>&, const SecureAllocator<U>&) {
|
||||
|
||||
#ifndef JSON_CONFIG_H_INCLUDED
|
||||
#define JSON_CONFIG_H_INCLUDED
|
||||
#include <cstddef>
|
||||
#include <cstdint>
|
||||
#include <istream>
|
||||
#include <memory>
|
||||
#include <ostream>
|
||||
#include <sstream>
|
||||
#include <string>
|
||||
#include <type_traits>
|
||||
#include <stddef.h>
|
||||
#include <string> //typedef String
|
||||
#include <stdint.h> //typedef int64_t, uint64_t
|
||||
|
||||
/// If defined, indicates that json library is embedded in CppTL library.
|
||||
//# define JSON_IN_CPPTL 1
|
||||
|
||||
/// If defined, indicates that json may leverage CppTL library
|
||||
//# define JSON_USE_CPPTL 1
|
||||
/// If defined, indicates that cpptl vector based map should be used instead of
|
||||
/// std::map
|
||||
/// as Value container.
|
||||
//# define JSON_USE_CPPTL_SMALLMAP 1
|
||||
|
||||
// If non-zero, the library uses exceptions to report bad input instead of C
|
||||
// assertion macros. The default is to use exceptions.
|
||||
@@ -250,132 +110,164 @@ bool operator!=(const SecureAllocator<T>&, const SecureAllocator<U>&) {
|
||||
#define JSON_USE_EXCEPTION 1
|
||||
#endif
|
||||
|
||||
// Temporary, tracked for removal with issue #982.
|
||||
#ifndef JSON_USE_NULLREF
|
||||
#define JSON_USE_NULLREF 1
|
||||
#endif
|
||||
|
||||
/// If defined, indicates that the source file is amalgamated
|
||||
/// to prevent private header inclusion.
|
||||
/// Remarks: it is automatically defined in the generated amalgamated header.
|
||||
// #define JSON_IS_AMALGAMATION
|
||||
|
||||
// Export macros for DLL visibility
|
||||
#if defined(JSON_DLL_BUILD)
|
||||
#ifdef JSON_IN_CPPTL
|
||||
#include <cpptl/config.h>
|
||||
#ifndef JSON_USE_CPPTL
|
||||
#define JSON_USE_CPPTL 1
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#ifdef JSON_IN_CPPTL
|
||||
#define JSON_API CPPTL_API
|
||||
#elif defined(JSON_DLL_BUILD)
|
||||
#if defined(_MSC_VER) || defined(__MINGW32__)
|
||||
#define JSON_API __declspec(dllexport)
|
||||
#define JSONCPP_DISABLE_DLL_INTERFACE_WARNING
|
||||
#elif defined(__GNUC__) || defined(__clang__)
|
||||
#define JSON_API __attribute__((visibility("default")))
|
||||
#endif // if defined(_MSC_VER)
|
||||
|
||||
#elif defined(JSON_DLL)
|
||||
#if defined(_MSC_VER) || defined(__MINGW32__)
|
||||
#define JSON_API __declspec(dllimport)
|
||||
#define JSONCPP_DISABLE_DLL_INTERFACE_WARNING
|
||||
#endif // if defined(_MSC_VER)
|
||||
#endif // ifdef JSON_DLL_BUILD
|
||||
|
||||
#endif // ifdef JSON_IN_CPPTL
|
||||
#if !defined(JSON_API)
|
||||
#define JSON_API
|
||||
#endif
|
||||
|
||||
#if defined(_MSC_VER) && _MSC_VER < 1800
|
||||
#error \
|
||||
"ERROR: Visual Studio 12 (2013) with _MSC_VER=1800 is the oldest supported compiler with sufficient C++11 capabilities"
|
||||
#endif
|
||||
|
||||
#if defined(_MSC_VER) && _MSC_VER < 1900
|
||||
// As recommended at
|
||||
// https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010
|
||||
extern JSON_API int msvc_pre1900_c99_snprintf(char* outBuf, size_t size,
|
||||
const char* format, ...);
|
||||
#define jsoncpp_snprintf msvc_pre1900_c99_snprintf
|
||||
#else
|
||||
#define jsoncpp_snprintf std::snprintf
|
||||
#endif
|
||||
|
||||
// If JSON_NO_INT64 is defined, then Json only support C++ "int" type for
|
||||
// integer
|
||||
// Storages, and 64 bits integer support is disabled.
|
||||
// #define JSON_NO_INT64 1
|
||||
|
||||
// JSONCPP_OVERRIDE is maintained for backwards compatibility of external tools.
|
||||
// C++11 should be used directly in JSONCPP.
|
||||
#define JSONCPP_OVERRIDE override
|
||||
#if defined(_MSC_VER) // MSVC
|
||||
# if _MSC_VER <= 1200 // MSVC 6
|
||||
// Microsoft Visual Studio 6 only support conversion from __int64 to double
|
||||
// (no conversion from unsigned __int64).
|
||||
# define JSON_USE_INT64_DOUBLE_CONVERSION 1
|
||||
// Disable warning 4786 for VS6 caused by STL (identifier was truncated to '255'
|
||||
// characters in the debug information)
|
||||
// All projects I've ever seen with VS6 were using this globally (not bothering
|
||||
// with pragma push/pop).
|
||||
# pragma warning(disable : 4786)
|
||||
# endif // MSVC 6
|
||||
|
||||
# if _MSC_VER >= 1500 // MSVC 2008
|
||||
/// Indicates that the following function is deprecated.
|
||||
# define JSONCPP_DEPRECATED(message) __declspec(deprecated(message))
|
||||
# endif
|
||||
|
||||
#endif // defined(_MSC_VER)
|
||||
|
||||
// In c++11 the override keyword allows you to explicitly define that a function
|
||||
// is intended to override the base-class version. This makes the code more
|
||||
// managable and fixes a set of common hard-to-find bugs.
|
||||
#if __cplusplus >= 201103L
|
||||
# define JSONCPP_OVERRIDE override
|
||||
# define JSONCPP_NOEXCEPT noexcept
|
||||
#elif defined(_MSC_VER) && _MSC_VER > 1600 && _MSC_VER < 1900
|
||||
# define JSONCPP_OVERRIDE override
|
||||
# define JSONCPP_NOEXCEPT throw()
|
||||
#elif defined(_MSC_VER) && _MSC_VER >= 1900
|
||||
# define JSONCPP_OVERRIDE override
|
||||
# define JSONCPP_NOEXCEPT noexcept
|
||||
#else
|
||||
# define JSONCPP_OVERRIDE
|
||||
# define JSONCPP_NOEXCEPT throw()
|
||||
#endif
|
||||
|
||||
#ifndef JSON_HAS_RVALUE_REFERENCES
|
||||
|
||||
#if defined(_MSC_VER) && _MSC_VER >= 1600 // MSVC >= 2010
|
||||
#define JSON_HAS_RVALUE_REFERENCES 1
|
||||
#endif // MSVC >= 2010
|
||||
|
||||
#ifdef __clang__
|
||||
#if __has_extension(attribute_deprecated_with_message)
|
||||
#define JSONCPP_DEPRECATED(message) __attribute__((deprecated(message)))
|
||||
#if __has_feature(cxx_rvalue_references)
|
||||
#define JSON_HAS_RVALUE_REFERENCES 1
|
||||
#endif // has_feature
|
||||
|
||||
#elif defined __GNUC__ // not clang (gcc comes later since clang emulates gcc)
|
||||
#if defined(__GXX_EXPERIMENTAL_CXX0X__) || (__cplusplus >= 201103L)
|
||||
#define JSON_HAS_RVALUE_REFERENCES 1
|
||||
#endif // GXX_EXPERIMENTAL
|
||||
|
||||
#endif // __clang__ || __GNUC__
|
||||
|
||||
#endif // not defined JSON_HAS_RVALUE_REFERENCES
|
||||
|
||||
#ifndef JSON_HAS_RVALUE_REFERENCES
|
||||
#define JSON_HAS_RVALUE_REFERENCES 0
|
||||
#endif
|
||||
#elif defined(__GNUC__) // not clang (gcc comes later since clang emulates gcc)
|
||||
#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5))
|
||||
#define JSONCPP_DEPRECATED(message) __attribute__((deprecated(message)))
|
||||
#elif (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
|
||||
#define JSONCPP_DEPRECATED(message) __attribute__((__deprecated__))
|
||||
#endif // GNUC version
|
||||
#elif defined(_MSC_VER) // MSVC (after clang because clang on Windows emulates
|
||||
// MSVC)
|
||||
#define JSONCPP_DEPRECATED(message) __declspec(deprecated(message))
|
||||
#endif // __clang__ || __GNUC__ || _MSC_VER
|
||||
|
||||
#ifdef __clang__
|
||||
# if __has_extension(attribute_deprecated_with_message)
|
||||
# define JSONCPP_DEPRECATED(message) __attribute__ ((deprecated(message)))
|
||||
# endif
|
||||
#elif defined __GNUC__ // not clang (gcc comes later since clang emulates gcc)
|
||||
# if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5))
|
||||
# define JSONCPP_DEPRECATED(message) __attribute__ ((deprecated(message)))
|
||||
# elif (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
|
||||
# define JSONCPP_DEPRECATED(message) __attribute__((__deprecated__))
|
||||
# endif // GNUC version
|
||||
#endif // __clang__ || __GNUC__
|
||||
|
||||
#if !defined(JSONCPP_DEPRECATED)
|
||||
#define JSONCPP_DEPRECATED(message)
|
||||
#endif // if !defined(JSONCPP_DEPRECATED)
|
||||
|
||||
#if defined(__clang__) || (defined(__GNUC__) && (__GNUC__ >= 6))
|
||||
#define JSON_USE_INT64_DOUBLE_CONVERSION 1
|
||||
#if __GNUC__ >= 6
|
||||
# define JSON_USE_INT64_DOUBLE_CONVERSION 1
|
||||
#endif
|
||||
|
||||
#if !defined(JSON_IS_AMALGAMATION)
|
||||
|
||||
#include "allocator.h"
|
||||
#include "version.h"
|
||||
# include "version.h"
|
||||
|
||||
# if JSONCPP_USING_SECURE_MEMORY
|
||||
# include "allocator.h" //typedef Allocator
|
||||
# endif
|
||||
|
||||
#endif // if !defined(JSON_IS_AMALGAMATION)
|
||||
|
||||
namespace Json {
|
||||
using Int = int;
|
||||
using UInt = unsigned int;
|
||||
typedef int Int;
|
||||
typedef unsigned int UInt;
|
||||
#if defined(JSON_NO_INT64)
|
||||
using LargestInt = int;
|
||||
using LargestUInt = unsigned int;
|
||||
typedef int LargestInt;
|
||||
typedef unsigned int LargestUInt;
|
||||
#undef JSON_HAS_INT64
|
||||
#else // if defined(JSON_NO_INT64)
|
||||
// For Microsoft Visual use specific types as long long is not supported
|
||||
#if defined(_MSC_VER) // Microsoft Visual Studio
|
||||
using Int64 = __int64;
|
||||
using UInt64 = unsigned __int64;
|
||||
typedef __int64 Int64;
|
||||
typedef unsigned __int64 UInt64;
|
||||
#else // if defined(_MSC_VER) // Other platforms, use long long
|
||||
using Int64 = int64_t;
|
||||
using UInt64 = uint64_t;
|
||||
#endif // if defined(_MSC_VER)
|
||||
using LargestInt = Int64;
|
||||
using LargestUInt = UInt64;
|
||||
typedef int64_t Int64;
|
||||
typedef uint64_t UInt64;
|
||||
#endif // if defined(_MSC_VER)
|
||||
typedef Int64 LargestInt;
|
||||
typedef UInt64 LargestUInt;
|
||||
#define JSON_HAS_INT64
|
||||
#endif // if defined(JSON_NO_INT64)
|
||||
|
||||
template <typename T>
|
||||
using Allocator =
|
||||
typename std::conditional<JSONCPP_USING_SECURE_MEMORY, SecureAllocator<T>,
|
||||
std::allocator<T>>::type;
|
||||
using String = std::basic_string<char, std::char_traits<char>, Allocator<char>>;
|
||||
using IStringStream =
|
||||
std::basic_istringstream<String::value_type, String::traits_type,
|
||||
String::allocator_type>;
|
||||
using OStringStream =
|
||||
std::basic_ostringstream<String::value_type, String::traits_type,
|
||||
String::allocator_type>;
|
||||
using IStream = std::istream;
|
||||
using OStream = std::ostream;
|
||||
} // namespace Json
|
||||
|
||||
// Legacy names (formerly macros).
|
||||
using JSONCPP_STRING = Json::String;
|
||||
using JSONCPP_ISTRINGSTREAM = Json::IStringStream;
|
||||
using JSONCPP_OSTRINGSTREAM = Json::OStringStream;
|
||||
using JSONCPP_ISTREAM = Json::IStream;
|
||||
using JSONCPP_OSTREAM = Json::OStream;
|
||||
#if JSONCPP_USING_SECURE_MEMORY
|
||||
#define JSONCPP_STRING std::basic_string<char, std::char_traits<char>, Json::SecureAllocator<char> >
|
||||
#define JSONCPP_OSTRINGSTREAM std::basic_ostringstream<char, std::char_traits<char>, Json::SecureAllocator<char> >
|
||||
#define JSONCPP_OSTREAM std::basic_ostream<char, std::char_traits<char>>
|
||||
#define JSONCPP_ISTRINGSTREAM std::basic_istringstream<char, std::char_traits<char>, Json::SecureAllocator<char> >
|
||||
#define JSONCPP_ISTREAM std::istream
|
||||
#else
|
||||
#define JSONCPP_STRING std::string
|
||||
#define JSONCPP_OSTRINGSTREAM std::ostringstream
|
||||
#define JSONCPP_OSTREAM std::ostream
|
||||
#define JSONCPP_ISTRINGSTREAM std::istringstream
|
||||
#define JSONCPP_ISTREAM std::istream
|
||||
#endif // if JSONCPP_USING_SECURE_MEMORY
|
||||
} // end namespace Json
|
||||
|
||||
#endif // JSON_CONFIG_H_INCLUDED
|
||||
|
||||
@@ -407,23 +299,17 @@ using JSONCPP_OSTREAM = Json::OStream;
|
||||
namespace Json {
|
||||
|
||||
// writer.h
|
||||
class StreamWriter;
|
||||
class StreamWriterBuilder;
|
||||
class Writer;
|
||||
class FastWriter;
|
||||
class StyledWriter;
|
||||
class StyledStreamWriter;
|
||||
|
||||
// reader.h
|
||||
class Reader;
|
||||
class CharReader;
|
||||
class CharReaderBuilder;
|
||||
|
||||
// json_features.h
|
||||
// features.h
|
||||
class Features;
|
||||
|
||||
// value.h
|
||||
using ArrayIndex = unsigned int;
|
||||
typedef unsigned int ArrayIndex;
|
||||
class StaticString;
|
||||
class Path;
|
||||
class PathArgument;
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
BIN
dep/llvm/clang-format.exe
Normal file
BIN
dep/llvm/clang-format.exe
Normal file
Binary file not shown.
2
dep/wil
2
dep/wil
Submodule dep/wil updated: 3c00e7f1d8...e8c599bca6
19
doc/Niksa.md
19
doc/Niksa.md
@@ -9,8 +9,6 @@ This document serves as a storage point for those posts.
|
||||
- [Output Processing between "Far East" and "Western"](#fesb)
|
||||
- [Why do we not backport things?](#backport)
|
||||
- [Why can't we have mixed elevated and non-elevated tabs in the Terminal?](#elevation)
|
||||
- [What's the difference between a shell and a terminal?](#shell-vs-terminal)
|
||||
|
||||
|
||||
## <a name="cmd"></a>Why do we avoid changing CMD.exe?
|
||||
`setlocal` doesn't behave the same way as an environment variable. It's a thing that would have to be put in at the top of the batch script that is `somefile.cmd` as one of its first commands to adjust the way that one specific batch file is processed by the `cmd.exe` engine. That's probably not suitable for your needs, but that's the way we have to go.
|
||||
@@ -181,20 +179,3 @@ Other platforms have accepted that risk in preference for user convenience. They
|
||||
|
||||
Original Source: https://github.com/microsoft/terminal/issues/632#issuecomment-519375707
|
||||
|
||||
## <a name="shell-vs-terminal"></a>What's the difference between a shell and a terminal?
|
||||
|
||||
_guest speaker @zadjii-msft_
|
||||
|
||||
I think there might be a bit of a misunderstanding here - there are two different kinds of applications we're talking about here:
|
||||
* shell applications, like `cmd.exe`, `powershell`, `zsh`, etc. These are text-only applications that emit streams of characters. They don't care at all about how they're eventually rendered to the user. These are also sometimes referred to as "commandline client" applications.
|
||||
* terminal applications, like the Windows Terminal, gnome-terminal, xterm, iterm2, hyper. These are graphical applications that can be used to render the output of commandline clients.
|
||||
|
||||
On Windows, if you just run `cmd.exe` directly, the OS will create an instance of `conhost.exe` as the _terminal_ for `cmd.exe`. The same thing happens for `powershell.exe`, the system will creates a new conhost window for any client that's not already connected to a terminal of some sort. This has lead to an enormous amount of confusion for people thinking that a conhost window is actually a "`cmd` window". `cmd` can't have a window, it's just a commandline application. Its window is always some other terminal.
|
||||
|
||||
Any terminal can run any commandline client application. So you can use the Windows Terminal to run whatever shell you want. I use mine for both `cmd` and `powershell`, and also WSL:
|
||||
|
||||
|
||||
|
||||
It's not the Terminal's responsibility to remember the commands executed by a commandline client. That's the responsibility of the _shell_. How would the terminal remember commands executed by something like `emacs` or `vim`? Those are both applications where the user is typing input and hitting enter, like they would at a cmd prompt, but without something that resembles a command history.
|
||||
|
||||
Original Source: https://github.com/microsoft/terminal/issues/6500#issuecomment-670035468
|
||||
|
||||
38
doc/TAEF.md
38
doc/TAEF.md
@@ -1,30 +1,9 @@
|
||||
### TAEF Overview ###
|
||||
|
||||
### TAEF ###
|
||||
TAEF, the Test Authoring and Execution Framework, is used extensively within the Windows organization to test the operating system code in a unified manner for system, driver, and application code. As the console is a Windows OS Component, we strive to continue using the same system such that tests can be ran in a unified manner both externally to Microsoft as well as inside the official OS Build/Test system.
|
||||
|
||||
The [official documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/) for TAEF describes the basic architecture, usage, and functionality of the test system. It is similar to Visual Studio test, but a bit more comprehensive and flexible.
|
||||
The [official documentation](https://msdn.microsoft.com/en-us/library/windows/hardware/hh439725\(v=vs.85\).aspx) for TAEF describes the basic architecture, usage, and functionality of the test system. It is similar to Visual Studio test, but a bit more comprehensive and flexible.
|
||||
|
||||
### Writing Tests
|
||||
|
||||
You may want to read the section [Authoring Tests in C++](https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/authoring-tests-in-c--) before getting your hands dirty. Note that the quoted header name in `#include "WexTestClass.h"` might be a bit confusing. You are not required to copy TAEF headers into the project folder.
|
||||
|
||||
Use the [TAEF Verify Macros for C++](https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/verify) in your test code to perform verifications.
|
||||
|
||||
### Running Tests
|
||||
|
||||
If you have Visual Studio and related C++ components installed, and you have successfully restored NuGets, you should have the TAEF test runner `te.exe` available locally as part of the `Taef.Redist.Wlk` package.
|
||||
|
||||
> Note that you cannot easily run TAEF tests directly through Visual Studio. The `Taef.Redist.Wlk` NuGet package comes with an adapter that will let you browse and execute TAEF tests inside of Visual Studio, but its performance and reliability prevent us from recommending it here.
|
||||
|
||||
In a "normal" CMD environment, `te.exe` may not be directly available. Try the following command to set up the development enviroment first:
|
||||
|
||||
```shell
|
||||
.\tools\razzle.cmd
|
||||
```
|
||||
|
||||
Then you should be able to use `%TAEF%` as an alias of the actual `te.exe`.
|
||||
|
||||
For the purposes of the OpenConsole project, you can run the tests using the `te.exe` that matches the architecture for which the test was built (x86/x64):
|
||||
For the purposes of the console project, you can run the tests using the *TE.exe* that matches the architecture for which the test was build (x86/x64) in the pattern
|
||||
|
||||
te.exe Console.Unit.Tests.dll
|
||||
|
||||
@@ -36,15 +15,6 @@ Limiting the tests to be run is also useful with:
|
||||
|
||||
Any pattern of class/method names can be specified after the */name:* flag with wildcard patterns.
|
||||
|
||||
For any further details on the functionality of the TAEF test runner, please see the [Executing Tests](https://docs.microsoft.com/en-us/windows-hardware/drivers/taef/executing-tests) section in the official documentation. Or run the embedded help with
|
||||
For any further details on the functionality of the TAEF test runner, *TE.exe*, please see the documentation above or run the embedded help with
|
||||
|
||||
te.exe /!
|
||||
|
||||
If you use PowerShell, try the following command:
|
||||
|
||||
```powershell
|
||||
Import-Module .\tools\OpenConsole.psm1
|
||||
Invoke-OpenConsoleTests
|
||||
```
|
||||
|
||||
`Invoke-OpenConsoleTests` supports a number of options, which you can enumerate by running `Invoke-OpenConsoleTests -?`.
|
||||
|
||||
@@ -67,12 +67,12 @@ To update the version of a given package, use the following snippet
|
||||
|
||||
where:
|
||||
- `$PackageName` is the name of the package, e.g. Microsoft.UI.Xaml
|
||||
- `$OldVersionNumber` is the version number currently used, e.g. 2.4.0-prerelease.200506002
|
||||
- `$NewVersionNumber` is the version number you want to migrate to, e.g. 2.5.0-prerelease.200812002
|
||||
- `$OldVersionNumber` is the version number currently used, e.g. 2.3.191217003-prerelease
|
||||
- `$NewVersionNumber` is the version number you want to migrate to, e.g. 2.4.200117003-prerelease
|
||||
|
||||
Example usage:
|
||||
|
||||
`git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.4.0-prerelease.200506002/2.5.0-prerelease.200812002/g'`
|
||||
`git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.3.191217003-prerelease/2.4.200117003-prerelease/g'`
|
||||
|
||||
## Using .nupkg files instead of downloaded Nuget packages
|
||||
If you want to use .nupkg files instead of the downloaded Nuget package, you can do this with the following steps:
|
||||
|
||||
@@ -1,258 +0,0 @@
|
||||
# New Json Utility API
|
||||
|
||||
## Raw value conversion (GetValue)
|
||||
|
||||
`GetValue` is a convenience helper that will either read a value into existing storage (type-deduced) or
|
||||
return a JSON value coerced into the specified type.
|
||||
|
||||
When reading into existing storage, it returns a boolean indicating whether that storage was modified.
|
||||
|
||||
If the JSON value cannot be converted to the specified type, an exception will be generated.
|
||||
For non-nullable type conversions (most POD types), `null` is considered to be an invalid type.
|
||||
|
||||
```c++
|
||||
std::string one;
|
||||
std::optional<std::string> two;
|
||||
|
||||
JsonUtils::GetValue(json, one);
|
||||
// one is populated or an exception is thrown.
|
||||
|
||||
JsonUtils::GetValue(json, two);
|
||||
// two is populated, nullopt or an exception is thrown
|
||||
|
||||
auto three = JsonUtils::GetValue<std::string>(json);
|
||||
// three is populated or an exception is thrown
|
||||
|
||||
auto four = JsonUtils::GetValue<std::optional<std::string>>(json);
|
||||
// four is populated or nullopt
|
||||
```
|
||||
|
||||
## Key lookup (GetValueForKey)
|
||||
|
||||
`GetValueForKey` follows the same rules as `GetValue`, but takes an additional key.
|
||||
It is assumed that the JSON value passed to GetValueForKey is of `object` type.
|
||||
|
||||
```c++
|
||||
std::string one;
|
||||
std::optional<std::string> two;
|
||||
|
||||
JsonUtils::GetValueForKey(json, "firstKey", one);
|
||||
// one is populated or unchanged.
|
||||
|
||||
JsonUtils::GetValueForKey(json, "secondKey", two);
|
||||
// two is populated, nullopt or unchanged
|
||||
|
||||
auto three = JsonUtils::GetValueForKey<std::string>(json, "thirdKey");
|
||||
// three is populated or zero-initialized
|
||||
|
||||
auto four = JsonUtils::GetValueForKey<std::optional<std::string>>(json, "fourthKey");
|
||||
// four is populated or nullopt
|
||||
```
|
||||
|
||||
## Rationale: Value-Returning Getters
|
||||
|
||||
JsonUtils provides two types of `GetValue...`: value-returning and reference-filling.
|
||||
|
||||
The reference-filling fixtures use type deduction so that a developer does not
|
||||
need to specify template parameters on every `GetValue` call. It excels at
|
||||
populating class members during deserialization.
|
||||
|
||||
The value-returning fixtures, on the other hand, are very useful for partial
|
||||
deserialization and key detection when you do not need to deserialize an entire
|
||||
instance of a class or you need to reason about the presence of members.
|
||||
|
||||
To provide a concrete example of the latter, consider:
|
||||
|
||||
```c++
|
||||
if (const auto guid{ GetValueForKey<std::optional<GUID>>(json, "guid") })
|
||||
// This condition is only true if there was a "guid" member in the provided JSON object.
|
||||
// It can be accessed through *guid.
|
||||
}
|
||||
```
|
||||
|
||||
If you are... | Use
|
||||
--------------|-----
|
||||
Deserializing | `GetValue(..., storage)`
|
||||
Interrogating | `storage = GetValue<T>(...)`
|
||||
|
||||
## Converting User-Defined Types
|
||||
|
||||
All conversions are done using specializations of
|
||||
`JsonUtils::ConversionTrait<T>`. To implement a converter for a user-defined
|
||||
type, you must implement a specialization of `JsonUtils::ConversionTrait<T>`.
|
||||
|
||||
Every specialization over `T` must implement `static T FromJson(const Json::Value&)`
|
||||
and `static bool CanConvert(const Json::Value&)`.
|
||||
|
||||
```c++
|
||||
struct MyCustomType { int val; };
|
||||
|
||||
template<>
|
||||
struct ConversionTrait<MyCustomType>
|
||||
{
|
||||
// This trait converts a string of the format "[0-9]" to a value of type MyCustomType.
|
||||
|
||||
static MyCustomType FromJson(const Json::Value& json)
|
||||
{
|
||||
return MyCustomType{ json.asString()[0] - '0' };
|
||||
}
|
||||
|
||||
static bool CanConvert(const Json::Value& json)
|
||||
{
|
||||
return json.isString();
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### Converting User-Defined Enumerations
|
||||
|
||||
Enumeration types represent a single choice out of multiple options.
|
||||
|
||||
In a JSON data model, they are typically represented as strings.
|
||||
|
||||
For parsing enumerations, JsonUtils provides the `JSON_ENUM_MAPPER` macro. It
|
||||
can be used to establish a converter that will take a set of known strings and
|
||||
convert them to values.
|
||||
|
||||
```c++
|
||||
JSON_ENUM_MAPPER(CursorStyle)
|
||||
{
|
||||
// pair_type is provided by ENUM_MAPPER.
|
||||
JSON_MAPPINGS(5) = {
|
||||
pair_type{ "bar", CursorStyle::Bar },
|
||||
pair_type{ "vintage", CursorStyle::Vintage },
|
||||
pair_type{ "underscore", CursorStyle::Underscore },
|
||||
pair_type{ "filledBox", CursorStyle::FilledBox },
|
||||
pair_type{ "emptyBox", CursorStyle::EmptyBox }
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
If the enum mapper fails to convert the provided string, it will throw an
|
||||
exception.
|
||||
|
||||
### Converting User-Defined Flag Sets
|
||||
|
||||
Flags represent a multiple-choice selection. They are typically implemented as
|
||||
enums with bitfield values intended to be ORed together.
|
||||
|
||||
In JSON, a set of flags may be represented by a single string (`"flagName"`) or
|
||||
an array of strings (`["flagOne", "flagTwo"]`).
|
||||
|
||||
JsonUtils provides a `JSON_FLAG_MAPPER` macro that can be used to produce a
|
||||
specialization for a set of flags.
|
||||
|
||||
Given the following flag enum,
|
||||
|
||||
```c++
|
||||
enum class JsonTestFlags : int
|
||||
{
|
||||
FlagOne = 1 << 0,
|
||||
FlagTwo = 1 << 1
|
||||
};
|
||||
```
|
||||
|
||||
You can register a flag mapper with the `JSON_FLAG_MAPPER` macro as follows:
|
||||
|
||||
```c++
|
||||
JSON_FLAG_MAPPER(JsonTestFlags)
|
||||
{
|
||||
JSON_MAPPINGS(2) = {
|
||||
pair_type{ "flagOne", JsonTestFlags::FlagOne },
|
||||
pair_type{ "flagTwo", JsonTestFlags::FlagTwo },
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
The `FLAG_MAPPER` also provides two convenience definitions, `AllSet` and
|
||||
`AllClear`, that can be used to represent "all choices" and "no choices"
|
||||
respectively.
|
||||
|
||||
```c++
|
||||
JSON_FLAG_MAPPER(JsonTestFlags)
|
||||
{
|
||||
JSON_MAPPINGS(4) = {
|
||||
pair_type{ "never", AllClear },
|
||||
pair_type{ "flagOne", JsonTestFlags::FlagOne },
|
||||
pair_type{ "flagTwo", JsonTestFlags::FlagTwo },
|
||||
pair_type{ "always", AllSet },
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
Because flag values are additive, `["always", "flagOne"]` will result in the
|
||||
same behavior as `"always"`.
|
||||
|
||||
If the flag mapper encounters an unknown flag, it will throw an exception.
|
||||
|
||||
If the flag mapper encounters a logical discontinuity such as `["never", "flagOne"]`
|
||||
(as in the above example), it will throw an exception.
|
||||
|
||||
### Advanced Use
|
||||
|
||||
`GetValue` and `GetValueForKey` can be passed, as their final arguments, any
|
||||
value whose type implements the same interface as `ConversionTrait<T>`--that
|
||||
is, `FromJson(const Json::Value&)` and `CanConvert(const Json::Value&)`.
|
||||
|
||||
This allows for one-off conversions without a specialization of
|
||||
`ConversionTrait` or even stateful converters.
|
||||
|
||||
#### Stateful Converter Sample
|
||||
|
||||
```c++
|
||||
struct MultiplyingConverter {
|
||||
int BaseValue;
|
||||
|
||||
bool CanConvert(const Json::Value&) { return true; }
|
||||
|
||||
int FromJson(const Json::Value& value)
|
||||
{
|
||||
return value.asInt() * BaseValue;
|
||||
}
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
Json::Value json{ 66 }; // A JSON value containing the number 66
|
||||
MultiplyingConverter conv{ 10 };
|
||||
|
||||
auto v = JsonUtils::GetValue<int>(json, conv);
|
||||
// v is equal to 660.
|
||||
```
|
||||
|
||||
## Behavior Chart
|
||||
|
||||
### GetValue(T&) (type-deducing)
|
||||
|
||||
-|json type invalid|json null|valid
|
||||
-|-|-|-
|
||||
`T`|❌ exception|❌ exception|✔ converted
|
||||
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
|
||||
|
||||
### GetValue<T>() (returning)
|
||||
|
||||
-|json type invalid|json null|valid
|
||||
-|-|-|-
|
||||
`T`|❌ exception|❌ exception|✔ converted
|
||||
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
|
||||
|
||||
### GetValueForKey(T&) (type-deducing)
|
||||
|
||||
GetValueForKey builds on the behavior set from GetValue by adding
|
||||
a "key not found" state. The remaining three cases are the same.
|
||||
|
||||
val type|key not found|_json type invalid_|_json null_|_valid_
|
||||
-|-|-|-|-
|
||||
`T`|🔵 unchanged|_❌ exception_|_❌ exception_|_✔ converted_
|
||||
`std::optional<T>`|🔵 unchanged|_❌ exception_|_🟨 `nullopt`_|_✔ converted_
|
||||
|
||||
### GetValueForKey<T>() (return value)
|
||||
|
||||
val type|key not found|_json type invalid_|_json null_|_valid_
|
||||
-|-|-|-|-
|
||||
`T`|🟨 `T{}` (zero value)|_❌ exception_|_❌ exception_|_✔ converted_
|
||||
`std::optional<T>`|🟨 `nullopt`|_❌ exception_|_🟨 `nullopt`_|_✔ converted_
|
||||
|
||||
### Future Direction
|
||||
|
||||
These converters lend themselves very well to automatic _serialization_.
|
||||
@@ -1 +1,199 @@
|
||||
⚠ This document has moved to [the Customize Settings section of the Windows Terminal documentation](https://docs.microsoft.com/windows/terminal/customize-settings/global-settings).
|
||||
# Settings.json Documentation
|
||||
|
||||
## Globals
|
||||
Properties listed below affect the entire window, regardless of the profile settings.
|
||||
|
||||
| Property | Necessity | Type | Default | Description |
|
||||
| -------- | --------- | ---- | ------- | ----------- |
|
||||
| `alwaysShowTabs` | _Required_ | Boolean | `true` | When set to `true`, tabs are always displayed. When set to `false` and `showTabsInTitlebar` is set to `false`, tabs only appear after typing <kbd>Ctrl</kbd> + <kbd>T</kbd>. |
|
||||
| `copyOnSelect` | Optional | Boolean | `false` | When set to `true`, a selection is immediately copied to your clipboard upon creation. When set to `false`, the selection persists and awaits further action. |
|
||||
| `copyFormatting` | Optional | Boolean | `false` | When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. |
|
||||
| `defaultProfile` | _Required_ | String | PowerShell guid | Sets the default profile. Opens by typing <kbd>Ctrl</kbd> + <kbd>T</kbd> or by clicking the '+' icon. The guid of the desired default profile is used as the value. |
|
||||
| `initialCols` | _Required_ | Integer | `120` | The number of columns displayed in the window upon first load. |
|
||||
| `initialPosition` | Optional | String | `","` | The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If `launchMode` is set to `"maximized"`, the window will be maximized on the monitor specified by those coordinates. |
|
||||
| `initialRows` | _Required_ | Integer | `30` | The number of rows displayed in the window upon first load. |
|
||||
| `launchMode` | Optional | String | `default` | Defines whether the Terminal will launch as maximized or not. Possible values: `"default"`, `"maximized"` |
|
||||
| `rowsToScroll` | Optional | Integer | `system` | The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or "system". |
|
||||
| `theme` | _Required_ | String | `system` | Sets the theme of the application. Possible values: `"light"`, `"dark"`, `"system"` |
|
||||
| `showTerminalTitleInTitlebar` | _Required_ | Boolean | `true` | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
|
||||
| `showTabsInTitlebar` | Optional | Boolean | `true` | When set to `true`, the tabs are moved into the titlebar and the titlebar disappears. When set to `false`, the titlebar sits above the tabs. |
|
||||
| `snapToGridOnResize` | Optional | Boolean | `false` | When set to `true`, the window will snap to the nearest character boundary on resize. When `false`, the window will resize "smoothly" |
|
||||
| `tabWidthMode` | Optional | String | `equal` | Sets the width of the tabs. Possible values: `"equal"`, `"titleLength"` |
|
||||
| `wordDelimiters` | Optional | String | <code> /\()"'-:,.;<>~!@#$%^&*|+=[]{}~?│</code><br>_(`│` is `U+2502 BOX DRAWINGS LIGHT VERTICAL`)_ | Determines the delimiters used in a double click selection. |
|
||||
| `confirmCloseAllTabs` | Optional | Boolean | `true` | When set to `true` closing a window with multiple tabs open WILL require confirmation. When set to `false` closing a window with multiple tabs open WILL NOT require confirmation. |
|
||||
| `disabledProfileSources` | Optional | Array[String] | `[]` | Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup. This array can contain any combination of `Windows.Terminal.Wsl`, `Windows.Terminal.Azure`, or `Windows.Terminal.PowershellCore`. For more information, see [UsingJsonSettings.md](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#dynamic-profiles) |
|
||||
| `experimental.rendering.forceFullRepaint` | Optional | Boolean | `false` | When set to true, we will redraw the entire screen each frame. When set to false, we will render only the updates to the screen between frames. |
|
||||
| `experimental.rendering.software` | Optional | Boolean | `false` | When set to true, we will use the software renderer (a.k.a. WARP) instead of the hardware one. |
|
||||
|
||||
## Profiles
|
||||
Properties listed below are specific to each unique profile.
|
||||
|
||||
| Property | Necessity | Type | Default | Description |
|
||||
| -------- | --------- | ---- | ------- | ----------- |
|
||||
| `guid` | _Required_ | String | | Unique identifier of the profile. Written in registry format: `"{00000000-0000-0000-0000-000000000000}"`. |
|
||||
| `name` | _Required_ | String | | Name of the profile. Displays in the dropdown menu. <br>Additionally, this value will be used as the "title" to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application. This "title" behavior can be overridden by using `tabTitle`. |
|
||||
| `acrylicOpacity` | Optional | Number | `0.5` | When `useAcrylic` is set to `true`, it sets the transparency of the window for the profile. Accepts floating point values from 0-1. |
|
||||
| `antialiasingMode` | Optional | String | `"grayscale"` | Controls how text is antialiased in the renderer. Possible values are "grayscale", "cleartype" and "aliased". Note that changing this setting will require starting a new terminal instance. |
|
||||
| `background` | Optional | String | | Sets the background color of the profile. Overrides `background` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
|
||||
| `backgroundImage` | Optional | String | | Sets the file location of the Image to draw over the window background. |
|
||||
| `backgroundImageAlignment` | Optional | String | `center` | Sets how the background image aligns to the boundaries of the window. Possible values: `"center"`, `"left"`, `"top"`, `"right"`, `"bottom"`, `"topLeft"`, `"topRight"`, `"bottomLeft"`, `"bottomRight"` |
|
||||
| `backgroundImageOpacity` | Optional | Number | `1.0` | Sets the transparency of the background image. Accepts floating point values from 0-1. |
|
||||
| `backgroundImageStretchMode` | Optional | String | `uniformToFill` | Sets how the background image is resized to fill the window. Possible values: `"none"`, `"fill"`, `"uniform"`, `"uniformToFill"` |
|
||||
| `closeOnExit` | Optional | String | `graceful` | Sets how the profile reacts to termination or failure to launch. Possible values: `"graceful"` (close when `exit` is typed or the process exits normally), `"always"` (always close) and `"never"` (never close). `true` and `false` are accepted as synonyms for `"graceful"` and `"never"` respectively. |
|
||||
| `colorScheme` | Optional | String | `Campbell` | Name of the terminal color scheme to use. Color schemes are defined under `schemes`. |
|
||||
| `commandline` | Optional | String | | Executable used in the profile. |
|
||||
| `cursorColor` | Optional | String | | Sets the cursor color of the profile. Overrides `cursorColor` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
|
||||
| `cursorHeight` | Optional | Integer | | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
|
||||
| `cursorShape` | Optional | String | `bar` | Sets the cursor shape for the profile. Possible values: `"vintage"` ( ▃ ), `"bar"` ( ┃ ), `"underscore"` ( ▁ ), `"filledBox"` ( █ ), `"emptyBox"` ( ▯ ) |
|
||||
| `fontFace` | Optional | String | `Cascadia Mono` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
|
||||
| `fontSize` | Optional | Integer | `12` | Sets the font size. |
|
||||
| `fontWeight` | Optional | String | `normal` | Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values: `"thin"`, `"extra-light"`, `"light"`, `"semi-light"`, `"normal"`, `"medium"`, `"semi-bold"`, `"bold"`, `"extra-bold"`, `"black"`, `"extra-black"`, or the corresponding numeric representation of OpenType font weight. |
|
||||
| `foreground` | Optional | String | | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `#rgb` or `"#rrggbb"`. |
|
||||
| `hidden` | Optional | Boolean | `false` | If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamically generated profiles, while leaving them in your settings file. |
|
||||
| `historySize` | Optional | Integer | `9001` | The number of lines above the ones displayed in the window you can scroll back to. |
|
||||
| `icon` | Optional | String | | Image file location of the icon used in the profile. Displays within the tab and the dropdown menu. |
|
||||
| `padding` | Optional | String | `8, 8, 8, 8` | Sets the padding around the text within the window. Can have three different formats: `"#"` sets the same padding for all sides, `"#, #"` sets the same padding for left-right and top-bottom, and `"#, #, #, #"` sets the padding individually for left, top, right, and bottom. |
|
||||
| `scrollbarState` | Optional | String | `"visible"` | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
|
||||
| `selectionBackground` | Optional | String | | Sets the selection background color of the profile. Overrides `selectionBackground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
|
||||
| `snapOnInput` | Optional | Boolean | `true` | When set to `true`, the window will scroll to the command input line when typing. When set to `false`, the window will not scroll when you start typing. |
|
||||
| `source` | Optional | String | | Stores the name of the profile generator that originated this profile. _There are no discoverable values for this field._ |
|
||||
| `startingDirectory` | Optional | String | `%USERPROFILE%` | The directory the shell starts in when it is loaded. |
|
||||
| `suppressApplicationTitle` | Optional | Boolean | `false` | When set to `true`, `tabTitle` overrides the default title of the tab and any title change messages from the application will be suppressed. When set to `false`, `tabTitle` behaves as normal. |
|
||||
| `tabTitle` | Optional | String | | If set, will replace the `name` as the title to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application. |
|
||||
| `useAcrylic` | Optional | Boolean | `false` | When set to `true`, the window will have an acrylic background. When set to `false`, the window will have a plain, untextured background. The transparency only applies to focused windows due to OS limitation. |
|
||||
| `experimental.retroTerminalEffect` | Optional | Boolean | `false` | When set to `true`, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed. |
|
||||
|
||||
## Schemes
|
||||
Properties listed below are specific to each color scheme. [ColorTool](https://github.com/microsoft/terminal/tree/master/src/tools/ColorTool) is a great tool you can use to create and explore new color schemes. All colors use hex color format.
|
||||
|
||||
| Property | Necessity | Type | Description |
|
||||
| -------- | ---- | ----------- | ----------- |
|
||||
| `name` | _Required_ | String | Name of the color scheme. |
|
||||
| `foreground` | _Required_ | String | Sets the foreground color of the color scheme. |
|
||||
| `background` | _Required_ | String | Sets the background color of the color scheme. |
|
||||
| `selectionBackground` | Optional | String | Sets the selection background color of the color scheme. |
|
||||
| `cursorColor` | Optional | String | Sets the cursor color of the color scheme. |
|
||||
| `black` | _Required_ | String | Sets the color used as ANSI black. |
|
||||
| `blue` | _Required_ | String | Sets the color used as ANSI blue. |
|
||||
| `brightBlack` | _Required_ | String | Sets the color used as ANSI bright black. |
|
||||
| `brightBlue` | _Required_ | String | Sets the color used as ANSI bright blue. |
|
||||
| `brightCyan` | _Required_ | String | Sets the color used as ANSI bright cyan. |
|
||||
| `brightGreen` | _Required_ | String | Sets the color used as ANSI bright green. |
|
||||
| `brightPurple` | _Required_ | String | Sets the color used as ANSI bright purple. |
|
||||
| `brightRed` | _Required_ | String | Sets the color used as ANSI bright red. |
|
||||
| `brightWhite` | _Required_ | String | Sets the color used as ANSI bright white. |
|
||||
| `brightYellow` | _Required_ | String | Sets the color used as ANSI bright yellow. |
|
||||
| `cyan` | _Required_ | String | Sets the color used as ANSI cyan. |
|
||||
| `green` | _Required_ | String | Sets the color used as ANSI green. |
|
||||
| `purple` | _Required_ | String | Sets the color used as ANSI purple. |
|
||||
| `red` | _Required_ | String | Sets the color used as ANSI red. |
|
||||
| `white` | _Required_ | String | Sets the color used as ANSI white. |
|
||||
| `yellow` | _Required_ | String | Sets the color used as ANSI yellow. |
|
||||
|
||||
## Keybindings
|
||||
Properties listed below are specific to each custom key binding.
|
||||
|
||||
| Property | Necessity | Type | Description |
|
||||
| -------- | ---- | ----------- | ----------- |
|
||||
| `command` | _Required_ | String | The command executed when the associated key bindings are pressed. |
|
||||
| `keys` | _Required_ | Array[String] or String | Defines the key combinations used to call the command. |
|
||||
| `action` | Optional | String | Adds additional functionality to certain commands. |
|
||||
|
||||
### Implemented Commands and Actions
|
||||
|
||||
Commands listed below are per the implementation in [`src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp`](https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp).
|
||||
|
||||
Keybindings can be structured in the following manners:
|
||||
|
||||
For commands without arguments:
|
||||
<br>
|
||||
`{ "command": "commandName", "keys": [ "modifiers+key" ] }`
|
||||
|
||||
For commands with arguments:
|
||||
<br>
|
||||
`{ "command": { "action": "commandName", "argument": "value" }, "keys": ["modifiers+key"] }`
|
||||
|
||||
| Command | Command Description | Action (*=required) | Action Arguments | Argument Descriptions |
|
||||
| ------- | ------------------- | ------ | ---------------- | ----------------- |
|
||||
| `adjustFontSize` | Change the text size by a specified point amount. | `delta` | integer | Amount of size change per command invocation. |
|
||||
| `closePane` | Close the active pane. | | | |
|
||||
| `closeTab` | Close the current tab. | | | |
|
||||
| `closeWindow` | Close the current window and all tabs within it. | | | |
|
||||
| `copy` | Copy the selected terminal content to your Windows Clipboard. | `singleLine` | boolean | When `true`, the copied content will be copied as a single line. When `false`, newlines persist from the selected text. |
|
||||
| `duplicateTab` | Make a copy and open the current tab. | | | |
|
||||
| `find` | Open the search dialog box. | | | |
|
||||
| `moveFocus` | Focus on a different pane depending on direction. | `direction`* | `left`, `right`, `up`, `down` | Direction in which the focus will move. |
|
||||
| `newTab` | Create a new tab. Without any arguments, this will open the default profile in a new tab. | 1. `commandLine`<br>2. `startingDirectory`<br>3. `tabTitle`<br>4. `index`<br>5. `profile` | 1. string<br>2. string<br>3. string<br>4. integer<br>5. string | 1. Executable run within the tab.<br>2. Directory in which the tab will open.<br>3. Title of the new tab.<br>4. Profile that will open based on its position in the dropdown (starting at 0).<br>5. Profile that will open based on its GUID or name. |
|
||||
| `nextTab` | Open the tab to the right of the current one. | | | |
|
||||
| `openNewTabDropdown` | Open the dropdown menu. | | | |
|
||||
| `openSettings` | Open the settings file. | | | |
|
||||
| `paste` | Insert the content that was copied onto the clipboard. | | | |
|
||||
| `prevTab` | Open the tab to the left of the current one. | | | |
|
||||
| `resetFontSize` | Reset the text size to the default value. | | | |
|
||||
| `resizePane` | Change the size of the active pane. | `direction`* | `left`, `right`, `up`, `down` | Direction in which the pane will be resized. |
|
||||
| `scrollDown` | Move the screen down. | | | |
|
||||
| `scrollUp` | Move the screen up. | | | |
|
||||
| `scrollUpPage` | Move the screen up a whole page. | | | |
|
||||
| `scrollDownPage` | Move the screen down a whole page. | | | |
|
||||
| `splitPane` | Halve the size of the active pane and open another. Without any arguments, this will open the default profile in the new pane. | 1. `split`*<br>2. `commandLine`<br>3. `startingDirectory`<br>4. `tabTitle`<br>5. `index`<br>6. `profile`<br>7. `splitMode` | 1. `vertical`, `horizontal`, `auto`<br>2. string<br>3. string<br>4. string<br>5. integer<br>6. string<br>7. string | 1. How the pane will split. `auto` will split in the direction that provides the most surface area.<br>2. Executable run within the pane.<br>3. Directory in which the pane will open.<br>4. Title of the tab when the new pane is focused.<br>5. Profile that will open based on its position in the dropdown (starting at 0).<br>6. Profile that will open based on its GUID or name.<br>7. Controls how the pane splits. Only accepts `duplicate` which will duplicate the focused pane's profile into a new pane. |
|
||||
| `switchToTab` | Open a specific tab depending on index. | `index`* | integer | Tab that will open based on its position in the tab bar (starting at 0). |
|
||||
| `toggleFullscreen` | Switch between fullscreen and default window sizes. | | | |
|
||||
| `unbound` | Unbind the associated keys from any command. | | | |
|
||||
|
||||
### Accepted Modifiers and Keys
|
||||
|
||||
#### Modifiers
|
||||
`ctrl+`, `shift+`, `alt+`
|
||||
|
||||
#### Keys
|
||||
| Type | Keys |
|
||||
| ---- | ---- |
|
||||
| Function and Alphanumeric Keys | `f1-f24`, `a-z`, `0-9` |
|
||||
| Symbols | ``` ` ```, `-`, `=`, `[`, `]`, `\`, `;`, `'`, `,`, `.`, `/` |
|
||||
| Arrow Keys | `down`, `left`, `right`, `up`, `pagedown`, `pageup`, `pgdn`, `pgup`, `end`, `home`, `plus` |
|
||||
| Action Keys | `tab`, `enter`, `esc`, `escape`, `space`, `backspace`, `delete`, `insert` |
|
||||
| Numpad Keys | `numpad_0-numpad_9`, `numpad0-numpad9`, `numpad_add`, `numpad_plus`, `numpad_decimal`, `numpad_period`, `numpad_divide`, `numpad_minus`, `numpad_subtract`, `numpad_multiply` |
|
||||
|
||||
## Background Images and Icons
|
||||
Some Terminal settings allow you to specify custom background images and icons. It is recommended that custom images and icons are stored in system-provided folders and are referred to using the correct [URI Schemes](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes). URI Schemes provide a way to reference files independent of their physical paths (which may change in the future).
|
||||
|
||||
The most useful URI schemes to remember when customizing background images and icons are:
|
||||
|
||||
| URI Scheme | Corresponding Physical Path | Use / description |
|
||||
| --- | --- | ---|
|
||||
| `ms-appdata:///Local/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\` | Per-machine files |
|
||||
| `ms-appdata:///Roaming/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\RoamingState\` | Common files |
|
||||
|
||||
> ⚠ Note: Do not rely on file references using the `ms-appx` URI Scheme (i.e. icons). These files are considered an internal implementation detail and may change name/location or may be omitted in the future.
|
||||
|
||||
### Icons
|
||||
Terminal displays icons for each of your profiles which Terminal generates for any built-in shells - PowerShell Core, PowerShell, and any installed Linux/WSL distros. Each profile refers to a stock icon via the `ms-appx` URI Scheme.
|
||||
|
||||
> ⚠ Note: Do not rely on the files referenced by the `ms-appx` URI Scheme - they are considered an internal implementation detail and may change name/location or may be omitted in the future.
|
||||
|
||||
You can refer to you own icons if you wish, e.g.:
|
||||
|
||||
```json
|
||||
"icon" : "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\icon-ubuntu-32.png",
|
||||
```
|
||||
|
||||
> 👉 Tip: Icons should be sized to 32x32px in an appropriate raster image format (e.g. .PNG, .GIF, or .ICO) to avoid having to scale your icons during runtime (causing a noticeable delay and loss of quality.)
|
||||
|
||||
### Custom Background Images
|
||||
You can apply a background image to each of your profiles, allowing you to configure/brand/style each of your profiles independently from one another if you wish.
|
||||
|
||||
To do so, specify your preferred `backgroundImage`, position it using `backgroundImageAlignment`, set its opacity with `backgroundImageOpacity`, and/or specify how your image fill the available space using `backgroundImageStretchMode`.
|
||||
|
||||
For example:
|
||||
```json
|
||||
"backgroundImage": "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\bg-ubuntu-256.png",
|
||||
"backgroundImageAlignment": "bottomRight",
|
||||
"backgroundImageOpacity": 0.1,
|
||||
"backgroundImageStretchMode": "none"
|
||||
```
|
||||
|
||||
> 👉 Tip: You can easily roam your collection of images and icons across all your machines by storing your icons and images in OneDrive (as shown above).
|
||||
|
||||
With these settings, your Terminal's Ubuntu profile would look similar to this:
|
||||
|
||||
|
||||
|
||||
@@ -86,7 +86,7 @@ project from our `TerminalAppLib` project:
|
||||
duplicate type definitions)-->
|
||||
|
||||
<Reference Include="Microsoft.Terminal.Settings">
|
||||
<HintPath>$(OpenConsoleCommonOutDir)\TerminalSettings\Microsoft.Terminal.Settings.winmd</HintPath>
|
||||
<HintPath>$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\Microsoft.Terminal.Settings.winmd</HintPath>
|
||||
<IsWinMDFile>true</IsWinMDFile>
|
||||
<Private>false</Private>
|
||||
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
|
||||
@@ -122,7 +122,7 @@ dir to your `AdditionalLibraryDirectories`, and adding the lib to your
|
||||
<ItemDefinitionGroup>
|
||||
<Link>
|
||||
<!-- Manually link with the TerminalAppLib.lib we've built. -->
|
||||
<AdditionalLibraryDirectories>$(OpenConsoleCommonOutDir)\TerminalAppLib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
|
||||
<AdditionalLibraryDirectories>$(SolutionDir)\$(Platform)\$(Configuration)\TerminalAppLib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
|
||||
|
||||
<AdditionalDependencies>TerminalAppLib.lib;%(AdditionalDependencies)</AdditionalDependencies>
|
||||
</Link>
|
||||
@@ -260,9 +260,9 @@ this:
|
||||
echo OutDir=$(OutDir)
|
||||
(xcopy /Y "$(SolutionDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.manifest" "$(OutDir)\TerminalApp.Unit.Tests.manifest*" )
|
||||
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalConnection\TerminalConnection.dll" "$(OutDir)\TerminalConnection.dll*" )
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalSettings\TerminalSettings.dll" "$(OutDir)\TerminalSettings.dll*" )
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalControl\TerminalControl.dll" "$(OutDir)\TerminalControl.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalConnection\TerminalConnection.dll" "$(OutDir)\TerminalConnection.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\TerminalSettings.dll" "$(OutDir)\TerminalSettings.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalControl\TerminalControl.dll" "$(OutDir)\TerminalControl.dll*" )
|
||||
</Command>
|
||||
</PostBuildEvent>
|
||||
</ItemDefinitionGroup>
|
||||
@@ -446,9 +446,9 @@ before. The complete `PostBuildEvent` now looks like this:
|
||||
|
||||
(xcopy /Y "$(SolutionDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.AppxManifest.xml" "$(OutDir)\TerminalApp.Unit.Tests.AppxManifest.xml*" )
|
||||
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalConnection\TerminalConnection.dll" "$(OutDir)\TerminalConnection.dll*" )
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalSettings\TerminalSettings.dll" "$(OutDir)\TerminalSettings.dll*" )
|
||||
(xcopy /Y "$(OpenConsoleCommonOutDir)\TerminalControl\TerminalControl.dll" "$(OutDir)\TerminalControl.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalConnection\TerminalConnection.dll" "$(OutDir)\TerminalConnection.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\TerminalSettings.dll" "$(OutDir)\TerminalSettings.dll*" )
|
||||
(xcopy /Y "$(SolutionDir)$(Platform)\$(Configuration)\TerminalControl\TerminalControl.dll" "$(OutDir)\TerminalControl.dll*" )
|
||||
</Command>
|
||||
</PostBuildEvent>
|
||||
</ItemDefinitionGroup>
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"$id": "https://github.com/microsoft/terminal/blob/main/doc/cascadia/profiles.schema.json",
|
||||
"$schema": "https://json-schema.org/draft/2019-09/schema#",
|
||||
"$id": "https://github.com/microsoft/terminal/blob/master/doc/cascadia/profiles.schema.json",
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"title": "Microsoft's Windows Terminal Settings Profile Schema",
|
||||
"definitions": {
|
||||
"KeyChordSegment": {
|
||||
"pattern": "^(?<modifier>(ctrl|alt|shift)(?:\\+(ctrl|alt|shift)(?<!\\2))?(?:\\+(ctrl|alt|shift)(?<!\\2|\\3))?\\+)?(?<key>[^\\s+]|app|menu|backspace|tab|enter|esc|escape|space|pgup|pageup|pgdn|pagedown|end|home|left|up|right|down|insert|delete|(?<!shift.+)(?:numpad_?[0-9]|numpad_(?:period|decimal))|numpad_(?:multiply|plus|add|minus|subtract|divide)|f[1-9]|f1[0-9]|f2[0-4]|plus)$",
|
||||
"pattern": "^(?<modifier>(ctrl|alt|shift)(?:\\+(ctrl|alt|shift)(?<!\\2))?(?:\\+(ctrl|alt|shift)(?<!\\2|\\3))?\\+)?(?<key>[^\\s+]|backspace|tab|enter|esc|escape|space|pgup|pageup|pgdn|pagedown|end|home|left|up|right|down|insert|delete|(?<!shift.+)(?:numpad_?[0-9]|numpad_(?:period|decimal))|numpad_(?:multiply|plus|add|minus|subtract|divide)|f[1-9]|f1[0-9]|f2[0-4]|plus)$",
|
||||
"type": "string",
|
||||
"description": "The string should fit the format \"[ctrl+][alt+][shift+]<keyName>\", where each modifier is optional, separated by + symbols, and keyName is either one of the names listed in the table below, or any single key character. The string should be written in full lowercase.\napp, menu\tMENU key\nbackspace\tBACKSPACE key\ntab\tTAB key\nenter\tENTER key\nesc, escape\tESC key\nspace\tSPACEBAR\npgup, pageup\tPAGE UP key\npgdn, pagedown\tPAGE DOWN key\nend\tEND key\nhome\tHOME key\nleft\tLEFT ARROW key\nup\tUP ARROW key\nright\tRIGHT ARROW key\ndown\tDOWN ARROW key\ninsert\tINS key\ndelete\tDEL key\nnumpad_0-numpad_9, numpad0-numpad9\tNumeric keypad keys 0 to 9. Can't be combined with the shift modifier.\nnumpad_multiply\tNumeric keypad MULTIPLY key (*)\nnumpad_plus, numpad_add\tNumeric keypad ADD key (+)\nnumpad_minus, numpad_subtract\tNumeric keypad SUBTRACT key (-)\nnumpad_period, numpad_decimal\tNumeric keypad DECIMAL key (.). Can't be combined with the shift modifier.\nnumpad_divide\tNumeric keypad DIVIDE key (/)\nf1-f24\tF1 to F24 function keys\nplus\tADD key (+)"
|
||||
"description": "The string should fit the format \"[ctrl+][alt+][shift+]<keyName>\", where each modifier is optional, separated by + symbols, and keyName is either one of the names listed in the table below, or any single key character. The string should be written in full lowercase.\nbackspace\tBACKSPACE key\ntab\tTAB key\nenter\tENTER key\nesc, escape\tESC key\nspace\tSPACEBAR\npgup, pageup\tPAGE UP key\npgdn, pagedown\tPAGE DOWN key\nend\tEND key\nhome\tHOME key\nleft\tLEFT ARROW key\nup\tUP ARROW key\nright\tRIGHT ARROW key\ndown\tDOWN ARROW key\ninsert\tINS key\ndelete\tDEL key\nnumpad_0-numpad_9, numpad0-numpad9\tNumeric keypad keys 0 to 9. Can't be combined with the shift modifier.\nnumpad_multiply\tNumeric keypad MULTIPLY key (*)\nnumpad_plus, numpad_add\tNumeric keypad ADD key (+)\nnumpad_minus, numpad_subtract\tNumeric keypad SUBTRACT key (-)\nnumpad_period, numpad_decimal\tNumeric keypad DECIMAL key (.). Can't be combined with the shift modifier.\nnumpad_divide\tNumeric keypad DIVIDE key (/)\nf1-f24\tF1 to F24 function keys\nplus\tADD key (+)"
|
||||
},
|
||||
"Color": {
|
||||
"default": "#",
|
||||
@@ -26,65 +26,36 @@
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"BellStyle": {
|
||||
"enum": [
|
||||
"none",
|
||||
"audible"
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"ProfileGuid": {
|
||||
"default": "{}",
|
||||
"pattern": "^\\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}\\}$",
|
||||
"type": "string"
|
||||
},
|
||||
"Icon": {
|
||||
"description": "Image file location or an emoji to be used as an icon. Displays within the tab, the dropdown menu, and jumplist.",
|
||||
"type": [
|
||||
"string",
|
||||
"null"
|
||||
]
|
||||
},
|
||||
"ShortcutActionName": {
|
||||
"enum": [
|
||||
"adjustFontSize",
|
||||
"closeOtherTabs",
|
||||
"closePane",
|
||||
"closeTab",
|
||||
"closeTabsAfter",
|
||||
"closeWindow",
|
||||
"commandPalette",
|
||||
"copy",
|
||||
"duplicateTab",
|
||||
"find",
|
||||
"moveFocus",
|
||||
"newTab",
|
||||
"nextTab",
|
||||
"openNewTabDropdown",
|
||||
"openSettings",
|
||||
"openTabColorPicker",
|
||||
"paste",
|
||||
"prevTab",
|
||||
"renameTab",
|
||||
"openTabRenamer",
|
||||
"resetFontSize",
|
||||
"resizePane",
|
||||
"scrollDown",
|
||||
"scrollDownPage",
|
||||
"scrollUp",
|
||||
"scrollUpPage",
|
||||
"sendInput",
|
||||
"setColorScheme",
|
||||
"setTabColor",
|
||||
"splitPane",
|
||||
"switchToTab",
|
||||
"tabSearch",
|
||||
"toggleAlwaysOnTop",
|
||||
"toggleFocusMode",
|
||||
"toggleFullscreen",
|
||||
"togglePaneZoom",
|
||||
"toggleRetroEffect",
|
||||
"wt",
|
||||
"find",
|
||||
"unbound"
|
||||
],
|
||||
"type": "string"
|
||||
@@ -106,40 +77,6 @@
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"CopyFormat": {
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "boolean"
|
||||
},
|
||||
{
|
||||
"type": "array",
|
||||
"items": {
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"html",
|
||||
"rtf"
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"html",
|
||||
"rtf",
|
||||
"all",
|
||||
"none"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"AnchorKey": {
|
||||
"enum": [
|
||||
"ctrl",
|
||||
"alt",
|
||||
"shift"
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"NewTerminalArgs": {
|
||||
"properties": {
|
||||
"commandline": {
|
||||
@@ -205,18 +142,6 @@
|
||||
"type": "boolean",
|
||||
"default": false,
|
||||
"description": "If true, the copied content will be copied as a single line (even if there are hard line breaks present in the text). If false, newlines persist from the selected text."
|
||||
},
|
||||
"copyFormatting": {
|
||||
"default": null,
|
||||
"description": "When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. An array of specific formats can also be used. Supported array values include `html` and `rtf`. Plain text is always copied. Not setting this value inherits the behavior of the `copyFormatting` global setting.",
|
||||
"oneOf": [
|
||||
{
|
||||
"$ref": "#/definitions/CopyFormat"
|
||||
},
|
||||
{
|
||||
"type": "null"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -285,28 +210,6 @@
|
||||
],
|
||||
"required": [ "direction" ]
|
||||
},
|
||||
"SendInputAction": {
|
||||
"description": "Arguments corresponding to a Send Input Action",
|
||||
"allOf": [
|
||||
{
|
||||
"$ref": "#/definitions/ShortcutAction"
|
||||
},
|
||||
{
|
||||
"properties": {
|
||||
"action": {
|
||||
"type": "string",
|
||||
"pattern": "sendInput"
|
||||
},
|
||||
"input": {
|
||||
"type": "string",
|
||||
"default": "",
|
||||
"description": "The text input to feed into the shell. ANSI escape sequences may be used. Escape codes like \\x1b must be written as \\u001b."
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"required": [ "input" ]
|
||||
},
|
||||
"SplitPaneAction": {
|
||||
"description": "Arguments corresponding to a Split Pane Action",
|
||||
"allOf": [
|
||||
@@ -328,152 +231,6 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"OpenSettingsAction": {
|
||||
"description": "Arguments corresponding to a Open Settings Action",
|
||||
"allOf": [
|
||||
{
|
||||
"$ref": "#/definitions/ShortcutAction"
|
||||
},
|
||||
{
|
||||
"properties": {
|
||||
"action": {
|
||||
"type": "string",
|
||||
"pattern": "openSettings"
|
||||
},
|
||||
"target": {
|
||||
"type": "string",
|
||||
"default": "settingsFile",
|
||||
"description": "The settings file to open.",
|
||||
"enum": [
|
||||
"settingsFile",
|
||||
"defaultsFile",
|
||||
"allFiles"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"SetTabColorAction": {
|
||||
"description": "Arguments corresponding to a Set Tab Color Action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "setTabColor" },
|
||||
"color": {
|
||||
"$ref": "#/definitions/Color",
|
||||
"default": null,
|
||||
"description": "If provided, will set the tab's color to the given value. If omitted, will reset the tab's color."
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"SetColorSchemeAction": {
|
||||
"description": "Arguments corresponding to a Set Color Scheme Action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "setColorScheme" },
|
||||
"colorScheme": {
|
||||
"type": "string",
|
||||
"default": "",
|
||||
"description": "the name of the scheme to apply to the active pane"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"required": [ "colorScheme" ]
|
||||
},
|
||||
"WtAction": {
|
||||
"description": "Arguments corresponding to a wt Action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "wt" },
|
||||
"commandline": {
|
||||
"type": "string",
|
||||
"default": "",
|
||||
"description": "a `wt` commandline to run in the current window"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"required": [ "commandline" ]
|
||||
},
|
||||
"CloseOtherTabsAction": {
|
||||
"description": "Arguments for a closeOtherTabs action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "closeOtherTabs" },
|
||||
"index": {
|
||||
"oneOf": [
|
||||
{ "type": "integer" },
|
||||
{ "type": null }
|
||||
],
|
||||
"default": "",
|
||||
"description": "Close the tabs other than the one at this index. If no index is provided, use the focused tab's index."
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"CloseTabsAfterAction": {
|
||||
"description": "Arguments for a closeTabsAfter action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "closeTabsAfter" },
|
||||
"index": {
|
||||
"oneOf": [
|
||||
{ "type": "integer" },
|
||||
{ "type": null }
|
||||
],
|
||||
"default": "",
|
||||
"description": "Close the tabs following the tab at this index. If no index is provided, use the focused tab's index."
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"ScrollUpAction": {
|
||||
"description": "Arguments for a scrollUp action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "scrollUp" },
|
||||
"rowsToScroll": {
|
||||
"type": ["integer", "null"],
|
||||
"default": null,
|
||||
"description": "Scroll up rowsToScroll lines. If no value is provided, use the system-level defaults."
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"ScrollDownAction": {
|
||||
"description": "Arguments for a scrollDown action",
|
||||
"allOf": [
|
||||
{ "$ref": "#/definitions/ShortcutAction" },
|
||||
{
|
||||
"properties": {
|
||||
"action": { "type": "string", "pattern": "scrollDown" },
|
||||
"rowsToScroll": {
|
||||
"type": ["integer", "null"],
|
||||
"default": null,
|
||||
"description": "Scroll down rowsToScroll lines. If no value is provided, use the system-level defaults."
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
"Keybinding": {
|
||||
"additionalProperties": false,
|
||||
"properties": {
|
||||
@@ -487,16 +244,7 @@
|
||||
{ "$ref": "#/definitions/SwitchToTabAction" },
|
||||
{ "$ref": "#/definitions/MoveFocusAction" },
|
||||
{ "$ref": "#/definitions/ResizePaneAction" },
|
||||
{ "$ref": "#/definitions/SendInputAction" },
|
||||
{ "$ref": "#/definitions/SplitPaneAction" },
|
||||
{ "$ref": "#/definitions/OpenSettingsAction" },
|
||||
{ "$ref": "#/definitions/SetTabColorAction" },
|
||||
{ "$ref": "#/definitions/SetColorSchemeAction" },
|
||||
{ "$ref": "#/definitions/WtAction" },
|
||||
{ "$ref": "#/definitions/CloseOtherTabsAction" },
|
||||
{ "$ref": "#/definitions/CloseTabsAfterAction" },
|
||||
{ "$ref": "#/definitions/ScrollUpAction" },
|
||||
{ "$ref": "#/definitions/ScrollDownAction" },
|
||||
{ "type": "null" }
|
||||
]
|
||||
},
|
||||
@@ -514,14 +262,6 @@
|
||||
"type": "array"
|
||||
}
|
||||
]
|
||||
},
|
||||
"icon": { "$ref": "#/definitions/Icon" },
|
||||
"name": {
|
||||
"description": "The name that will appear in the command palette. If one isn't provided, the terminal will attempt to automatically generate a name.",
|
||||
"type": [
|
||||
"string",
|
||||
"null"
|
||||
]
|
||||
}
|
||||
},
|
||||
"required": [
|
||||
@@ -534,11 +274,6 @@
|
||||
"additionalProperties": true,
|
||||
"description": "Properties that affect the entire window, regardless of the profile settings.",
|
||||
"properties": {
|
||||
"alwaysOnTop": {
|
||||
"default": false,
|
||||
"description": "When set to true, the window is created on top of all other windows. If multiple windows are all \"always on top\", the most recently focused one will be the topmost",
|
||||
"type": "boolean"
|
||||
},
|
||||
"alwaysShowTabs": {
|
||||
"default": true,
|
||||
"description": "When set to true, tabs are always displayed. When set to false and \"showTabsInTitlebar\" is set to false, tabs only appear after opening a new tab.",
|
||||
@@ -551,27 +286,12 @@
|
||||
},
|
||||
"copyFormatting": {
|
||||
"default": true,
|
||||
"description": "When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. An array of specific formats can also be used. Supported array values include `html` and `rtf`. Plain text is always copied.",
|
||||
"$ref": "#/definitions/CopyFormat"
|
||||
},
|
||||
"disableAnimations": {
|
||||
"default": false,
|
||||
"description": "When set to `true`, visual animations will be disabled across the application.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"largePasteWarning": {
|
||||
"default": true,
|
||||
"description": "When set to true, trying to paste text with more than 5 KiB of characters will display a warning asking you whether to continue or not with the paste.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"multiLinePasteWarning": {
|
||||
"default": true,
|
||||
"description": "When set to true, trying to paste text with a \"new line\" character will display a warning asking you whether to continue or not with the paste.",
|
||||
"description": "When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"defaultProfile": {
|
||||
"description": "Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\".",
|
||||
"type": "string"
|
||||
"$ref": "#/definitions/ProfileGuid",
|
||||
"description": "Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\". The \"guid\" of the desired default profile is used as the value."
|
||||
},
|
||||
"disabledProfileSources": {
|
||||
"description": "Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup.",
|
||||
@@ -590,46 +310,37 @@
|
||||
},
|
||||
"initialCols": {
|
||||
"default": 120,
|
||||
"description": "The number of columns displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
|
||||
"description": "The number of columns displayed in the window upon first load.",
|
||||
"maximum": 999,
|
||||
"minimum": 1,
|
||||
"type": "integer"
|
||||
},
|
||||
"initialPosition": {
|
||||
"$ref": "#/definitions/Coordinates",
|
||||
"description": "The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), the window will be maximized on the monitor specified by those coordinates."
|
||||
"description": "The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If \"launchMode\" is set to maximized, the window will be maximized on the monitor specified by those coordinates."
|
||||
},
|
||||
"initialRows": {
|
||||
"default": 30,
|
||||
"description": "The number of rows displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
|
||||
"description": "The number of rows displayed in the window upon first load.",
|
||||
"maximum": 999,
|
||||
"minimum": 1,
|
||||
"type": "integer"
|
||||
},
|
||||
"startOnUserLogin": {
|
||||
"default": false,
|
||||
"description": "When set to true, this enables the launch of Windows Terminal at startup. Setting this to false will disable the startup task entry. If the Windows Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"launchMode": {
|
||||
"default": "default",
|
||||
"description": "Defines whether the terminal will launch as maximized, full screen, or in a window. Setting this to \"focus\" is equivalent to launching the terminal in the \"default\" mode, but with the focus mode enabled. Similar, setting this to \"maximizedFocus\" will result in launching the terminal in a maximized window with the focus mode enabled.",
|
||||
"description": "Defines whether the Terminal will launch as maximized or not.",
|
||||
"enum": [
|
||||
"fullscreen",
|
||||
"maximized",
|
||||
"default",
|
||||
"focus",
|
||||
"maximizedFocus"
|
||||
"default"
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"rowsToScroll": {
|
||||
"default": "system",
|
||||
"description": "This parameter once allowed you to override the systemwide \"choose how many lines to scroll at one time\" setting. It no longer does so.",
|
||||
"description": "The number of rows to scroll at a time with the mouse wheel. This will override the system setting if the value is not zero or \"system\".",
|
||||
"maximum": 999,
|
||||
"minimum": 0,
|
||||
"type": [ "integer", "string" ],
|
||||
"deprecated": true
|
||||
"type": [ "integer", "string" ]
|
||||
},
|
||||
"keybindings": {
|
||||
"description": "Properties are specific to each custom key binding.",
|
||||
@@ -665,9 +376,8 @@
|
||||
},
|
||||
"tabWidthMode": {
|
||||
"default": "equal",
|
||||
"description": "Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title\n -\"compact\" sizes each tab to the length of its title when focused, and shrinks to the size of only the icon when the tab is unfocused.",
|
||||
"description": "Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title",
|
||||
"enum": [
|
||||
"compact",
|
||||
"equal",
|
||||
"titleLength"
|
||||
],
|
||||
@@ -682,41 +392,6 @@
|
||||
"default": true,
|
||||
"description": "When set to \"true\" closing a window with multiple tabs open will require confirmation. When set to \"false\", the confirmation dialog will not appear.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"useTabSwitcher": {
|
||||
"default": true,
|
||||
"description": "Deprecated. Please use \"tabSwitcherMode\" instead.",
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "boolean"
|
||||
},
|
||||
{
|
||||
"enum": [
|
||||
"mru",
|
||||
"inOrder",
|
||||
"disabled",
|
||||
],
|
||||
"type": "string"
|
||||
}
|
||||
],
|
||||
"deprecated": true
|
||||
},
|
||||
"tabSwitcherMode": {
|
||||
"default": true,
|
||||
"description": "When set to \"true\" or \"mru\", the \"nextTab\" and \"prevTab\" commands will use the tab switcher UI, with most-recently-used ordering. When set to \"inOrder\", these actions will switch tabs in their current ordering. Set to \"false\" to disable the tab switcher.",
|
||||
"oneOf": [
|
||||
{
|
||||
"type": "boolean"
|
||||
},
|
||||
{
|
||||
"enum": [
|
||||
"mru",
|
||||
"inOrder",
|
||||
"disabled",
|
||||
],
|
||||
"type": "string"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
"required": [
|
||||
@@ -753,16 +428,7 @@
|
||||
},
|
||||
"backgroundImage": {
|
||||
"description": "Sets the file location of the image to draw over the window background.",
|
||||
"oneOf": [
|
||||
{
|
||||
"type": ["string", null]
|
||||
},
|
||||
{
|
||||
"enum": [
|
||||
"desktopWallpaper"
|
||||
]
|
||||
}
|
||||
]
|
||||
"type": ["string", "null"]
|
||||
},
|
||||
"backgroundImageAlignment": {
|
||||
"default": "center",
|
||||
@@ -798,11 +464,6 @@
|
||||
],
|
||||
"type": "string"
|
||||
},
|
||||
"bellStyle": {
|
||||
"default": "audible",
|
||||
"description": "Controls what happens when the application emits a BEL character. When set to \"audible\", the Terminal will play a sound. When set to \"none\", nothing will happen.",
|
||||
"$ref": "#/definitions/BellStyle"
|
||||
},
|
||||
"closeOnExit": {
|
||||
"default": "graceful",
|
||||
"description": "Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
|
||||
@@ -873,7 +534,7 @@
|
||||
"fontWeight": {
|
||||
"default": "normal",
|
||||
"description": "Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values:\n -\"thin\"\n -\"extra-light\"\n -\"light\"\n -\"semi-light\"\n -\"normal\" (default)\n -\"medium\"\n -\"semi-bold\"\n -\"bold\"\n -\"extra-bold\"\n -\"black\"\n -\"extra-black\" or the corresponding numeric representation of OpenType font weight.",
|
||||
"oneOf": [
|
||||
"oneOf": [
|
||||
{
|
||||
"enum": [
|
||||
"thin",
|
||||
@@ -895,8 +556,7 @@
|
||||
"minimum": 100,
|
||||
"type": "integer"
|
||||
}
|
||||
]
|
||||
},
|
||||
}
|
||||
"foreground": {
|
||||
"$ref": "#/definitions/Color",
|
||||
"default": "#cccccc",
|
||||
@@ -918,7 +578,10 @@
|
||||
"minimum": -1,
|
||||
"type": "integer"
|
||||
},
|
||||
"icon":{ "$ref": "#/definitions/Icon" },
|
||||
"icon": {
|
||||
"description": "Image file location of the icon used in the profile. Displays within the tab and the dropdown menu.",
|
||||
"type": ["string", "null"]
|
||||
},
|
||||
"name": {
|
||||
"description": "Name of the profile. Displays in the dropdown menu.",
|
||||
"minLength": 1,
|
||||
@@ -927,15 +590,8 @@
|
||||
"padding": {
|
||||
"default": "8, 8, 8, 8",
|
||||
"description": "Sets the padding around the text within the window. Can have three different formats:\n -\"#\" sets the same padding for all sides \n -\"#, #\" sets the same padding for left-right and top-bottom\n -\"#, #, #, #\" sets the padding individually for left, top, right, and bottom.",
|
||||
"oneOf": [
|
||||
{
|
||||
"pattern": "^-?[0-9]+(\\.[0-9]+)?( *, *-?[0-9]+(\\.[0-9]+)?|( *, *-?[0-9]+(\\.[0-9]+)?){3})?$",
|
||||
"type": "string"
|
||||
},
|
||||
{
|
||||
"type": "integer"
|
||||
}
|
||||
]
|
||||
"pattern": "^-?[0-9]+(\\.[0-9]+)?( *, *-?[0-9]+(\\.[0-9]+)?|( *, *-?[0-9]+(\\.[0-9]+)?){3})?$",
|
||||
"type": "string"
|
||||
},
|
||||
"scrollbarState": {
|
||||
"default": "visible",
|
||||
@@ -958,11 +614,6 @@
|
||||
"description": "When set to true, the window will scroll to the command input line when typing. When set to false, the window will not scroll when you start typing.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"altGrAliasing": {
|
||||
"default": true,
|
||||
"description": "By default Windows treats Ctrl+Alt as an alias for AltGr. When altGrAliasing is set to false, this behavior will be disabled.",
|
||||
"type": "boolean"
|
||||
},
|
||||
"source": {
|
||||
"description": "Stores the name of the profile generator that originated this profile.",
|
||||
"type": ["string", "null"]
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
# Creating a New Project
|
||||
|
||||
## Creating a new WinRT Component DLL and referencing it in another project
|
||||
|
||||
When creating a new DLL, it was really helpful to reference an existing DLL's `.vcxproj` like `TerminalControl.vcxproj`. While you should mostly try to copy what the existing `.vcxproj` has, here's a handful of things to double check for as you go along.
|
||||
|
||||
- [ ] Make sure to `<Import>` our pre props at the _top_ of the vcxproj, and our post props at the _bottom_ of the vcxproj.
|
||||
```
|
||||
<!-- pre props -->
|
||||
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
|
||||
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
|
||||
|
||||
<!-- everything else -->
|
||||
|
||||
<!-- post props -->
|
||||
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.post.props" />
|
||||
```
|
||||
- [ ] Add a `<ProjectReference>` to your new `.vcxproj` in both `WindowsTerminal.vcxproj` and `TerminalApp.vcxproj`
|
||||
- [ ] Add a `<Reference>` to `TerminalAppLib.vcxproj` similar to this:
|
||||
```
|
||||
<Reference Include="Microsoft.Terminal.NewDLL">
|
||||
<HintPath>$(OpenConsoleCommonOutDir)\TerminalNewDLL\Microsoft.Terminal.NewDLL.winmd</HintPath>
|
||||
<IsWinMDFile>true</IsWinMDFile>
|
||||
<Private>false</Private>
|
||||
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
|
||||
</Reference>
|
||||
```
|
||||
- [ ] Make sure the project has a `.def` file with the following lines. The `WINRT_GetActivationFactory` part is important to expose the new DLL's activation factory so that other projects can successfully call the DLL's `GetActivationFactory` to get the DLL's classes.
|
||||
```
|
||||
EXPORTS
|
||||
DllCanUnloadNow = WINRT_CanUnloadNow PRIVATE
|
||||
DllGetActivationFactory = WINRT_GetActivationFactory PRIVATE
|
||||
```
|
||||
- For a bit more context on this whole process, the `AppXManifest.xml` file defines which classes belong to which DLLs. If your project wants class `X.Y.Z`, it can look it up in the manifest's definitions and see that it came from `X.Y.dll`. Then it'll load up the DLL, and call a particular function called `GetActivationFactory(L"X.Y.Z")` to get the class it wants. So, the definitions in `AppXManifest` are _required_ for this activation to work properly, and I found myself double checking the file to see that the definitions I expect are there.
|
||||
- _Note_: If your new library eventually rolls up as a reference to our Centennial Packaging project `CascadiaPackage`, you don't have to worry about manually adding your definitions to the `AppXManifest.xml` because the Centennial Packaging project automatically enumerates the reference tree of WinMDs and stitches that information into the `AppXManifest.xml`. However, if your new project does _not_ ultimately roll up to a packaging project that will automatically put the references into `AppXManifest`, you will have to add them in manually.
|
||||
|
||||
### Troubleshooting
|
||||
- If you hit an error that looks like this:
|
||||
```
|
||||
X found processing metadata file ..\blah1\Microsoft.UI.Xaml.winmd, type already exists in file ..\blah\NewDLLProject\Microsoft.UI.Xaml.winmd.
|
||||
```
|
||||
The `Microsoft.UI.Xaml.winmd` is showing up in the output folder when it shouldn't. Try adding this block at the top of your `.vcxproj`
|
||||
```
|
||||
<ItemDefinitionGroup>
|
||||
<Reference>
|
||||
<Private>false</Private>
|
||||
</Reference>
|
||||
</ItemDefinitionGroup>
|
||||
```
|
||||
This will make all references non-private, meaning "don't copy it into my folder" by default.
|
||||
|
||||
- If you hit a `Class not Registered` error, this might be because a class isn't getting registered in the app manifest. You can go check `src/cascadia/CascadiaPackage/bin/x64/Debug/AppX/AppXManifest.xml` to see if there exist entries to the classes of your newly created DLL. If the references aren't there, double check that you've added `<ProjectReference>` blocks to both `WindowsTerminal.vcxproj` and `TerminalApp.vcxproj`.
|
||||
|
||||
- If you hit an extremely vague error along the lines of `Error in the DLL`, and right before that line you notice that your new DLL is loaded and unloaded right after each other, double check that your new DLL's definitions show up in the `AppXManifest.xml` file. If your new DLL is included as a reference to a project that rolls up to `CascadiaPackage`, double check that you've created a `.def` file for the project. Otherwise if your new project _does not_ roll up to a package that populates the `AppXManifest` references for you, you'll have to add those references yourself.
|
||||
BIN
doc/images/custom-icon-and-background-image.jpg
Normal file
BIN
doc/images/custom-icon-and-background-image.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB After Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 300 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 101 KiB After Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 98 KiB After Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 117 KiB After Width: | Height: | Size: 130 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.3 KiB After Width: | Height: | Size: 5.5 KiB |
@@ -1,146 +0,0 @@
|
||||
---
|
||||
author: Mike Griese @zadjii-msft
|
||||
created on: 2020-07-31
|
||||
last updated: 2020-08-03
|
||||
issue id: #1337
|
||||
---
|
||||
# Per-Profile Tab Colors
|
||||
|
||||
## Abstract
|
||||
|
||||
This spec describes a way to specify tab colors in a profile in a way that will
|
||||
be forward compatible with theming the Terminal. This spec will be largely
|
||||
dedicated to the design of a single setting, but within the context of theming.
|
||||
|
||||
## Inspiration
|
||||
|
||||
Following the addition of the Tab Color Picker in [#3789], we've had numerous
|
||||
requests for the ability to set the color of a tab directly within a profile.
|
||||
While largely we're tracking theming in [#3327], including the specification of
|
||||
a tab color, the theming spec ([#5772] )is very large and will take a while to
|
||||
revise and approve. This spec is intended to pull a single point out from that
|
||||
spec to make it more easily reviewable, and implement it in a way that will
|
||||
continue working when we add support for themes in the future.
|
||||
|
||||
## Solution Design
|
||||
|
||||
To enable per-profile tab colors, we'll add a single setting: `tabColor`. For
|
||||
now<sup>[[1](#user-content-footnote-1)]</sup>, this setting will accept any
|
||||
`#rrggbb` color string.
|
||||
|
||||
Since each profile creates a `Pane` with a `TermControl`, we'll need to store
|
||||
this color not in the `Tab`, but somewhere below `Pane`, so that when you switch
|
||||
between Panes in a tab with different `tabColor`s, the color will update
|
||||
automatically. When a new `TermControl` is created, we'll store this color in the
|
||||
`TermControl`'s `Terminal` core. This is to support the future possibility of
|
||||
setting the tab color via VT sequences.
|
||||
|
||||
A Tab's color will be the result of layering a variety of sources, from the bottom up:
|
||||
|
||||
Color | | Set by
|
||||
-- | -- | --
|
||||
Runtime Color | _optional_ |Color Picker / `setTabColor` action
|
||||
Control Tab Color | _optional_ | Profile's `tabColor`, or a color set by VT
|
||||
Theme Tab Background | _optional_ | `tab.backgroundColor` in the theme
|
||||
Tab Default Color | **default** | TabView in XAML
|
||||
|
||||
Some examples:
|
||||
* **Scenario 1**: The user has set `"tabColor": "#ff0000"` in their profile.
|
||||
When they create tabs with that profile, instead of appearing in the default
|
||||
color for the TabView, they'll be `#ff0000`.
|
||||
* **Scenario 2**: The user has set `"tabColor": "#ff0000"` in their profile.
|
||||
When they try to set the color for that tab (with the color picker) to
|
||||
`#0000ff`, the tab's color is updated to reflect this new blue color. When
|
||||
they clear the runtime color (with the color picker), the tab will return to
|
||||
`#ff0000`.
|
||||
* **Scenario 3**: The user has two profiles with colors set, one to `"tabColor":
|
||||
"#ff0000"`, and the other with `"tabColor": "#00ff00"`. If they open these
|
||||
profiles in two panes side-by side, the tab's color will update to reflect the
|
||||
color from the currently-focused control.
|
||||
* **Scenario 4**: The user has two profiles with colors set, one to `"tabColor":
|
||||
"#ff0000"`, and the other with `"tabColor": "#00ff00"`. If they open these
|
||||
profiles in two panes side-by side, and try to set the color for that tab
|
||||
(with the color picker) to `#0000ff`, the tab's color is updated to reflect
|
||||
this new blue color. Regardless of which pane is focused, the tab will be
|
||||
blue.
|
||||
* **Scenario 5**: The user has set `"tabColor": "#ff0000"` in their profile
|
||||
("Profile A"), and `"tab.backgroundColor": "#00ff00"`in their theme. When they
|
||||
create tabs with "Profile A", the tabs will appear red. Other tabs (for
|
||||
profiles without `tabColor` set) will appear green, using the color from the
|
||||
theme.
|
||||
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
In general, this is going to look exactly like the colored tabs look now.
|
||||
|
||||
|
||||
|
||||
## Capabilities
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td><strong>Accessibility</strong></td>
|
||||
<td>
|
||||
N/A
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Security</strong></td>
|
||||
<td>
|
||||
N/A
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Reliability</strong></td>
|
||||
<td>
|
||||
No expected change
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Compatibility</strong></td>
|
||||
<td>
|
||||
This entire spec outlines how this feature is designed with a emphasis on future
|
||||
compatibility. As such, there are no expected regressions in the future when we
|
||||
do add support for themes.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Performance, Power, and Efficiency</strong></td>
|
||||
<td>
|
||||
No expected change
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Potential Issues
|
||||
|
||||
None expected.
|
||||
|
||||
## Footnotes
|
||||
|
||||
<a id="footnote-1"><a>[1]: When full theming support is added, themes will
|
||||
provide support for setting colors as one of a variety of values:
|
||||
|
||||
* An `#rrggbb` string
|
||||
* The system accent color
|
||||
* The current background color of the Terminal
|
||||
* A value from a given resource key from XAML
|
||||
|
||||
When support for these other types of "smart" colors is added, then the profile
|
||||
`tabColor` setting will also gracefully accept these values.
|
||||
|
||||
## Future considerations
|
||||
|
||||
* It's not out of the realm of possibility that someone might want to color each
|
||||
_pane_'s color at runtime. In that case, the runtime color would be stored in
|
||||
the `Pane`, not the `Tab`.
|
||||
|
||||
|
||||
|
||||
<!-- Footnotes -->
|
||||
|
||||
[#1337]: https://github.com/microsoft/terminal/issues/1337
|
||||
[#3789]: https://github.com/microsoft/terminal/issues/3789
|
||||
[#3327]: https://github.com/microsoft/terminal/issues/3327
|
||||
[#5772]: https://github.com/microsoft/terminal/pull/5772
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 816 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 253 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
@@ -1,227 +0,0 @@
|
||||
---
|
||||
author: Leon Liang @leonMSFT
|
||||
created on: 2019-11-27
|
||||
last updated: 2020-06-16
|
||||
issue id: 1502
|
||||
---
|
||||
|
||||
# Advanced Tab Switcher
|
||||
|
||||
## Abstract
|
||||
|
||||
Currently the user is able to cycle through tabs on the tab bar. However, this horizontal cycling can be pretty inconvenient when the tab titles are long or when there are too many tabs on the tab bar. It could also get hard to see all your available tabs if the tab titles are long and your screen is small. In addition, there's a common use case to quickly switch between two tabs, e.g. when one tab is used as reference and the other is the actively worked-on tab. If the tabs are not right next to each other on the tab bar, it could be difficult to quickly swap between the two. Having the tabs displayed in Most Recently Used (MRU) order would help with this problem. It could also make the user experience better when there are a handful of tabs that are frequently used, but are nowhere near each other on the tab bar.
|
||||
|
||||
Having a tab switcher UI, like the ones in Visual Studio and Visual Studio Code, could help with the tab experience. Presenting the tabs vertically in their own little UI allows the user to see more of the tabs at once, compared to scanning the tab row horizontally and scrolling left/right to find the tab you want. The tab order in those tab switchers are also in MRU order by default.
|
||||
|
||||
To try to alleviate some of these user scenarios, we want to create a tab switcher similar to the ones found in VSCode and VS. This spec will cover the design of the switcher, and how a user would interact with the switcher. It would be primarily keyboard driven, and would give a pop-up display of a vertical list of tabs. The tab switcher would also be able to display the tabs in Most Recently Used (MRU) order.
|
||||
|
||||
## Inspiration
|
||||
|
||||
This was mainly inspired by the tab switcher that's found in Visual Studio Code and Visual Studio.
|
||||
|
||||
VS Code's tab switcher appears directly underneath the tab bar.
|
||||
|
||||
|
||||
|
||||
Visual Studio's tab switcher presents itself as a box in the middle of the editor.
|
||||
|
||||
|
||||
|
||||
In terms of navigating the switcher, both VSCode and Visual Studio behave very similarly. Both open with the press of <kbd>ctrl+tab</kbd> and dismiss on release of <kbd>ctrl</kbd>. They both also allow the user to select the tab with the mouse and with <kbd>enter</kbd>. <kbd>esc</kbd> and a mouse click outside of the switcher both dismiss the window as well.
|
||||
|
||||
I'm partial towards looking like VSCode's Tab Switcher - specifically because it seems like both their Command Palette and Tab Switcher use the same UI. You can observe this by first bringing up the command palette, then hitting the keybinding to bring up the tab switcher. You'll notice that they're both using the same centered drop-down from the tab row. In fact, hitting the Tab Switcher keybinding in VSCode while the Command Palette is open simply auto fills the search box with "edit active", signifying that the user wants to select one of the tabs to edit, effectively "swapping" to the tab that's highlighted.
|
||||
|
||||
Since Terminal now has a command palette, it would be amazing to reuse that UI and simply fill it with the names of a user's currently open tabs!
|
||||
|
||||
## Solution Design
|
||||
|
||||
To extend upon the command palette, we simply need to create and maintain two Vector<Commands>, where each command will simply dispatch a `SwitchToTab` `ShortcutAction`. One vector will have the commands in tab row order, and the other will be in MRU order. They'll both have to be maintained along with our existing vector of tabs.
|
||||
|
||||
These vectors of commands can then be set as the commands to pull from in the command palette, and as long as the tab titles are available in these commands, the command palette will be able to naturally filter through the tabs as a user types in its search bar. Just like the command palette, a user will be able to navigate through the list of tabs with the arrow keys and pointer interactions. As part of this implementation, I can supplement these actions with "tab switcher specific" navigation keybindings that would only work if the command palette is in tab switcher mode.
|
||||
|
||||
The `TabSwitcherControl` will use `TerminalPage`'s `ShortcutActionDispatch` to dispatch a `SwitchToTab` `ShortcutAction`. This will eventually cause `TerminalPage::_OnTabSelectionChanged` to be called. We can update the MRU in this function to be sure that changing tabs from the TabSwitcher, clicking on a tab, or nextTab/prevTab-ing will keep the MRU up-to-date. Adding or closing tabs are handled in `_OpenNewTab` and `_CloseFocusedTab`, which will need to be modified to update the command vectors.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
The Tab Switcher will reuse a lot of the XAML code that's used in the command palette. This means it'll show up as a drop-down from the horizontal center of the tab row. It'll appear as a single overlay over the whole Terminal window. There will also be a search box on top of the list of tabs. Here's a rough mockup of how the command palette/tab switcher looks like:
|
||||
|
||||
|
||||
|
||||
Each entry in the list will show the tab's titles and their assigned number for quick switching, and only one line will be highlighted to signify the tab that is currently selected. The top 9 tabs in the list are numbered for quick switching, and the rest of the tabs will simply have an empty space where a number would be.
|
||||
|
||||
The list would look (roughly) like this:
|
||||
```
|
||||
1 foo (highlighted)
|
||||
2 boo
|
||||
3 Windows
|
||||
4 /c/Users/booboo
|
||||
5 Git Moo
|
||||
6 shoo
|
||||
7 /c/
|
||||
8 /d/
|
||||
9 /e/
|
||||
/f/
|
||||
/g/
|
||||
/h/
|
||||
```
|
||||
|
||||
The highlighted line can move up or down, and if the user moves up while the highlighted line is already at the top of the list, the highlight will wrap around to the bottom of the list. Similarly, it will wrap to the top if the highlight is at the bottom of the list and the user moves down.
|
||||
|
||||
If there's more tabs than the UI can display, the list of tabs will scroll up/down as the user keeps iterating up/down. Even if some of the numbered tabs (the first 9 tabs) are not visible, the user can still press any number 1 through 9 to quick switch to that tab.
|
||||
|
||||
To give an example of what happens after scrolling past the end, imagine a user is starting from the state in the mock above. The user then iterates down past the end of the visible list four times. The below mock shows the result.
|
||||
|
||||
```
|
||||
5 Git Moo
|
||||
6 shoo
|
||||
7 /c/
|
||||
8 /d
|
||||
9 /e/
|
||||
/f/
|
||||
/g/
|
||||
/h/
|
||||
/i/
|
||||
/j/
|
||||
/k/
|
||||
/l/ (highlighted)
|
||||
```
|
||||
|
||||
The tabs designated by numbers 1 through 4 are no longer visible (but still quick-switchable), and the list now starts with "Git Moo", which is associated with number 5.
|
||||
|
||||
### Using the Switcher
|
||||
|
||||
#### Opening the Tab Switcher
|
||||
|
||||
The user can press a keybinding named `tabSwitcher` to bring up the command palette UI with a list of tab titles.
|
||||
The user can also bring up the command palette first, and type a "tab switcher" prefix like "@" into the search bar to switch into "tab switcher mode".
|
||||
The user will be able to change it to whatever they like.
|
||||
There will also be an optional `anchor` arg that may be provided to this keybinding.
|
||||
|
||||
#### Keeping it open
|
||||
|
||||
We use the term `anchor` to illustrate the idea that the UI stays visible as long as something is "anchoring" it down.
|
||||
|
||||
Here's an example of how to set the `anchor` key in the settings:
|
||||
```
|
||||
{"keys": ["ctrl+tab"], "command": {"action": "openTabSwitcher", "anchor": "ctrl" }}
|
||||
```
|
||||
|
||||
This user provided the `anchor` key arg, and set it to <kbd>ctrl</kbd>. So, the user would open the UI with <kbd>ctrl+tab</kbd>, and as long as the user is holding <kbd>ctrl</kbd> down, the UI won't dismiss. The moment the user releases <kbd>ctrl</kbd>, the UI dismisses. The `anchor` key needs to be one of the keys in the `openTabSwitcher` keybinding. If it isn't, we'll display a warning dialog in this case saying that the `anchor` key isn't actually part of the keybinding, and the user might run into some weird behavior.
|
||||
|
||||
If `openTabSwitcher` is not given an `anchor` key, the switcher will stay visible even after the release of the keybinding.
|
||||
|
||||
#### Switching through Tabs
|
||||
|
||||
The user will be able to navigate through the switcher with the following keybindings:
|
||||
|
||||
- Switching Down: <kbd>tab</kbd> or <kbd>downArrow</kbd>
|
||||
- Switching Up: <kbd>shift+tab</kbd> or <kbd>upArrow</kbd>
|
||||
|
||||
As the user is cycling through the tab list, the selected tab will be highlighted but the terminal won't actually switch focus to the selected tab. This also applies to pointer interaction. Hovering over an item with a mouse will highlight the item but not switch to the tab.
|
||||
|
||||
#### Closing the Switcher and Bringing a Tab into Focus
|
||||
|
||||
There are two _dismissal_ keybindings:
|
||||
|
||||
1. <kbd>enter</kbd> : brings the currently selected tab into focus and dismisses the UI.
|
||||
2. <kbd>esc</kbd> : dismisses the UI without changing tab focus.
|
||||
|
||||
The following are ways a user can dismiss the UI, _whether or not_ the `Anchor` key is provided to `openTabSwitcher`.
|
||||
|
||||
1. The user can press a number associated with a tab to instantly switch to the tab and dismiss the switcher.
|
||||
2. The user can click on a tab to instantly switch to the tab and dismiss the switcher.
|
||||
3. The user can click outside of the UI to dismiss the switcher without bringing the selected tab into focus.
|
||||
4. The user can press any of the dismissal keybindings.
|
||||
|
||||
If the `anchor` key is provided, then in addition to the above methods, the UI will dismiss upon the release of the `anchor` key.
|
||||
|
||||
Pressing the `openTabSwitcher` keychord again will not close the switcher, it'll do nothing.
|
||||
|
||||
### Most Recently Used Order
|
||||
|
||||
We'll provide a setting that will allow the list of tabs to be presented in either _in-order_ (how the tabs are ordered on the tab bar), or _Most Recently Used Order_ (MRU). MRU means that the tab that the terminal most recently visited will be on the top of the list, and the tab that the terminal has not visited for the longest time will be on the bottom.
|
||||
|
||||
There will be an argument for the `openTabSwitcher` action called `displayOrder`. This can be either `inOrder` or `mruOrder`. Making the setting an argument passed into `openTabSwitcher` would allow the user to have one keybinding to open an MRU Tab Switcher, and different one for the In-Order Tab Switcher. For example:
|
||||
```
|
||||
{"keys": ["ctrl+tab"], "command": {"action": "openTabSwitcher", "anchor":"ctrl", "displayOrder":"mruOrder"}}
|
||||
{"keys": ["ctrl+shift+p"], "command": {"action": "openTabSwitcher", "anchor":"ctrl", "displayOrder":"inOrder"}}
|
||||
```
|
||||
By default (when the arg isn't specified), `displayOrder` will be "mruOrder".
|
||||
|
||||
### Numbered Tabs
|
||||
|
||||
Similar to how the user can currently switch to a particular tab with a combination of keys such as <kbd>ctrl+shift+1</kbd>, we want to have the tab switcher provide a number to the first nine tabs (1-9) in the list for quick switching. If there are more than nine tabs in the list, then the rest of the tabs will not have a number assigned.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
- The tab switcher will be using WinUI, and so it'll be automatically linked to the UIA tree. This allows screen readers to find it, and so narrator will be able to navigate the switcher easily.
|
||||
- The UI is also fully keyboard-driven, with the option of using a mouse to interact with the UI.
|
||||
- When the tab switcher pops up, the focus immediately swaps to it.
|
||||
- For the sake of more contrast with the background, we could use a ThemeShadow to bring the UI closer to the user, making the focus clearer.
|
||||
|
||||
### Security
|
||||
|
||||
This shouldn't introduce any security issues.
|
||||
|
||||
### Reliability
|
||||
|
||||
How we're updating the MRU is something to watch out for since it triggers on a lot of tab interactions. However, I don't foresee the update taking long at all, and I can't imagine that users can create and delete tabs fast enough to matter.
|
||||
|
||||
### Compatibility
|
||||
|
||||
- The existing way of navigating horizontally through the tabs on the tab bar should not break.
|
||||
- These should also be separate keybindings from the keybindings associated with using the tab switcher.
|
||||
- When a user reorders their tabs on the tab bar, the MRU order remains unchanged. For example:
|
||||
- Tab Bar:`[cmd(focused), ps, wsl]` and MRU:`[cmd, ps, wsl]`
|
||||
- Reordered Tab Bar:`[wsl, cmd(focused), ps]` and MRU:`[cmd, ps, wsl]`
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
## Potential Issues
|
||||
|
||||
We'll need to be careful about how the UI is presented depending on different sizes of the terminal. We also should test how the UI looks as it's open and resizing is happening. Visual Studio's tab switcher is a fixed size, and is always in the middle. Even when the VS window is smaller than the tab switcher size, the tab switcher will show up larger than the VS window itself.
|
||||
|
||||
|
||||
|
||||
|
||||
Visual Studio Code only allows the user to shrink the window until it hits a minimum width and height. This minimum width and height gives its tab switcher enough space to show a meaningful amount of information.
|
||||
|
||||
|
||||
|
||||
Terminal can't really replicate Visual Studio's version of the tab switcher in this situation. The TabSwitcher needs to be contained within the Terminal. So, if the TabSwitcher is always centered and has a percentage padding from the borders of the Terminal, it'll shrink as Terminal shrinks. Since the Terminal also has a minimum width, the switcher should always have enough space to be usefully visible.
|
||||
|
||||
## Future considerations
|
||||
|
||||
### Pane Navigation
|
||||
|
||||
There was discussion in [#1502] that brought up the idea of pane navigation, inspired by tmux.
|
||||
|
||||
|
||||
|
||||
Tmux allows the user to navigate directly to a pane and even give a preview of the pane. This would be extremely useful since it would allow the user to see a tree of their open tabs and panes. Currently there's no way to see what panes are open in each tab, so if you're looking for a particular pane, you'd need to cycle through your tabs to find it. If something like pane profile names (not sure what information to present in the switcher for panes) were presented in the TabSwitcher, the user could see all the panes in one box.
|
||||
|
||||
To support pane navigation, the tab switcher can simply have another column to the right of the tab list to show a list of panes inside the selected tab. As the user iterates through the tab list, they can simply hit right to dig deeper into the tab's panes, and hit left to come back to the tab list. Each tab's list of panes will be MRU or in-order, depending on which `displayOrder` arg was provided to the `openTabSwitcher` keybinding.
|
||||
|
||||
Pane navigation is a clear next step to build on top of the tab switcher, but this spec will specifically deal with just tab navigation in order to keep the scope tight. The tab switcher implementation just needs to allow for pane navigation to be added in later.
|
||||
|
||||
### Tab Preview on Hover
|
||||
|
||||
With this feature, having a tab highlighted in the switcher would make the Terminal display that tab as if it switched to it. I believe currently there is no way to set focus to a tab in a "preview" mode. This is important because MRU updates whenever a tab is focused, but we don't want the MRU to update on a preview. Given that this feature is a "nice thing to have", I'll leave it for
|
||||
after the tab switcher has landed.
|
||||
|
||||
## Resources
|
||||
|
||||
Feature Request: An advanced tab switcher [#1502]
|
||||
Ctrl+Tab toggle between last two windows like Alt+Tab [#973]
|
||||
The Command Palette Thread [#2046]
|
||||
The Command Palette Spec [#5674]
|
||||
Feature Request: Search [#605]
|
||||
|
||||
<!-- Footnotes -->
|
||||
[#605]: https://github.com/microsoft/terminal/issues/605
|
||||
[#973]: https://github.com/microsoft/terminal/issues/973
|
||||
[#1502]: https://github.com/microsoft/terminal/issues/1502
|
||||
[#2046]: https://github.com/microsoft/terminal/issues/2046
|
||||
[#5674]: https://github.com/microsoft/terminal/pull/5674
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 233 KiB |
@@ -1,112 +0,0 @@
|
||||
---
|
||||
author: Kayla Cinnamon @cinnamon-msft
|
||||
created on: 2020-07-13
|
||||
last updated: 2020-08-11
|
||||
issue id: #1564
|
||||
---
|
||||
|
||||
# Settings UI Design
|
||||
|
||||
## Abstract
|
||||
|
||||
This design document describes how each page of the settings UI will be laid out along with design mockups to display how the UI will appear. The mock ups are for appearance purposes and some layouts and naming may be different in this doc. This doc should be considered the final say.
|
||||
|
||||
## UI Design
|
||||
|
||||
### Overall navigation with Startup page
|
||||
|
||||
This is the list of the top-level navigation items that will appear on the left nav bar:
|
||||
|
||||
- General
|
||||
- Startup
|
||||
- Interaction
|
||||
- Rendering
|
||||
- Appearance
|
||||
- Global
|
||||
- Color schemes
|
||||
- Themes*
|
||||
- Profiles
|
||||
- Defaults
|
||||
- Enumerate profiles
|
||||
- Add new
|
||||
- Keyboard
|
||||
- Mouse*
|
||||
- Command Palette*
|
||||
- Marketplace*
|
||||
|
||||
\* Themes, mouse, command palette, and marketplace will be added once they're implemented.
|
||||
|
||||
|
||||
|
||||
### Profile appearance page
|
||||
|
||||
This page requires special design because it includes the TerminalControl window to preview appearance changes. This preview window will appear on the following pages:
|
||||
|
||||
- Appearance - Color Schemes
|
||||
- Profiles - Appearance
|
||||
|
||||
|
||||
|
||||
### Keyboard page
|
||||
|
||||
The keyboard page will list the enabled key bindings and provide a way for users to add and remove them.
|
||||
|
||||
|
||||
|
||||
When someone hovers over one of the items in the table, the Edit and Delete buttons will appear. Below is what the modal looks like if they were to click Edit on a command that does not have any arguments/actions. In the future, we would want this text box to be able to listen for key combinations. This would add a "listen" button to the UI.
|
||||
|
||||
|
||||
|
||||
If the command they select has additional arguments/actions, the modal will dynamically size as arguments/actions are added.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Settings layout
|
||||
|
||||
Below is the list of all settings on their respective pages in the settings UI. The title row aligns with the navigation view on the left of the UI. Bolded headers in those columns align with top nav on the page.
|
||||
|
||||
| General - Startup | General - Interaction | General - Rendering | Appearance - Global | Appearance - Color Schemes | Profiles - Global | Profiles - Enumerate profiles | Profiles - Add new |
|
||||
| ---------------- | --------------------- | ------------------- | ------------------- | -------------------------- | ----------------- | ----------------------------- | ------------------ |
|
||||
| Default profile (dropdown) | Copy after selection is made (checkbox) | Software rendering (checkbox) | Theme (radio) | Name (text box) | **General** | **General** | **General** | **General** |
|
||||
| Launch on startup (checkbox) | Copy formatting (checkbox) | Screen redrawing (checkbox) | Show/Hide the title bar (checkbox) | Cursor color (color picker) | Command line (text box) | Scrollbar visibility (radio) | Scrollbar visibility (radio) |
|
||||
| Launch size (radio) | Word delimiters (text box) | | Show terminal title in title bar (checkbox) | Selection background (color picker) | Starting directory (browse button) | Command line (browse button) | Command line (browse button) |
|
||||
| Launch position (text box) | Window resize behavior (checkbox) | | Always show tabs (checkbox) | Background (color picker) | Icon (browse button) | Starting directory (browse button) | Starting directory (browse button) |
|
||||
| Columns on first launch (number picker) | | | Tab width mode (radio) | Foreground (color picker) | Tab title (text box) | Name (text box) | Name (text box) |
|
||||
| Rows on first launch (number picker) | | | Hide close all tabs popup (checkbox) | Black (color picker) | Scrollbar visibility (radio) | Icon (browse button) | Icon (browse button) |
|
||||
| Automatically create new profiles when new shells are installed (checkbox) | | | | Blue (color picker) | **Appearance** | Tab title (text box) | Tab title (text box) |
|
||||
| | | | | Cyan (color picker) | Font face (text box) | **Appearance** | **Appearance** |
|
||||
| | | | | Green (color picker) | Font size (number picker) | Retro terminal effects (checkbox) | Retro terminal effects (checkbox) |
|
||||
| | | | | Purple (color picker) | Font weight (dropdown) | Font face (text box) | Font face (text box) |
|
||||
| | | | | Red (color picker) | Padding (text box) | Font size (number picker) | Font size (number picker) |
|
||||
| | | | | White (color picker) | Cursor shape (radio) | Font weight (dropdown) | Font weight (dropdown) |
|
||||
| | | | | Yellow (color picker) | Cursor color (color picker) | Padding (text box) | Padding (text box) |
|
||||
| | | | | Bright black (color picker) | Cursor height (number picker) | Cursor shape (radio) | Cursor shape (radio) |
|
||||
| | | | | Bright blue (color picker) | Color scheme (dropdown) | Cursor color (color picker) | Cursor color (color picker) |
|
||||
| | | | | Bright cyan (color picker) | Foreground color (color picker) | Cursor height (number picker) | Cursor height (number picker) |
|
||||
| | | | | Bright green (color picker) | Background color (color picker) | Color scheme (dropdown) | Color scheme (dropdown) |
|
||||
| | | | | Bright purple (color picker) | Selection background color (color picker) | Foreground color (color picker) | Foreground color (color picker) |
|
||||
| | | | | Bright red (color picker) | Enable acrylic (checkbox) | Background color (color picker) | Background color (color picker) |
|
||||
| | | | | Bright white (color picker) | Acrylic opacity (number picker) | Selection background color (color picker) | Selection background color (color picker) |
|
||||
| | | | | Bright yellow (color picker) | Background image (browse button) | Enable acrylic (checkbox) | Enable acrylic (checkbox) |
|
||||
| | | | | | Background image stretch mode (radio) | Acrylic opacity (number picker) | Acrylic opacity (number picker) |
|
||||
| | | | | | Background image alignment (dropdown) | Background image (browse button) | Background image (browse button) |
|
||||
| | | | | | Background image opacity (number picker) | Background image stretch mode (radio) | Background image stretch mode (radio) |
|
||||
| | | | | | Retro terminal effects (checkbox) | Background image alignment (dropdown) | Background image alignment (dropdown) |
|
||||
| | | | | | **Advanced** | Background image opacity (number picker) | Background image opacity (number picker) |
|
||||
| | | | | | Hide profile from dropdown (checkbox) | **Advanced** | **Advanced** |
|
||||
| | | | | | Suppress title changes (checkbox) | GUID (text box) | GUID (text box) |
|
||||
| | | | | | Antialiasing text (radio) | Hide profile from dropdown (checkbox) | Hide profile from dropdown (checkbox) |
|
||||
| | | | | | AltGr aliasing (checkbox) | Suppress title changes (checkbox) | Suppress title changes (checkbox) |
|
||||
| | | | | | Scroll to input when typing (checkbox) | Antialiasing text (radio) | Antialiasing text (radio) |
|
||||
| | | | | | History size (number picker) | AltGr aliasing (checkbox) | AltGr aliasing (checkbox) |
|
||||
| | | | | | How the profile closes (radio) | Scroll to input when typing (checkbox) | Scroll to input when typing (checkbox) |
|
||||
| | | | | | | History size (number picker) | History size (number picker) |
|
||||
| | | | | | | How the profile closes (radio) | How the profile closes (radio) |
|
||||
|
||||
## Potential Issues
|
||||
|
||||
## Future considerations
|
||||
|
||||
## Resources
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 172 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 173 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 171 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 170 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 181 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
@@ -1,122 +0,0 @@
|
||||
---
|
||||
author: Kayla Cinnamon @cinnamon-msft
|
||||
created on: 2020-06-29
|
||||
last updated: 2020-08-10
|
||||
issue id: #1564
|
||||
---
|
||||
|
||||
# Settings UI Implementation
|
||||
|
||||
## Abstract
|
||||
|
||||
This spec describes the basic functionality of the settings UI, including disabling it, the navigation items, launch methods, and editing of settings. The specific layout of each page will defined in later design reviews.
|
||||
|
||||
## Inspiration
|
||||
|
||||
We have been wanting a settings UI since the dawn of Terminal time, so we need to define how it will interact with the application and how users should expect to interact with it.
|
||||
|
||||
## Solution Design
|
||||
|
||||
The settings UI will be the default experience. We will provide users an option to skip the settings UI and edit the raw JSON file.
|
||||
|
||||
### Ability to disable displaying the settings UI
|
||||
|
||||
Some users don't want a UI for the settings. We can update the `openSettings` key binding with a `settingsUI` option.
|
||||
|
||||
If people still like the UI but want to access the JSON file, we can provide an "Open the JSON file" button at the bottom of the navigation menu.
|
||||
|
||||
### Launch method: launch in a new tab
|
||||
|
||||
Clicking the settings button in the dropdown menu will open the settings UI in a new tab. This helps us take steps toward supporting non-terminal content in a tab. Users will be able to see their visual changes by using the preview window inside the settings UI on relevant pages.
|
||||
|
||||
#### We also considered: launch in a new window
|
||||
|
||||
Clicking the settings button in the dropdown menu will open the settings UI in a new window. This allows the user to edit their settings and see the Terminal live update with their changes.
|
||||
|
||||
In the Windows taskbar, the icon will appear as if Terminal has multiple windows open.
|
||||
|
||||
### Editing and saving settings: implement a save button
|
||||
|
||||
Users will only see their settings changes take place once they click "Save". Clicking "Save" will write to the settings.json file. This aligns with the functionality that exists today by editing the settings.json file in a text editor and saving it.
|
||||
|
||||
We will also be adding a TerminalControl inside the settings UI to preview what the changes will look like before actually saving them to the settings.json file.
|
||||
|
||||
#### We also considered: automatically save settings
|
||||
|
||||
As users edit fields in the settings UI, they are automatically saved and written to the JSON file. This allows the user to see their settings changes taking place in real time.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
Layout of all of the settings per page can be found in the [design doc](./design.md).
|
||||
|
||||
### Top-level navigation: more descriptive navigation
|
||||
|
||||
The navigation menu is broken up into more digestible sections. This aligns more closely to other terminals. The following are the proposed navigation items:
|
||||
|
||||
- General
|
||||
- Startup
|
||||
- Interaction
|
||||
- Rendering
|
||||
- Appearance
|
||||
- Global
|
||||
- Color schemes
|
||||
- Themes*
|
||||
- Profiles
|
||||
- Defaults
|
||||
- Enumerate profiles
|
||||
- Add new
|
||||
- Keyboard
|
||||
- Mouse*
|
||||
- Command Palette*
|
||||
- Marketplace*
|
||||
|
||||
\* Themes, mouse, command palette, and marketplace will be added once they're implemented.
|
||||
|
||||
|
||||
|
||||
#### We also considered: align with JSON
|
||||
|
||||
The settings UI could have top-level navigation that aligns with the overall structure of the settings.json file. The following are the proposed navigation items:
|
||||
|
||||
- Globals
|
||||
- Profiles
|
||||
- Color schemes
|
||||
- Bindings
|
||||
|
||||
For Bindings, it would have key bindings, mouse bindings, and command palette inside it.
|
||||
|
||||
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
This will have to undergo full accessibility testing because it is a new UI element. All items inside the settings UI should be accessible by a screen reader and the keyboard. Additionally, all of the settings UI will have to be localized.
|
||||
|
||||
### Security
|
||||
|
||||
This does not impact security.
|
||||
|
||||
### Reliability
|
||||
|
||||
This will not improve reliability.
|
||||
|
||||
### Compatibility
|
||||
|
||||
This will change the default experience to open the UI, rather than the JSON file in a text editor. This behavior can be reverted with the setting listed [above](#ability-to-disable-displaying-the-settings-ui).
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
This does not affect performance, power, nor efficiency.
|
||||
|
||||
## Potential Issues
|
||||
|
||||
## Future considerations
|
||||
|
||||
- We will have to have design reviews for all of the content pages.
|
||||
- The `hidden` property will need special consideration. Ideally, all profiles will appear in the settings regardless if `hidden` is set to `true`.
|
||||
- We should have undo functionality. In a text editor, you can type `Ctrl+Z` however the settings UI is a bit more complex.
|
||||
- Once we have a marketplace for themes and extensions, this should be added to the top-level navigation.
|
||||
- As we add more features, the top-level navigation is subject to change in favor of improved usability.
|
||||
|
||||
## Resources
|
||||
@@ -1,300 +0,0 @@
|
||||
---
|
||||
author: Mike Griese @zadjii-msft
|
||||
created on: 2020-5-13
|
||||
last updated: 2020-08-04
|
||||
issue id: 1571
|
||||
---
|
||||
|
||||
# New Tab Menu Customization
|
||||
|
||||
## Abstract
|
||||
|
||||
Many users have lots and _lots_ of profiles that they use. Some of these
|
||||
profiles the user might not use that frequently. When that happens, the new tab
|
||||
dropdown can become quite cluttered.
|
||||
|
||||
A common ask is for the ability to reorder and reorganize this dropdown. This
|
||||
spec provides a design for how the user might be able to specify the
|
||||
customization in their settings.
|
||||
|
||||
## Inspiration
|
||||
|
||||
Largely, this spec was inspired by discussion in
|
||||
[#1571](https://github.com/microsoft/terminal/issues/1571#issuecomment-519504048)
|
||||
and the _many_ linked threads.
|
||||
|
||||
## Solution Design
|
||||
|
||||
This design proposes adding a new setting `"newTabMenu"`. When unset, (the
|
||||
default), the new tab menu is populated with all the profiles, in the order they
|
||||
appear in the users settings file. When set, this enables the user to control
|
||||
the appearance of the new tab dropdown. Let's take a look at an example:
|
||||
|
||||
```json
|
||||
{
|
||||
"profiles":{ ... },
|
||||
"newTabMenu": [
|
||||
{ "type":"profile", "profile": "cmd" },
|
||||
{ "type":"profile", "profile": "Windows PowerShell" },
|
||||
{ "type":"separator" },
|
||||
{
|
||||
"type":"folder",
|
||||
"name": "ssh",
|
||||
"icon": "C:\\path\\to\\icon.png",
|
||||
"entries":[
|
||||
{ "type":"profile", "profile": "Host 1" },
|
||||
{ "type":"profile", "profile": "8.8.8.8" },
|
||||
{ "type":"profile", "profile": "Host 2" }
|
||||
]
|
||||
},
|
||||
{ "type":"separator" },
|
||||
{ "type":"profile", "profile": "Ubuntu-18.04" },
|
||||
{ "type":"profile", "profile": "Fedora" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
If a user were to use this as their new tab menu, that they would get is a menu
|
||||
that looks like this:
|
||||
|
||||
|
||||
|
||||
_fig 1_: A _very rough_ mockup of what this feature might look like
|
||||
|
||||
There are five `type`s of objects in this menu:
|
||||
* `"type":"profile"`: This is a profile. Clicking on this entry will open a new
|
||||
tab, with that profile. The profile is identified with the `"profile"`
|
||||
parameter, which accepts either a profile `name` or GUID. The icon for this
|
||||
entry will be the profile's icon, and the text on the entry will be the
|
||||
profile's name.
|
||||
* `"type":"separator"`: This represents a XAML `MenuFlyoutSeparator`, enabling
|
||||
the user to visually space out entries.
|
||||
* `"type":"folder"`: This represents a nested menu of entries.
|
||||
- The `"name"` property provides a string of text to display for the group.
|
||||
- The `"icon"` property provides a path to a image to use as the icon. This
|
||||
property is optional.
|
||||
- The `"entries"` property specifies a list of menu entries that will appear
|
||||
nested under this entry. This can contain other `"type":"folder"` groups as
|
||||
well!
|
||||
* `"type":"action"`: This represents a menu entry that should execute a specific
|
||||
`ShortcutAction`.
|
||||
- the `id` property will specify the global action ID (see [#6899], [#7175])
|
||||
to identify the action to perform when the user selects the entry. Actions
|
||||
with invalid IDs will be ignored and omitted from the list.
|
||||
- The text for this entry will be the action's label (which is
|
||||
either provided as the `"name"` in the global list of actions, or the
|
||||
generated name if no `name` was provided)
|
||||
- The icon for this entry will similarly re-use the action's `icon`.
|
||||
* `"type":"remainingProfiles"`: This is a special type of entry that will be
|
||||
expanded to contain one `"type":"profile"` entry for every profile that was
|
||||
not already listed in the menu. This will allow users to add one entry for
|
||||
just "all the profiles they haven't manually added to the menu".
|
||||
- This type of entry can only be specified once - trying to add it to the menu
|
||||
twice will raise a warning, and ignore all but the first `remainingProfiles`
|
||||
entry.
|
||||
- This type of entry can also be set inside a `folder` entry, allowing users
|
||||
to highlight only a couple profiles in the top-level of the menu, but
|
||||
enabling all other profiles to also be accessible.
|
||||
- The "name" of these entries will simply be the name of the profile
|
||||
- The "icon" of these entries will simply be the profile's icon
|
||||
|
||||
The "default" new tab menu could be imagined as the following blob of json:
|
||||
|
||||
```json
|
||||
{
|
||||
"newTabMenu": [
|
||||
{ "type":"remainingProfiles" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Other considerations
|
||||
|
||||
Also considered during the investigation for this feature was re-using the list
|
||||
of profiles to expose the structure of the new tab menu. For example, doing
|
||||
something like:
|
||||
|
||||
```json
|
||||
"profiles": {
|
||||
"defaults": {},
|
||||
"list":
|
||||
[
|
||||
{ "name": "cmd" },
|
||||
{ "name": "powershell" },
|
||||
{ "type": "separator" },
|
||||
{
|
||||
"type": "folder" ,
|
||||
"profiles": [
|
||||
{ "name": "ubuntu" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This option was not pursued because we felt that it needlessly complicated the
|
||||
contents of the list of profiles objects. We'd rather have the `profiles` list
|
||||
exclusively contain `Profile` objects, and have other elements of the json
|
||||
_refer_ to those profiles. What if someone would like to have an action that
|
||||
opened a new tab with profile index 4, and then they set that action as entry 4
|
||||
in the profile's list? That would certainly be some sort of unexpected behavior.
|
||||
|
||||
Additionally, what if someone wants to have an entry that opens a tab with one
|
||||
pane with one profile in it, and another pane with different profile in it? Or
|
||||
what if they want the same profile to appear twice in the menu?
|
||||
|
||||
By overloading the structure of the `profiles` list, we're forcing all other
|
||||
consumers of the list of profiles to care about the structure of the elements of
|
||||
the list. These other consumers should only really care about the list of
|
||||
profiles, and not necessarily how they're structured in the new tab dropdown.
|
||||
Furthermore, it complicates the list of profiles, by adding actions intermixed
|
||||
with the profiles.
|
||||
|
||||
The design chosen in this spec more cleanly separates the responsibilities of
|
||||
the list of profiles and the contents of the new tab menu. This way, each object
|
||||
can be defined independent of the structure of the other.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
See the above _figure 1_.
|
||||
|
||||
The profile's `icon` will also appear as the icon on `profile` entries. If
|
||||
there's a keybinding bound to open a new tab with that profile, then that will
|
||||
also be added to the `MenuFlyoutItem` as the accelerator text, similar to the
|
||||
text we have nowadays.
|
||||
|
||||
Beneath the list of profiles will _always_ be the same "Settings", "Feedback"
|
||||
and "About" entries, separated by a `MenuFlyoutSeparator`. This is consistent
|
||||
with the UI as it exists with no customization. These entries cannot be removed
|
||||
with this feature, only the list of profiles customized.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
This menu will be added to the XAML tree in the same fashion as the current new
|
||||
tab flyout, so there should be no dramatic change here.
|
||||
|
||||
### Security
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Reliability
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Compatibility
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
## Potential Issues
|
||||
|
||||
Currently, the `openTab` and `splitPane` keybindings will accept a `index`
|
||||
parameter to say either:
|
||||
* "Create a new tab/pane with the N'th profile"
|
||||
* "Create a new tab/pane with the profile at index N in the new
|
||||
tab dropdown".
|
||||
|
||||
These two were previously synonymous, as the N'th profile was always the N'th in
|
||||
the dropdown. However, with this change, we'll be changing the meaning of that
|
||||
argument to mean explicitly the first option - "Open a tab/pane with the N'th
|
||||
profile".
|
||||
|
||||
A previous version of this spec considered changing the meaning of that
|
||||
parameter to mean "open the entry at index N", the second option. However, in
|
||||
[Command Palette, Addendum 1], we found that naming that command would become
|
||||
unnecessarily complex.
|
||||
|
||||
To cover that above scenario, we could consider adding an `index` parameter to
|
||||
the `openNewTabDropdown` action. If specified, that would open either the N'th
|
||||
action in the dropdown (ignoring separators), or open the dropdown with the n'th
|
||||
item selected.
|
||||
|
||||
The N'th entry in the menu won't always be a profile: it might be a folder with
|
||||
more options, or it might be an action (that might not be opening a new tab/pane
|
||||
at all).
|
||||
|
||||
Given all the above scenarios, `openNewTabDropdown` with an `"index":N`
|
||||
parameter will behave in the following ways. If the Nth top-level entry in the
|
||||
new tab menu is a:
|
||||
* `"type":"profile"`: perform the `newTab` or `splitPane` action with that profile.
|
||||
* `"type":"folder"`: Focus the first element in the sub menu, so the user could
|
||||
navigate it with the keyboard.
|
||||
* `"type":"separator"`: Ignore these when counting top-level entries.
|
||||
* `"type":"action"`: Perform the action.
|
||||
|
||||
So for example:
|
||||
|
||||
```
|
||||
New Tab Button ▽
|
||||
├─ Folder 1
|
||||
│ └─ Profile A
|
||||
│ └─ Action B
|
||||
├─ Separator
|
||||
├─ Folder 2
|
||||
│ └─ Profile C
|
||||
│ └─ Profile D
|
||||
├─ Action E
|
||||
└─ Profile F
|
||||
```
|
||||
|
||||
And assuming the user has bound:
|
||||
```json
|
||||
{
|
||||
"bindings":
|
||||
[
|
||||
{ "command": { "action": "openNewTabDropdown", "index": 0 }, "keys": "ctrl+shift+1" },
|
||||
{ "command": { "action": "openNewTabDropdown", "index": 1 }, "keys": "ctrl+shift+2" },
|
||||
{ "command": { "action": "openNewTabDropdown", "index": 2 }, "keys": "ctrl+shift+3" },
|
||||
{ "command": { "action": "openNewTabDropdown", "index": 3 }, "keys": "ctrl+shift+4" },
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
* <kbd>ctrl+shift+1</kbd> focuses "Profile A", but the user needs to press
|
||||
enter/space to creates a new tab/split
|
||||
* <kbd>ctrl+shift+2</kbd> focuses "Profile C", but the user needs to press
|
||||
enter/space to creates a new tab/split
|
||||
* <kbd>ctrl+shift+3</kbd> performs Action E
|
||||
* <kbd>ctrl+shift+4</kbd> Creates a new tab/split with Profile F
|
||||
|
||||
## Future considerations
|
||||
|
||||
* The user could set a `"name"`/`"text"`, or `"icon"` property to these menu
|
||||
items manually, to override the value from the profile or action. These
|
||||
settings would be totally optional, but it's not unreasonable that someone
|
||||
might want this.
|
||||
* We may want to consider adding a default icon for all folders or actions in
|
||||
the menu. For example, a folder (like 📁) for `folder` entries, or something
|
||||
like ⚡ for actions. We'll leave these unset by default, and evaluate setting
|
||||
these icons by default in the future.
|
||||
* Something considered during review was a way to specify "All my WSL profiles".
|
||||
Maybe the user wants to have all their profiles generated by the WSL Distro
|
||||
Generator appear in a "WSL" folder. This would likely require a more elaborate
|
||||
filtering syntax, to be able to select only profiles where a certain property
|
||||
has a specific value. Consider the user who has multiple "SSH
|
||||
me@\<some host\>.com" profiles, and they want all their "SSH\*" profiles to
|
||||
appear in an "SSH" folder. This feels out-of-scope for this spec.
|
||||
* A similar structure could potentially also be used for customizing the context
|
||||
menu within a control, or the context menu for the tab. (see [#3337])
|
||||
- In both of those cases, it might be important to somehow refer to the
|
||||
context of the current tab or control in the json. Think for example about
|
||||
"Close tab" or "Close other tabs" - currently, those work by _knowing_ which
|
||||
tab the "action" is specified for, not by actually using a `closeTab` action.
|
||||
In the future, they might need to be implemented as something like
|
||||
- Close Tab: `{ "action": "closeTab", "index": "${selectedTab.index}" }`
|
||||
- Close Other Tabs: `{ "action": "closeTabs", "otherThan": "${selectedTab.index}" }`
|
||||
- Close Tabs to the Right: `{ "action": "closeTabs", "after": "${selectedTab.index}" }`
|
||||
|
||||
|
||||
<!-- Footnotes -->
|
||||
[#2046]: https://github.com/microsoft/terminal/issues/2046
|
||||
[Command Palette, Addendum 1]: https://github.com/microsoft/terminal/blob/main/doc/specs/%232046%20-%20Unified%20keybindings%20and%20commands%2C%20and%20synthesized%20action%20names.md
|
||||
|
||||
[#3337]: https://github.com/microsoft/terminal/issues/3337
|
||||
[#6899]: https://github.com/microsoft/terminal/issues/6899
|
||||
[#7175]: https://github.com/microsoft/terminal/issues/7175
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
@@ -1,795 +0,0 @@
|
||||
---
|
||||
author: Mike Griese @zadjii-msft
|
||||
created on: 2019-08-01
|
||||
last updated: 2020-06-16
|
||||
issue id: 2046
|
||||
---
|
||||
|
||||
# Command Palette
|
||||
|
||||
## Abstract
|
||||
|
||||
This spec covers the addition of a "command palette" to the Windows Terminal.
|
||||
The Command Palette is a GUI that the user can activate to search for and
|
||||
execute commands. Beneficially, the command palette allows the user to execute
|
||||
commands _even if they aren't bound to a keybinding_.
|
||||
|
||||
## Inspiration
|
||||
|
||||
This feature is largely inspired by the "Command Palette" in text editors like
|
||||
VsCode, Sublime Text and others.
|
||||
|
||||
This spec was initially drafted in [a
|
||||
comment](https://github.com/microsoft/terminal/issues/2046#issuecomment-514219791)
|
||||
in [#2046]. That was authored during the annual Microsoft Hackathon, where I
|
||||
proceeded to prototype the solution. This spec is influenced by things I learned
|
||||
prototyping.
|
||||
|
||||
Initially, the command palette was designed simply as a method for executing
|
||||
certain actions that the user pre-defined. With the addition of [commandline
|
||||
arguments](https://github.com/microsoft/terminal/issues/4632) to the Windows
|
||||
Terminal in v0.9, we also considered what it might mean to be able to have the
|
||||
command palette work as an effective UI not only for dispatching pre-defined
|
||||
commands, but also `wt.exe` commandlines to the current terminal instance.
|
||||
|
||||
## Solution Design
|
||||
|
||||
Fundamentally, we need to address two different modes of using the command palette:
|
||||
* In the first mode, the command palette can be used to quickly look up
|
||||
pre-defined actions and dispatch them. We'll refer to this as "Action Mode".
|
||||
* The second mode allows the user to run `wt` commandline commands and have them
|
||||
apply immediately to the current Terminal window. We'll refer to this as
|
||||
"commandline mode".
|
||||
|
||||
Both these options will be discussed in detail below.
|
||||
|
||||
### Action Mode
|
||||
|
||||
We'll introduce a new top-level array to the user settings, under the key
|
||||
`commands`. `commands` will contain an array of commands, each with the
|
||||
following schema:
|
||||
|
||||
```js
|
||||
{
|
||||
"name": string|object,
|
||||
"action": string|object,
|
||||
"icon": string
|
||||
}
|
||||
```
|
||||
|
||||
Command names should be human-friendly names of actions, though they don't need
|
||||
to necessarily be related to the action that it fires. For example, a command
|
||||
with `newTab` as the action could have `"Open New Tab"` as the name.
|
||||
|
||||
The command will be parsed into a new class, `Command`:
|
||||
|
||||
```c++
|
||||
class Command
|
||||
{
|
||||
winrt::hstring Name();
|
||||
winrt::TerminalApp::ActionAndArgs ActionAndArgs();
|
||||
winrt::hstring IconSource();
|
||||
}
|
||||
```
|
||||
|
||||
We'll add another structure in GlobalAppSettings to hold all these actions. It
|
||||
will just be a `std::vector<Command>` in `GlobalAppSettings`.
|
||||
|
||||
We'll need app to be able to turn this vector into a `ListView`, or similar, so
|
||||
that we can display this list of actions. Each element in the view will be
|
||||
intrinsically associated with the `Command` object it's associated with. In
|
||||
order to support this, we'll make `Command` a winrt type that implements
|
||||
`Windows.UI.Xaml.Data.INotifyPropertyChanged`. This will let us bind the XAML
|
||||
element to the winrt type.
|
||||
|
||||
When an element is clicked on in the list of commands, we'll raise the event
|
||||
corresponding to that `ShortcutAction`. `AppKeyBindings` already does a great
|
||||
job of dispatching `ShortcutActions` (and their associated arguments), so we'll
|
||||
re-use that. We'll pull the basic parts of dispatching `ActionAndArgs`
|
||||
callbacks into another class, `ShortcutActionDispatch`, with a single
|
||||
`DoAction(ActionAndArgs)` method (and events for each action).
|
||||
`AppKeyBindings` will be initialized with a reference to the
|
||||
`ShortcutActionDispatch` object, so that it can call `DoAction` on it.
|
||||
Additionally, by having a singular `ShortcutActionDispatch` instance, we won't
|
||||
need to re-hook up the ShortcutAction keybindings each time we re-load the
|
||||
settings.
|
||||
|
||||
In `TerminalPage`, when someone clicks on an item in the list, we'll get the
|
||||
`ActionAndArgs` associated with that list element, and call `DoAction` on
|
||||
the app's `ShortcutActionDispatch`. This will trigger the event handler just the
|
||||
same as pressing the keybinding.
|
||||
|
||||
#### Commands for each profile?
|
||||
|
||||
[#3879] Is a request for being able to launch a profile directly, via the
|
||||
command palette. Essentially, the user will type the name of a profile, and hit
|
||||
enter to launch that profile. I quite like this idea, but with the current spec,
|
||||
this won't work great. We'd need to manually have one entry in the command
|
||||
palette for each profile, and every time the user adds a profile, they'd need to
|
||||
update the list of commands to add a new entry for that profile as well.
|
||||
|
||||
This is a fairly complicated addition to this feature, so I'd hold it for
|
||||
"Command Palette v2", though I believe it's solution deserves special
|
||||
consideration from the outset.
|
||||
|
||||
I suggest that we need a mechanism by which the user can specify a single
|
||||
command that would be expanded to one command for every profile in the list of
|
||||
profiles. Consider the following sample:
|
||||
|
||||
```json
|
||||
"commands": [
|
||||
{
|
||||
"expandOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": "New Tab with ${profile.name}",
|
||||
"command": { "action": "newTab", "profile": "${profile.name}" }
|
||||
},
|
||||
{
|
||||
"expandOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": "New Vertical Split with ${profile.name}",
|
||||
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
|
||||
}
|
||||
],
|
||||
```
|
||||
|
||||
In this example:
|
||||
* The `"expandOn": "profiles"` property indicates that each command should be
|
||||
repeated for each individual profile.
|
||||
* The `${profile.name}` value is treated as "when expanded, use the given
|
||||
profile's name". This allows each command to use the `name` and `icon`
|
||||
properties of a `Profile` to customize the text of the command.
|
||||
|
||||
To ensure that this works correctly, we'll need to make sure to expand these
|
||||
commands after all the other settings have been parsed, presumably in the
|
||||
`Validate` phase. If we do it earlier, it's possible that not all the profiles
|
||||
from various sources will have been added yet, which would lead to an incomplete
|
||||
command list.
|
||||
|
||||
We'll need to have a placeholder property to indicate that a command should be
|
||||
expanded for each `Profile`. When the command is first parsed, we'll leave the
|
||||
format strings `${...}` unexpanded at this time. Then, in the validate phase,
|
||||
when we encounter a `"expandOn": "profiles"` command, we'll remove it from the
|
||||
list, and use it as a prototype to generate commands for every `Profile` in our
|
||||
profiles list. We'll do a string find-and-replace on the format strings to
|
||||
replace them with the values from the profile, before adding the completed
|
||||
command to the list of commands.
|
||||
|
||||
Of course, how does this work with localization? Considering the [section
|
||||
below](#localization), we'd update the built-in commands to the following:
|
||||
|
||||
```json
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "NewTabWithProfileCommandName" },
|
||||
"command": { "action": "newTab", "profile": "${profile.name}" }
|
||||
},
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "NewVerticalSplitWithProfileCommandName" },
|
||||
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
|
||||
}
|
||||
],
|
||||
```
|
||||
|
||||
In this example, we'll look up the `NewTabWithProfileCommandName` resource when
|
||||
we're first parsing the command, to find a string similar to `"New Tab with
|
||||
${profile.name}"`. When we then later expand the command, we'll see the
|
||||
`${profile.name}` bit from the resource, and expand that like we normally would.
|
||||
|
||||
Trickily, we'll need to make sure to have a helper for replacing strings like
|
||||
this that can be used for general purpose arg parsing. As you can see, the
|
||||
`profile` property of the `newTab` command also needs the name of the profile.
|
||||
Either the command validation will need to go through and update these strings
|
||||
manually, or we'll need another of enabling these `IActionArgs` classes to fill
|
||||
those parameters in based on the profile being used. Perhaps the command
|
||||
pre-expansion could just stash the json for the action, then expand it later?
|
||||
This implementation detail is why this particular feature is not slated for
|
||||
inclusion in an initial Command Palette implementation.
|
||||
|
||||
From initial prototyping, it seems like the best solution will be to stash the
|
||||
command's original json around when parsing an expandable command like the above
|
||||
examples. Then, we'll handle the expansion in the settings validation phase,
|
||||
after all the profiles and color schemes have been loaded.
|
||||
|
||||
For each profile, we'll need to replace all the instances in the original json
|
||||
of strings like `${profile.name}` with the profile's name to create a new json
|
||||
string. We'll attempt to parse that new string into a new command to add to the
|
||||
list of commands.
|
||||
|
||||
### Commandline Mode
|
||||
|
||||
One of our more highly requested features is the ability to run a `wt.exe`
|
||||
commandline in the current WT window (see [#4472]). Typically, users want the
|
||||
ability to do this straight from whatever shell they're currently running.
|
||||
However, we don't really have an effective way currently to know if WT is itself
|
||||
being called from another WT instance, and passing those arguments to the
|
||||
hosting WT. Furthermore, in the long term, we see that feature as needing the
|
||||
ability to not only run commands in the current WT window, but an _arbitrary_ WT
|
||||
window.
|
||||
|
||||
The Command Palette seems like a natural fit for a stopgap measure while we
|
||||
design the correct way to have a `wt` commandline apply to the window it's
|
||||
running in.
|
||||
|
||||
In Commandline Mode, the user can simply type a `wt.exe` commandline, and when
|
||||
they hit enter, we'll parse the commandline and dispatch it _to the current
|
||||
window_. So if the user wants to open a new tab, they could type `new-tab` in
|
||||
Commandline Mode, and it would open a new tab in the current window. They're
|
||||
also free to chain multiple commands like they can with `wt` from a shell - by
|
||||
entering something like `split-pane -p "Windows PowerShell" ; split-pane -H
|
||||
wsl.exe`, the terminal would execute two `SplitPane` actions in the currently
|
||||
focused pane, creating one with the "Windows PowerShell" profile and another
|
||||
with the default profile running `wsl` in it.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
We'll add another action that can be used to toggle the visibility of the
|
||||
command palette. Pressing that keybinding will bring up the command palette. We
|
||||
should make sure to add a argument to this action that specifies whether the
|
||||
palette should be opened directly in Action Mode or Commandline Mode.
|
||||
|
||||
When the command palette appears, we'll want it to appear as a single overlay
|
||||
over all of the panes of the Terminal. The drop-down will be centered
|
||||
horizontally, dropping down from the top (from the tab row). When commands are
|
||||
entered, it will be implied that they are delivered to the focused terminal
|
||||
pane. This will help avoid two problematic scenarios that could arise from
|
||||
having the command palette attached to a single pane:
|
||||
* When attached to a single pane, it might be very easy for the UI to quickly
|
||||
become cluttered, especially at smaller pane sizes.
|
||||
* This avoids the "find the overlay problem" which is common in editors like
|
||||
VS where the dialog appears attached to the active editor pane.
|
||||
|
||||
The palette will consist of two main UI elements: a text box for
|
||||
entering/searching for commands, and in action mode, a list of commands.
|
||||
|
||||
### Action Mode
|
||||
|
||||
The list of commands will be populated with all the commands by default. Each
|
||||
command will appear like a `MenuFlyoutItem`, with an icon at the left (if it has
|
||||
one) and the name visible. When opened, the palette will automatically highlight
|
||||
the first entry in the list.
|
||||
|
||||
The user can navigate the list of entries with the arrow keys. Hitting enter
|
||||
will close the palette and execute the action that's highlighted. Hitting escape
|
||||
will dismiss the palette, returning control to the terminal. When the palette is
|
||||
closed for any reason (executing a command, dismissing with either escape or the
|
||||
`toggleCommandPalette` keybinding), we'll clear out any search text from the
|
||||
palette, so the user can start fresh again.
|
||||
|
||||
We'll also want to enable the command palette to be filterable, so that the user
|
||||
can type the name of a command, and the command palette will automatically
|
||||
filter the list of commands. This should be more powerful then just a simple
|
||||
string compare - the user should be able to type a search string, and get all
|
||||
the commands that match a "fuzzy search" for that string. This will allow users
|
||||
to find the command they're looking for without needing to type the entire
|
||||
command.
|
||||
|
||||
For example, consider the following list of commands:
|
||||
|
||||
```json
|
||||
"commands": [
|
||||
{ "icon": null, "name": "New Tab", "action": "newTab" },
|
||||
{ "icon": null, "name": "Close Tab", "action": "closeTab" },
|
||||
{ "icon": null, "name": "Close Pane", "action": "closePane" },
|
||||
{ "icon": null, "name": "[-] Split Horizontal", "action": { "action": "splitPane", "split": "horizontal" } },
|
||||
{ "icon": null, "name": "[ | ] Split Vertical", "action": { "action": "splitPane", "split": "vertical" } },
|
||||
{ "icon": null, "name": "Next Tab", "action": "nextTab" },
|
||||
{ "icon": null, "name": "Prev Tab", "action": "prevTab" },
|
||||
{ "icon": null, "name": "Open Settings", "action": "openSettings" },
|
||||
{ "icon": null, "name": "Open Media Controls", "action": "openTestPane" }
|
||||
],
|
||||
```
|
||||
|
||||
* "open" should return both "**Open** Settings" and "**Open** Media Controls".
|
||||
* "Tab" would return "New **Tab**", "Close **Tab**", "Next **Tab**" and "Prev
|
||||
**Tab**".
|
||||
* "P" would return "Close **P**ane", "[-] S**p**lit Horizontal", "[ | ]
|
||||
S**p**lit Vertical", "**P**rev Tab", "O**p**en Settings" and "O**p**en Media
|
||||
Controls".
|
||||
* Even more powerfully, "sv" would return "[ | ] Split Vertical" (by matching
|
||||
the **S** in "Split", then the **V** in "Vertical"). This is a great example
|
||||
of how a user could execute a command with very few keystrokes.
|
||||
|
||||
As the user types, we should **bold** each matching character in the command
|
||||
name, to show how their input correlates to the results on screen.
|
||||
|
||||
Additionally, it will be important for commands in the action list to display
|
||||
the keybinding that's bound to them, if there is one.
|
||||
|
||||
### Commandline Mode
|
||||
|
||||
Commandline mode is much simpler. In this mode, we'll simply display a text input,
|
||||
similar to the search box that's rendered for Action Mode. In this box, the
|
||||
user will be able to type a `wt.exe` style commandline. The user does not need
|
||||
to start this commandline with `wt` (or `wtd`, etc) - since we're already
|
||||
running in WT, the user shouldn't really need to repeat themselves.
|
||||
|
||||
When the user hits <kbd>enter</kbd>, we'll attempt to parse the commandline. If
|
||||
we're successful in parsing the commandline, we can close the palette and
|
||||
dispatch the commandline. If the commandline had errors, we should reveal a text
|
||||
box with an error message below the text input. We'll leave the palette open
|
||||
with their entered command, so they can edit the commandline and try again. We
|
||||
should _probably_ leave the message up for a few seconds once they've begun
|
||||
editing the commandline, but eventually hide the message (ideally with a motion
|
||||
animation).
|
||||
|
||||
### Switching Between Modes
|
||||
|
||||
**TODO**: This is a topic for _discussion_.
|
||||
|
||||
How do we differentiate Action Mode from Commandline Mode?
|
||||
|
||||
I think there should be a character that the user types that switches the mode.
|
||||
This is reminiscent of how the command palette works in applications like VsCode
|
||||
and Sublime Text. The same UI is used for a number of functions. In the case of
|
||||
VsCode, when the user opens the palette, it's initially in a "navigate to file"
|
||||
mode. When the user types the prefix character `@`, the menu seamlessly switches
|
||||
to a "navigate to symbol mode". Similarly, users can use `:` for "go to line"
|
||||
and `>` enters an "editor command" mode.
|
||||
|
||||
I believe we should use a similarly implemented UI. The UI would be in one of
|
||||
the two modes by default, and typing the prefix character would enter the other
|
||||
mode. If the user deletes the prefix character, then we'd switch back into the
|
||||
default mode.
|
||||
|
||||
When the user is in Action Mode vs Commandline mode, if the input is empty
|
||||
(besides potentially the prefix character), we should probably have some sort of
|
||||
placeholder text visible to indicate which mode the user is in. Something like
|
||||
_"Enter a command name..."_ for action mode, or _"Type a wt commandline..."_ for
|
||||
commandline mode.
|
||||
|
||||
Initially, I favored having the palette in Action Mode by default, and typing a
|
||||
`:` prefix to enter Commandline Mode. This is fairly similar to how tmux's
|
||||
internal command prompt works, which is bound to `<prefix>-:` by default.
|
||||
|
||||
If we wanted to remain _similar_ to VsCode, we'd have no prefix character be the
|
||||
Commandline Mode, and `>` would enter the Action mode. I'd think that might
|
||||
actually be _backwards_ from what I'd expect, with `>` being the default
|
||||
character for the end of the default `cmd` `%PROMPT%`.
|
||||
|
||||
**FOR DISCUSSION** What option makes the most sense to the team? I'm leaning
|
||||
towards the VsCode style (where Action='>', Commandline='') currently.
|
||||
|
||||
Enabling the user to configure this prefix is discussed below in "[Future
|
||||
Considerations](#Configuring-The-ActionCommandline-Mode-Prefix)".
|
||||
|
||||
### Layering and "Unbinding" Commands
|
||||
|
||||
As we'll be providing a list of default commands, the user will inevitably want
|
||||
to change or remove some of these default commands.
|
||||
|
||||
Commands should be layered based upon the _evaluated_ value of the "name"
|
||||
property. Since the default commands will all use localized strings in the
|
||||
`"name": { "key": "KeyName" }` format, the user should be able to override the
|
||||
command based on the localized string for that command.
|
||||
|
||||
So, assuming that `NewTabCommandName` is evaluated as "Open New Tab", the
|
||||
following command
|
||||
```json
|
||||
{ "icon": null, "name": { "key": "NewTabCommandName" }, "action": "newTab" },
|
||||
```
|
||||
|
||||
Could be overridden with the command:
|
||||
```json
|
||||
{ "icon": null, "name": "Open New Tab", "action": "splitPane" },
|
||||
```
|
||||
|
||||
Similarly, if the user wants to remove that command from the command palette,
|
||||
they could set the action to `null`:
|
||||
|
||||
```json
|
||||
{ "icon": null, "name": "Open New Tab", "action": null },
|
||||
```
|
||||
|
||||
This will remove the command from the command list.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
As the entire command palette will be a native XAML element, it'll automatically
|
||||
be hooked up to the UIA tree, allowing for screen readers to naturally find it.
|
||||
* When the palette is opened, it will automatically receive focus.
|
||||
* The terminal panes will not be able to be interacted with while the palette
|
||||
is open, which will help keep the UIA tree simple while the palette is open.
|
||||
|
||||
### Security
|
||||
|
||||
This should not introduce any _new_ security concerns. We're relying on the
|
||||
security of jsoncpp for parsing json. Adding new keys to the settings file
|
||||
will rely on jsoncpp's ability to securely parse those json values.
|
||||
|
||||
### Reliability
|
||||
|
||||
We'll need to make sure that invalid commands are ignored. A command could be
|
||||
invalid because:
|
||||
* it has a null `name`, or a name with the empty string for a value.
|
||||
* it has a null `action`, or an action specified that's not an actual
|
||||
`ShortcutAction`.
|
||||
|
||||
We'll ignore invalid commands from the user's settings, instead of hard
|
||||
crashing. I don't believe this is a scenario that warrants an error dialog to
|
||||
indicate to the user that there's a problem with the json.
|
||||
|
||||
### Compatibility
|
||||
|
||||
We will need to define default _commands_ for all the existing keybinding
|
||||
commands. With #754, we could add all the actions (that make sense) as commands
|
||||
to the commands list, so that everyone wouldn't need to define them manually.
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
We'll be adding a few extra XAML elements to our tree which will certainly
|
||||
increase our runtime memory footprint while the palette is open.
|
||||
|
||||
We'll additionally be introducing a few extra json values to parse, so that could
|
||||
increase our load times (though this will likely be negligible).
|
||||
|
||||
## Potential Issues
|
||||
|
||||
This will first require the work in [#1205] to work properly. Right now we
|
||||
heavily lean on the "focused" element to determine which terminal is "active".
|
||||
However, when the command palette is opened, focus will move out of the terminal
|
||||
control into the command palette, which leads to some hard to debug crashes.
|
||||
|
||||
Additionally, we'll need to ensure that the "fuzzy search" algorithm proposed
|
||||
above will work for non-english languages, where a single character might be
|
||||
multiple `char`s long. As we'll be using a standard XAML text box for input, we
|
||||
won't need to worry about handling the input ourselves.
|
||||
|
||||
### Localization
|
||||
|
||||
Because we'll be shipping a set of default commands with the terminal, we should
|
||||
make sure that list of commands can be localizable. Each of the names we'll give
|
||||
to the commands should be locale-specific.
|
||||
|
||||
To facilitate this, we'll use a special type of object in JSON that will let us
|
||||
specify a resource name in JSON. We'll use a syntax like the following to
|
||||
suggest that we should load a string from our resources, as opposed to using the
|
||||
value from the file:
|
||||
|
||||
```json
|
||||
"commands": [
|
||||
{ "icon": null, "name": { "key": "NewTabCommandName" }, "action": "newTab" },
|
||||
{ "icon": null, "name": { "key": "CloseTabCommandKey" }, "action": "closeTab" },
|
||||
{ "icon": null, "name": { "key": "ClosePaneCommandKey" }, "action": "closePane" },
|
||||
{ "icon": null, "name": { "key": "SplitHorizontalCommandKey" }, "action": { "action": "splitPane", "split": "horizontal" } },
|
||||
{ "icon": null, "name": { "key": "SplitVerticalCommandKey" }, "action": { "action": "splitPane", "split": "vertical" } },
|
||||
{ "icon": null, "name": { "key": "NextTabCommandKey" }, "action": "nextTab" },
|
||||
{ "icon": null, "name": { "key": "PrevTabCommandKey" }, "action": "prevTab" },
|
||||
{ "icon": null, "name": { "key": "OpenSettingsCommandKey" }, "action": "openSettings" },
|
||||
],
|
||||
```
|
||||
|
||||
We'll check at parse time if the `name` property is a string or an object. If
|
||||
it's a string, we'll treat that string as the literal text. Otherwise, if it's
|
||||
an object, we'll attempt to use the `key` property of that object to look up a
|
||||
string from our `ResourceDictionary`. This way, we'll be able to ship localized
|
||||
strings for all the built-in commands, while also allowing the user to easily
|
||||
add their own commands.
|
||||
|
||||
During the spec review process, we considered other options for localization as
|
||||
well. The original proposal included options such as having one `defaults.json`
|
||||
file per-locale, and building the Terminal independently for each locale. Those
|
||||
were not really feasible options, so we instead settled on this solution, as it
|
||||
allowed us to leverage the existing localization support provided to us by the
|
||||
platform.
|
||||
|
||||
The `{ "key": "resourceName" }` solution proposed here was also touched on in
|
||||
[#5280].
|
||||
|
||||
### Proposed Defaults
|
||||
|
||||
These are the following commands I'm proposing adding to the command palette by
|
||||
default. These are largely the actions that are bound by default.
|
||||
|
||||
```json
|
||||
"commands": [
|
||||
{ "icon": null, "name": { "key": "NewTabCommandKey" }, "action": "newTab" },
|
||||
{ "icon": null, "name": { "key": "DuplicateTabCommandKey" }, "action": "duplicateTab" },
|
||||
{ "icon": null, "name": { "key": "DuplicatePaneCommandKey" }, "action": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" } },
|
||||
{ "icon": null, "name": { "key": "SplitHorizontalCommandKey" }, "action": { "action": "splitPane", "split": "horizontal" } },
|
||||
{ "icon": null, "name": { "key": "SplitVerticalCommandKey" }, "action": { "action": "splitPane", "split": "vertical" } },
|
||||
|
||||
{ "icon": null, "name": { "key": "CloseWindowCommandKey" }, "action": "closeWindow" },
|
||||
{ "icon": null, "name": { "key": "ClosePaneCommandKey" }, "action": "closePane" },
|
||||
|
||||
{ "icon": null, "name": { "key": "OpenNewTabDropdownCommandKey" }, "action": "openNewTabDropdown" },
|
||||
{ "icon": null, "name": { "key": "OpenSettingsCommandKey" }, "action": "openSettings" },
|
||||
|
||||
{ "icon": null, "name": { "key": "FindCommandKey" }, "action": "find" },
|
||||
|
||||
{ "icon": null, "name": { "key": "NextTabCommandKey" }, "action": "nextTab" },
|
||||
{ "icon": null, "name": { "key": "PrevTabCommandKey" }, "action": "prevTab" },
|
||||
|
||||
{ "icon": null, "name": { "key": "ToggleFullscreenCommandKey" }, "action": "toggleFullscreen" },
|
||||
|
||||
{ "icon": null, "name": { "key": "CopyTextCommandKey" }, "action": { "action": "copy", "singleLine": false } },
|
||||
{ "icon": null, "name": { "key": "PasteCommandKey" }, "action": "paste" },
|
||||
|
||||
{ "icon": null, "name": { "key": "IncreaseFontSizeCommandKey" }, "action": { "action": "adjustFontSize", "delta": 1 } },
|
||||
{ "icon": null, "name": { "key": "DecreaseFontSizeCommandKey" }, "action": { "action": "adjustFontSize", "delta": -1 } },
|
||||
{ "icon": null, "name": { "key": "ResetFontSizeCommandKey" }, "action": "resetFontSize" },
|
||||
|
||||
{ "icon": null, "name": { "key": "ScrollDownCommandKey" }, "action": "scrollDown" },
|
||||
{ "icon": null, "name": { "key": "ScrollDownPageCommandKey" }, "action": "scrollDownPage" },
|
||||
{ "icon": null, "name": { "key": "ScrollUpCommandKey" }, "action": "scrollUp" },
|
||||
{ "icon": null, "name": { "key": "ScrollUpPageCommandKey" }, "action": "scrollUpPage" }
|
||||
]
|
||||
```
|
||||
|
||||
## Addenda
|
||||
|
||||
This spec also has a follow-up spec which introduces further changes upon this
|
||||
original draft. Please also refer to:
|
||||
|
||||
* June 2020: Unified keybindings and commands, and synthesized action names.
|
||||
|
||||
## Future considerations
|
||||
|
||||
* Commands will provide an easy point for allowing an extension to add its
|
||||
actions to the UI, without forcing the user to bind the extension's actions to
|
||||
a keybinding
|
||||
* Also discussed in [#2046] was the potential for adding a command that inputs a
|
||||
certain commandline to be run by the shell. I felt that was out of scope for
|
||||
this spec, so I'm not including it in detail. I believe that would be
|
||||
accomplished by adding a `inputCommand` action, with two args: `commandline`,
|
||||
a string, and `suppressNewline`, an optional bool, defaulted to false. The
|
||||
`inputCommand` action would deliver the given `commandline` as input to the
|
||||
connection, followed by a newline (as to execute the command).
|
||||
`suppressNewline` would prevent the newline from being added. This would work
|
||||
relatively well, so long as you're sitting at a shell prompt. If you were in
|
||||
an application like `vim`, this might be handy for executing a sequence of
|
||||
vim-specific keybindings. Otherwise, you're just going to end up writing a
|
||||
commandline to the buffer of vim. It would be weird, but not unexpected.
|
||||
* Additionally mentioned in [#2046] was the potential for profile-scoped
|
||||
commands. While that's a great idea, I believe it's out of scope for this
|
||||
spec.
|
||||
* Once [#754] lands, we'll need to make sure to include commands for each action
|
||||
manually in the default settings. This will add some overhead that the
|
||||
developer will need to do whenever they add an action. That's unfortunate, but
|
||||
will be largely beneficial to the end user.
|
||||
* We could theoretically also display the keybinding for a certain command in
|
||||
the `ListViewItem` for the command. We'd need some way to correlate a
|
||||
command's action to a keybinding's action. This could be done in a follow-up
|
||||
task.
|
||||
* We might want to alter the fuzzy-search algorithm, to give higher precedence
|
||||
in the results list to commands with more consecutive matching characters.
|
||||
Alternatively we could give more weight to commands where the search matched
|
||||
the initial character of words in the command.
|
||||
- For example: `ot` would give more weight to "**O**pen **T**ab" than
|
||||
"**O**pen Se**t**tings").
|
||||
* We may want to add a button to the New Tab Button's dropdown to "Show Command
|
||||
Palette". I'm hesitant to keep adding new buttons to that UI, but the command
|
||||
palette is otherwise not highly discoverable.
|
||||
- We could add another button to the UI to toggle the visibility of the
|
||||
command palette. This was the idea initially proposed in [#2046].
|
||||
- For both these options, we may want a global setting to hide that button, to
|
||||
keep the UI as minimal as possible.
|
||||
* [#1571] is a request for customizing the "new tab dropdown" menu. When we get
|
||||
to discussing that design, we should consider also enabling users to add
|
||||
commands from their list of commands to that menu as well.
|
||||
- This is included in the spec in [#5888].
|
||||
* I think it would be cool if there was a small timeout as the user was typing
|
||||
in commandline mode before we try to auto-parse their commandline, to check
|
||||
for errors. Might be useful to help sanity check users. We can always parse
|
||||
their `wt` commandlines safely without having to execute them.
|
||||
* It would be cool if the commands the user typed in Commandline Mode could be
|
||||
saved to a history of some sort, so they could easily be re-entered.
|
||||
- It would be especially cool if it could do this across launches.
|
||||
- We don't really have any way of storing transient data like that in the
|
||||
Terminal, so that would need to be figured out first.
|
||||
- Typically the Command Palette is at the top of the view, with the
|
||||
suggestions below it, so navigating through the history would be _backwards_
|
||||
relative to a normal shell.
|
||||
* Perhaps users will want the ability to configure which side of the window the
|
||||
palette appears on?
|
||||
- This might fit in better with [#3327].
|
||||
* [#3753] is a pull request that covers the addition of an "Advanced Tab
|
||||
Switcher". In an application like VsCode, their advanced tab switcher UI is
|
||||
similar to their command palette UI. It might make sense that the user could
|
||||
use the command palette UI to also navigate to active tabs or panes within the
|
||||
terminal, by control name. We've already outlined how the Command Palette
|
||||
could operate in "Action Mode" or "Commandline Mode" - we could also add
|
||||
"Navigate Mode" on `@`, for navigating between tabs or panes.
|
||||
- The tab switcher could probably largely re-use the command palette UI, but
|
||||
maybe hide the input box by default.
|
||||
* We should make sure to add a setting in the future that lets the user opt-in
|
||||
to showing most-recently used commands _first_ in the search order, and
|
||||
possibly even pre-populating the search box with whatever their last entry
|
||||
was.
|
||||
- I'm thinking these are two _separate_ settings.
|
||||
|
||||
### Nested Commands
|
||||
|
||||
Another idea for a future spec is the concept of "nested commands", where a
|
||||
single command has many sub-commands. This would hide the children commands from
|
||||
the entire list of commands, allowing for much more succinct top-level list of
|
||||
commands, and allowing related commands to be grouped together.
|
||||
- For example, I have a text editor plugin that enables rendering markdown to a
|
||||
number of different styles. To use that command in my text editor, first I hit
|
||||
enter on the "Render Markdown..." command, then I select which style I want to
|
||||
render to, in another list of options. This way, I don't need to have three
|
||||
options for "Render Markdown to github", "Render Markdown to gitlab", all in
|
||||
the top-level list.
|
||||
- We probably also want to allow a nested command set to be evaluated at runtime
|
||||
somehow. Like if we had a "Open New Tab..." command that then had a nested
|
||||
menu with the list of profiles.
|
||||
|
||||
The above might be able to be expressed through some JSON like the following:
|
||||
```json
|
||||
"commands": [
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "NewTabWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "NewTabWithProfileCommandName" },
|
||||
"command": { "action": "newTab", "profile": "${profile.name}" }
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": "Connect to ssh...",
|
||||
"commands": [
|
||||
{
|
||||
"icon": "...",
|
||||
"name": "first.com",
|
||||
"command": { "action": "newTab", "commandline": "ssh me@first.com" }
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": "second.com",
|
||||
"command": { "action": "newTab", "commandline": "ssh me@second.com" }
|
||||
}
|
||||
]
|
||||
}
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "SplitPaneWithProfileCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" }
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneVerticalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" }
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneHorizontalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
This would define three commands, each with a number of nested commands underneath it:
|
||||
* For the first command:
|
||||
- It uses the XAML resource `NewTabWithProfileRootCommandName` as it's name.
|
||||
- Activating this command would cause us to remove all the other commands from
|
||||
the command palette, and only show the nested commands.
|
||||
- It contains nested commands, one for each profile.
|
||||
- Each nested command would use the XAML resource
|
||||
`NewTabWithProfileCommandName`, which then would also contain the string
|
||||
`${profile.name}`, to be filled with the profile's name in the command's
|
||||
name.
|
||||
- It would also use the profile's icon as the command icon.
|
||||
- Activating any of the nested commands would dispatch an action to create a
|
||||
new tab with that profile
|
||||
* The second command:
|
||||
- It uses the string literal `"Connect to ssh..."` as it's name
|
||||
- It contains two nested commands:
|
||||
- Each nested command has it's own literal name
|
||||
- Activating these commands would cause us to open a new tab with the
|
||||
provided `commandline` instead of the default profile's `commandline`
|
||||
* The third command:
|
||||
- It uses the XAML resource `NewTabWithProfileRootCommandName` as it's name.
|
||||
- It contains nested commands, one for each profile.
|
||||
- Each one of these sub-commands each contains 3 subcommands - one that will
|
||||
create a new split pane automatically, one vertically, and one
|
||||
horizontally, each using the given profile.
|
||||
|
||||
So, you could imagine the entire tree as follows:
|
||||
|
||||
```
|
||||
<Command Palette>
|
||||
├─ New Tab With Profile...
|
||||
│ ├─ Profile 1
|
||||
│ ├─ Profile 2
|
||||
│ └─ Profile 3
|
||||
├─ Connect to ssh...
|
||||
│ ├─ first.com
|
||||
│ └─ second.com
|
||||
└─ New Pane...
|
||||
├─ Profile 1...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
├─ Profile 2...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
└─ Profile 3...
|
||||
├─ Split Automatically
|
||||
├─ Split Vertically
|
||||
└─ Split Horizontally
|
||||
```
|
||||
|
||||
Note that the palette isn't displayed like a tree - it only ever displays the
|
||||
commands from one single level at a time. So at first, only:
|
||||
|
||||
* New Tab With Profile...
|
||||
* Connect to ssh...
|
||||
* New Pane...
|
||||
|
||||
are visible. Then, when the user <kbd>enter</kbd>'s on one of these (like "New
|
||||
Pane"), the UI will change to display:
|
||||
|
||||
* Profile 1...
|
||||
* Profile 2...
|
||||
* Profile 3...
|
||||
|
||||
### Configuring the Action/Commandline Mode prefix
|
||||
|
||||
As always, I'm also on board with the "this should be configurable by the user"
|
||||
route, so they can change what mode the command palette is in by default, and
|
||||
what the prefixes for different modes are, but I'm not sure how we'd define that
|
||||
cleanly in the settings.
|
||||
|
||||
```json
|
||||
{
|
||||
"commandPaletteActionModePrefix": "", // or null, for no prefix
|
||||
"commandPaletteCommandlineModePrefix": ">"
|
||||
}
|
||||
```
|
||||
|
||||
We'd need to have validation on that though, what if both of them were set to
|
||||
`null`? One of them would _need_ to be `null`, so if both have a character, do
|
||||
we just assume one is the default?
|
||||
|
||||
## Resources
|
||||
Initial post that inspired this spec: #[2046](https://github.com/microsoft/terminal/issues/2046)
|
||||
|
||||
Keybindings args: #[1349](https://github.com/microsoft/terminal/pull/1349)
|
||||
|
||||
Cascading User & Default Settings: #[754](https://github.com/microsoft/terminal/issues/754)
|
||||
|
||||
Untie "active control" from "currently XAML-focused control" #[1205](https://github.com/microsoft/terminal/issues/1205)
|
||||
|
||||
Allow dropdown menu customization in profiles.json [#1571](https://github.com/microsoft/terminal/issues/1571)
|
||||
|
||||
Search or run a command in Dropdown menu [#3879]
|
||||
|
||||
Spec: Introduce a mini-specification for localized resource use from JSON [#5280]
|
||||
|
||||
<!-- Footnotes -->
|
||||
[#754]: https://github.com/microsoft/terminal/issues/754
|
||||
[#1205]: https://github.com/microsoft/terminal/issues/1205
|
||||
[#1142]: https://github.com/microsoft/terminal/pull/1349
|
||||
[#2046]: https://github.com/microsoft/terminal/issues/2046
|
||||
[#1571]: https://github.com/microsoft/terminal/issues/1571
|
||||
[#3879]: https://github.com/microsoft/terminal/issues/3879
|
||||
[#5280]: https://github.com/microsoft/terminal/pull/5280
|
||||
[#4472]: https://github.com/microsoft/terminal/issues/4472
|
||||
[#3327]: https://github.com/microsoft/terminal/issues/3327
|
||||
[#3753]: https://github.com/microsoft/terminal/pulls/3753
|
||||
[#5888]: https://github.com/microsoft/terminal/pulls/5888
|
||||
@@ -1,608 +0,0 @@
|
||||
---
|
||||
author: Mike Griese @zadjii-msft
|
||||
created on: 2020-06-15
|
||||
last updated: 2020-06-19
|
||||
issue id: 2046
|
||||
---
|
||||
|
||||
# Command Palette, Addendum 1 - Unified keybindings and commands, and synthesized action names
|
||||
|
||||
## Abstract
|
||||
|
||||
This document is intended to serve as an addition to the [Command Palette Spec].
|
||||
While that spec is complete in it's own right, subsequent discussion revealed
|
||||
additional ways to improve the functionality and usability of the command
|
||||
palette. This document builds largely on the topics already introduced in the
|
||||
original spec, so readers should first familiarize themselves with that
|
||||
document.
|
||||
|
||||
One point of note from the original document was that the original specification
|
||||
was entirely too verbose when defining both keybindings and commands for
|
||||
actions. Consider, for instance, a user that wants to bind the action "duplicate
|
||||
the current pane". In that spec, they need to add both a keybinding and a
|
||||
command:
|
||||
|
||||
```json
|
||||
{
|
||||
"keybindings": [
|
||||
{ "keys": [ "ctrl+alt+t" ], "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" } },
|
||||
],
|
||||
"commands": [
|
||||
{ "name": "Duplicate Pane", "action": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "icon": null },
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
These two entries are practically the same, except for two key differentiators:
|
||||
* the keybinding has a `keys` property, indicating which key chord activates the
|
||||
action.
|
||||
* The command has a `name` property, indicating what name to display for the
|
||||
command in the Command Palette.
|
||||
|
||||
What if the user didn't have to duplicate this action? What if the user could
|
||||
just add this action once, in their `keybindings` or `commands`, and have it
|
||||
work both as a keybinding AND a command?
|
||||
|
||||
|
||||
## Solution Design
|
||||
|
||||
This spec will outline two primary changes to keybindings and commands.
|
||||
1. Unify keybindings and commands, so both `keybindings` and `commands` can
|
||||
specify either actions bound to keys, and/or actions bound to entries in the
|
||||
Command Palette.
|
||||
2. Propose a mechanism by which actions do not _require_ a `name` to appear in
|
||||
the Command Palette.
|
||||
|
||||
These proposals are two atomic units - either could be approved or rejected
|
||||
independently of one another. They're presented together here in the same doc
|
||||
because together, they present a compelling story.
|
||||
|
||||
### Proposal 1: Unify Keybindings and Commands
|
||||
|
||||
As noted above, keybindings and commands have nearly the exact same syntax, save
|
||||
for a couple properties. To make things easier for the user, I'm proposing
|
||||
treating everything in _both_ the `keybindings` _and_ the `commands` arrays as
|
||||
**BOTH** a keybinding and a command.
|
||||
|
||||
Furthermore, as a change from the previous spec, we'll be using `bindings` from
|
||||
here on as the unified `keybindings` and `commands` lists. This is considering
|
||||
that we'll currently be using `bindings` for both commands and keybindings, but
|
||||
we'll potentially also have mouse & touch bindings in this array in the future.
|
||||
We'll "deprecate" the existing `keybindings` property, and begin to exclusively
|
||||
use `bindings` as the new property name. For compatibility reasons, we'll
|
||||
continue to parse `keybindings` in the same way we parse `bindings`. We'll
|
||||
simply layer `bindings` on top of the legacy `keybindings`.
|
||||
|
||||
* Anything entry that has a `keys` value will be added to the keybindings.
|
||||
Pressing that keybinding will activate the action defined in `command`.
|
||||
* Anything with a `name`<sup>[1]</sup> will be added as an entry (using that
|
||||
name) to the Command Palette's Action Mode.
|
||||
|
||||
###### Caveats
|
||||
|
||||
* **Nested commands** (commands with other nested commands). If a command has
|
||||
nested commands in the `commands` property, AND a `keys` property, then
|
||||
pressing that keybinding should open the Command Palette directly to that
|
||||
level of nesting of commands.
|
||||
* **"Iterable" commands** (with an `iterateOn` property): These are commands
|
||||
that are expanded into one command per profile. These cannot really be bound
|
||||
as keybindings - which action should be bound to the key? They can't all be
|
||||
bound to the same key. If a KeyBinding/Command json blob has a valid
|
||||
`iterateOn` property, then we'll ignore it as a keybinding. This includes any
|
||||
commands that are nested as children of this command - we won't be able to
|
||||
know which of the expanded children will be the one to bind the keys to.
|
||||
|
||||
<sup>[1]</sup>: This requirement will be relaxed given **Proposal 2**, below,
|
||||
but ignored for the remainder of this section, for illustrative purposes.
|
||||
|
||||
#### Example
|
||||
|
||||
Consider the following settings:
|
||||
|
||||
```json
|
||||
"bindings": [
|
||||
{ "name": "Duplicate Tab", "command": "duplicateTab", "keys": "ctrl+alt+a" },
|
||||
{ "command": "nextTab", "keys": "ctrl+alt+b" },
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "NewTabWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "NewTabWithProfileCommandName" },
|
||||
"command": { "action": "newTab", "profile": "${profile.name}" }
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": "Connect to ssh...",
|
||||
"commands": [
|
||||
{
|
||||
"keys": "ctrl+alt+c",
|
||||
"icon": "...",
|
||||
"name": "first.com",
|
||||
"command": { "action": "newTab", "commandline": "ssh me@first.com" }
|
||||
},
|
||||
{
|
||||
"keys": "ctrl+alt+d",
|
||||
"icon": "...",
|
||||
"name": "second.com",
|
||||
"command": { "action": "newTab", "commandline": "ssh me@second.com" }
|
||||
}
|
||||
]
|
||||
}
|
||||
{
|
||||
"keys": "ctrl+alt+e",
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "SplitPaneWithProfileCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"keys": "ctrl+alt+f",
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" }
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneVerticalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" }
|
||||
},
|
||||
{
|
||||
"icon": "...",
|
||||
"name": { "key": "SplitPaneHorizontalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
This will generate a tree of commands as follows:
|
||||
|
||||
```
|
||||
<Command Palette>
|
||||
├─ Duplicate tab { ctrl+alt+a }
|
||||
├─ New Tab With Profile...
|
||||
│ ├─ Profile 1
|
||||
│ ├─ Profile 2
|
||||
│ └─ Profile 3
|
||||
├─ Connect to ssh...
|
||||
│ ├─ first.com { ctrl+alt+c }
|
||||
│ └─ second.com { ctrl+alt+d }
|
||||
└─ New Pane... { ctrl+alt+e }
|
||||
├─ Profile 1...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
├─ Profile 2...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
└─ Profile 3...
|
||||
├─ Split Automatically
|
||||
├─ Split Vertically
|
||||
└─ Split Horizontally
|
||||
```
|
||||
|
||||
Note also the keybindings in the above example:
|
||||
* <kbd>ctrl+alt+a</kbd>: This key chord is bound to the "Duplicate tab"
|
||||
(`duplicateTab`) action, which is also bound to the command with the same
|
||||
name.
|
||||
* <kbd>ctrl+alt+b</kbd>: This key chord is bound to the `nextTab` action, which
|
||||
doesn't have an associated command.
|
||||
* <kbd>ctrl+alt+c</kbd>: This key chord is bound to the "Connect to
|
||||
ssh../first.com" action, which will open a new tab with the `commandline`
|
||||
`"ssh me@first.com"`. When the user presses this keybinding, the action will
|
||||
be executed immediately, without the Command Palette appearing.
|
||||
* <kbd>ctrl+alt+d</kbd>: This is the same as the above, but with the "Connect to
|
||||
ssh../second.com" action.
|
||||
* <kbd>ctrl+alt+e</kbd>: This key chord is bound to opening the Command Palette
|
||||
to the "New Pane..." command's menu. When the user presses this keybinding,
|
||||
they'll be prompted with this command's sub-commands:
|
||||
```
|
||||
Profile 1...
|
||||
Profile 2...
|
||||
Profile 3...
|
||||
```
|
||||
* <kbd>ctrl+alt+f</kbd>: This key will _not_ be bound to any action. The parent
|
||||
action is iterable, which means that the `SplitPaneName` command is going to
|
||||
get turned into one command for each and every profile, and therefore cannot
|
||||
be bound to just a single action.
|
||||
|
||||
### Proposal 2: Automatically synthesize action names
|
||||
|
||||
Previously, all Commands were required to have a `name`. This name was used as
|
||||
the text for the action in the Action Mode of the Command Palette. However, this
|
||||
is a little tedious for users who already have lots of keys bound. They'll need
|
||||
to go through and add names to each of their existing keybindings to ensure that
|
||||
the actions appear in the palette. Could we instead synthesize the names for the
|
||||
commands ourselves? This would enable users to automatically get each of their
|
||||
existing keybindings to appear in the palette without any extra work.
|
||||
|
||||
To support this, the following changes will be made:
|
||||
* `ActionAndArgs` will get a `GenerateName()` method defined. This will create a
|
||||
string describing the `ShortcutAction` and it's associated `ActionArgs`.
|
||||
- Not EVERY action _needs_ to define a result for `GenerateName`. Actions that
|
||||
don't _won't_ be automatically added to the Command Palette.
|
||||
- Each of the strings used in `GenerateName` will need to come from our
|
||||
resources, so they can be localized appropriately.
|
||||
* When we're parsing commands, if a command doesn't have a `name`, we'll instead
|
||||
attempt to use `GenerateName` to create the unique string for the action
|
||||
associated with this command. If the command does have a `name` set, we'll use
|
||||
that string instead, allowing the user to override the default name.
|
||||
- If a command has it's name set to `null`, then we'll ignore the command
|
||||
entirely, not just use the generated name.
|
||||
|
||||
[**Appendix 1**](#appendix-1-name-generation-samples-for-ShortcutActions) below
|
||||
shows a complete sample of the strings that will be generated for each of the existing
|
||||
`ShortcutActions`, and many of the actions that have been proposed, but not yet
|
||||
implemented.
|
||||
|
||||
These strings should be human-friendly versions of the actions and their
|
||||
associated args. For some of these actions, with very few arguments, the strings
|
||||
can be relatively simple. Take for example, `CopyText`:
|
||||
|
||||
JSON | Generated String
|
||||
-- | --
|
||||
`{ "action":"copyText" }` | "Copy text"
|
||||
`{ "action":"copyText", "singleLine": true }` | "Copy text as a single line"
|
||||
`{ "action":"copyText", "singleLine": false, "copyFormatting": false }` | "Copy text without formatting"
|
||||
`{ "action":"copyText", "singleLine": true, "copyFormatting": true }` | "Copy text as a single line without formatting"
|
||||
|
||||
CopyText is a bit of a simplistic case however, with very few args or
|
||||
permutations of argument values. For things like `newTab`, `splitPane`, where
|
||||
there are many possible arguments and values, it will be acceptable to simply
|
||||
append `", property:value"` strings to the generated names for each of the set
|
||||
values.
|
||||
|
||||
For example:
|
||||
|
||||
JSON | Generated String
|
||||
-- | --
|
||||
`{ "action":"newTab", "profile": "Hello" }` | "Open a new tab, profile:Hello"
|
||||
`{ "action":"newTab", "profile": "Hello", "directory":"C:\\", "commandline": "wsl.exe", title": "Foo" }` | "Open a new tab, profile:Hello, directory:C:\\, commandline:wsl.exe, title:Foo"
|
||||
|
||||
|
||||
This is being chosen in favor of something that might be more human-friendly,
|
||||
like "Open a new tab with profile {profile name} in {directory} with
|
||||
{commandline} and a title of {title}". This string would be much harder to
|
||||
synthesize, especially considering localization concerns.
|
||||
|
||||
#### Remove the resource key notation
|
||||
|
||||
Since we'll be using localized names for each of the actions in `GenerateName`,
|
||||
we no longer _need_ to provide the `{ "name":{ "key": "SomeResourceKey" } }`
|
||||
syntax introduced in the original spec. This functionality was used to allow us
|
||||
to define localizable names for the default commands.
|
||||
|
||||
However, I think we should keep this functionality, to allow us additional
|
||||
flexibility when defining default commands.
|
||||
|
||||
### Complete Defaults
|
||||
|
||||
Considering both of the above proposals, the default keybindings and commands
|
||||
will be defined as follows:
|
||||
|
||||
* The current default keybindings will be untouched. These actions will
|
||||
automatically be added to the Command Palette, using their names generated
|
||||
from `GenerateName`.
|
||||
- **TODO: FOR DISCUSSION**: Should we manually set the names for the default
|
||||
"New Tab, profile index: 0" keybindings to `null`? This seems like a not
|
||||
terribly helpful name for the Command Palette, especially considering the
|
||||
iterable commands listed below.
|
||||
* We'll add a few new commands:
|
||||
- A nested, iterable command for "Open new tab with
|
||||
profile..."/"Profile:{profile name}"
|
||||
- A nested, iterable command for "Select color scheme..."/"{scheme name}"
|
||||
- A nested, iterable command for "New Pane..."/"Profile:{profile
|
||||
name}..."/["Automatic", "Horizontal", "Vertical"]
|
||||
> 👉 NOTE: These default nested commands can be removed by the user defining
|
||||
> `{ "name": "Open new tab with profile...", "action":null }` (et al) in their
|
||||
> settings.
|
||||
- If we so chose, in the future we can add further commands that we think are
|
||||
helpful to `defaults.json`, without needing to give them keys. For example,
|
||||
we could add
|
||||
```json
|
||||
{ "command": { "action": "copy", "singleLine": true } }
|
||||
```
|
||||
to `bindings`, to add a "copy text as a single line" command, without
|
||||
necessarily binding it to a keystroke.
|
||||
|
||||
|
||||
These changes to the `defaults.json` are represented in json as the following:
|
||||
|
||||
```json
|
||||
"bindings": [
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "NewTabWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": "${profile.name}",
|
||||
"command": { "action": "newTab", "profile": "${profile.name}" }
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "SelectColorSchemeRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "schemes",
|
||||
"icon": null,
|
||||
"name": "${scheme.name}",
|
||||
"command": { "action": "selectColorScheme", "scheme": "${scheme.name}" }
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "SplitPaneWithProfileRootCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"iterateOn": "profiles",
|
||||
"icon": "${profile.icon}",
|
||||
"name": { "key": "SplitPaneWithProfileCommandName" },
|
||||
"commands": [
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "SplitPaneName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" }
|
||||
},
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "SplitPaneVerticalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" }
|
||||
},
|
||||
{
|
||||
"icon": null,
|
||||
"name": { "key": "SplitPaneHorizontalName" },
|
||||
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" }
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
A complete diagram of what the default Command Palette will look like given the
|
||||
default keybindings and these changes is given in [**Appendix
|
||||
2**](#appendix-2-complete-default-command-palette).
|
||||
|
||||
## Concerns
|
||||
|
||||
**DISCUSSION**: "New tab with index {index}". How does this play with
|
||||
the new tab dropdown customizations in [#5888]? In recent iterations of that
|
||||
spec, we changed the meaning of `{ "action": "newTab", "index": 1 }` to mean
|
||||
"open the first entry in the new tab menu". If that's a profile, then we'll open
|
||||
a new tab with it. If it's an action, we'll perform that action. If it's a
|
||||
nested menu, then we'll open the menu to that entry.
|
||||
|
||||
Additionally, how exactly does that play with something like `{ "action":
|
||||
"newTab", "index": 1, "commandline": "wsl.exe" }`? This is really a discussion
|
||||
for that spec, but is an issue highlighted by this spec. If the first entry is
|
||||
anything other than a `profile`, then the `commandline` parameter doesn't really
|
||||
mean anything anymore. I'm tempted to revert this particular portion of the new
|
||||
tab menu customization spec over this.
|
||||
|
||||
We could instead add an `index` to `openNewTabDropdown`, and have that string
|
||||
instead be "Open new tab dropdown, index:1". That would help disambiguate the
|
||||
two.
|
||||
|
||||
Following discussion, it was decided that this was in fact the cleanest
|
||||
solution, when accounting for both the needs of the new tab dropdown and the
|
||||
command palette. The [#5888] spec has been updated to reflect this.
|
||||
|
||||
## Future considerations
|
||||
|
||||
* Some of these command names are starting to get _very_ long. Perhaps we need a
|
||||
netting to display Command Palette entries on two lines (or multiple, as
|
||||
necessary).
|
||||
* When displaying the entries of a nested command to the user, should we display
|
||||
a small label showing the name of the previous command? My gut says _yes_. In
|
||||
the Proposal 1 example, pressing `ctrl+alt+e` to jump to "Split Pane..."
|
||||
should probably show a small label that displays "Split Pane..." above the
|
||||
list of nested commands.
|
||||
* It wouldn't be totally impossible to allow keys to be bound to an iterable
|
||||
command, and then simply have the key work as "open the command palette with
|
||||
only the commands generated by this iterable command". This is left as a
|
||||
future option, as it might require some additional technical plumbing.
|
||||
|
||||
## Appendix 1: Name generation samples for `ShortcutAction`s
|
||||
|
||||
### Current `ShortcutActions`
|
||||
|
||||
* `CopyText`
|
||||
- "Copy text"
|
||||
- "Copy text as a single line"
|
||||
- "Copy text without formatting"
|
||||
- "Copy text as a single line without formatting"
|
||||
* `PasteText`
|
||||
- "Paste text"
|
||||
* `OpenNewTabDropdown`
|
||||
- "Open new tab dropdown"
|
||||
* `DuplicateTab`
|
||||
- "Duplicate tab"
|
||||
* `NewTab`
|
||||
- "Open a new tab, profile:{profile name}, directory:{directory}, commandline:{commandline}, title:{title}"
|
||||
* `NewWindow`
|
||||
- "Open a new window"
|
||||
- "Open a new window, profile:{profile name}, directory:{directory}, commandline:{commandline}, title:{title}"
|
||||
* `CloseWindow`
|
||||
- "Close window"
|
||||
* `CloseTab`
|
||||
- "Close tab"
|
||||
* `ClosePane`
|
||||
- "Close pane"
|
||||
* `NextTab`
|
||||
- "Switch to the next tab"
|
||||
* `PrevTab`
|
||||
- "Switch to the previous tab"
|
||||
* `SplitPane`
|
||||
- "Open a new pane, profile:{profile name}, split direction:{direction}, split size:{X%/Y chars}, resize parents, directory:{directory}, commandline:{commandline}, title:{title}"
|
||||
- "Duplicate the current pane, split direction:{direction}, split size:{X%/Y chars}, resize parents, directory:{directory}, commandline:{commandline}, title:{title}"
|
||||
* `SwitchToTab`
|
||||
- "Switch to tab {index}"
|
||||
* `AdjustFontSize`
|
||||
- "Increase the font size"
|
||||
- "Decrease the font size"
|
||||
* `ResetFontSize`
|
||||
- "Reset the font size"
|
||||
* `ScrollUp`
|
||||
- "Scroll up a line"
|
||||
- "Scroll up {amount} lines"
|
||||
* `ScrollDown`
|
||||
- "Scroll down a line"
|
||||
- "Scroll down {amount} lines"
|
||||
* `ScrollUpPage`
|
||||
- "Scroll up a page"
|
||||
- "Scroll up {amount} pages"
|
||||
* `ScrollDownPage`
|
||||
- "Scroll down a page"
|
||||
- "Scroll down {amount} pages"
|
||||
* `ResizePane`
|
||||
- "Resize pane {direction}"
|
||||
- "Resize pane {direction} {percent}%"
|
||||
* `MoveFocus`
|
||||
- "Move focus {direction}"
|
||||
* `Find`
|
||||
- "Toggle the search box"
|
||||
* `ToggleFullscreen`
|
||||
- "Toggle fullscreen mode"
|
||||
* `OpenSettings`
|
||||
- "Open settings"
|
||||
- "Open settings file"
|
||||
- "Open default settings file"
|
||||
* `ToggleCommandPalette`
|
||||
- "Toggle the Command Palette"
|
||||
- "Toggle the Command Palette in commandline mode"
|
||||
|
||||
### Other yet unimplemented actions:
|
||||
* `SwitchColorScheme`
|
||||
- "Select color scheme {name}"
|
||||
* `ToggleRetroEffect`
|
||||
- "Toggle the retro terminal effect"
|
||||
* `ExecuteCommandline`
|
||||
- "Run a wt commandline: {cmdline}"
|
||||
* `ExecuteActions`
|
||||
- OPINION: THIS ONE SHOULDN'T HAVE A NAME. We're not including any of these by
|
||||
default. The user knows what they're putting in the settings by adding this
|
||||
action, let them name it.
|
||||
- Alternatively: "Run actions: {action.ToName() for action in actions}"
|
||||
* `SendInput`
|
||||
- OPINION: THIS ONE SHOULDN'T HAVE A NAME. We're not including any of these by
|
||||
default. The user knows what they're putting in the settings by adding this
|
||||
action, let them name it.
|
||||
* `ToggleMarkMode`
|
||||
- "Toggle Mark Mode"
|
||||
* `NextTab`
|
||||
- "Switch to the next most-recent tab"
|
||||
* `SetTabColor`
|
||||
- "Set the color of the current tab to {#color}"
|
||||
* It would be _really_ cool if we could display a sample of the color
|
||||
inline, but that's left as a future consideration.
|
||||
- "Set the color for this tab..."
|
||||
* this command isn't nested, but hitting enter immediately does something
|
||||
with the UI, so that's _fine_
|
||||
* `RenameTab`
|
||||
- "Rename this tab to {name}"
|
||||
- "Rename this tab..."
|
||||
* this command isn't nested, but hitting enter immediately does something
|
||||
with the UI, so that's _fine_
|
||||
|
||||
|
||||
## Appendix 2: Complete Default Command Palette
|
||||
|
||||
This diagram shows what the default value of the Command Palette would be. This
|
||||
assumes that the user has 3 profiles, "Profile 1", "Profile 2", and "Profile 3",
|
||||
as well as 3 schemes: "Scheme 1", "Scheme 2", and "Scheme 3".
|
||||
|
||||
```
|
||||
<Command Palette>
|
||||
├─ Close Window
|
||||
├─ Toggle fullscreen mode
|
||||
├─ Open new tab dropdown
|
||||
├─ Open settings
|
||||
├─ Open default settings file
|
||||
├─ Toggle the search box
|
||||
├─ New Tab
|
||||
├─ New Tab, profile index: 0
|
||||
├─ New Tab, profile index: 1
|
||||
├─ New Tab, profile index: 2
|
||||
├─ New Tab, profile index: 3
|
||||
├─ New Tab, profile index: 4
|
||||
├─ New Tab, profile index: 5
|
||||
├─ New Tab, profile index: 6
|
||||
├─ New Tab, profile index: 7
|
||||
├─ New Tab, profile index: 8
|
||||
├─ Duplicate tab
|
||||
├─ Switch to the next tab
|
||||
├─ Switch to the previous tab
|
||||
├─ Switch to tab 0
|
||||
├─ Switch to tab 1
|
||||
├─ Switch to tab 2
|
||||
├─ Switch to tab 3
|
||||
├─ Switch to tab 4
|
||||
├─ Switch to tab 5
|
||||
├─ Switch to tab 6
|
||||
├─ Switch to tab 7
|
||||
├─ Switch to tab 8
|
||||
├─ Close pane
|
||||
├─ Open a new pane, split: horizontal
|
||||
├─ Open a new pane, split: vertical
|
||||
├─ Duplicate the current pane
|
||||
├─ Resize pane down
|
||||
├─ Resize pane left
|
||||
├─ Resize pane right
|
||||
├─ Resize pane up
|
||||
├─ Move focus down
|
||||
├─ Move focus left
|
||||
├─ Move focus right
|
||||
├─ Move focus up
|
||||
├─ Copy Text
|
||||
├─ Paste Text
|
||||
├─ Scroll down a line
|
||||
├─ Scroll down a page
|
||||
├─ Scroll up a line
|
||||
├─ Scroll up a page
|
||||
├─ Increase the font size
|
||||
├─ Decrease the font size
|
||||
├─ Reset the font size
|
||||
├─ New Tab With Profile...
|
||||
│ ├─ Profile 1
|
||||
│ ├─ Profile 2
|
||||
│ └─ Profile 3
|
||||
├─ Select Color Scheme...
|
||||
│ ├─ Scheme 1
|
||||
│ ├─ Scheme 2
|
||||
│ └─ Scheme 3
|
||||
└─ New Pane...
|
||||
├─ Profile 1...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
├─ Profile 2...
|
||||
| ├─ Split Automatically
|
||||
| ├─ Split Vertically
|
||||
| └─ Split Horizontally
|
||||
└─ Profile 3...
|
||||
├─ Split Automatically
|
||||
├─ Split Vertically
|
||||
└─ Split Horizontally
|
||||
```
|
||||
|
||||
|
||||
<!-- Footnotes -->
|
||||
[Command Palette Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%232046%20-%20Command%20Palette.md
|
||||
@@ -1,135 +0,0 @@
|
||||
---
|
||||
author: Carlos Zamora @carlos-zamora
|
||||
created on: 2020-05-14
|
||||
last updated: 2020-05-14
|
||||
issue id: #2557
|
||||
---
|
||||
|
||||
# Open Settings Keybinding
|
||||
|
||||
## Abstract
|
||||
|
||||
This spec outlines an expansion to the existing `openSettings` keybinding.
|
||||
|
||||
## Inspiration
|
||||
|
||||
As a Settings UI becomes more of a reality, the behavior of this keybinding will be expanded on to better interact with the UI. Prior to a Settings UI, there was only one concept of the modifiable user settings: settings.json.
|
||||
|
||||
Once the Settings UI is created, we can expect users to want to access the following scenarios:
|
||||
- Settings UI: globals page
|
||||
- Settings UI: profiles page
|
||||
- Settings UI: color schemes page
|
||||
- Settings UI: keybindings page
|
||||
- settings.json
|
||||
- defaults.json
|
||||
These are provided as non-comprehensive examples of pages that might be in a future Settings UI. The rest of the doc assumes these are the pages in the Settings UI.
|
||||
|
||||
|
||||
## Solution Design
|
||||
Originally, #2557 was intended to allow for a keybinding arg to access defaults.json. I imagined a keybinding arg such as "openDefaults: true/false" to accomplish this. However, this is not expandable in the following scenarios:
|
||||
- what if we decide to create more settings files in the future? (i.e. themes.json, extensions.json, etc...)
|
||||
- when the Settings UI comes in, there is ambiguity as to what `openSettings` does (json? UI? Which page?)
|
||||
|
||||
### Proposition 1.1: the minimal `target` arg
|
||||
Instead, what if we introduced a new `target` keybinding argument, that could be used as follows:
|
||||
| Keybinding Command | Behavior |
|
||||
|--|--|
|
||||
| `"command": { "action": "openSettings", "target": "settingsFile" }` | opens "settings.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "target": "defaultsFile" }` | opens "defaults.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "target": "allSettingsFiles" }` | opens all of settings files in your default text editor |
|
||||
| `"command": { "action": "openSettings", "target": "settingsUI" }` | opens the Settings UI |
|
||||
|
||||
This was based on Proposition 1 below, but reduced the overhead of people able to define specific pages to go to.
|
||||
|
||||
### Other options we considered were...
|
||||
|
||||
#### Proposition 1: the `target` arg
|
||||
We considered making target be more specific like this:
|
||||
| Keybinding Command | Behavior |
|
||||
|--|--|
|
||||
| `"command": { "action": "openSettings", "target": "settingsFile" }` | opens "settings.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "target": "defaultsFile" }` | opens "defaults.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "target": "uiSettings" }` | opens the Settings UI |
|
||||
| `"command": { "action": "openSettings", "target": "uiGlobals" }` | opens the Settings UI to the Globals page |
|
||||
| `"command": { "action": "openSettings", "target": "uiProfiles" }` | opens the Settings UI to the Profiles page |
|
||||
| `"command": { "action": "openSettings", "target": "uiColorSchemes" }` | opens the Settings UI to the Color Schemes page |
|
||||
|
||||
If the Settings UI does not have a home page, `uiGlobals` and `uiSettings` will do the same thing.
|
||||
|
||||
This provides the user with more flexibility to decide what settings page to open and how to access it.
|
||||
|
||||
#### Proposition 2: the `format` and `page` args
|
||||
Another approach would be to break up `target` into `format` and `page`.
|
||||
|
||||
`format` would be either `json` or `ui`, dictating how you can access the setting.
|
||||
`page` would be any of the categories we have for settings: `settings`, `defaults`, `globals`, `profiles`, etc...
|
||||
|
||||
This could look like this:
|
||||
| Keybinding Command | Behavior |
|
||||
|--|--|
|
||||
| `"command": { "action": "openSettings", "format": "json", "page": "settings" }` | opens "settings.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "format": "json", "page": "defaults" }` | opens "defaults.json" in your default text editor |
|
||||
| `"command": { "action": "openSettings", "format": "ui", "page": "settings" }` | opens the Settings UI |
|
||||
| `"command": { "action": "openSettings", "format": "ui", "page": "globals" }` | opens the Settings UI to the Globals page |
|
||||
| `"command": { "action": "openSettings", "format": "ui", "page": "profiles" }` | opens the Settings UI to the Profiles page |
|
||||
| `"command": { "action": "openSettings", "format": "ui", "page": "colorSchemes" }` | opens the Settings UI to the Color Schemes page |
|
||||
|
||||
The tricky thing for this approach is, what do we do in the following scenario:
|
||||
```js
|
||||
{ "command": { "action": "openSettings", "format": "json", "page": "colorSchemes" } }
|
||||
```
|
||||
In situations like this, where the user wants a `json` format, but chooses a `page` that is a part of a larger settings file, I propose we simply open `settings.json` (or whichever file contains the settings for the desired feature).
|
||||
|
||||
#### Proposition 3: minimal approach
|
||||
What if we don't need to care about the page, and we really just cared about the format: UI vs json? Then, we still need a way to represent opening defaults.json. We could simplify Proposition 2 to be as follows:
|
||||
- `format`: `json`, `ui`
|
||||
- ~`page`~ `openDefaults`: `true`, `false`
|
||||
|
||||
Here, we take away the ability to specifically choose which page the user wants to open, but the result looks much cleaner.
|
||||
|
||||
If there are concerns about adding more settings files in the future, `openDefaults` could be renamed to be `target`, and this would still serve as a hybrid of Proposition 1 and 2, with less possible options.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
The user has full control over modifying and adding these keybindings.
|
||||
|
||||
However, the question arises for what the default experience should be. I propose the following:
|
||||
| Keychord | Behavior |
|
||||
| <kbd>ctrl+,</kbd> | Open settings.json |
|
||||
| <kbd>ctrl+alt+,</kbd> | Open defaults.json |
|
||||
|
||||
When the Settings UI gets added in, they will be updated to open their respective pages in the Settings UI.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
None.
|
||||
|
||||
### Security
|
||||
|
||||
None.
|
||||
|
||||
### Reliability
|
||||
|
||||
None.
|
||||
|
||||
### Compatibility
|
||||
|
||||
Users that expect a json file to open would have to update their keybinding to do so.
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
## Potential Issues
|
||||
|
||||
None.
|
||||
|
||||
## Future considerations
|
||||
|
||||
When the Settings UI becomes available, a new value for `target` of `settingsUI` will be added and it will become the default target.
|
||||
|
||||
If the community finds value in opening to a specific page of the Settings UI, `target` will be responsible for providing that functionality.
|
||||
|
||||
## Resources
|
||||
|
||||
None.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 60 KiB |
@@ -1,559 +0,0 @@
|
||||
---
|
||||
author: Mike Griese @zadjii-msft
|
||||
created on: 2020-05-07
|
||||
last updated: 2020-06-03
|
||||
issue id: 4999
|
||||
---
|
||||
|
||||
# Improved keyboard handling in Conpty
|
||||
|
||||
## Abstract
|
||||
|
||||
The Windows Console internally uses [`INPUT_RECORD`]s to represent the various
|
||||
types of input that a user might send to a client application. This includes
|
||||
things like keypresses, mouse events, window resizes, etc.
|
||||
|
||||
However, conpty's keyboard input is fundamentally backed by VT sequences, which
|
||||
limits the range of keys that a terminal application can actually send relative
|
||||
to what the console was capable of. This results in a number of keys that were
|
||||
previously representable in the console as `INPUT_RECORD`s, but are impossible
|
||||
to send to a client application that's running in conpty mode.
|
||||
|
||||
Some of these issues include, but are not limited to:
|
||||
|
||||
* Some keybindings used by PSReadLine aren't getting through [#879]
|
||||
* Bug Report: Control+Space not sent to terminal emulator. [#2865]
|
||||
* Shift+Enter always submits, breaking PSReadline features [#530]
|
||||
* Powershell: Ctrl-Alt-? does not work in Windows Terminal [#3079]
|
||||
* Bug: ctrl+break is not ctrl+c [#1119]
|
||||
* Something wrong with keyboard modifiers processing? [#1694]
|
||||
* Numeric input not accepted by choice.exe [#3608]
|
||||
* Ctrl+Keys that can't be encoded as VT should still fall through as the unmodified character [#3483]
|
||||
* Modifier keys are not properly propagated to application hosted in Windows Terminal [#4334] / [#4446]
|
||||
|
||||
This spec covers a mechanism by which we can add support to ConPTY so that a
|
||||
terminal application could send `INPUT_RECORD`-like key events to conpty,
|
||||
enabling client applications to receive the full range of keys once again.
|
||||
Included at the bottom of this document is a collection of [options that were
|
||||
investigated](#options-considered) as a part of preparing this document.
|
||||
|
||||
## Considerations
|
||||
|
||||
When evaluating existing encoding schemes for viability, the following things
|
||||
were used to evaluate whether or not a particular encoding would work for our
|
||||
needs:
|
||||
|
||||
* Would a particular encoding be mixable with other normal VT processing easily?
|
||||
- How would the Terminal know when it should send a \<chosen_encoding> key vs
|
||||
a normally encoded one?
|
||||
- For ex, <kbd>Ctrl+space</kbd> - should we send `NUL` or
|
||||
\<chosen_encoding's version of ctrl+space>
|
||||
* If there's a scenario where Windows Terminal might _not_ be connected to a
|
||||
conpty, then how does conpty enable \<chosen_encoding>?
|
||||
* Is the goal "Full `INPUT_RECORD` fidelity" or "Make the above scenarios work"?
|
||||
- One could imagine having the Terminal special-case the above keys, and send
|
||||
the xterm modifyOtherKeys sequences just for those scenarios.
|
||||
- This would _not_ work for <kbd>shift</kbd> all by itself.
|
||||
- In my _opinion_, "just making the above work" is a subset of "full
|
||||
INPUT_RECORD", and inevitably we're going to want "full INPUT_RECORD"
|
||||
|
||||
The goal we're trying to achieve is communicating `INPUT_RECORD`s from the
|
||||
terminal to the client app via conpty. This isn't supposed to be a \*nix
|
||||
terminal compatible communication, it's supposed to be fundamentally Win32-like.
|
||||
|
||||
Keys that we definitely need to support, that don't have unique VT sequences:
|
||||
* <kbd>Ctrl+Space</kbd> ([#879], [#2865])
|
||||
* <kbd>Shift+Enter</kbd> ([#530])
|
||||
* <kbd>Ctrl+Break</kbd> ([#1119])
|
||||
* <kbd>Ctrl+Alt+?</kbd> ([#3079])
|
||||
* <kbd>Ctrl</kbd>, <kbd>Alt</kbd>, <kbd>Shift</kbd>, (without another keydown/up) ([#3608], [#4334], [#4446])
|
||||
|
||||
> 👉 NOTE: There are actually 5 types of events that can all be encoded as an
|
||||
> `INPUT_RECORD`. This spec primarily focuses on the encoding of
|
||||
> `KEY_EVENT_RECORD`s. It is left as a Future Consideration to add support for
|
||||
> the other types of `INPUT_RECORD` as other sequences, which could be done
|
||||
> trivially similarly to the following proposal.
|
||||
|
||||
## Solution Design
|
||||
|
||||
### Inspiration
|
||||
|
||||
The design we've settled upon is one that's highly inspired by a few precedents:
|
||||
* `Application Cursor Keys (DECCKM)` is a long-supported VT sequence which a
|
||||
client application can use to request a different input format from the
|
||||
Terminal. This is the DECSET sequence `^[[?1h`/`^[[?1l` (for enable/disable,
|
||||
respectively). This changes the sequences sent by keys like the Arrow keys
|
||||
from a sequence like `^[[A` to `^[OA` instead.
|
||||
* The `kitty` terminal emulator uses a similar DECSET sequence for enabling
|
||||
their own input format, which they call ["full mode"]. Similar to DECCKM, this
|
||||
changes the format of the sequences that the terminal should send for keyboard
|
||||
input. Their "full mode" contains much more information when keys are pressed
|
||||
or released (though, less than a full `INPUT_RECORD` worth of data). Instead
|
||||
of input being sent to the client as a CSI or SS3 sequence, this `kitty` mode
|
||||
uses "Application Program-Command" (or "APC") sequences , prefixed with `^[_`.
|
||||
* [iTerm2](https://www.iterm2.com/documentation-escape-codes.html) has a region
|
||||
of OSC's that they've carved for themselves all starting with the same initial
|
||||
parameter, `1337`. They then have a number of commands that all use the second
|
||||
parameter to indicate what command specific to iTerm2 they're actually
|
||||
implementing.
|
||||
|
||||
### Requesting `win32-input-mode`
|
||||
|
||||
An application can request `win32-input-mode` with the following private mode sequence:
|
||||
|
||||
```
|
||||
^[ [ ? 9001 h/l
|
||||
l: Disable win32-input-mode
|
||||
h: Enable win32-input-mode
|
||||
```
|
||||
|
||||
Private mode `9001` seems unused according to the [xterm
|
||||
documentation](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html). This is
|
||||
stylistically similar to how `DECKPM`, `DECCKM`, and `kitty`'s ["full mode"] are
|
||||
enabled.
|
||||
|
||||
> 👉 NOTE: an earlier draft of this spec used an OSC sequence for enabling these
|
||||
> sequences. This was abandoned in favor of the more stylistically consistent
|
||||
> private mode params proposed above. Additionally, if implemented as a private
|
||||
> mode, then a client app could query if this setting was set with `DECRQM`
|
||||
|
||||
When a terminal receives a `^[[?9001h` sequence, they should switch into
|
||||
`win32-input-mode`. In `win32-input-mode`, the terminal will send keyboard input
|
||||
to the connected client application in the following format:
|
||||
|
||||
### `win32-input-mode` sequences
|
||||
|
||||
The `KEY_EVENT_RECORD` portion of an input record (the part that's important for
|
||||
us to encode in this feature) is defined as the following:
|
||||
|
||||
```c++
|
||||
typedef struct _KEY_EVENT_RECORD {
|
||||
BOOL bKeyDown;
|
||||
WORD wRepeatCount;
|
||||
WORD wVirtualKeyCode;
|
||||
WORD wVirtualScanCode;
|
||||
union {
|
||||
WCHAR UnicodeChar;
|
||||
CHAR AsciiChar;
|
||||
} uChar;
|
||||
DWORD dwControlKeyState;
|
||||
} KEY_EVENT_RECORD;
|
||||
```
|
||||
|
||||
To encode all of this information, I propose the following sequence. This is a
|
||||
CSI sequence with a final terminator character of `_`. This character appears to
|
||||
only be used as a terminator for the [SCO input
|
||||
sequence](https://vt100.net/docs/vt510-rm/chapter6.html) for
|
||||
<kbd>Ctrl+Shift+F10</kbd>. This conflict isn't a real concern for us
|
||||
compatibility wise. For more details, see [SCO
|
||||
Compatibility](#SCO-compatibility) below.
|
||||
|
||||
```
|
||||
^[ [ Vk ; Sc ; Uc ; Kd ; Cs ; Rc _
|
||||
|
||||
Vk: the value of wVirtualKeyCode - any number. If omitted, defaults to '0'.
|
||||
|
||||
Sc: the value of wVirtualScanCode - any number. If omitted, defaults to '0'.
|
||||
|
||||
Uc: the decimal value of UnicodeChar - for example, NUL is "0", LF is
|
||||
"10", the character 'A' is "65". If omitted, defaults to '0'.
|
||||
|
||||
Kd: the value of bKeyDown - either a '0' or '1'. If omitted, defaults to '0'.
|
||||
|
||||
Cs: the value of dwControlKeyState - any number. If omitted, defaults to '0'.
|
||||
|
||||
Rc: the value of wRepeatCount - any number. If omitted, defaults to '1'.
|
||||
|
||||
```
|
||||
|
||||
> 👉 NOTE: an earlier draft of this spec used an APC sequence for encoding the
|
||||
> input sequences. This was changed to a CSI for stylistic reasons. There's not
|
||||
> a great body of reference anywhere that lists APC sequences in use, so there's
|
||||
> no way to know if the sequence would collide with another terminal emulator's
|
||||
> usage. Furthermore, using an APC seems to give a distinct impression that
|
||||
> this is some "Windows Terminal" specific sequence, which is not intended. This
|
||||
> is a Windows-specific sequence, but one that any Terminal/application could
|
||||
> use.
|
||||
|
||||
In this way, a terminal can communicate input to a connected client application
|
||||
as `INPUT_RECORD`s, without any loss of fidelity.
|
||||
|
||||
#### Example
|
||||
|
||||
When the user presses <kbd>Ctrl+F1</kbd> in the console, the console actually
|
||||
send 4 input records to the client application:
|
||||
* A <kbd>Ctrl</kbd> down event
|
||||
* A <kbd>F1</kbd> down event
|
||||
* A <kbd>F1</kbd> up event
|
||||
* A <kbd>Ctrl</kbd> up event
|
||||
|
||||
Encoded in `win32-input-mode`, this would look like the following:
|
||||
```
|
||||
^[[17;29;0;1;8;1_
|
||||
^[[112;59;0;1;8;1_
|
||||
^[[112;59;0;0;8;1_
|
||||
^[[17;29;0;0;0;1_
|
||||
|
||||
Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
|
||||
Down: 1 Repeat: 1 KeyCode: 0x70 ScanCode: 0x3b Char: \0 (0x0) KeyState: 0x28
|
||||
Down: 0 Repeat: 1 KeyCode: 0x70 ScanCode: 0x3b Char: \0 (0x0) KeyState: 0x28
|
||||
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20
|
||||
```
|
||||
|
||||
Similarly, for a keypress like <kbd>Ctrl+Alt+A</kbd>, which is 6 key events:
|
||||
```
|
||||
^[[17;29;0;1;8;1_
|
||||
^[[18;56;0;1;10;1_
|
||||
^[[65;30;0;1;10;1_
|
||||
^[[65;30;0;0;10;1_
|
||||
^[[18;56;0;0;8;1_
|
||||
^[[17;29;0;0;0;1_
|
||||
|
||||
Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
|
||||
Down: 1 Repeat: 1 KeyCode: 0x12 ScanCode: 0x38 Char: \0 (0x0) KeyState: 0x2a
|
||||
Down: 1 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: \0 (0x0) KeyState: 0x2a
|
||||
Down: 0 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: \0 (0x0) KeyState: 0x2a
|
||||
Down: 0 Repeat: 1 KeyCode: 0x12 ScanCode: 0x38 Char: \0 (0x0) KeyState: 0x28
|
||||
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20
|
||||
```
|
||||
|
||||
Or, for something simple like <kbd>A</kbd> (which is 4 key events):
|
||||
```
|
||||
^[[16;42;0;1;16;1_
|
||||
^[[65;30;65;1;16;1_
|
||||
^[[16;42;0;0;0;1_
|
||||
^[[65;30;97;0;0;1_
|
||||
|
||||
Down: 1 Repeat: 1 KeyCode: 0x10 ScanCode: 0x2a Char: \0 (0x0) KeyState: 0x30
|
||||
Down: 1 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: A (0x41) KeyState: 0x30
|
||||
Down: 0 Repeat: 1 KeyCode: 0x10 ScanCode: 0x2a Char: \0 (0x0) KeyState: 0x20
|
||||
Down: 0 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: a (0x61) KeyState: 0x20
|
||||
```
|
||||
|
||||
> 👉 NOTE: In all the above examples, I had my NumLock key off. If I had the
|
||||
> NumLock key instead pressed, all the KeyState parameters would have bits 0x20
|
||||
> set. To get these keys with a NumLock, add 32 to the value.
|
||||
|
||||
These parameters are ordered based on how likely they are to be used. Most of
|
||||
the time, the repeat count is not needed (it's almost always `1`), so it can be
|
||||
left off when not required. Similarly, the control key state is probably going
|
||||
to be 0 a lot of the time too, so that is second last. Even keydown will be 0 at
|
||||
least half the time, so that can be omitted some of the time.
|
||||
|
||||
Furthermore, considering omitted values in CSI parameters default to the values
|
||||
specified above, the above sequences could each be shortened to the following.
|
||||
|
||||
* <kbd>Ctrl+F1</kbd>
|
||||
```
|
||||
^[[17;29;;1;8_
|
||||
^[[112;59;;1;8_
|
||||
^[[112;59;;;8_
|
||||
^[[17;29_
|
||||
```
|
||||
|
||||
* <kbd>Ctrl+Alt+A</kbd>
|
||||
```
|
||||
^[[17;29;;1;8_
|
||||
^[[18;56;;1;10_
|
||||
^[[65;30;;1;10_
|
||||
^[[65;30;;;10_
|
||||
^[[18;56;;;8_
|
||||
^[[17;29;;_
|
||||
```
|
||||
|
||||
* <kbd>A</kbd> (which is <kbd>shift+a</kbd>)
|
||||
```
|
||||
^[[16;42;;1;16_
|
||||
^[[65;30;65;1;16_
|
||||
^[[16;42_
|
||||
^[[65;30;97_
|
||||
```
|
||||
|
||||
* Or even easier, just <kbd>a</kbd>
|
||||
```
|
||||
^[[65;30;97;1_
|
||||
^[[65;30;97_
|
||||
```
|
||||
|
||||
### Scenarios
|
||||
|
||||
#### User is typing into WSL from the Windows Terminal
|
||||
|
||||
`WT -> conpty[1] -> wsl`
|
||||
|
||||
* Conpty[1] will ask for `win32-input-mode` from the Windows Terminal when
|
||||
conpty[1] first boots up. Conpty will _always_ ask for win32-input-mode -
|
||||
Terminals that _don't_ support this mode will ignore this sequence on startup.
|
||||
* When the user types keys in Windows Terminal, WT will translate them into
|
||||
win32 sequences and send them to conpty[1]
|
||||
* Conpty[1] will translate those win32 sequences into `INPUT_RECORD`s.
|
||||
- When those `INPUT_RECORD`s are written to the input buffer, they'll be
|
||||
converted into VT sequences corresponding to whatever input mode the linux
|
||||
app is in.
|
||||
* When WSL reads the input, it'll read (using `ReadConsoleInput`) a stream of
|
||||
`INPUT_RECORD`s that contain only character information, which it will then
|
||||
pass to the linux application.
|
||||
- This is how `wsl.exe` behaves today, before this change.
|
||||
|
||||
#### User is typing into `cmd.exe` running in WSL interop
|
||||
|
||||
`WT -> conpty[1] -> wsl -> conpty[2] -> cmd.exe`
|
||||
|
||||
(presuming you start from the previous scenario, and launch `cmd.exe` inside wsl)
|
||||
|
||||
* Conpty[2] will ask for `win32-input-mode` from conpty[1] when conpty[2] first
|
||||
boots up.
|
||||
- As conpty[1] is just a conhost that knows how to handle
|
||||
`win32-input-mode`, it will switch its own VT input handling into
|
||||
`win32-input-mode`
|
||||
* When the user types keys in Windows Terminal, WT will translate them into
|
||||
win32 sequences and send them to conpty[1]
|
||||
* Conpty[1] will translate those win32 sequences into `INPUT_RECORD`s. When
|
||||
conpty[1] writes these to its buffer, it will translate the `INPUT_RECORD`s
|
||||
into VT sequences for the `win32-input-mode`. This is because it believes the
|
||||
client (in this case, the conpty[2] running attached to `wsl`) wants
|
||||
`win32-input-mode`.
|
||||
* When WSL reads the input, it'll read (using `ReadConsoleInput`) a stream of
|
||||
`INPUT_RECORD`s that contain only character information, which it will then
|
||||
use to pass a stream of characters to conpty[2].
|
||||
* Conpty[2] will get those sequences, and will translate those win32 sequences
|
||||
into `INPUT_RECORD`s
|
||||
* When `cmd.exe` reads the input, they'll receive the full `INPUT_RECORD`s
|
||||
they're expecting
|
||||
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
This is not a user-facing feature.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Accessibility
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Security
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Reliability
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
### Compatibility
|
||||
|
||||
This isn't expected to break any existing scenarios. The information that we're
|
||||
passing to conpty from the Terminal should strictly have _more_ information in
|
||||
them than they used to. Conhost was already capable of translating
|
||||
`INPUT_RECORD`s back into VT sequences, so this should work the same as before.
|
||||
|
||||
There's some hypothetical future where the Terminal isn't connected to conpty.
|
||||
In that future, the Terminal will still be able to work correctly, even with
|
||||
this ConPTY change. The Terminal will only switch into sending
|
||||
`win32-input-mode` sequences when _conpty asks for them_. Otherwise, the
|
||||
Terminal will still behave like a normal terminal emulator.
|
||||
|
||||
#### Terminals that don't support `?9001h`
|
||||
|
||||
Traditionally, whenever a terminal emulator doesn't understand a particular VT
|
||||
sequence, they simply ignore the unknown sequence. This assumption is being
|
||||
relied upon heavily, as ConPTY will _always_ emit a `^[[?9001h` on
|
||||
initialization, to request `win32-input-mode`.
|
||||
|
||||
#### SCO Compatibility
|
||||
|
||||
As mentioned above, the `_` character is used as a terminator for the [SCO input
|
||||
sequence](https://vt100.net/docs/vt510-rm/chapter6.html) for
|
||||
<kbd>Ctrl+Shift+F10</kbd>. This conflict would be a problem if a hypothetical
|
||||
terminal was connected to conpty that sent input to conpty in SCO format.
|
||||
However, if that terminal was only sending input to conpty in SCO mode, it would
|
||||
have much worse problems than just <kbd>Ctrl+Shift+F10</kbd> not working. If we
|
||||
did want to support SCO mode in the future, I'd even go so far as to say we
|
||||
could maybe treat a `win32-input-mode` sequence with no params as
|
||||
<kbd>Ctrl+Shift+F10</kbd>, considering that `KEY_EVENT_RECORD{0}` isn't really
|
||||
valid anyways.
|
||||
|
||||
#### Remoting `INPUT_RECORD`s
|
||||
|
||||
A potential area of concern is the fact that VT sequences are often used to
|
||||
remote input from one machine to another. For example, a terminal might be
|
||||
running on machine A, and the conpty at the end of the pipe (which is running
|
||||
the client application) might be running on another machine B.
|
||||
|
||||
If these two machines have different keyboard layouts, then it's possible that
|
||||
the `INPUT_RECORD`s synthesized by the terminal on machine A won't really be
|
||||
valid on machine B. It's possible that machine B has a different mapping of scan
|
||||
codes \<-> characters. A client that's running on machine B that uses win32 APIs
|
||||
to try and infer the vkey, scancode, or character from the other information in
|
||||
the `INPUT_RECORD` might end up synthesizing the wrong values.
|
||||
|
||||
At the time of writing, we're not really sure what a good solution to this
|
||||
problem would be. Client applications that use `win32-input-mode` should be
|
||||
aware of this, and be written with the understanding that these values are
|
||||
coming from the terminal's machine, which might not necessarily be the local
|
||||
machine.
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
## Potential Issues
|
||||
|
||||
_(no change expected)_
|
||||
|
||||
## Future considerations
|
||||
|
||||
* We could also hypothetically use this same mechanism to send Win32-like mouse
|
||||
events to conpty, since similar to VT keyboard events, VT mouse events don't
|
||||
have the same fidelity that Win32 mouse events do.
|
||||
- We could enable this with a different terminating character, to identify
|
||||
which type of `INPUT_RECORD` event we're encoding.
|
||||
* Client applications that want to be able to read full Win32 keyboard input
|
||||
from `conhost` _using VT_ will also be able to use `^[[?9001h` to do this. If
|
||||
they emit `^[[?9001h`, then conhost will switch itself into
|
||||
`win32-input-mode`, and the client will read `win32-input-mode` encoded
|
||||
sequences as input. This could enable other cross-platform applications to
|
||||
also use win32-like input in the future.
|
||||
|
||||
## Options Considered
|
||||
|
||||
_disclaimer: these notes are verbatim from my research notes in [#4999]_.
|
||||
|
||||
### Create our own format for `INPUT_RECORD`s
|
||||
|
||||
* If we wanted to do this, then we'd probably want to have the Terminal only
|
||||
send input as this format, and not use the existing translator to synthesize
|
||||
VT sequences
|
||||
- Consider sending a ctrl down, '^A', ctrl up. We wouldn't want to send this
|
||||
as three sequences, because conpty will take the '^A' and synthesize
|
||||
_another_ ctrl down, ctrl up pair.
|
||||
* With conpty passthrough mode, we'd still need the `InputStateMachineEngine`
|
||||
to convert these sequences into INPUT_RECORDs to translate back to VT
|
||||
* Wouldn't really expect client apps to ever _need_ this format, but it could
|
||||
always be possible for them to need it in the future.
|
||||
|
||||
#### Pros:
|
||||
* Definitely gets us all the information that we need.
|
||||
* Can handle solo modifiers
|
||||
* Can handle keydown and keyup separately
|
||||
* We can make the sequence however we want to parse it.
|
||||
|
||||
#### Cons:
|
||||
* No reference implementation, so we'd be flying blind
|
||||
* We'd be defining our own VT sequences for these, which we've never done
|
||||
before. This was _inevitable_, however, this is still the first time we'd be
|
||||
doing this.
|
||||
* By having the Terminal send all input as _this protocol_, VT Input passthrough
|
||||
to apps that want VT input won't work anymore for the Terminal. That's _okay_
|
||||
|
||||
### kitty extension
|
||||
[Reference](https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling)
|
||||
|
||||
#### Pros:
|
||||
* Not terribly difficult to decode
|
||||
* Unique from anything else we'd be processing, as it's an APC sequence
|
||||
(`\x1b_`)
|
||||
* From their docs:
|
||||
> All printable key presses without modifier keys are sent
|
||||
just as in the normal mode. ... For non printable keys and key combinations
|
||||
including one or more modifiers, an escape sequence encoding the key event is
|
||||
sent
|
||||
- I think I like this. ASCII and other keyboard layout chars (things that would
|
||||
hit `SendChar`) would still just come through as the normal char.
|
||||
|
||||
#### Cons:
|
||||
* Their encoding table is _odd_. [Look at
|
||||
this](https://sw.kovidgoyal.net/kitty/key-encoding.html). What order is that
|
||||
in? Obviously the first column is sorted alphabetically, but the mapping of
|
||||
key->char is in a certainly hard to decipher order.
|
||||
* I can't get it working locally, so hard to test 😐
|
||||
* They do declare the `fullkbd` terminfo capability to identify that they
|
||||
support this mode, but I'm not sure anyone else uses it.
|
||||
- I'm also not sure that any _client_ apps are reading this currently.
|
||||
* This isn't designed to be full `KEY_EVENT`s - where would we put the scancode
|
||||
(for apps that think that's important)?
|
||||
- We'd have to extend this protocol _anyways_
|
||||
|
||||
### `xterm` "Set key modifier options"
|
||||
Notably looking at
|
||||
[`modifyOtherKeys`](https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:modifyOtherKeys).
|
||||
|
||||
#### Pros:
|
||||
* `xterm` implements this so there's a reference implementation
|
||||
* relatively easy to parse these sequences. `CSI 27 ; <modifiers> ; <key> ~`
|
||||
|
||||
#### Cons:
|
||||
* Only sends the sequence on key-up
|
||||
* Doesn't send modifiers all on their own
|
||||
|
||||
### `DECPCTERM`
|
||||
[VT100.net doc](https://vt100.net/docs/vt510-rm/DECPCTERM.html)
|
||||
|
||||
#### Pros:
|
||||
* Enables us to send key-down and key-up keys independently
|
||||
* Enables us to send modifiers on their own
|
||||
* Part of the VT 510 standard
|
||||
|
||||
#### Cons:
|
||||
* neither `xterm` nor `gnome-terminal` (VTE) seem to implement this. I'm not
|
||||
sure if anyone's got a reference implementation for us to work with.
|
||||
* Unsure how this would work with other keyboard layouts
|
||||
- [this doc](https://vt100.net/docs/vt510-rm/chapter8.html#S8.13) seems to
|
||||
list the key-down/up codes for all the en-us keyboard keys, but the
|
||||
scancodes for these are different for up and down. That would seem to
|
||||
imply we couldn't just shove the Win32 scancode in those bits
|
||||
|
||||
### `DECKPM`, `DECSMKR`
|
||||
[DECKPM](https://vt100.net/docs/vt510-rm/DECKPM.html)
|
||||
[DECSMKR](https://vt100.net/docs/vt510-rm/DECSMKR.html)
|
||||
[DECEKBD](https://vt100.net/docs/vt510-rm/DECEKBD.html)
|
||||
|
||||
#### Pros:
|
||||
* Enables us to send key-down and key-up keys independently
|
||||
* Enables us to send modifiers on their own
|
||||
* Part of the VT 510 standard
|
||||
|
||||
#### Cons:
|
||||
* neither `xterm` nor `gnome-terminal` (VTE) seem to implement this. I'm not
|
||||
sure if anyone's got a reference implementation for us to work with.
|
||||
* not sure that "a three-character ISO key position name, for example C01" is
|
||||
super compatible with our Win32 VKEYs.
|
||||
|
||||
|
||||
### `libtickit` encoding
|
||||
[Source](http://www.leonerd.org.uk/hacks/fixterms)
|
||||
|
||||
#### Pros:
|
||||
* Simple encoding scheme
|
||||
|
||||
#### Cons:
|
||||
* Doesn't differentiate between keydowns and keyups
|
||||
* Unsure who implements this - not extensively investigated
|
||||
|
||||
|
||||
## Resources
|
||||
|
||||
* The initial discussion for this topic was done in [#879], and much of the
|
||||
research of available options is also available as a discussion in [#4999].
|
||||
* [Why Is It so Hard to Detect Keyup Event on Linux?](https://blog.robertelder.org/detect-keyup-event-linux-terminal/)
|
||||
- and the [HackerNews discussion](https://news.ycombinator.com/item?id=19012132)
|
||||
* [ConEmu specific OSCs](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)
|
||||
* [iterm2 specific sequences](https://www.iterm2.com/documentation-escape-codes.html)
|
||||
* [terminal-wg draft list of OSCs](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/10)
|
||||
|
||||
<!-- Footnotes -->
|
||||
[#530]: https://github.com/microsoft/terminal/issues/530
|
||||
[#879]: https://github.com/microsoft/terminal/issues/879
|
||||
[#1119]: https://github.com/microsoft/terminal/issues/1119
|
||||
[#1694]: https://github.com/microsoft/terminal/issues/1694
|
||||
[#2865]: https://github.com/microsoft/terminal/issues/2865
|
||||
[#3079]: https://github.com/microsoft/terminal/issues/3079
|
||||
[#3483]: https://github.com/microsoft/terminal/issues/3483
|
||||
[#3608]: https://github.com/microsoft/terminal/issues/3608
|
||||
[#4334]: https://github.com/microsoft/terminal/issues/4334
|
||||
[#4446]: https://github.com/microsoft/terminal/issues/4446
|
||||
[#4999]: https://github.com/microsoft/terminal/issues/4999
|
||||
|
||||
[`INPUT_RECORD`]: https://docs.microsoft.com/en-us/windows/console/input-record-str
|
||||
|
||||
["full mode"]: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.9 KiB After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.1 KiB After Width: | Height: | Size: 11 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user