Compare commits

..

41 Commits

Author SHA1 Message Date
Dustin L. Howett
3add65228d Migrate spelling-0.0.21 changes from main 2021-02-17 13:00:50 -08:00
Dustin L. Howett
dae07a11b6 Migrate spelling-0.0.19 changes from main 2021-02-17 13:00:50 -08:00
Javier
ae23d37dca wpf: prevent a 0 size when VS builds the Terminal window too early (#9194)
The terminal WPF container might have a (0,0) render size when VS
eagerly attempts to initialize the terminal tool window when it is
pinned during startup, but no actual UI is shown due to the VS welcome
dialog that shows up before VS can build the terminal tool window.

We've fixed this issue previously in other areas but only recently did
we get a complete enough dump to find the corner cases for this issue.

This should patch all the gaps that cause this bug.

## Validation Steps Performed
I've manually validated the scenarios shown in the user dumps.

(cherry picked from commit 12eb69f665)
2021-02-17 13:05:59 -08:00
Dustin L. Howett
5fdd1560fd [1.5 ONLY] Remove the close submenu (#9102)
There's a platform issue that causes it to crash.
Fixes #8944.
2021-02-10 11:28:22 -08:00
Sarim Khan
3b876cc0b5 fix tab title propagation issues (#9054)
- Fixes empty app title when  `showTerminalTitleInTitlebar` is false
- Fixes Tab title propagation to Window title when
  `showTerminalTitleInTitlebar` is false
- Fixes Tab title propagation to Window - title doesn't update when
  Window is unfocused

1. There were a missing
   `_settings.GlobalSettings().ShowTitleInTitlebar()` check. Because of
   this Title update event was being fired even when
   `showTerminalTitleInTitlebar` is false. This results in empty tab
   title to propagate to Window title. Also then after switching tabs
   back and forth, tab title propagates to window title. These shouldn't
   propagate when `showTerminalTitleInTitlebar` is false. I added the
   `showTerminalTitleInTitlebar` check in relevant logic to fix the
   behavior.

2. Code was checking `tab.FocusState() != FocusState::Unfocused` , but
   when the whole terminal window is not in focus, the active tab is
   also in Unfocused state. This was preventing tab title to propagate
   to window title when application is unfocused. I added the logic of
   checking matching selected tabs' index. This fixes the issue.

## Validation Steps Performed
I did the reproduce steps descripted in the issue to reproduce the bugs.
After applying the fixes, the bugs don't appear anymore while doing the
reproduce steps.

Closes #8704

(cherry picked from commit 47881a802f)
2021-02-09 11:45:12 -08:00
Dustin L. Howett
970d441a52 Update Cascadia Code to 2102.03 (#9088)
The February 2021 update of Cascadia Code fixes 23 issues and
introduces support for infinite arrow ligatures and control pictures.

(cherry picked from commit 6af49a5246)
2021-02-09 11:44:27 -08:00
Carlos Zamora
d86f5c1f74 Generate settings.json if deleted while WT is open (#9012)
The settings.json was not regenerated if WT was already open. This resulted in the `ShellExecute` from trying to open the settings to pop up Notepad and say that this file didn't exist. We now detect if the settings.json was deleted to kick off loading the settings.

Closes #8955

(cherry picked from commit a5931fbead)
2021-02-04 16:45:28 -08:00
Mike Griese
84a5b668c1 Manually initialize the warnings vector to prevent a crash on launch (#8995)
## Summary of the Pull Request

Oops, winrt `IVector`s need to be manually initialized, when default-constructed `std::vector`s didn't. Simple oversight.

## PR Checklist
* [x] Closes #8986
* [x] I work here
* [x] A test would be great but ain't nobody got time for that.
* [n/a] Requires documentation to be updated

## Validation Steps Performed
Ran the terminal with
```json

    "schemes" :
    [ {} ]
```
First the crash repro'd, now it doesn't.

(cherry picked from commit 9d71fa817d)
2021-02-04 16:45:28 -08:00
James Holderness
ee83677122 Fix crash in terminal when tab closed while data is being output (#8982)
If there is data being output when a tab is closed, that can sometimes
result in the application crashing, because the renderer may still be in
use at the time is it destroyed. This PR attempts to prevent that from
happening by adding a lock in the `TermControl::Close` method.

What we're trying to prevent is the connection thread still being
active, and potentially accessing the renderer, after it has been
destroyed. So by acquiring the terminal lock in `TermControl::Close`,
after we've stopped accepting new output, we can be sure that the
connection thread is no longer active (it holds the lock while it is
processing output). So once we've acquired and released the lock, it
should be safe to tear down and destroy the renderer.

## Validation Steps Performed

While this crash is difficult to reproduce in general usage, it occurred
quite frequently when testing my `DECPS` implementation (there is some
tricky thread synchronisation, which seems more likely to trigger the
issue). With this patch applied, though, those crashes have stopped
occurring.

I've also stepped through the shutdown code in the debugger, manually
freezing threads to get them aligned in the right way to trigger the
crash (as explained in issue #8734). Again with the patch applied, I can
no longer get the crash to occur.

Closes #8734

(cherry picked from commit 40ebe5ab54)
2021-02-04 16:45:28 -08:00
hereafter
2594edcec0 Fix crash in explorer background context menu logic (#8977)
Fix a bug brought in with PR: #8638

see,
#8936
#8638

* [x] Closes #8936
* [x] CLA signed
* [x] Tests passed

With the help from @nc-x, the issue is reproduced and fixed by this patch.

CLSCTX_IN_PROCESS is not good enough for all cases to create IShellWindows interface.
Put a CLSCTX_ALL fixes the issue.

Another debugging warning dialogs  for reusing not null com_ptr in the loop is fixed too.
(This was shown in debug builds only)

(cherry picked from commit e207236713)
2021-02-04 16:45:28 -08:00
Javier
b092bdd42c wpf: Add a TerminalControlSize emptiness check (#8906)
Watson reports show that an "ArgumentException" is being thrown due to `renderSize`
not being valid. Added a check for renderSize before attempting to resize.

(cherry picked from commit 96e0232603)
2021-01-27 11:07:57 -08:00
Michael Niksa
2568a7cef2 Cleanup NuGet.Config file. (#8829)
Cleans up a ton of competing and outdated sources from our NuGet.Config to improve reliability and maintainability.

## PR Checklist
* [x] Closes an overdue-to-clean mess.
* [x] I work here.
* [x] Tests covered below.
* [x] I've discussed this with @DHowett already.

## Validation Steps Performed
- [x] - NuGet restored everything I could get my hands on (all `packages.config`) in our project before and after the change.
- [x] - The build and tests still run fine. (PR automation should check this one)

(cherry picked from commit 0fa286c011)
2021-01-25 12:54:14 -08:00
Don-Vito
bda1494394 Fix tab selection to bring the tab into view (#8832)
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/3638
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already.

##Detailed Description of the Pull Request / Additional comments
A workaround for https://github.com/microsoft/microsoft-ui-xaml/issues/3945.
Thanks to @michael-hawker and @chingucoding for the suggested solution.

(cherry picked from commit 12b12d5b07)
2021-01-25 12:54:14 -08:00
Javier
118195a970 Added negative value check for resize newsize (#8792)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Adds a negative value check for when the terminal window is hidden/show in VS

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
[Bug 1265984](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1265984): [Terminal] VS crashes when clicking the hidden terminal tab

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] 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.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual validation.

(cherry picked from commit 9aea904229)
2021-01-25 12:54:08 -08:00
Don-Vito
fd2b3f7632 Fix right-click paste to clear current selection (#8742)
Closes #8729

(cherry picked from commit 20fc57ee0f)
2021-01-25 12:54:08 -08:00
Don-Vito
2692874c71 Teach flyouts and palette to prefer user bindings over defaults (#8725)
Store the order of the bindings and upon lookup prefer the binding
that was added last.
The defaults will always "loose" to user overrides.

Closes #2991

(cherry picked from commit 058cbd11e7)
2021-01-25 12:54:07 -08:00
PankajBhojwani
a205f4547d Fix multi line paste detection and filtering (#8634)
- Detect `\r` when warning about multi line paste
- Translate `\n` to `\r` on paste

## PR Checklist
* [x] Closes #8601
* [x] Closes #5821

## Validation Steps Performed
Manual testing

(cherry picked from commit 49d008537f)
2021-01-25 12:54:07 -08:00
Dustin L. Howett
944fddbbe9 winconpty: close the pty host handle after terminating it (#8707)
It rather raises the question as to how we missed this.

Closes #8706

(cherry picked from commit 8bef5eefd5)
2021-01-25 12:54:07 -08:00
Sato Kenta
677ab36a8a Fix color animation bug of title bar buttons (#8649)
In dark mode (and high contrast mode), color animation of title bar
button uses wrong color.  Cause of this issue is using invalid data in
`ColorAnimation`.  I fixed this bug by changing `ColorAnimation` value
in XAML layout file.

According to a [forum post], `To` value of `ColorAnimation` must be
frozen. But original source code uses "color binding" which makes this
value dynamic.  As a result, the value set by default is always used,
that means, light mode.

So I added new resource named `CaptionButtonStrokeColor` and
`CaptionButtonBackgroundColor` which has static color value.

In light mode and dark mode, I set `SystemBaseHighColor` in the color
resource.  `SystemBaseHighColor` is the same as
`SystemControlForegroundBaseHighBrush.Color` which is originally used in
animation.

The background color animation happened to work correctly because its
value is the same between light mode and dark mode.  But I also fixed
background color animation.

## Validation Steps Performed

There is no need to add new test with this fix.

- I changed the `theme` value in `settings.json` and confirmed that the
  correct color values were used.
- I confirmed that it works correctly even if the Windows theme is
  changed.

[forum post]: https://social.msdn.microsoft.com/Forums/vstudio/en-US/027c364f-5d75-424f-aafd-7fb76b10b676/templatebinding-on-storyboard?forum=wpf

Closes #7314

(cherry picked from commit 713027b5e3)
2021-01-25 12:54:07 -08:00
hereafter
334e518773 make "open terminal here" context menu work for directory background (#8638)
This commit makes "Open in Windows Terminal" Context menu work again for
directory background even on system that OS fix is not applied.

This is a fallback solution to OS fixes mentioned in #6414.
While OS fix is on its way, we need a fallback that works on existing OS
versions.

The approach to this is: when no item is selected (nullptr for
IShellItemArray*), we use shell api to query the path of current active
Explorer window. A special case is handled for Windows Desktop. Once
we are able to obtain the path, we launch Windows Terminal with it.

1. Right click on desktop to bring up the Context menu, pick "Open in
   Windows Terminal", verify that a terminal is opened with correct
   initial path.

2. Open a few File Explorer windows, pick any window, navigate to a
   folder, click on "Background" to bring up the context menu, click
   "Open in Windows Terminal" verify that a terminal is opened with
   correct initial path.

Closes #6414

(cherry picked from commit fcca88ab25)
2021-01-25 12:54:04 -08:00
Kiminori Kaburagi
9e9c0bea83 Calculate initial height properly (#8584)
Closes #8527

(cherry picked from commit e943785e1a)
2021-01-25 12:53:26 -08:00
Mike Griese
5f29f7603d Replace the KB Dialog with a InfoBar (#8524)
This changes the keyboard warning from a dialog to an `InfoBar`, which
we just got in MUX 2.5. Some users were unhappy that we'd always display
the dialog. We learned from the input team that this service _should_
always be enabled. We're also learing from users that they don't always
want it enabled.

We're working with the Input team to help us figure out how this service
can be disabled _and the Terminal work just fine_. They're confident
that it _shouldn't_. For 99% of our users, they're right. So we don't
want to get rid of the dialog entirely, we want to understand how this
is possible. While we wait, let's make the message less aggressive.

This is instead of making a `iKnowWhatImDoingDisableTheKeyboardWarning`
setting to disable the dialog. Props to @cornem for suggesting the less
aggressive solution.

## Validation Steps Performed
Tested manually, but by forcing the message to always display. Disabling
the service requires two full reboots, and _ain't nobody got time for
that_.

Closes #8228
Closes #4448, for now

(cherry picked from commit ff5b2b84d2)
2021-01-25 12:53:26 -08:00
Kiminori Kaburagi
ceb0551066 Change tab close and rename icons to better fit the UI (#8424)
Closes #8419

Co-authored-by: KiminoriKaburagi <heipo_nogu@outlook.jp>
(cherry picked from commit 6952f1acda)
2021-01-25 12:53:26 -08:00
Dustin L. Howett
c17fdf07ee Update to Microsoft.UI.Xaml 2.5 "stable" (#8500)
This commit moves us to the Xaml prerelease (201202003) that is
equivalent to public stable release 2.5.

Remember, we need to use prereleases for some silly reason.

(cherry picked from commit 87492c4a26)
2021-01-25 12:53:26 -08:00
James Holderness
a315fd5f62 Correct horizontal coordinates in viewport overflow test (#8456)
When resizing the buffer in the `SetConsoleScreenBufferSize` and
`SetConsoleScreenBufferInfoEx` APIs, we have tests in place to make sure
that the resize doesn't result in the viewport extending past the bottom
or right of the buffer (since that can eventually result in exceptions
being thrown). Unfortunately these tests were using the wrong X
coordinate, so they failed to detect an overflow along the horizontal
axis. This PR corrects that mistake.

PR #8309 was where the overflow detection was initially added.

The original code was using the `Viewport::EndExclusive` method to
determine the extent of the viewport, mistakenly thinking that it
returned the bottom right coordinates (it actually returns the left
coordinate). So I've now added a `BottomRightExclusive` method to the
`Viewport` class, that actually does return the coordinates we need, and
have updated the overflow tests to use that method instead.

## Validation Steps Performed
I've manually confirmed that the test case is issue #8453 is no longer
throwing an exception.

Closes #8453

(cherry picked from commit 2a2f6b32a2)
2021-01-25 12:53:25 -08:00
Chester Liu
305946caa0 Improve clipboard handling in "drag and drop" scenario (#8461)
This PR improves the clipboard handling logic of "drag and drop" in
TermControl, making it more useful and less likely to crash.

* Added support for two more categories of content, `ApplicationLink`
  and `WebLink`.
* Reordered the ifs, making `StorageItem` the last clause. With WT being
  a text-oriented application, I think we can safely assume that the
  content being pasted is likely to be text/links.
* Catch possible exceptions during
  `e.DataView().GetStorageItemsAsync()`.

Closes #7804

(cherry picked from commit 60f1b0b285)
2021-01-25 12:53:25 -08:00
Dustin L. Howett
cadca1e839 Fix the xterm and SGR mouse encodings for CTRL, ALT, SHIFT (#8379)
We had the xterm and SGR codings for meta/ctrl backwards. Oops.

This commit also fixes an observed issue in Windows Terminal where we
were passing in a console-style modifiers enum when MouseInput is
expecting MK_ constants.

I decided to unify MouseInput around the console-style modifier
constants because they have support for META (which MK_ does not) and
can differentiate between left/right alt/ctrl.

Our tests are fundamentally flawed here: they use a copy of the
modifier key generating logic _themselves_, so we got a bit of "error
carried forward."

I did not fix the tests to use known-good control sequences, I simply
replaced the character generator with another copy of the modifier code.
I did, however, extend them to test ctrl|meta and left/right modifiers.

Fixes #8291

(cherry picked from commit b1e1c7cdf4)
2021-01-25 12:53:25 -08:00
Don-Vito
c5e1bbdd25 Fix a race condition in pane animation completion that broke sizing (#8241)
Fixes a race in pane entrance animation, where the animation
completion routine processes wrong children.

Validated w/ manual testing

Closes #8230

(cherry picked from commit c41e078e85)
2021-01-25 12:53:25 -08:00
Don-Vito
817df81f48 Fix combining wt args and "wt new-tab" args in implicit context (#8315)
Currently when implicit tab command is specified (i.e., we have
parameters for new-tab, but don't have the explicit subcommand name) we
fallback to parsing the entire arg list as new tab command.

However, if we also have a launch profile (or anything else that might in
the future belong to the upper scope) it is passed as a parameter to the
new tab command, failing the parsing.

The idea behind my solution is to run the parser as a prefix command -
i.e., as long as we succeed to parse [options] / [subcommand] we will
parse them (populating the fields like a launch mode), but once we will
discover something unfamiliar, like profile, we will know that the
prefix is over and will handle the remaining suffix as a new tab
command.

## Validation Steps Performed
* UT added
* Manual run of different options

Closes #7318

(cherry picked from commit 435e45726e)
2021-01-25 12:53:25 -08:00
D. Cheatham
a388adf50a Fix close button not using the tab's text color (#8046) (#8209)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This sets the tab close button color to match the tab text color.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#8046
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #8046
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] 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: #8046

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
This sets the tab close button color to match the tab text color.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Test light theme white tab mouse hover effect:
![Screenshot_2020-11-07_152110_3](https://user-images.githubusercontent.com/7143383/98640319-ec735e80-22de-11eb-8d35-08188405b566.png)

Test dark theme white tab mouse hover effect:
![Screenshot_2020-11-07_153021_2](https://user-images.githubusercontent.com/7143383/98640377-f006e580-22de-11eb-9bb5-dde9fe9b81b6.png)

(cherry picked from commit 2a340802dc)
2021-01-25 12:53:25 -08:00
James Holderness
5fb99657ea Fix out-of-bounds exceptions in Set...{Buffer,Screen}Size (#8309)
This fixes a number of exceptions that can cause conhost to crash when
the buffer is resized in such a way that the viewport or cursor position
end up out of bounds.

Technically this is a fix for issue #256, although that has been closed
as "needs-repro".

The main fix was to add checks in the `SetConsoleScreenBufferSizeImpl`
and `SetConsoleScreenBufferInfoExImpl` methods, to make sure the
viewport doesn't extend past the bottom or right of the buffer after a
resize. If it has overflowed, we move the viewport back up or left until
it's back within the buffer boundaries. We also check if the cursor
position has ended up out of bounds, and if so, clamp it back inside the
buffer.

The `SCREEN_INFORMATION::SetViewport` was also a source of viewport
overflow problems, because it was mistakenly using inclusive coordinates
in its range checks, which resulted in them being off by one. That has
now been corrected to use exclusive coordinates.

Finally, the `IsCursorDoubleWidth` method was incorrectly marked as
`noexcept`, which was preventing its exceptions from being caught.
Ideally it shouldn't be throwing exceptions at all any more, but I've
removed the `noexcept` specifier, so if it does throw an exception,
it'll at least have more chance of recovering without a crash.

## Validation Steps Performed

I put together a few test cases (based on the reports in issues #276 and
#1976) which consistently caused conhost to crash, or to generate an
exception visible in the debug output. With this PR applied, those test
cases are no longer crashing or triggering exceptions.

Closes #1976

(cherry picked from commit 9a070490d4)
2021-01-25 12:53:25 -08:00
Don-Vito
12c100cdb0 Prevent resizing terminal to a lower-than-minimum width (#8066)
Until now, we relied on WM_SIZING to ensure that the island is not
downsized below minimal allowed dimensions. However, on some occasions
WM_WINDOWPOSCHANGED, e.g. when anchoring a window to the top/bottom of
the screen. This message will use dimensions obtained from
WM_GETMINMAXINFO. Until now we didn't override this value, falling back
to the defaults. As a result we got an inconsistent behavior (at least
when attaching the anchor).

I added logic very similar to the one we use in IslandWindow::_OnSizing
to the MINMAXINFO handler: snap the client area, add non client
exclusive are, consider DPI along the computation.

* Manual testing of minimizing, maximizing, resizing, attaching
  different anchors, etc.

Closes #8026

(cherry picked from commit e3fcfccc52)
2021-01-25 12:53:22 -08:00
Don-Vito
431559fd83 Avoid an access violation in pane animation if the child is closed (#8218)
Some UTs crash with access violation, that occurs during pane animation.
The reason for this is a race, upon which the pane is closed (set to
nullptr) before the parent is animated.  Added a simple check against
null.  Doubt it can happen in production, yet worth taking care!

(cherry picked from commit 5a942bcb6f)
2021-01-25 12:53:06 -08:00
Dustin Howett
109f9c451f Revert "Always create a new environment block before we spawn a process (#7243)"
This reverts commit 849243af99.

References #7418

(cherry picked from commit 4204d2535c)
(cherry picked from commit fce00ff8f6)
2021-01-25 12:48:40 -08:00
Dustin Howett
95b9b7c852 Revert "Fix environment block creation (#7401)"
This reverts commit 7886f16714.

(cherry picked from commit e46ba65665)
(cherry picked from commit d1b26085e1)
2021-01-25 12:48:25 -08:00
Mike Griese
f3cdf6841f Change the default tab switch mode back to inOrder (#8326)
We changed the default to "mru", and that was unkind to all our existing users.

(cherry picked from commit a52a1d3b8d)
2020-11-19 16:01:10 -08:00
Don-Vito
1228897071 Fix default backgroundImageStretch to be uniformToFill (#8280)
This commit fixes the default value to comply with documentation.

Closes #8256

(cherry picked from commit 77a204b765)
2020-11-19 16:01:10 -08:00
Bhaskar Shankarling
0300b31117 align command palette prefix > to left when visible (#8279)
Fixes the clear button to clear the typed command not clickable in the
command palette.

- From the primary investigation it looked like the `TextBlock` element
  introduced in #7935 was somehow blocking (appearing on top of) the
  clear button.
- It was also blocking the command palette input field from being able
  to access which was preventing the text in the input field from being
  selected and the cursor would still show as `pointer` cursor instead
  of a `text selection` cursor
- Adding `HorizontalAlignment="Left"` property to the above-mentioned
  `TextBlock` element fixed the issue.

## Validation Steps Performed
- Created the Dev build for `x64` in Visual Studio and verified the
  functionality manually.

Closes #8220

(cherry picked from commit a8f3f584a0)
2020-11-19 16:01:10 -08:00
Travis Hester
368fa17c2d 8249: Remove trailing commas in profiles.schema.json (#8257)
Fixes https parsing of the latest version of `profiles.schema.json`, particularly by VS Code Intellisense.

* [x] Closes #8249

The VS Code parsing warning below is a known and unrelated existing issue due to VS Code only supporting JSON Schema Draft 7. It does not prevent Intellisense from functioning.

> Draft 2019-09 schemas are not yet fully supported.

## Validation Steps Performed

Manually tested and successfully validated by fixing a local copy of `profiles.schema.json` and defining it as `$schema` in `settings.json`

(cherry picked from commit d28a4da596)
2020-11-19 16:01:09 -08:00
Don-Vito
c7607417d3 8247: Custom key bindings are broken for tab navigation (#8250)
There are two code paths for Ctrl+Tab and for everything else:

Ctrl + Tab is working perfectly
* On the first tab navigation TerminalPage::_SelectNextTab resets the
  tab commands, and since palette is not visible selects the relevant
  tab index
* On the second navigation Ctrl+Tab is intercepted by
  CommandPalette::_previewKeyDownHandler and everything works fine

But with custom binding things are screwed:
* On the first tab navigation TerminalPage::_SelectNextTab resets the
  tab commands, and since palette is not visible selects the relevant
  tab index
* On the second navigation keys are not intercepted and thus
  TerminalPage::_SelectNextTab is called again. It resets the commands,
  but now since the palette is visible we simply invoke
  CommandPalette::SelectNextItem. Which in turn misbehaves because no
  item is selected.

The approach for the solution is not to reset anything if the command
palette is already open.

## Validation Steps Performed
* Manual testing of both custom and non-custom bindings with different
  amount of tabs.

Closes #8247

(cherry picked from commit 0437fe9d8e)
2020-11-19 16:01:09 -08:00
Don-Vito
204c9d2cf4 Make sure to disable pane entrance animation if user requests (#8237)
We were only checking app animations during pane _exit_.

(cherry picked from commit e80108118d)
2020-11-19 16:01:09 -08:00
1711 changed files with 20087 additions and 211342 deletions

View File

@@ -1,12 +0,0 @@
{
"version": 1,
"isRoot": true,
"tools": {
"XamlStyler.Console": {
"version": "3.2008.4",
"commands": [
"xstyler"
]
}
}
}

54
.github/ISSUE_TEMPLATE/Bug_Report.md vendored Normal file
View File

@@ -0,0 +1,54 @@
---
name: "Bug report 🐛"
about: Report errors or unexpected behavior
title: ''
labels: ''
assignees: ''
---
<!--
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.
All good? Then proceed!
-->
<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.
**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.
If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.
Please use this form and describe your issue, concisely but precisely, with as much detail as possible.
-->
# Environment
```none
Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):
Any other software?
```
# Steps to reproduce
<!-- A description of how to trigger this bug. -->
# Expected behavior
<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->
# Actual behavior
<!-- What's actually happening? -->

View File

@@ -1,53 +0,0 @@
name: "Bug report 🐛"
description: Report errors or unexpected behavior
body:
- type: markdown
attributes:
value: |
Please make sure to [search for existing issues](https://github.com/microsoft/terminal/issues) and [check the FAQ](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)) before filing a new one!
If this is an application crash, please also provide a [Feedback Hub](https://aka.ms/terminal-feedback-hub) submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal" and choose "Share My Feedback" after submission to get the link.
- type: input
attributes:
label: Windows Terminal version (or Windows build number)
placeholder: "10.0.19042.0, 1.7.3651.0"
description: |
If you are reporting an issue in Windows Terminal, you can find the version in the about dialog.
If you are reporting an issue with the Windows Console, please run `ver` or `[Environment]::OSVersion`.
validations:
required: true
- type: textarea
attributes:
label: Other Software
description: If you're reporting a bug about our interaction with other software, what software? What versions?
placeholder: |
vim 8.2 (inside WSL)
OpenSSH_for_Windows_8.1p1
My Cool Application v0.3 (include a code snippet if it would help!)
validations:
required: false
- type: textarea
attributes:
label: Steps to reproduce
placeholder: Tell us the steps required to trigger your bug.
validations:
required: true
- type: textarea
attributes:
label: Expected Behavior
description: If you want to include screenshots, paste them into the markdown editor below.
placeholder: What were you expecting?
validations:
required: false
- type: textarea
attributes:
label: Actual Behavior
placeholder: What happened instead?
validations:
required: true

View File

@@ -1,4 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="vswhere" version="2.6.7" />
</packages>
</packages>

View File

@@ -1,13 +0,0 @@
{
// See https://go.microsoft.com/fwlink/?LinkId=827846 to learn about workspace recommendations.
// Extension identifier format: ${publisher}.${name}. Example: vscode.csharp
// List of extensions which should be recommended for users of this workspace.
"recommendations": [
"ms-vscode.cpptools"
],
// List of extensions recommended by VS Code that should not be recommended for users of this workspace.
"unwantedRecommendations": [
]
}

24
.vscode/launch.json vendored
View File

@@ -1,24 +0,0 @@
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Debug OpenConsole by Launching (x64, debug)",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceFolder}\\bin\\x64\\debug\\openconsole.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
},
{
"name": "Debug Terminal by Attaching (You go build/register/launch it first.)",
"type": "cppvsdbg",
"request": "attach",
"processId": "${command:pickProcess}"
}
]
}

105
.vscode/settings.json vendored
View File

@@ -1,105 +0,0 @@
{
"C_Cpp.default.browse.databaseFilename": "${workspaceFolder}\\.vscode\\.BROWSE.VC.DB",
"C_Cpp.default.browse.path": [
"${workspaceFolder}"
],
"C_Cpp.loggingLevel": "None",
"files.associations": {
"xstring": "cpp",
"*.idl": "cpp",
"array": "cpp",
"future": "cpp",
"istream": "cpp",
"memory": "cpp",
"tuple": "cpp",
"type_traits": "cpp",
"utility": "cpp",
"variant": "cpp",
"xlocmes": "cpp",
"xlocmon": "cpp",
"xlocnum": "cpp",
"xloctime": "cpp",
"multi_span": "cpp",
"pointers": "cpp",
"vector": "cpp",
"bitset": "cpp",
"deque": "cpp",
"initializer_list": "cpp",
"list": "cpp",
"queue": "cpp",
"random": "cpp",
"regex": "cpp",
"stack": "cpp",
"xhash": "cpp",
"xtree": "cpp",
"xutility": "cpp",
"span": "cpp",
"string_span": "cpp",
"algorithm": "cpp",
"atomic": "cpp",
"bit": "cpp",
"cctype": "cpp",
"charconv": "cpp",
"chrono": "cpp",
"clocale": "cpp",
"cmath": "cpp",
"compare": "cpp",
"complex": "cpp",
"concepts": "cpp",
"condition_variable": "cpp",
"cstdarg": "cpp",
"cstddef": "cpp",
"cstdint": "cpp",
"cstdio": "cpp",
"cstdlib": "cpp",
"cstring": "cpp",
"ctime": "cpp",
"cwchar": "cpp",
"cwctype": "cpp",
"exception": "cpp",
"filesystem": "cpp",
"fstream": "cpp",
"functional": "cpp",
"iomanip": "cpp",
"ios": "cpp",
"iosfwd": "cpp",
"iostream": "cpp",
"iterator": "cpp",
"limits": "cpp",
"locale": "cpp",
"map": "cpp",
"memory_resource": "cpp",
"mutex": "cpp",
"new": "cpp",
"numeric": "cpp",
"optional": "cpp",
"ostream": "cpp",
"ratio": "cpp",
"set": "cpp",
"shared_mutex": "cpp",
"sstream": "cpp",
"stdexcept": "cpp",
"stop_token": "cpp",
"streambuf": "cpp",
"string": "cpp",
"system_error": "cpp",
"thread": "cpp",
"typeinfo": "cpp",
"unordered_map": "cpp",
"unordered_set": "cpp",
"xfacet": "cpp",
"xiosbase": "cpp",
"xlocale": "cpp",
"xlocbuf": "cpp",
"xlocinfo": "cpp",
"xmemory": "cpp",
"xstddef": "cpp",
"xtr1common": "cpp"
},
"files.exclude": {
"**/bin/**": true,
"**/obj/**": true,
"**/packages/**": true,
"**/Generated Files/**": true
}
}

121
.vscode/tasks.json vendored
View File

@@ -1,121 +0,0 @@
{
"version": "2.0.0",
"tasks": [
{
"type": "process",
"label": "Build Terminal/Console",
"command": "powershell.exe",
"args": [
"-Command",
"Import-Module ${workspaceFolder}\\tools\\OpenConsole.psm1;",
"Set-MsBuildDevEnvironment;",
"$project = switch(\"${input:buildProjectChoice}\"){OpenConsole{\"Conhost\\Host_EXE\"} Terminal{\"Terminal\\CascadiaPackage\"} TermControl{\"Terminal\\TerminalControl\"}};",
"$target = switch(\"${input:buildModeChoice}\"){Build{\"\"} Rebuild{\":Rebuild\"} Clean{\":Clean\"}};",
"$target = $project + $target;",
"msbuild",
"${workspaceFolder}\\OpenConsole.sln",
"/p:Configuration=${input:configChoice}",
"/p:Platform=${input:platformChoice}",
"/p:AppxSymbolPackageEnabled=false", // This takes a long time, so false if we don't really need it.
"/t:$target",
"/m", // Parallel builds
"/verbosity:minimal"
],
"problemMatcher": ["$msCompile"],
"group": {
"kind": "build",
"isDefault": true
},
"runOptions": {
"reevaluateOnRerun": false,
"instanceLimit": 1,
"runOn": "default"
}
},
{
"type": "process",
"label": "Register Windows Terminal x64 Debug",
"command": "powershell.exe",
"args": [
"-Command",
"Import-Module ${workspaceFolder}\\tools\\OpenConsole.psm1;",
"Set-MsBuildDevEnvironment;",
"Set-Location -Path ${workspaceFolder}\\src\\cascadia\\CascadiaPackage\\AppPackages\\CascadiaPackage_0.0.1.0_x64_Debug_Test;",
"if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) { Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'};",
"New-Item ..\\loose -Type Directory -Force;",
"makeappx unpack /v /o /p .\\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\\Loose\\;",
"Add-AppxPackage -Path ..\\loose\\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown"
],
"problemMatcher": ["$msCompile"],
"group": {
"kind": "build"
}
},
{
"type": "process",
"label": "Run Windows Terminal Dev",
"command": "wtd.exe",
"args": [
],
"problemMatcher": ["$msCompile"],
},
{
"type": "process",
"label": "Run Code Format",
"command": "powershell.exe",
"args": [
"-Command",
"Import-Module ${workspaceFolder}\\tools\\OpenConsole.psm1;",
"Set-MsBuildDevEnvironment;",
"Invoke-CodeFormat",
],
"problemMatcher": ["$msCompile"],
}
],
"inputs":[
{
"id": "platformChoice",
"type": "pickString",
"description": "Processor architecture choice",
"options":[
"x64",
"x86",
"arm64"
],
"default": "x64"
},
{
"id": "configChoice",
"type": "pickString",
"description": "Debug or release?",
"options":[
"Debug",
"Release"
],
"default": "Debug"
},
{
"id": "buildModeChoice",
"type": "pickString",
"description": "Build, rebuild, or clean?",
"options":[
"Build",
"Rebuild",
"Clean"
],
"default": "Build"
},
{
"id": "buildProjectChoice",
"type": "pickString",
"description": "OpenConsole or Terminal?",
"options":[
"OpenConsole",
"Terminal",
"TermControl"
],
"default": "Terminal"
}
]
}

View File

@@ -17,7 +17,7 @@
"Microsoft.Net.Component.4.5.TargetingPack",
"Microsoft.VisualStudio.Component.DiagnosticTools",
"Microsoft.VisualStudio.Component.Debugger.JustInTime",
"Microsoft.VisualStudio.Component.Windows10SDK.19041",
"Microsoft.VisualStudio.Component.Windows10SDK.18362",
"Microsoft.VisualStudio.ComponentGroup.UWP.Support",
"Microsoft.VisualStudio.Component.VC.CoreIde",
"Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",

View File

@@ -43,7 +43,7 @@ If no existing item describes your issue/feature, great - please file a new issu
* Have a question that you don't see answered in docs, videos, etc.? File an issue
* Want to know if we're planning on building a particular feature? File an issue
* Got a great idea for a new feature? File an issue/request/idea
* Don't understand how to do something? File an issue
* Don't understand how to do something? File an issue/Community Guidance Request
* Found an existing issue that describes yours? Great - upvote and add additional commentary / info / repro-steps / etc.
When you hit "New Issue", select the type of issue closest to what you want to report/ask/request:
@@ -111,13 +111,13 @@ However, some issues/features will require careful thought & formal design befor
Specs help collaborators discuss different approaches to solve a problem, describe how the feature will behave, how the feature will impact the user, what happens if something goes wrong, etc. Driving towards agreement in a spec, before any code is written, often results in simpler code, and less wasted effort in the long run.
Specs will be managed in a very similar manner as code contributions so please follow the "[Fork, Branch and Create your PR](CONTRIBUTING.md#fork-clone-branch-and-create-your-pr)" section below.
Specs will be managed in a very similar manner as code contributions so please follow the "Fork, Branch and Create your PR" below.
### Writing / Contributing-to a Spec
To write/contribute to a spec: fork, branch and commit via PRs, as you would with any code changes.
Specs are written in markdown, stored under the [`\doc\specs`](./doc/specs) folder and named `[issue id] - [spec description].md`.
Specs are written in markdown, stored under the `\doc\spec` folder and named `[issue id] - [spec description].md`.
👉 **It is important to follow the spec templates and complete the requested information**. The available spec templates will help ensure that specs contain the minimum information & decisions necessary to permit development to begin. In particular, specs require you to confirm that you've already discussed the issue/idea with the team in an issue and that you provide the issue ID for reference.

View File

@@ -217,83 +217,3 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```
## boost
**Source**: [https://github.com/boostorg/boost](https://github.com/boostorg/boost)
### License
```
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
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, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
```
# Microsoft Open Source
This product also incorporates source code from other Microsoft open source projects, all licensed under the MIT license.
## `GSL`
**Source**: [https://github.com/microsoft/GSL](https://github.com/microsoft/GSL)
## `Microsoft-UI-XAML`
**Source**: [https://github.com/microsoft/Microsoft-UI-XAML](https://github.com/microsoft/Microsoft-UI-XAML)
## `VirtualDesktopUtils`
**Source**: [https://github.com/microsoft/PowerToys](https://github.com/microsoft/PowerToys)
## `wil`
**Source**: [https://github.com/microsoft/wil](https://github.com/microsoft/wil)
### License
```
The MIT License
Copyright (c) Microsoft Corporation. All rights reserved.
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.
```

File diff suppressed because it is too large Load Diff

View File

@@ -1,5 +1,3 @@
![terminal-logos](https://user-images.githubusercontent.com/48369326/115790869-4c852b00-a37c-11eb-97f1-f61972c7800c.png)
# Welcome to the Windows Terminal, Console and Command-Line repo
This repository contains the source code for:
@@ -35,23 +33,10 @@ This is our preferred method.
#### Via GitHub
For users who are unable to install Windows Terminal from the Microsoft Store,
released builds can be manually downloaded from this repository's [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).
Download the `Microsoft.WindowsTerminal_<versionNumber>.msixbundle` file from
the **Assets** section. To install the app, you can simply double-click on the
`.msixbundle` file, and the app installer should automatically run. If that
fails for any reason, you can try the following command at a PowerShell prompt:
```powershell
# NOTE: If you are using PowerShell 7+, please run
# Import-Module Appx -UseWindowsPowerShell
# before using Add-AppxPackage.
Add-AppxPackage Microsoft.WindowsTerminal_<versionNumber>.msixbundle
```
> 🔴 Note: If you install Terminal manually:
>
> * Terminal will not auto-update when new builds are released so you will need
@@ -243,7 +228,7 @@ Visual Studio.
## Documentation
All project documentation is located at [aka.ms/terminal-docs](https://aka.ms/terminal-docs). If you would like
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).
@@ -278,7 +263,6 @@ If you would like to ask a question that you feel doesn't warrant an issue
* Carlos Zamora, Developer: [@cazamor_msft](https://twitter.com/cazamor_msft)
* Leon Liang, Developer: [@leonmsft](https://twitter.com/leonmsft)
* Pankaj Bhojwani, Developer
* Leonard Hecker, Developer: [@LeonardHecker](https://twitter.com/LeonardHecker)
## Developer Guidance

View File

@@ -1,221 +0,0 @@
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.31205.134
MinimumVisualStudioVersion = 10.0.40219.1
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "Package", "scratch\ScratchIslandApp\Package\Package.wapproj", "{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "SampleAppLib", "scratch\ScratchIslandApp\SampleApp\SampleAppLib.vcxproj", "{A4394404-37F7-41C1-802B-49788D3720E3}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "SampleApp", "scratch\ScratchIslandApp\SampleApp\dll\SampleApp.vcxproj", "{26C51792-41A3-4FE0-AB5E-8B69D557BF91}"
ProjectSection(ProjectDependencies) = postProject
{A4394404-37F7-41C1-802B-49788D3720E3} = {A4394404-37F7-41C1-802B-49788D3720E3}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowExe", "scratch\ScratchIslandApp\WindowExe\WindowExe.vcxproj", "{B4427499-9FDE-4208-B456-5BC580637633}"
ProjectSection(ProjectDependencies) = postProject
{26C51792-41A3-4FE0-AB5E-8B69D557BF91} = {26C51792-41A3-4FE0-AB5E-8B69D557BF91}
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Props", "{53DD5520-E64C-4C06-B472-7CE62CA539C9}"
ProjectSection(SolutionItems) = preProject
src\common.build.post.props = src\common.build.post.props
src\common.build.pre.props = src\common.build.pre.props
src\common.build.tests.props = src\common.build.tests.props
common.openconsole.props = common.openconsole.props
src\cppwinrt.build.post.props = src\cppwinrt.build.post.props
src\cppwinrt.build.pre.props = src\cppwinrt.build.pre.props
src\wap-common.build.post.props = src\wap-common.build.post.props
src\wap-common.build.pre.props = src\wap-common.build.pre.props
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "fmt", "src\dep\fmt\fmt.vcxproj", "{6BAE5851-50D5-4934-8D5E-30361A8A40F3}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types", "src\types\lib\types.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820263}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "dependencies", "dependencies", "{75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
AuditMode|ARM64 = AuditMode|ARM64
AuditMode|x64 = AuditMode|x64
AuditMode|x86 = AuditMode|x86
Debug|ARM64 = Debug|ARM64
Debug|x64 = Debug|x64
Debug|x86 = Debug|x86
Fuzzing|ARM64 = Fuzzing|ARM64
Fuzzing|x64 = Fuzzing|x64
Fuzzing|x86 = Fuzzing|x86
Release|ARM64 = Release|ARM64
Release|x64 = Release|x64
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.ActiveCfg = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.Build.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.Deploy.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.ActiveCfg = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.Build.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.Deploy.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.ActiveCfg = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.Build.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.Deploy.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.Build.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.Deploy.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.ActiveCfg = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.Build.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.Deploy.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.ActiveCfg = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.Build.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.Deploy.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.Build.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.Deploy.0 = Debug|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.ActiveCfg = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.Build.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.Deploy.0 = Debug|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.ActiveCfg = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.Build.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.Deploy.0 = Debug|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.ActiveCfg = Release|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.Build.0 = Release|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.Deploy.0 = Release|ARM64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.ActiveCfg = Release|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.Build.0 = Release|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.Deploy.0 = Release|x64
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.ActiveCfg = Release|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.Build.0 = Release|x86
{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.Deploy.0 = Release|x86
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x64.ActiveCfg = AuditMode|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x64.Build.0 = AuditMode|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x86.Build.0 = AuditMode|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|ARM64.ActiveCfg = Debug|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|ARM64.Build.0 = Debug|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x64.ActiveCfg = Debug|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x64.Build.0 = Debug|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x86.ActiveCfg = Debug|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x86.Build.0 = Debug|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x64.Build.0 = Fuzzing|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x86.Build.0 = Fuzzing|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|ARM64.ActiveCfg = Release|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|ARM64.Build.0 = Release|ARM64
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x64.ActiveCfg = Release|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x64.Build.0 = Release|x64
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x86.ActiveCfg = Release|Win32
{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x86.Build.0 = Release|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x64.ActiveCfg = AuditMode|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x64.Build.0 = AuditMode|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x86.Build.0 = AuditMode|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|ARM64.ActiveCfg = Debug|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|ARM64.Build.0 = Debug|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x64.ActiveCfg = Debug|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x64.Build.0 = Debug|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x86.ActiveCfg = Debug|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x86.Build.0 = Debug|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x64.Build.0 = Fuzzing|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x86.Build.0 = Fuzzing|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|ARM64.ActiveCfg = Release|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|ARM64.Build.0 = Release|ARM64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x64.ActiveCfg = Release|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x64.Build.0 = Release|x64
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x86.ActiveCfg = Release|Win32
{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x86.Build.0 = Release|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x64.ActiveCfg = AuditMode|x64
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x64.Build.0 = AuditMode|x64
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x86.Build.0 = AuditMode|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|ARM64.ActiveCfg = Debug|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|ARM64.Build.0 = Debug|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x64.ActiveCfg = Debug|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x64.Build.0 = Debug|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x86.ActiveCfg = Debug|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x86.Build.0 = Debug|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x64.Build.0 = Fuzzing|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x86.Build.0 = Fuzzing|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Release|ARM64.ActiveCfg = Release|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Release|ARM64.Build.0 = Release|ARM64
{B4427499-9FDE-4208-B456-5BC580637633}.Release|x64.ActiveCfg = Release|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Release|x64.Build.0 = Release|x64
{B4427499-9FDE-4208-B456-5BC580637633}.Release|x86.ActiveCfg = Release|Win32
{B4427499-9FDE-4208-B456-5BC580637633}.Release|x86.Build.0 = Release|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.ActiveCfg = AuditMode|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.Build.0 = AuditMode|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.Build.0 = AuditMode|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.ActiveCfg = Debug|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.Build.0 = Debug|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.ActiveCfg = Debug|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.Build.0 = Debug|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.ActiveCfg = Debug|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.Build.0 = Debug|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.Build.0 = Fuzzing|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x86.Build.0 = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.ActiveCfg = Release|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.Build.0 = Release|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.ActiveCfg = Release|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.Build.0 = Release|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.ActiveCfg = Release|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.Build.0 = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.ActiveCfg = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.Build.0 = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.Build.0 = AuditMode|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.Build.0 = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.Build.0 = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.Build.0 = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.Build.0 = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x86.Build.0 = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.Build.0 = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.Build.0 = Release|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(NestedProjects) = preSolution
{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}
{18D09A24-8240-42D6-8CB6-236EEE820263} = {75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {05EAE315-9188-4D7B-B889-7D5F480A8915}
EndGlobalSection
EndGlobal

View File

@@ -1,41 +0,0 @@
{
"AttributesTolerance": 1,
"KeepFirstAttributeOnSameLine": true,
"MaxAttributeCharactersPerLine": 0,
"MaxAttributesPerLine": 1,
"NewlineExemptionElements": "RadialGradientBrush, GradientStop, LinearGradientBrush, ScaleTransform, SkewTransform, RotateTransform, TranslateTransform, Trigger, Condition, Setter",
"SeparateByGroups": false,
"AttributeIndentation": 0,
"AttributeIndentationStyle": 1,
"RemoveDesignTimeReferences": false,
"EnableAttributeReordering": true,
"AttributeOrderingRuleGroups": [
"x:Class",
"xmlns, xmlns:x",
"xmlns:*",
"x:Key, Key, x:Name, Name, x:Uid, Uid, Title",
"Grid.Row, Grid.RowSpan, Grid.Column, Grid.ColumnSpan, Canvas.Left, Canvas.Top, Canvas.Right, Canvas.Bottom",
"Width, Height, MinWidth, MinHeight, MaxWidth, MaxHeight",
"Margin, Padding, HorizontalAlignment, VerticalAlignment, HorizontalContentAlignment, VerticalContentAlignment, Panel.ZIndex",
"*:*, *",
"PageSource, PageIndex, Offset, Color, TargetName, Property, Value, StartPoint, EndPoint",
"mc:Ignorable, d:IsDataSource, d:LayoutOverrides, d:IsStaticText",
"Storyboard.*, From, To, Duration"
],
"FirstLineAttributes": "",
"OrderAttributesByName": true,
"PutEndingBracketOnNewLine": false,
"RemoveEndingTagOfEmptyElement": true,
"SpaceBeforeClosingSlash": true,
"RootElementLineBreakRule": 0,
"ReorderVSM": 2,
"ReorderGridChildren": false,
"ReorderCanvasChildren": false,
"ReorderSetters": 0,
"FormatMarkupExtension": true,
"NoNewLineMarkupExtensions": "x:Bind, Binding",
"ThicknessSeparator": 2,
"ThicknessAttributes": "Margin, Padding, BorderThickness, ThumbnailClipMargin",
"FormatOnSave": true,
"CommentPadding": 2,
}

View File

@@ -29,147 +29,4 @@ function GetQueryTestRunsUri
$baseUri = GetAzureDevOpsBaseUri -CollectionUri $CollectionUri -TeamProject $TeamProject
$queryUri = "$baseUri/_apis/test/runs?buildUri=$BuildUri$includeRunDetailsParameter&api-version=5.0"
return $queryUri
}
function Get-HelixJobTypeFromTestRun
{
Param ($testRun)
$testRunSingleResultUri = "$($testRun.url)/results?`$top=1&`$skip=0&api-version=5.1"
$singleTestResult = Invoke-RestMethod -Uri $testRunSingleResultUri -Method Get -Headers $azureDevOpsRestApiHeaders
$count = $singleTestResult.value.Length
if($count -eq 0)
{
# If the count is 0, then results have not yet been reported for this run.
# We only care about completed runs with results, so it is ok to just return 'UNKNOWN' for this run.
return "UNKNOWN"
}
else
{
$info = ConvertFrom-Json $singleTestResult.value.comment
$helixJobId = $info.HelixJobId
$job = Invoke-RestMethodWithRetries "https://helix.dot.net/api/2019-06-17/jobs/${helixJobId}?access_token=${HelixAccessToken}"
return $job.Type
}
}
function Append-HelixAccessTokenToUrl
{
Param ([string]$url, [string]$token)
if($url.Contains("?"))
{
$url = "$($url)&access_token=$($token)"
}
else
{
$url = "$($url)?access_token=$($token)"
}
return $url
}
# The Helix Rest api is sometimes unreliable. So we call these apis with retry logic.
# Note: The Azure DevOps apis are stable and do not need to be called with this retry logic.
$helixApiRetries = 0
$helixApiRetriesMax = 10
function Download-StringWithRetries
{
Param ([string]$fileName, [string]$url)
$result = ""
$done = $false
while(!($done))
{
try
{
Write-Host "Downloading $fileName"
$result = (New-Object System.Net.WebClient).DownloadString($url)
$done = $true
}
catch
{
Write-Host "Failed to download $fileName $($PSItem.Exception)"
$helixApiRetries = $helixApiRetries + 1
if($helixApiRetries -lt $helixApiRetriesMax)
{
Write-Host "Sleep and retry download of $fileName"
Start-Sleep 60
}
else
{
throw "Failed to download $fileName"
}
}
}
return $result
}
function Invoke-RestMethodWithRetries
{
Param ([string]$url,$Headers)
$result = @()
$done = $false
while(!($done))
{
try
{
$result = Invoke-RestMethod -Uri $url -Method Get -Headers $Headers
$done = $true
}
catch
{
Write-Host "Failed to invoke Rest method $($PSItem.Exception)"
$helixApiRetries = $helixApiRetries + 1
if($helixApiRetries -lt $helixApiRetriesMax)
{
Write-Host "Sleep and retry invoke"
Start-Sleep 60
}
else
{
throw "Failed to invoke Rest method"
}
}
}
return $result
}
function Download-FileWithRetries
{
Param ([string]$fileurl, [string]$destination)
$done = $false
while(!($done))
{
try
{
Write-Host "Downloading $destination"
$webClient.DownloadFile($fileurl, $destination)
$done = $true
}
catch
{
Write-Host "Failed to download $destination $($PSItem.Exception)"
$helixApiRetries = $helixApiRetries + 1
if($helixApiRetries -lt $helixApiRetriesMax)
{
Write-Host "Sleep and retry download of $destination"
Start-Sleep 60
}
else
{
throw "Failed to download $destination"
}
}
}
}

View File

@@ -9,7 +9,7 @@ $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)
{
@@ -19,13 +19,11 @@ 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\Microsoft.Taef.10.60.210621002\build\Binaries\$Platform\*" $payloadDir
Copy-Item "$nugetPackagesDir\Microsoft.Taef.10.60.210621002\build\Binaries\$Platform\NetFx4.5\*" $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\"
New-Item -ItemType Directory -Force -Path "$payloadDir\content\"
Copy-Item "$nugetPackagesDir\Microsoft.Internal.Windows.Terminal.TestContent.1.0.1\content\*" "$payloadDir\content\"
function Copy-If-Exists
{
@@ -54,13 +52,3 @@ 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"
# Copy the APPX package from the 'drop' artifact dir
Copy-Item "$repoDirectory\Artifacts\$ArtifactName\appx\CascadiaPackage_0.0.1.0_$Platform.msix" $payloadDir\CascadiaPackage.zip
# Rename it to extension of ZIP because Expand-Archive is real sassy on the build machines
# and refuses to unzip it because of its file extension while on a desktop, it just
# does the job without complaining.
# Extract the APPX package
Expand-Archive -LiteralPath $payloadDir\CascadiaPackage.zip -DestinationPath $payloadDir\appx

View File

@@ -9,6 +9,11 @@ Param(
$helixLinkFile = "$OutputFolder\LinksToHelixTestFiles.html"
$accessTokenParam = ""
if($HelixAccessToken)
{
$accessTokenParam = "?access_token=$HelixAccessToken"
}
function Generate-File-Links
{
@@ -40,69 +45,66 @@ $azureDevOpsRestApiHeaders = @{
$queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri -IncludeRunDetails
Write-Host "queryUri = $queryUri"
$testRuns = Invoke-RestMethodWithRetries $queryUri -Headers $azureDevOpsRestApiHeaders
$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)
{
Write-Host "testRunUri = $testRun.url"
$testResults = Invoke-RestMethodWithRetries "$($testRun.url)/results?api-version=5.0" -Headers $azureDevOpsRestApiHeaders
$testResults = Invoke-RestMethod -Uri "$($testRun.url)/results?api-version=5.0" -Method Get -Headers $azureDevOpsRestApiHeaders
$isTestRunNameShown = $false
foreach ($testResult in $testResults.value)
{
$info = ConvertFrom-Json $testResult.comment
$helixJobId = $info.HelixJobId
$helixWorkItemName = $info.HelixWorkItemName
$workItem = "$helixJobId-$helixWorkItemName"
Write-Host "Helix Work Item = $workItem"
if (-not $workItems.Contains($workItem))
if ("comment" -in $testResult)
{
$workItems.Add($workItem)
$filesQueryUri = "https://helix.dot.net/api/2019-06-17/jobs/$helixJobId/workitems/$helixWorkItemName/files$accessTokenParam"
$files = Invoke-RestMethodWithRetries $filesQueryUri
$info = ConvertFrom-Json $testResult.comment
$helixJobId = $info.HelixJobId
$helixWorkItemName = $info.HelixWorkItemName
$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)
$workItem = "$helixJobId-$helixWorkItemName"
if (-not $workItems.Contains($workItem))
{
if(-Not $isTestRunNameShown)
$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)
{
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 = $testResult.automatedTestName.Split('.')[0]
$archPath = $testResult.automatedTestName.Split('.')[1]
$fileName = $pgcFile.Name
$fullPath = "$OutputFolder\PGO\$flavorPath\$archPath"
$destination = "$fullPath\$fileName"
Write-Host "Copying $($pgcFile.Name) to $destination"
if (-Not (Test-Path $fullPath))
if(-Not $isTestRunNameShown)
{
New-Item $fullPath -ItemType Directory
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"
$link = $pgcFile.Link
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 "Downloading $link to $destination"
Write-Host "Copying $($pgcFile.Name) to $destination"
Download-FileWithRetries $link $destination
if (-Not (Test-Path $fullPath))
{
New-Item $fullPath -ItemType Directory
}
$link = "$($pgcFile.Link)$accessTokenParam"
$webClient.DownloadFile($link, $destination)
}
}
}
}

View File

@@ -13,8 +13,6 @@
</ItemGroup>
<!-- These .proj files are generated by the build machine prior to running tests via GenerateTestProjFile.ps1. -->
<Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-TerminalAppLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
<Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-SettingsModelLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
<Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-HostTestsUIA.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
<Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-WindowsTerminalUIATests.proj" Condition=" '$(TestSuite)'=='PgoInstrumentationSuite' " />
<Import Project="$(ProjFilesPath)\RunTestsInHelix-TerminalAppLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
<Import Project="$(ProjFilesPath)\RunTestsInHelix-HostTestsUIA.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
</Project>

View File

@@ -1,8 +1,7 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
<package id="Microsoft.Internal.Windows.Terminal.TestContent" version="1.0.1" />
<package id="Microsoft.Taef" version="10.60.210621002" 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" />

View File

@@ -18,7 +18,7 @@ FOR %%A IN (TestHostApp.exe,te.exe,te.processhost.exe,conhost.exe,OpenConsole.ex
echo %TIME%
:: kill dhandler, which is a tool designed to handle unexpected windows appearing. But since our tests are
:: 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
@@ -28,7 +28,7 @@ echo %TIME%
powershell -ExecutionPolicy Bypass .\InstallTestAppDependencies.ps1
echo %TIME%
set testBinaryCandidates=TerminalApp.LocalTests.dll SettingsModel.LocalTests.dll Conhost.UIA.Tests.dll WindowsTerminal.UIA.Tests.dll
set testBinaryCandidates=TerminalApp.LocalTests.dll Conhost.UIA.Tests.dll
set testBinaries=
for %%B in (%testBinaryCandidates%) do (
if exist %%B (
@@ -46,6 +46,7 @@ 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=
@@ -102,4 +103,4 @@ copy /y *_subresults.json %HELIX_WORKITEM_UPLOAD_ROOT%
type testResults.xml
echo %TIME%
echo %TIME%

View File

@@ -0,0 +1,5 @@
<SignConfigXML>
<job platform="" configuration="" dest="__INPATHROOT__" jobname="EngFunSimpleSign" approvers="">
<file src="__INPATHROOT__\Microsoft.Terminal*.nupkg" signType="NuGet" />
</job>
</SignConfigXML>

View File

@@ -0,0 +1,5 @@
<SignConfigXML>
<job platform="" configuration="" certSubject="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" jobname="EngFunSimpleSign" approvers="">
<file src="__INPATHROOT__\Microsoft.WindowsTerminal*.msixbundle" signType="136020001" />
</job>
</SignConfigXML>

View File

@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
<package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
<package id="TAEF.Redist.Wlk" version="10.57.200731005-develop" targetFramework="native" />
</packages>

View File

@@ -1,27 +0,0 @@
trigger: none
pr: none
variables:
- name: runCodesignValidationInjectionBG
value: false
# 0.0.yyMM.dd##
# 0.0.1904.0900
name: 0.0.$(Date:yyMM).$(Date:dd)$(Rev:rr)
stages:
- stage: Build_x64
displayName: Build x64
dependsOn: []
condition: succeeded()
jobs:
- template: ./templates/build-console-pgo.yml
parameters:
platform: x64
- stage: Publish_PGO_Databases
displayName: Publish PGO databases
dependsOn: ['Build_x64']
jobs:
- template: ./templates/pgo-build-and-publish-nuget-job.yml
parameters:
pgoArtifact: 'PGO'

View File

@@ -1,487 +1,48 @@
# This build should never run as CI or against a pull request.
trigger: none
pr: none
pool:
name: WinDevPool-L
demands: ImageOverride -equals WinDevVS16-latest
parameters:
- name: branding
displayName: "Branding (Build Type)"
type: string
default: Release
values:
- Release
- Preview
- name: buildTerminal
displayName: "Build Windows Terminal MSIX"
type: boolean
default: true
- name: buildTerminalVPack
displayName: "Build Windows Terminal VPack"
type: boolean
default: false
- name: buildWPF
displayName: "Build Terminal WPF Control"
type: boolean
default: false
- name: pgoBuildMode
displayName: "PGO Build Mode"
type: string
default: Optimize
values:
- Optimize
- Instrument
- None
- name: buildConfigurations
type: object
default:
- Release
- name: buildPlatforms
type: object
default:
- x64
- x86
- arm64
variables:
TerminalInternalPackageVersion: "0.0.7"
baseYearForVersioning: 2019 # Used by build-console-int
versionMajor: 0
versionMinor: 1
name: $(BuildDefinitionName)_$(date:yyMM).$(date:dd)$(rev:rrr)
resources:
repositories:
- repository: self
type: git
ref: main
# When we move off PackageES for Versioning, we'll need to switch
# name to this format. For now, though, we need to use DayOfYear.Rev
# to unique our builds, as mandated by PackageES's Setup task.
# name: '$(versionMajor).$(versionMinor).$(DayOfYear)$(Rev:r).0'
#
# Build name/version number above must end with .0 to make the
# store publication machinery happy.
name: 'Terminal_$(date:yyMM).$(date:dd)$(rev:rrr)'
# Build Arguments:
# WindowsTerminalOfficialBuild=[true,false]
# true - this is running on our build agent
# false - running locally
# WindowsTerminalBranding=[Dev,Preview,Release]
# <none> - Development build resources (default)
# Preview - Preview build resources
# Release - regular build resources
jobs:
- job: Build
strategy:
matrix:
${{ each config in parameters.buildConfigurations }}:
${{ each platform in parameters.buildPlatforms }}:
${{ config }}_${{ platform }}:
BuildConfiguration: ${{ config }}
BuildPlatform: ${{ platform }}
displayName: Build
cancelTimeoutInMinutes: 1
steps:
- checkout: self
clean: true
submodules: true
persistCredentials: True
- task: PkgESSetupBuild@12
displayName: Package ES - Setup Build
inputs:
disableOutputRedirect: true
- task: PowerShell@2
displayName: Rationalize Build Platform
inputs:
targetType: inline
script: >-
$Arch = "$(BuildPlatform)"
- template: ./templates/build-console-audit-job.yml
parameters:
platform: x64
If ($Arch -Eq "x86") { $Arch = "Win32" }
- template: ./templates/build-console-int.yml
parameters:
platform: x64
additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview
Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
- task: NuGetToolInstaller@1
displayName: Use NuGet 5.10
inputs:
versionSpec: 5.10
- task: NuGetCommand@2
displayName: NuGet custom
inputs:
command: custom
selectOrConfig: config
nugetConfigPath: NuGet.Config
arguments: restore OpenConsole.sln -SolutionDirectory $(Build.SourcesDirectory)
- task: UniversalPackages@0
displayName: Download terminal-internal Universal Package
inputs:
feedListDownload: 2b3f8893-a6e8-411f-b197-a9e05576da48
packageListDownload: e82d490c-af86-4733-9dc4-07b772033204
versionListDownload: $(TerminalInternalPackageVersion)
- task: TouchdownBuildTask@1
displayName: Download Localization Files
inputs:
teamId: 7105
authId: $(TouchdownAppId)
authKey: $(TouchdownAppKey)
resourceFilePath: >-
src\cascadia\TerminalApp\Resources\en-US\Resources.resw
- template: ./templates/build-console-int.yml
parameters:
platform: x86
additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview
src\cascadia\TerminalControl\Resources\en-US\Resources.resw
- template: ./templates/build-console-int.yml
parameters:
platform: arm64
additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview
src\cascadia\TerminalConnection\Resources\en-US\Resources.resw
- template: ./templates/check-formatting.yml
src\cascadia\TerminalSettingsModel\Resources\en-US\Resources.resw
src\cascadia\TerminalSettingsEditor\Resources\en-US\Resources.resw
src\cascadia\WindowsTerminalUniversal\Resources\en-US\Resources.resw
src\cascadia\CascadiaPackage\Resources\en-US\Resources.resw
appendRelativeDir: true
localizationTarget: false
pseudoSetting: Included
- task: PowerShell@2
displayName: Move Loc files one level up
inputs:
targetType: inline
script: >-
$Files = Get-ChildItem . -R -Filter 'Resources.resw' | ? FullName -Like '*en-US\*\Resources.resw'
$Files | % { Move-Item -Verbose $_.Directory $_.Directory.Parent.Parent -EA:Ignore }
pwsh: true
- task: PowerShell@2
displayName: Generate NOTICE.html from NOTICE.md
inputs:
filePath: .\build\scripts\Generate-ThirdPartyNotices.ps1
arguments: -MarkdownNoticePath .\NOTICE.md -OutputPath .\src\cascadia\CascadiaPackage\NOTICE.html
pwsh: true
- ${{ if eq(parameters.pgoBuildMode, 'Optimize') }}:
- task: PowerShell@2
displayName: Restore PGO Database
inputs:
filePath: tools/PGODatabase/restore-pgodb.ps1
workingDirectory: $(Build.SourcesDirectory)\tools\PGODatabase
- ${{ if eq(parameters.buildTerminal, true) }}:
- task: VSBuild@1
displayName: Build solution **\OpenConsole.sln
inputs:
solution: '**\OpenConsole.sln'
vsVersion: 16.0
msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }} /t:Terminal\CascadiaPackage;Terminal\WindowsTerminalUniversal /p:WindowsTerminalReleaseBuild=true /bl:$(Build.SourcesDirectory)\msbuild.binlog
platform: $(BuildPlatform)
configuration: $(BuildConfiguration)
clean: true
maximumCpuCount: true
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: binlog'
condition: failed()
continueOnError: True
inputs:
PathtoPublish: $(Build.SourcesDirectory)\msbuild.binlog
ArtifactName: binlog-$(BuildPlatform)
- ${{ if eq(parameters.pgoBuildMode, 'Optimize') }}:
- task: PowerShell@2
displayName: Validate binaries are optimized
condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
inputs:
targetType: inline
script: >-
$Binaries = 'OpenConsole.exe', 'WindowsTerminal.exe', 'TerminalApp.dll', 'TerminalConnection.dll', 'Microsoft.Terminal.Control.dll', 'Microsoft.Terminal.Remoting.dll', 'Microsoft.Terminal.Settings.Editor.dll', 'Microsoft.Terminal.Settings.Model.dll'
foreach ($BinFile in $Binaries) {
& "$(Build.SourcesDirectory)\tools\PGODatabase\verify-pgo.ps1" "$(Build.SourcesDirectory)/src/cascadia/CascadiaPackage/bin/$(BuildPlatform)/$(BuildConfiguration)/$BinFile"
}
- task: PowerShell@2
displayName: Check MSIX for common regressions
inputs:
targetType: inline
script: >-
$Package = Get-ChildItem -Recurse -Filter "CascadiaPackage_*.msix"
.\build\scripts\Test-WindowsTerminalPackage.ps1 -Verbose -Path $Package.FullName
pwsh: true
- ${{ if eq(parameters.buildWPF, true) }}:
- task: VSBuild@1
displayName: Build solution **\OpenConsole.sln for PublicTerminalCore
condition: and(succeeded(), ne(variables['BuildPlatform'], 'arm64'))
inputs:
solution: '**\OpenConsole.sln'
vsVersion: 16.0
msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }} /p:WindowsTerminalReleaseBuild=true /t:Terminal\wpf\PublicTerminalCore
platform: $(BuildPlatform)
configuration: $(BuildConfiguration)
- task: PowerShell@2
displayName: Source Index PDBs
inputs:
filePath: build\scripts\Index-Pdbs.ps1
arguments: -SearchDir '$(Build.SourcesDirectory)' -SourceRoot '$(Build.SourcesDirectory)' -recursive -Verbose -CommitId $(Build.SourceVersion)
errorActionPreference: silentlyContinue
- task: ComponentGovernanceComponentDetection@0
displayName: Component Detection
- task: PowerShell@2
displayName: Run Unit Tests
condition: and(succeeded(), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
enabled: False
inputs:
filePath: build\scripts\Run-Tests.ps1
arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
- task: PowerShell@2
displayName: Run Feature Tests
condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
enabled: False
inputs:
filePath: build\scripts\Run-Tests.ps1
arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
- ${{ if eq(parameters.buildTerminal, true) }}:
- task: CopyFiles@2
displayName: Copy *.appx/*.msix to Artifacts
inputs:
Contents: >-
**/*.appx
**/*.msix
**/*.appxsym
!**/Microsoft.VCLibs*.appx
TargetFolder: $(Build.ArtifactStagingDirectory)/appx
OverWrite: true
flattenFolders: true
- task: PublishBuildArtifacts@1
displayName: Publish Artifact (appx)
inputs:
PathtoPublish: $(Build.ArtifactStagingDirectory)/appx
ArtifactName: appx-$(BuildPlatform)-$(BuildConfiguration)
- ${{ if eq(parameters.buildWPF, true) }}:
- task: CopyFiles@2
displayName: Copy PublicTerminalCore.dll to Artifacts
condition: and(succeeded(), ne(variables['BuildPlatform'], 'arm64'))
inputs:
Contents: >-
**/PublicTerminalCore.dll
**/api-ms-win-core-synch-l1-2-0.dll
TargetFolder: $(Build.ArtifactStagingDirectory)/wpf
OverWrite: true
flattenFolders: true
- task: PublishBuildArtifacts@1
displayName: Publish Artifact (PublicTerminalCore)
condition: and(succeeded(), ne(variables['BuildPlatform'], 'arm64'))
inputs:
PathtoPublish: $(Build.ArtifactStagingDirectory)/wpf
ArtifactName: wpf-dll-$(BuildPlatform)-$(BuildConfiguration)
- task: PublishSymbols@2
displayName: Publish symbols path
continueOnError: True
inputs:
SearchPattern: '**/*.pdb'
IndexSources: false
SymbolServerType: TeamServices
- ${{ if eq(parameters.buildTerminal, true) }}:
- job: BundleAndSign
displayName: Create and sign AppX/MSIX bundles
dependsOn: Build
steps:
- checkout: self
clean: true
submodules: true
persistCredentials: True
- task: PkgESSetupBuild@12
displayName: Package ES - Setup Build
inputs:
disableOutputRedirect: true
- task: DownloadBuildArtifacts@0
displayName: Download Artifacts (*.appx, *.msix)
inputs:
downloadType: specific
itemPattern: >-
**/*.msix
**/*.appx
extractTars: false
- task: PowerShell@2
displayName: Create WindowsTerminal*.msixbundle
inputs:
filePath: build\scripts\Create-AppxBundle.ps1
arguments: -InputPath "$(System.ArtifactsDirectory)" -ProjectName CascadiaPackage -BundleVersion 0.0.0.0 -OutputPath "$(System.ArtifactsDirectory)\Microsoft.WindowsTerminal_$(XES_APPXMANIFESTVERSION)_8wekyb3d8bbwe.msixbundle"
- task: PowerShell@2
displayName: Create WindowsTerminalUniversal*.msixbundle
inputs:
filePath: build\scripts\Create-AppxBundle.ps1
arguments: -InputPath "$(System.ArtifactsDirectory)" -ProjectName WindowsTerminalUniversal -BundleVersion $(XES_APPXMANIFESTVERSION) -OutputPath "$(System.ArtifactsDirectory)\Microsoft.WindowsTerminalUniversal_$(XES_APPXMANIFESTVERSION)_8wekyb3d8bbwe.msixbundle"
- task: EsrpCodeSigning@1
displayName: Submit *.msixbundle to ESRP for code signing
inputs:
ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
FolderPath: $(System.ArtifactsDirectory)
Pattern: Microsoft.WindowsTerminal*.msixbundle
UseMinimatch: true
signConfigType: inlineSignParams
inlineOperation: >-
[
{
"KeyCode": "Dynamic",
"CertTemplateName": "WINMSAPP1ST",
"CertSubjectName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US",
"OperationCode": "SigntoolSign",
"Parameters": {
"OpusName": "Microsoft",
"OpusInfo": "http://www.microsoft.com",
"FileDigest": "/fd \"SHA256\"",
"TimeStamp": "/tr \"http://rfc3161.gtm.corp.microsoft.com/TSS/HttpTspServer\" /td sha256"
},
"ToolName": "sign",
"ToolVersion": "1.0"
},
{
"KeyCode": "Dynamic",
"CertTemplateName": "WINMSAPP1ST",
"CertSubjectName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US",
"OperationCode": "SigntoolVerify",
"Parameters": {},
"ToolName": "sign",
"ToolVersion": "1.0"
}
]
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: appxbundle-signed'
inputs:
PathtoPublish: $(System.ArtifactsDirectory)
ArtifactName: appxbundle-signed
- ${{ if eq(parameters.buildWPF, true) }}:
- job: PackageAndSignWPF
strategy:
matrix:
${{ each config in parameters.buildConfigurations }}:
${{ config }}:
BuildConfiguration: ${{ config }}
displayName: Create NuGet Package (WPF Terminal Control)
dependsOn: Build
steps:
- checkout: self
clean: true
submodules: true
persistCredentials: True
- task: PkgESSetupBuild@12
displayName: Package ES - Setup Build
inputs:
disableOutputRedirect: true
- task: DownloadBuildArtifacts@0
displayName: Download x86 PublicTerminalCore
inputs:
artifactName: wpf-dll-x86-$(BuildConfiguration)
itemPattern: '**/*.dll'
downloadPath: bin\Win32\$(BuildConfiguration)\
extractTars: false
- task: DownloadBuildArtifacts@0
displayName: Download x64 PublicTerminalCore
inputs:
artifactName: wpf-dll-x64-$(BuildConfiguration)
itemPattern: '**/*.dll'
downloadPath: bin\x64\$(BuildConfiguration)\
extractTars: false
- task: PowerShell@2
displayName: Move downloaded artifacts up a level
inputs:
targetType: inline
# Find all artifact files and move them up a directory. Ugh.
script: >-
Get-ChildItem bin -Recurse -Directory -Filter wpf-dll-* | % {
$_ | Get-ChildItem -Recurse -File | % {
Move-Item -Verbose $_.FullName $_.Directory.Parent.FullName
}
}
- task: NuGetToolInstaller@1
displayName: Use NuGet 5.10.0
inputs:
versionSpec: 5.10.0
- task: NuGetCommand@2
displayName: NuGet restore copy
inputs:
selectOrConfig: config
nugetConfigPath: NuGet.Config
- task: VSBuild@1
displayName: Build solution **\OpenConsole.sln for WPF Control
inputs:
solution: '**\OpenConsole.sln'
vsVersion: 16.0
msbuildArgs: /p:WindowsTerminalReleaseBuild=$(UseReleaseBranding);Version=$(XES_PACKAGEVERSIONNUMBER) /t:Pack
platform: Any CPU
configuration: $(BuildConfiguration)
maximumCpuCount: true
- task: PublishSymbols@2
displayName: Publish symbols path
continueOnError: True
inputs:
SearchPattern: '**/*.pdb'
IndexSources: false
SymbolServerType: TeamServices
SymbolsArtifactName: Symbols_WPF_$(BuildConfiguration)
- task: CopyFiles@2
displayName: Copy *.nupkg to Artifacts
inputs:
Contents: '**/*Wpf*.nupkg'
TargetFolder: $(Build.ArtifactStagingDirectory)/nupkg
OverWrite: true
flattenFolders: true
- task: EsrpCodeSigning@1
displayName: Submit *.nupkg to ESRP for code signing
inputs:
ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
FolderPath: $(Build.ArtifactStagingDirectory)/nupkg
Pattern: '*.nupkg'
UseMinimatch: true
signConfigType: inlineSignParams
inlineOperation: >-
[
{
"KeyCode": "CP-401405",
"OperationCode": "NuGetSign",
"Parameters": {},
"ToolName": "sign",
"ToolVersion": "1.0"
},
{
"KeyCode": "CP-401405",
"OperationCode": "NuGetVerify",
"Parameters": {},
"ToolName": "sign",
"ToolVersion": "1.0"
}
]
- task: PublishBuildArtifacts@1
displayName: Publish Artifact (nupkg)
inputs:
PathtoPublish: $(Build.ArtifactStagingDirectory)\nupkg
ArtifactName: wpf-nupkg-$(BuildConfiguration)
- ${{ if eq(parameters.buildTerminalVPack, true) }}:
- job: VPack
displayName: Create Windows vPack
dependsOn: BundleAndSign
steps:
- checkout: self
clean: true
submodules: true
- task: PkgESSetupBuild@12
displayName: Package ES - Setup Build
- task: DownloadBuildArtifacts@0
displayName: Download Build Artifacts
inputs:
artifactName: appxbundle-signed
extractTars: false
- task: PowerShell@2
displayName: Rename and stage packages for vpack
inputs:
targetType: inline
script: >-
# Rename to known/fixed name for Windows build system
Get-ChildItem Microsoft.WindowsTerminal_*.msixbundle | Rename-Item -NewName { 'Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle' }
# Create vpack directory and place item inside
mkdir WindowsTerminal.app
mv Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle .\WindowsTerminal.app\
workingDirectory: $(System.ArtifactsDirectory)\appxbundle-signed
- task: PkgESVPack@12
displayName: 'Package ES - VPack'
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
inputs:
sourceDirectory: $(System.ArtifactsDirectory)\appxbundle-signed\WindowsTerminal.app
description: Windows Terminal pre-install application
pushPkgName: WindowsTerminal.app
owner: condev
...
- template: ./templates/release-sign-and-bundle.yml

View File

@@ -8,12 +8,9 @@ jobs:
variables:
BuildConfiguration: AuditMode
BuildPlatform: ${{ parameters.platform }}
pool:
${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPoolOSS-L
${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPool-L
demands: ImageOverride -equals WinDevVS16-latest
pool: "windevbuildagents"
# The public pool is also an option!
# pool: { vmImage: windows-2019 }
steps:
- checkout: self

View File

@@ -11,32 +11,21 @@ jobs:
variables:
BuildConfiguration: ${{ parameters.configuration }}
BuildPlatform: ${{ parameters.platform }}
pool:
${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPoolOSS-L
${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPool-L
demands: ImageOverride -equals WinDevVS16-latest
pool: "windevbuildagents"
# The public pool is also an option!
# pool: { vmImage: windows-2019 }
steps:
- template: build-console-steps.yml
parameters:
additionalBuildArguments: ${{ parameters.additionalBuildArguments }}
# It appears that the Component Governance build task that gets automatically injected stopped working
# when we renamed our main branch.
- task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
displayName: 'Component Detection'
condition: and(succeededOrFailed(), not(eq(variables['Build.Reason'], 'PullRequest')))
- 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'
platform: ${{ parameters.platform }}
configuration: ${{ parameters.configuration }}
rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
- template: helix-processtestresults-job.yml

View File

@@ -0,0 +1,30 @@
parameters:
configuration: 'Release'
platform: ''
additionalBuildArguments: ''
jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
variables:
BuildConfiguration: ${{ parameters.configuration }}
BuildPlatform: ${{ parameters.platform }}
pool:
name: Package ES Lab E
demands:
- msbuild
- visualstudio
- vstest
steps:
- task: PkgESSetupBuild@10
displayName: 'Package ES - Setup Build'
inputs:
useDfs: false
productName: WindowsTerminal
disableOutputRedirect: true
- template: build-console-steps.yml
parameters:
additionalBuildArguments: "/p:XesUseOneStoreVersioning=true;XesBaseYearForStoreVersion=$(baseYearForVersioning) ${{ parameters.additionalBuildArguments }}"

View File

@@ -1,54 +0,0 @@
parameters:
configuration: 'Release'
platform: ''
additionalBuildArguments: ''
minimumExpectedTestsExecutedCount: 1 # Sanity check for minimum expected tests to be reported
rerunPassesRequiredToAvoidFailure: 0
jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
variables:
BuildConfiguration: ${{ parameters.configuration }}
BuildPlatform: ${{ parameters.platform }}
PGOBuildMode: 'Instrument'
pool:
${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPoolOSS-L
${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
name: WinDevPool-L
demands: ImageOverride -equals WinDevVS16-latest
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: succeeded()
testSuite: 'PgoInstrumentationSuite'
taefQuery: '@IsPgo=true'
configuration: ${{ parameters.configuration }}
platform: ${{ parameters.platform }}
rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
- template: helix-processtestresults-job.yml
parameters:
name: 'ProcessTestResults'
pgoArtifact: 'PGO'
dependsOn:
- RunTestsInHelix
condition: succeededOrFailed()
rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
- template: pgo-merge-pgd-job.yml
parameters:
name: 'MergePGD'
dependsOn:
- ProcessTestResults
pgoArtifact: 'PGO'
platform: ${{ parameters.platform }}

View File

@@ -22,7 +22,7 @@ steps:
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:
@@ -32,29 +32,6 @@ steps:
restoreSolution: build/packages.config
restoreDirectory: '$(Build.SourcesDirectory)\packages'
# The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
- script: |
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
del %TEMP%\vsinstalldir.txt
call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
echo VCToolsInstallDir = %VCToolsInstallDir%
echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
displayName: 'Retrieve VC tools directory'
- task: CmdLine@1
displayName: 'Display build machine environment variables'
inputs:
filename: 'set'
- task: powershell@2
displayName: 'Restore PGO database'
condition: eq(variables['PGOBuildMode'], 'Optimize')
inputs:
targetType: filePath
workingDirectory: $(Build.SourcesDirectory)\tools\PGODatabase
filePath: $(Build.SourcesDirectory)\tools\PGODatabase\restore-pgodb.ps1
- task: VSBuild@1
displayName: 'Build solution **\OpenConsole.sln'
inputs:
@@ -68,9 +45,6 @@ steps:
- task: PowerShell@2
displayName: 'Check MSIX for common regressions'
# PGO runtime needs its own CRT and it's in the package for convenience.
# That will make this script mad so skip since we're not shipping the PGO Instrumentation one anyway.
condition: ne(variables['PGOBuildMode'], 'Instrument')
inputs:
targetType: inline
script: |
@@ -79,7 +53,6 @@ steps:
- task: powershell@2
displayName: 'Source Index PDBs'
condition: ne(variables['PGOBuildMode'], 'Instrument')
inputs:
targetType: filePath
filePath: build\scripts\Index-Pdbs.ps1
@@ -95,25 +68,13 @@ steps:
If ($Arch -Eq "x86") { $Arch = "Win32" }
Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
- task: PowerShell@2
displayName: 'Validate binaries are optimized'
condition: eq(variables['pgoBuildMode'], 'Optimize')
inputs:
targetType: inline
script: |
$Binaries = 'OpenConsole.exe', 'WindowsTerminal.exe', 'TerminalApp.dll', 'TerminalConnection.dll', 'Microsoft.Terminal.Control.dll', 'Microsoft.Terminal.Remoting.dll', 'Microsoft.Terminal.Settings.Editor.dll', 'Microsoft.Terminal.Settings.Model.dll'
foreach ($BinFile in $Binaries)
{
& "$(Build.SourcesDirectory)\tools\PGODatabase\verify-pgo.ps1" "$(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/$BinFile"
}
- task: PowerShell@2
displayName: 'Run Unit Tests'
inputs:
targetType: filePath
filePath: build\scripts\Run-Tests.ps1
arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
condition: and(succeeded(), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
- task: PowerShell@2
displayName: 'Run Feature Tests (x64 only)'
@@ -121,7 +82,7 @@ steps:
targetType: filePath
filePath: build\scripts\Run-Tests.ps1
arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), eq(variables['BuildPlatform'], 'x64'))
condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
- task: PowerShell@2
displayName: 'Convert Test Logs from WTL to xUnit format'
@@ -129,14 +90,13 @@ steps:
targetType: filePath
filePath: build\Helix\ConvertWttLogToXUnit.ps1
arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
condition: and(ne(variables['PGOBuildMode'], 'Instrument'),or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
condition: or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86'))
- task: PublishTestResults@2
displayName: 'Upload converted test logs'
condition: ne(variables['PGOBuildMode'], 'Instrument')
inputs:
testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
testResultsFiles: '**/onBuildMachineResults.xml'
testResultsFiles: '**/onBuildMachineResults.xml'
#searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
#mergeTestResults: false # Optional
#failTaskOnFailedTests: false # Optional
@@ -167,47 +127,24 @@ steps:
TargetFolder: '$(Build.ArtifactStagingDirectory)/appx'
OverWrite: true
flattenFolders: true
condition: succeeded()
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/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.exe
$(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.dll
$(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.xml
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.exe
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.dll
$(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.xml
**/Microsoft.VCLibs.*.appx
**/TestHostApp/*.exe
**/TestHostApp/*.dll
**/TestHostApp/*.xml
!**/*.pdb
!**/*.ipdb
!**/*.obj
!**/*.pch
**/TestHostApp/*
TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
OverWrite: true
flattenFolders: true
condition: succeeded()
condition: and(and(succeeded(), eq(variables['BuildPlatform'], 'x64')), ne(variables['Build.Reason'], 'PullRequest'))
- task: PublishBuildArtifacts@1
displayName: 'Publish All Build Artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
- task: CopyFiles@2
displayName: 'Copy PGO databases needed for PGO instrumentation run'
inputs:
Contents: |
**/*.pgd
TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/PGO/$(BuildPlatform)'
OverWrite: true
flattenFolders: true
condition: and(succeeded(), eq(variables['PGOBuildMode'], 'Instrument'))
- task: PublishBuildArtifacts@1
displayName: 'Publish All PGO Artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/PGO'
ArtifactName: 'PGO'
condition: and(succeeded(), eq(variables['PGOBuildMode'], 'Instrument'))
ArtifactName: 'drop'

View File

@@ -12,4 +12,4 @@ steps:
inputs:
targetType: filePath
filePath: build\Helix\GenerateTestProjFile.ps1
arguments: -TestFile '${{ parameters.testFilePath }}' -OutputProjFile '$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform)\${{ parameters.outputProjFileName }}' -JobTestSuiteName '${{ parameters.testSuite }}' -TaefPath '$(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.60.210621002\build\Binaries\x86' -TaefQuery '${{ parameters.taefQuery }}'
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 }}'

View File

@@ -5,16 +5,24 @@ parameters:
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'
helixType: 'test/devtest'
artifactName: 'drop'
maxParallel: 4
rerunPassesRequiredToAvoidFailure: 5
taefQuery: ''
configuration: ''
platform: ''
# if 'useBuildOutputFromBuildId' is set, we will default to using a build from this pipeline:
useBuildOutputFromPipeline: $(System.DefinitionId)
openHelixTargetQueues: 'windows.10.amd64.client19h1.open.xaml'
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 }}
@@ -25,21 +33,19 @@ jobs:
timeoutInMinutes: 120
strategy:
maxParallel: ${{ parameters.maxParallel }}
matrix: ${{ parameters.matrix }}
variables:
buildConfiguration: ${{ parameters.configuration }}
buildPlatform: ${{ parameters.platform }}
openHelixTargetQueues: ${{ parameters.openHelixTargetQueues }}
artifactsDir: $(Build.SourcesDirectory)\Artifacts
taefPath: $(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.60.210621002\build\Binaries\$(buildPlatform)
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:
@@ -53,23 +59,23 @@ jobs:
nugetConfigPath: nuget.config
restoreDirectory: packages
- task: DownloadBuildArtifacts@0
- task: DownloadBuildArtifacts@0
condition:
and(succeeded(),eq(variables['useBuildOutputFromBuildId'],''))
inputs:
artifactName: ${{ parameters.artifactName }}
inputs:
artifactName: ${{ parameters.artifactName }}
downloadPath: '$(artifactsDir)'
- task: DownloadBuildArtifacts@0
- task: DownloadBuildArtifacts@0
condition:
and(succeeded(),ne(variables['useBuildOutputFromBuildId'],''))
inputs:
inputs:
buildType: specific
buildVersionToDownload: specific
project: $(System.TeamProjectId)
pipeline: ${{ parameters.useBuildOutputFromPipeline }}
buildId: $(useBuildOutputFromBuildId)
artifactName: ${{ parameters.artifactName }}
artifactName: ${{ parameters.artifactName }}
downloadPath: '$(artifactsDir)'
- task: CmdLine@1
@@ -84,60 +90,35 @@ jobs:
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'
- task: PowerShell@2
displayName: 'Make artifact directories'
inputs:
targetType: inline
script: |
New-Item -ItemType Directory -Force -Path "$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\"
New-Item -ItemType Directory -Force -Path "$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform)\"
- template: helix-createprojfile-steps.yml
parameters:
condition: and(succeeded(),eq('${{ parameters.testSuite }}','DevTestSuite'))
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(),eq('${{ parameters.testSuite }}','DevTestSuite'))
testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\SettingsModel.LocalTests.dll'
outputProjFileName: 'RunTestsInHelix-SettingsModelLocalTests.proj'
testSuite: '${{ parameters.testSuite }}'
taefQuery: ${{ parameters.taefQuery }}
- template: helix-createprojfile-steps.yml
parameters:
condition: and(succeeded(),eq('${{ parameters.testSuite }}','DevTestSuite'))
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 }}
- template: helix-createprojfile-steps.yml
parameters:
condition: and(succeeded(),or(eq('${{ parameters.testSuite }}','PgoInstrumentationSuite'),eq('${{ parameters.testSuite }}','DevTestSuite')))
testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\WindowsTerminal.UIA.Tests.dll'
outputProjFileName: 'RunTestsInHelix-WindowsTerminalUIATests.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:
@@ -147,3 +128,4 @@ jobs:
projects: build\Helix\RunTestsInHelix.proj
custom: msbuild
arguments: '$(helixCommonArgs) /p:IsExternal=true /p:Creator=Terminal /p:HelixTargetQueues=$(openHelixTargetQueues)'

View File

@@ -1,62 +0,0 @@
# From our friends at MUX: https://github.com/microsoft/microsoft-ui-xaml/blob/main/build/AzurePipelinesTemplates/MUX-BuildAndPublishPGONuGet-Job.yml
parameters:
dependsOn: ''
pgoArtifact: PGO
jobs:
- job: BuildAndPublishPGONuGet
dependsOn: ${{ parameters.dependsOn }}
pool:
vmImage: 'windows-2019'
variables:
artifactsPath: $(Build.SourcesDirectory)\Artifacts
pgoToolsPath: $(Build.SourcesDirectory)\tools\PGODatabase
nuspecPath: $(pgoToolsPath)\NuSpecs
nuspecFilename: PGO.nuspec
steps:
- task: DownloadBuildArtifacts@0
inputs:
artifactName: ${{ parameters.pgoArtifact }}
downloadPath: $(artifactsPath)
- task: NuGetToolInstaller@0
displayName: 'Use NuGet 5.2.0'
inputs:
versionSpec: 5.2.0
- task: CopyFiles@2
displayName: 'Copy pgd files to NuGet build directory'
inputs:
sourceFolder: $(artifactsPath)\${{ parameters.pgoArtifact }}
contents: '**\*.pgd'
targetFolder: $(nuspecPath)\tools
- task: powershell@2
displayName: 'Generate NuSpec file'
inputs:
targetType: filePath
filePath: $(pgoToolsPath)\generate-nuspec.ps1
workingDirectory: $(pgoToolsPath)
arguments: $(nuspecPath)\$(nuspecFilename).template $(nuspecPath)\$(nuspecFilename)
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
displayName: 'NuGet pack'
inputs:
command: pack
packagesToPack: '$(nuspecPath)\$(nuspecFilename)'
basePath: '$(nuspecPath)'
packDestination: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
inputs:
pathToPublish: $(Build.ArtifactStagingDirectory)
artifactName: ${{ parameters.pgoArtifact }}
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
displayName: 'NuGet push'
inputs:
command: push
publishVstsFeed: Terminal/TerminalDependencies
packagesToPush: $(Build.ArtifactStagingDirectory)/*.nupkg

View File

@@ -1,90 +0,0 @@
parameters:
dependsOn: ''
pgoArtifact: PGO
platform: ''
jobs:
- job: MergePGD
dependsOn: ${{ parameters.dependsOn }}
pool:
vmImage: 'windows-2019'
variables:
artifactsPath: $(Build.SourcesDirectory)\Artifacts
pgoArtifactsPath: $(artifactsPath)\${{ parameters.pgoArtifact }}
buildPlatform: ${{ parameters.platform }}
steps:
# The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
- script: |
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
del %TEMP%\vsinstalldir.txt
call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
echo VCToolsInstallDir = %VCToolsInstallDir%
echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
displayName: 'Retrieve VC tools directory'
- task: DownloadBuildArtifacts@0
inputs:
artifactName: ${{ parameters.pgoArtifact }}
downloadPath: $(artifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge WindowsTerminal*.pgc WindowsTerminal.pgd
displayName: 'Merge Terminal pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge OpenConsole*.pgc OpenConsole.pgd
displayName: 'Merge OpenConsole pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge Microsoft.Terminal.Control*.pgc Microsoft.Terminal.Control.pgd
displayName: 'Merge Microsoft.Terminal.Control pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge Microsoft.Terminal.Remoting*.pgc Microsoft.Terminal.Remoting.pgd
displayName: 'Merge Microsoft.Terminal.Remoting pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge Microsoft.Terminal.Settings.Editor*.pgc Microsoft.Terminal.Settings.Editor.pgd
displayName: 'Merge Microsoft.Terminal.Settings.Editor pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge Microsoft.Terminal.Settings.Model*.pgc Microsoft.Terminal.Settings.Model.pgd
displayName: 'Merge Microsoft.Terminal.Settings.Model pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge TerminalApp*.pgc TerminalApp.pgd
displayName: 'Merge TerminalApp pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- script: |
cd $(buildPlatform)
"%VCToolsInstallDir%\bin\hostx64\x64\pgomgr.exe" /merge TerminalConnection*.pgc TerminalConnection.pgd
displayName: 'Merge TerminalConnection pgc files into pgd'
workingDirectory: $(pgoArtifactsPath)
- task: CopyFiles@2
displayName: 'Copy merged pgd to artifact staging'
inputs:
sourceFolder: $(pgoArtifactsPath)
contents: '**\$(buildPlatform)\*.pgd'
targetFolder: $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts@1
inputs:
pathToPublish: $(Build.ArtifactStagingDirectory)
artifactName: ${{ parameters.pgoArtifact }}

View File

@@ -0,0 +1,74 @@
parameters:
configuration: 'Release'
jobs:
- job: SignDeploy${{ parameters.configuration }}
displayName: Sign and Deploy for ${{ parameters.configuration }}
dependsOn:
- Buildx64AuditMode
- Buildx64Release
- Buildx86Release
- Buildarm64Release
- CodeFormatCheck
condition: |
and
(
in(dependencies.Buildx64AuditMode.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
in(dependencies.Buildx64Release.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
in(dependencies.Buildx86Release.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
in(dependencies.Buildarm64Release.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
in(dependencies.CodeFormatCheck.result, 'Succeeded', 'SucceededWithIssues', 'Skipped')
)
variables:
BuildConfiguration: ${{ parameters.configuration }}
AppxProjectName: CascadiaPackage
AppxBundleName: Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle
pool:
name: Package ES Lab E
steps:
- checkout: self
clean: true
- task: PkgESSetupBuild@10
displayName: 'Package ES - Setup Build'
inputs:
useDfs: false
productName: WindowsTerminal
disableOutputRedirect: true
- task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
displayName: 'Component Detection'
- task: DownloadBuildArtifacts@0
displayName: Download AppX artifacts
inputs:
artifactName: 'appx-$(BuildConfiguration)'
itemPattern: |
**/*.appx
**/*.msix
downloadPath: '$(Build.ArtifactStagingDirectory)\appx'
- task: PowerShell@2
displayName: 'Create $(AppxBundleName)'
inputs:
targetType: filePath
filePath: '.\build\scripts\Create-AppxBundle.ps1'
arguments: |
-InputPath "$(Build.ArtifactStagingDirectory)\appx" -ProjectName $(AppxProjectName) -BundleVersion 0.0.0.0 -OutputPath "$(Build.ArtifactStagingDirectory)\$(AppxBundleName)"
- task: PkgESCodeSign@10
displayName: 'Package ES - SignConfig.WindowsTerminal.xml'
inputs:
signConfigXml: 'build\config\SignConfig.WindowsTerminal.xml'
inPathRoot: '$(Build.ArtifactStagingDirectory)'
outPathRoot: '$(Build.ArtifactStagingDirectory)\signed'
- task: PublishBuildArtifacts@1
displayName: 'Publish Signed AppX'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)\signed'
ArtifactName: 'appxbundle-signed-$(BuildConfiguration)'

View File

@@ -1,97 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="16.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- THIS PROJECT CANNOT BE LOADED INTO THE SOLUTION. -->
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Release|Any CPU">
<Configuration>Release</Configuration>
<Platform>AnyCPU</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Fuzzing|Any CPU">
<Configuration>Fuzzing</Configuration>
<Platform>AnyCPU</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="AuditMode|Any CPU">
<Configuration>AuditMode</Configuration>
<Platform>AnyCPU</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|Any CPU">
<Configuration>Debug</Configuration>
<Platform>AnyCPU</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>d97c3c61-53cd-4e72-919b-9a0940e038f9</ProjectGuid>
</PropertyGroup>
<PropertyGroup>
<IntermediateOutputPath>$(SolutionDir)obj\$(Configuration)\GenerateFeatureFlags\</IntermediateOutputPath>
<OpenConsoleCommonOutDir>$(SolutionDir)bin\$(Configuration)\</OpenConsoleCommonOutDir>
<_WTBrandingName Condition="'$(WindowsTerminalBranding)'=='Preview'">Preview</_WTBrandingName>
<_WTBrandingName Condition="'$(WindowsTerminalBranding)'=='Release'">Release</_WTBrandingName>
<_WTBrandingName Condition="'$(_WTBrandingName)'==''">Dev</_WTBrandingName>
</PropertyGroup>
<Target Name="_GenerateBranchAndBrandingCache">
<Exec Command="git.exe rev-parse --abbrev-ref HEAD"
CustomWarningRegularExpression="^fatal:.*"
ConsoleToMsBuild="true"
IgnoreExitCode="true">
<Output TaskParameter="ConsoleOutput" ItemName="_GitBranchLines" />
</Exec>
<ItemGroup>
<_BrandingLines Include="$(_WTBrandingName)" />
</ItemGroup>
<WriteLinesToFile File="$(IntermediateOutputPath)branch_branding_cache.txt"
Lines="@(_GitBranchLines);@(_BrandingLines)"
Overwrite="true"
WriteOnlyWhenDifferent="true" />
<ItemGroup>
<FileWrites Include="$(IntermediateOutputPath)branch_branding_cache.txt" />
<_BranchBrandingCacheFiles Include="$(IntermediateOutputPath)branch_branding_cache.txt" />
</ItemGroup>
</Target>
<Target Name="_RunFeatureFlagScript"
Inputs="@(FeatureFlagFile);@(_BranchBrandingCacheFiles)"
Outputs="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h"
DependsOnTargets="_GenerateBranchAndBrandingCache">
<MakeDir Directories="$(OpenConsoleCommonOutDir)\inc" />
<Exec
Command="powershell -NoLogo -NoProfile -NonInteractive -ExecutionPolicy ByPass -Command &quot;$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1&quot; -Path &quot;%(FeatureFlagFile.FullPath)&quot; -Branding $(_WTBrandingName)"
ConsoleToMsBuild="true"
StandardOutputImportance="low">
<Output TaskParameter="ConsoleOutput" ItemName="_FeatureFlagFileLines" />
</Exec>
<!--
We gather the feature flag output in MSBuild and emit the file so that we can take advantage of
WriteOnlyWhenDifferent. Doing this ensures that we don't rebuild the world when the branch changes
(if it results in a new TilFeatureStaging.h that would have had the same content/features as the previous one)
-->
<WriteLinesToFile File="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h"
Lines="@(_FeatureFlagFileLines)"
Overwrite="true"
WriteOnlyWhenDifferent="true" />
<ItemGroup>
<FileWrites Include="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h" />
</ItemGroup>
</Target>
<Target Name="Build" DependsOnTargets="_RunFeatureFlagScript" />
<Target Name="Clean">
<Delete Files="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h" />
</Target>
<ItemGroup>
<FeatureFlagFile Include="$(SolutionDir)\src\features.xml" />
</ItemGroup>
</Project>

View File

@@ -22,7 +22,7 @@ Param(
[Parameter(HelpMessage="Path to makeappx.exe")]
[ValidateScript({Test-Path $_ -Type Leaf})]
[string]
$MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\MakeAppx.exe"
$MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\MakeAppx.exe"
)
If ($null -Eq (Get-Item $MakeAppxPath -EA:SilentlyContinue)) {

View File

@@ -3,24 +3,12 @@
# Checks for code formatting errors. Will throw exception if any are found.
function Invoke-CheckBadCodeFormatting() {
Import-Module ./tools/OpenConsole.psm1
# Don't run the XAML formatter in this step - even if it changes nothing,
# it'll still touch all the .xaml files.
Invoke-CodeFormat -IgnoreXaml
Invoke-CodeFormat
# returns a non-zero exit code if there are any diffs in the tracked files in the repo
git diff-index --quiet HEAD --
if ($lastExitCode -eq 1) {
# Write the list of files that need updating to the log
git diff-index --name-only HEAD
throw "code formatting bad, run Invoke-CodeFormat on branch"
}
# Manually check the formatting of our .xaml files, without touching them.
Test-XamlFormat
}
Invoke-CheckBadCodeFormatting

View File

@@ -8,7 +8,7 @@ Param(
[Parameter(HelpMessage="Path to Windows Kit")]
[ValidateScript({Test-Path $_ -Type Leaf})]
[string]
$WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0"
$WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0"
)
$ErrorActionPreference = "Stop"
@@ -58,7 +58,7 @@ Try {
### Check the activatable class entries for a few DLLs we need.
$inProcServers = $Manifest.Package.Extensions.Extension.InProcessServer.Path
$RequiredInProcServers = ("TerminalApp.dll", "Microsoft.Terminal.Control.dll", "Microsoft.Terminal.Remoting.dll", "Microsoft.Terminal.Settings.Editor.dll", "Microsoft.Terminal.Settings.Model.dll", "TerminalConnection.dll")
$RequiredInProcServers = ("TerminalApp.dll", "TerminalControl.dll", "TerminalConnection.dll")
Write-Verbose "InProc Servers: $inProcServers"

View File

@@ -19,13 +19,9 @@
"/.github/",
"/samples/",
"/res/terminal/",
"/res/fonts/",
"/doc/specs/",
"/doc/cascadia/",
"/doc/user-docs/",
"/src/tools/MonarchPeasantSample/",
"/scratch/",
"Scratch.sln",
"/doc/user-docs/"
],
"SuffixFilters": [
".dbb",
@@ -41,7 +37,6 @@
".wrn",
".rec",
".err",
"XamlStyler.json",
".xlsx"
]
]
}

View File

@@ -3,9 +3,9 @@
<!-- This file is read by XES, which we use in our Release builds. -->
<PropertyGroup Label="Version">
<XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
<XesBaseYearForStoreVersion>2021</XesBaseYearForStoreVersion>
<XesBaseYearForStoreVersion>2020</XesBaseYearForStoreVersion>
<VersionMajor>1</VersionMajor>
<VersionMinor>11</VersionMinor>
<VersionMinor>5</VersionMinor>
<VersionInfoProductName>Windows Terminal</VersionInfoProductName>
</PropertyGroup>
</Project>

Submodule dep/wil updated: 2e225973d6...3c00e7f1d8

View File

@@ -5,13 +5,13 @@
`.../console/published/wincon.w` in the OS repo when you submit the PR.
The branch won't build without it.
* For now, you can update winconp.h with your consumable changes.
* Define registry name (ex `CONSOLE_REGISTRY_CURSORCOLOR`)
* Add the setting to `CONSOLE_STATE_INFO`
* Define the property key ID and the property key itself.
* define registry name (ex `CONSOLE_REGISTRY_CURSORCOLOR`)
* add the setting to `CONSOLE_STATE_INFO`
* define the property key ID and the property key itself
- Yes, the large majority of the `DEFINE_PROPERTYKEY` defs are the same, it's only the last byte of the guid that changes
2. Add matching fields to Settings.hpp
- Add getters, setters, the whole drill.
- add getters, setters, the whole drill.
3. Add to the propsheet
- We need to add it to *reading and writing* the registry from the propsheet, and *reading* the link from the propsheet. Yes, that's weird, but the propsheet is smart enough to re-use ShortcutSerialization::s_SetLinkValues, but not smart enough to do the same with RegistrySerialization.

View File

@@ -12,11 +12,11 @@ Use the [TAEF Verify Macros for C++](https://docs.microsoft.com/en-us/windows-ha
### 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 `Microsoft.Taef` package.
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 `Microsoft.Taef` 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.
> 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 environment first:
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
@@ -48,17 +48,3 @@ Invoke-OpenConsoleTests
```
`Invoke-OpenConsoleTests` supports a number of options, which you can enumerate by running `Invoke-OpenConsoleTests -?`.
### Debugging Tests
If you want to debug a test, you can do so by using the TAEF /waitForDebugger flag, such as:
runut *Tests.dll /name:TextBufferTests::TestInsertCharacter /waitForDebugger
Replace the test name with the one you want to debug. Then, TAEF will begin executing the test and output something like this:
TAEF: Waiting for debugger - PID <some PID> @ IP <some IP address>
You can then attach to that PID in your debugger of choice. In Visual Studio, you can use Debug -> Attach To Process, or you could use WinDbg or whatever you want.
Once the debugger attaches, the test will execute and your breakpoints will be hit.

View File

@@ -9,13 +9,13 @@ The primary usages of WIL in our code so far are...
### Smart Pointers ###
Inside [wil/resource.h](https://github.com/microsoft/wil/blob/master/include/wil/resource.h) are smart pointer like classes for many Windows OS resources like file handles, socket handles, process handles, and so on. They're of the form `wil::unique_handle` and call the appropriate/matching OS function (like `CloseHandle()` in this case) when they go out of scope.
Inside [wil\resource.h](https://github.com/microsoft/wil/blob/master/include/wil/resource.h) are smart pointer like classes for many Windows OS resources like file handles, socket handles, process handles, and so on. They're of the form `wil::unique_handle` and call the appropriate/matching OS function (like `CloseHandle()` in this case) when they go out of scope.
Another useful item is `wil::make_unique_nothrow()` which is analogous to `std::make_unique` (except without the exception which might help you integrate with existing exception-free code in the console.) This will return a `wistd::unique_ptr` (vs. a `std::unique_ptr`) which can be used in a similar manner.
### Result Handling ###
To manage the various types of result codes that come back from Windows APIs, the file [wil/result.h](https://github.com/microsoft/wil/blob/master/include/wil/result.h) provides a wealth of macros that can help.
To manage the various types of result codes that come back from Windows APIs, the file [wil\result.h](https://github.com/microsoft/wil/blob/master/include/wil/result.h) provides a wealth of macros that can help.
As an example, the method `DuplicateHandle()` returns a `BOOL` value that is `FALSE` under failure and would like you to `GetLastError()` from the operating system to find out what the actual result code is. In this circumstance, you could use the macro `RETURN_IF_WIN32_BOOL_FALSE` to wrap the call to `DuplicateHandle()` which would automatically handle this pattern for you and return the `HRESULT` equivalent on failure.

View File

@@ -127,4 +127,4 @@ When a release is created, if the PR ID number is linked inside the release desc
- Issue message: 🎉This issue was addressed in #{pull request ID}, which has now been successfully released as {release name} {release version}.🎉"
## Admin Panel
[Here](https://portal.fabricbot.ms/bot/?repo=microsoft/terminal)
[Here](https://fabric-cp.azurewebsites.net/bot/)

View File

@@ -9,13 +9,7 @@ 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:
When using Visual Studio, be sure to set up the path for code formatting. To download the required clang-format.exe file, follow one of the building instructions below and run:
```powershell
Import-Module .\tools\OpenConsole.psm1
Set-MsBuildDevEnvironment
Get-Format
```
After, go to Tools > Options > Text Editor > C++ > Formatting and checking "Use custom clang-format.exe file" in Visual Studio and choose the clang-format.exe in the repository at /packages/clang-format.win-x86.10.0.0/tools/clang-format.exe by clicking "browse" right under the check box.
When using Visual Studio, be sure to set up the path for code formatting. This can be done in Visual Studio by going to Tools > Options > Text Editor > C++ > Formatting and checking "Use custom clang-format.exe file" and choosing the clang-format.exe in the repository at /dep/llvm/clang-format.exe by clicking "browse" right under the check box.
### Building in PowerShell

View File

@@ -1,397 +0,0 @@
# Adding Settings to Windows Terminal
Adding a setting to Windows Terminal is fairly straightforward. This guide serves as a reference on how to add a setting.
## 1. Terminal Settings Model
The Terminal Settings Model (`Microsoft.Terminal.Settings.Model`) is responsible for (de)serializing and exposing settings.
### `INHERITABLE_SETTING` macro
The `INHERITABLE_SETTING` macro can be used to implement inheritance for your new setting and store the setting in the settings model. It takes three parameters:
- `type`: the type that the setting will be stored as
- `name`: the name of the variable for storage
- `defaultValue`: the value to use if the user does not define the setting anywhere
### Adding a Profile setting
This tutorial will add `CloseOnExitMode CloseOnExit` as a profile setting.
1. In `Profile.h`, declare/define the setting:
```c++
INHERITABLE_SETTING(CloseOnExitMode, CloseOnExit, CloseOnExitMode::Graceful)
```
2. In `Profile.idl`, expose the setting via WinRT:
```c++
Boolean HasCloseOnExit();
void ClearCloseOnExit();
CloseOnExitMode CloseOnExit;
```
3. In `Profile.cpp`, add (de)serialization and copy logic:
```c++
// Top of file:
// - Add the serialization key
static constexpr std::string_view CloseOnExitKey{ "closeOnExit" };
// CopySettings() or Copy():
// - The setting is exposed in the Settings UI
profile->_CloseOnExit = source->_CloseOnExit;
// LayerJson():
// - get the value from the JSON
JsonUtils::GetValueForKey(json, CloseOnExitKey, _CloseOnExit);
// ToJson():
// - write the value to the JSON
JsonUtils::SetValueForKey(json, CloseOnExitKey, _CloseOnExit);
```
- If the setting is not a primitive type, in `TerminalSettingsSerializationHelpers.h` add (de)serialization logic for the accepted values:
```c++
// For enum values...
JSON_ENUM_MAPPER(::winrt::Microsoft::Terminal::Settings::Model::CloseOnExitMode)
{
JSON_MAPPINGS(3) = {
pair_type{ "always", ValueType::Always },
pair_type{ "graceful", ValueType::Graceful },
pair_type{ "never", ValueType::Never },
};
};
// For enum flag values...
JSON_FLAG_MAPPER(::winrt::Microsoft::Terminal::TerminalControl::CopyFormat)
{
JSON_MAPPINGS(5) = {
pair_type{ "none", AllClear },
pair_type{ "html", ValueType::HTML },
pair_type{ "rtf", ValueType::RTF },
pair_type{ "all", AllSet },
};
};
// NOTE: This is also where you can add functionality for...
// - overloaded type support (i.e. accept a bool and an enum)
// - custom (de)serialization logic (i.e. coordinates)
```
### Adding a Global setting
Follow the "adding a Profile setting" instructions above, but do it on the `GlobalAppSettings` files.
### Adding an Action
This tutorial will add the `openSettings` action.
1. In `KeyMapping.idl`, declare the action:
```c++
// Add the action to ShortcutAction
enum ShortcutAction
{
OpenSettings
}
```
2. In `ActionAndArgs.cpp`, add serialization logic:
```c++
// Top of file:
// - Add the serialization key
static constexpr std::string_view OpenSettingsKey{ "openSettings" };
// ActionKeyNamesMap:
// - map the new enum to the json key
{ OpenSettingsKey, ShortcutAction::OpenSettings },
```
3. If the action should automatically generate a name when it appears in the Command Palette...
```c++
// In ActionAndArgs.cpp GenerateName() --> GeneratedActionNames
{ ShortcutAction::OpenSettings, RS_(L"OpenSettingsCommandKey") },
// In Resources.resw for Microsoft.Terminal.Settings.Model.Lib,
// add the generated name
// NOTE: Visual Studio presents the resw file as a table.
// If you choose to edit the file with a text editor,
// the code should look something like this...
<data name="OpenSettingsCommandKey" xml:space="preserve">
<value>Open settings file</value>
</data>
```
4. If the action supports arguments...
- In `ActionArgs.idl`, declare the arguments
```c++
[default_interface] runtimeclass OpenSettingsArgs : IActionArgs
{
// this declares the "target" arg
SettingsTarget Target { get; };
};
```
- In `ActionArgs.h`, define the new runtime class
```c++
struct OpenSettingsArgs : public OpenSettingsArgsT<OpenSettingsArgs>
{
OpenSettingsArgs() = default;
// adds a getter/setter for your argument, and defines the json key
WINRT_PROPERTY(SettingsTarget, Target, SettingsTarget::SettingsFile);
static constexpr std::string_view TargetKey{ "target" };
public:
hstring GenerateName() const;
bool Equals(const IActionArgs& other)
{
auto otherAsUs = other.try_as<OpenSettingsArgs>();
if (otherAsUs)
{
return otherAsUs->_Target == _Target;
}
return false;
};
static FromJsonResult FromJson(const Json::Value& json)
{
// LOAD BEARING: Not using make_self here _will_ break you in the future!
auto args = winrt::make_self<OpenSettingsArgs>();
JsonUtils::GetValueForKey(json, TargetKey, args->_Target);
return { *args, {} };
}
IActionArgs Copy() const
{
auto copy{ winrt::make_self<OpenSettingsArgs>() };
copy->_Target = _Target;
return *copy;
}
};
```
- In `ActionArgs.cpp`, define `GenerateName()`. This is used to automatically generate a name when it appears in the Command Palette.
- In `ActionAndArgs.cpp`, add serialization logic:
```c++
// ActionKeyNamesMap --> argParsers
{ ShortcutAction::OpenSettings, OpenSettingsArgs::FromJson },
```
### Adding an Action Argument
Follow step 3 from the "adding an Action" instructions above, but modify the relevant `ActionArgs` files.
## 2. Setting Functionality
Now that the Terminal Settings Model is updated, Windows Terminal can read and write to the settings file. This section covers how to add functionality to your newly created setting.
### App-level settings
App-level settings are settings that affect the frame of Windows Terminal. Generally, these tend to be global settings. The `TerminalApp` project is responsible for presenting the frame of Windows Terminal. A few files of interest include:
- `TerminalPage`: XAML control responsible for the look and feel of Windows Terminal
- `AppLogic`: WinRT class responsible for window-related issues (i.e. the titlebar, focus mode, etc...)
Both have access to a `CascadiaSettings` object, for you to read the loaded setting and update Windows Terminal appropriately.
### Terminal-level settings
Terminal-level settings are settings that affect a shell session. Generally, these tend to be profile settings. The `TerminalApp` project is responsible for packaging this settings from the Terminal Settings Model to the terminal instance. There are two kinds of settings here:
- `IControlSettings`:
- These are settings that affect the `TerminalControl` (a XAML control that hosts a shell session).
- Examples include background image customization, interactivity behavior (i.e. selection), acrylic and font customization.
- The `TerminalControl` project has access to these settings via a saved `IControlSettings` member.
- `ICoreSettings`:
- These are settings that affect the `TerminalCore` (a lower level object that interacts with the text buffer).
- Examples include initial size, history size, and cursor customization.
- The `TerminalCore` project has access to these settings via a saved `ICoreSettings` member.
`TerminalApp` packages these settings into a `TerminalSettings : IControlSettings, ICoreSettings` object upon creating a new terminal instance. To do so, you must submit the following changes:
- Declare the setting in `IControlSettings.idl` or `ICoreSettings.idl` (whichever is relevant to your setting). If your setting is an enum setting, declare the enum here instead of in the `TerminalSettingsModel` project.
- In `TerminalSettings.h`, declare/define the setting...
```c++
// The WINRT_PROPERTY macro declares/defines a getter setter for the setting.
// Like INHERITABLE_SETTING, it takes in a type, name, and defaultValue.
WINRT_PROPERTY(bool, UseAcrylic, false);
```
- In `TerminalSettings.cpp`...
- update `_ApplyProfileSettings` for profile settings
- update `_ApplyGlobalSettings` for global settings
- If additional processing is necessary, that would happen here. For example, `backgroundImageAlignment` is stored as a `ConvergedAlignment` in the Terminal Settings Model, but converted into XAML's separate horizontal and vertical alignment enums for packaging.
### Actions
Actions are packaged as an `ActionAndArgs` object, then handled in `TerminalApp`. To add functionality for actions...
- In the `ShortcutActionDispatch` files, dispatch an event when the action occurs...
```c++
// ShortcutActionDispatch.idl
event Windows.Foundation.TypedEventHandler<ShortcutActionDispatch, Microsoft.Terminal.Settings.Model.ActionEventArgs> OpenSettings;
// ShortcutActionDispatch.h
TYPED_EVENT(OpenSettings, TerminalApp::ShortcutActionDispatch, Microsoft::Terminal::Settings::Model::ActionEventArgs);
// ShortcutActionDispatch.cpp --> DoAction()
// - dispatch the appropriate event
case ShortcutAction::OpenSettings:
{
_OpenSettingsHandlers(*this, eventArgs);
break;
}
```
- In `TerminalPage` files, handle the event...
```c++
// TerminalPage.h
// - declare the handler
void _HandleOpenSettings(const IInspectable& sender, const Microsoft::Terminal::Settings::Model::ActionEventArgs& args);
// TerminalPage.cpp --> _RegisterActionCallbacks()
// - register the handler
_actionDispatch->OpenSettings({ this, &TerminalPage::_HandleOpenSettings });
// AppActionHandlers.cpp
// - direct the function to the right place and call a helper function
void TerminalPage::_HandleOpenSettings(const IInspectable& /*sender*/,
const ActionEventArgs& args)
{
// NOTE: this if-statement can be omitted if the action does not support arguments
if (const auto& realArgs = args.ActionArgs().try_as<OpenSettingsArgs>())
{
_LaunchSettings(realArgs.Target());
args.Handled(true);
}
}
```
`AppActionHandlers` vary based on the action you want to perform. A few useful helper functions include:
- `_GetFocusedTab()`: retrieves the focused tab
- `_GetActiveControl()`: retrieves the active terminal control
- `_GetTerminalTabImpl()`: tries to cast the given tab as a `TerminalTab` (a tab that hosts a terminal instance)
## 3. Settings UI
### Exposing Enum Settings
If the new setting supports enums, you need to expose a map of the enum and the respective value in the Terminal Settings Model's `EnumMappings`:
```c++
// EnumMappings.idl
static Windows.Foundation.Collections.IMap<String, Microsoft.Terminal.Settings.Model.CloseOnExitMode> CloseOnExitMode { get; };
// EnumMappings.h
static winrt::Windows::Foundation::Collections::IMap<winrt::hstring, CloseOnExitMode> CloseOnExitMode();
// EnumMappings.cpp
// - this macro leverages the json enum mapper in TerminalSettingsSerializationHelper to expose
// the mapped values across project boundaries
DEFINE_ENUM_MAP(Model::CloseOnExitMode, CloseOnExitMode);
```
### Binding and Localizing the Enum Setting
Find the page in the Settings UI that the new setting fits best in. In this example, we are adding `LaunchMode`.
1. In `Launch.idl`, expose the bindable setting...
```c++
// Expose the current value for the setting
IInspectable CurrentLaunchMode;
// Expose the list of possible values
Windows.Foundation.Collections.IObservableVector<Microsoft.Terminal.Settings.Editor.EnumEntry> LaunchModeList { get; };
```
2. In `Launch.h`, declare the bindable enum setting...
```c++
// the GETSET_BINDABLE_ENUM_SETTING macro accepts...
// - name: the name of the setting
// - enumType: the type of the setting
// - settingsModelName: how to retrieve the setting (use State() to get access to the settings model)
// - settingNameInModel: the name of the setting in the terminal settings model
GETSET_BINDABLE_ENUM_SETTING(LaunchMode, Model::LaunchMode, State().Settings().GlobalSettings, LaunchMode);
```
3. In `Launch.cpp`, populate these functions...
```c++
// Constructor (after InitializeComponent())
// the INITIALIZE_BINDABLE_ENUM_SETTING macro accepts...
// - name: the name of the setting
// - enumMappingsName: the name from the TerminalSettingsModel's EnumMappings
// - enumType: the type for the enum
// - resourceSectionAndType: prefix for the localization
// - resourceProperty: postfix for the localization
INITIALIZE_BINDABLE_ENUM_SETTING(LaunchMode, LaunchMode, LaunchMode, L"Globals_LaunchMode", L"Content");
```
4. In `Resources.resw` for Microsoft.Terminal.Settings.Editor, add the localized text to expose each enum value. Use the following format: `<SettingGroup>_<SettingName><EnumValue>.Content`
- `SettingGroup`:
- `Globals` for global settings
- `Profile` for profile settings
- `SettingName`:
- the Pascal-case format for the setting type (i.e. `LaunchMode` for `"launchMode"`)
- `EnumValue`:
- the json key for the setting value, but with the first letter capitalized (i.e. `Focus` for `"focus"`)
- The resulting resw key should look something like this `Globals_LaunchModeFocus.Content`
- This is the text that will be used in your control
### Updating the UI
When adding a setting to the UI, make sure you follow the [UWP design guidance](https://docs.microsoft.com/windows/uwp/design/).
#### Enum Settings
Now, create a XAML control in the relevant XAML file. Use the following tips and tricks to style everything appropriately:
- Wrap the control in a `ContentPresenter` adhering to the `SettingContainerStyle` style
- Bind `SelectedItem` to the relevant `Current<Setting>` (i.e. `CurrentLaunchMode`). Ensure it's a TwoWay binding
- Bind `ItemsSource` to `<Setting>List` (i.e. `LaunchModeList`)
- Set the ItemTemplate to the `Enum<ControlType>Template` (i.e. `EnumRadioButtonTemplate` for radio buttons)
- Set the style to the appropriate one in `CommonResources.xaml`
```xml
<!--Launch Mode-->
<ContentPresenter Style="{StaticResource SettingContainerStyle}">
<muxc:RadioButtons x:Uid="Globals_LaunchMode"
SelectedItem="{x:Bind CurrentLaunchMode, Mode="TwoWay"}"
ItemsSource="{x:Bind LaunchModeList}"
ItemTemplate="{StaticResource EnumRadioButtonTemplate}"
Style="{StaticResource RadioButtonsSettingStyle}"/>
</ContentPresenter>
```
To add any localized text, add a `x:Uid`, and access the relevant property via the Resources.resw file. For example, `Globals_LaunchMode.Header` sets the header for this control. You can also set the tooltip text like this:
`Globals_DefaultProfile.[using:Windows.UI.Xaml.Controls]ToolTipService.ToolTip`.
#### Non-Enum Settings
Continue to reference `CommonResources.xaml` for appropriate styling and wrap the control with a similar `ContentPresenter`. However, instead of binding to the `Current<Setting>` and `<Setting>List`, bind directly to the setting via the state. Binding a setting like `altGrAliasing` should look something like this:
```xml
<!--AltGr Aliasing-->
<ContentPresenter Style="{StaticResource SettingContainerStyle}">
<CheckBox x:Uid="Profile_AltGrAliasing"
IsChecked="{x:Bind State.Profile.AltGrAliasing, Mode=TwoWay}"
Style="{StaticResource CheckBoxSettingStyle}"/>
</ContentPresenter>
```
#### Profile Settings
If you are specifically adding a Profile setting, in addition to the steps above, you need to make the setting observable by modifying the `Profiles` files...
```c++
// Profiles.idl --> ProfileViewModel
// - this declares the setting as observable using the type and the name of the setting
OBSERVABLE_PROJECTED_SETTING(Microsoft.Terminal.Settings.Model.CloseOnExitMode, CloseOnExit);
// Profiles.h --> ProfileViewModel
// - this defines the setting as observable off of the _profile object
OBSERVABLE_PROJECTED_SETTING(_profile, CloseOnExit);
// Profiles.h --> ProfileViewModel
// - if the setting cannot be inherited by another profile (aka missing the Clear() function), use the following macro instead:
PERMANENT_OBSERVABLE_PROJECTED_SETTING(_profile, Guid);
```
The `ProfilePageNavigationState` holds a `ProfileViewModel`, which wraps the `Profile` object from the Terminal Settings Model. The `ProfileViewModel` makes all of the profile settings observable.
### Actions
Actions are not yet supported in the Settings UI.

View File

@@ -8,20 +8,19 @@ 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.
// one is populated or unchanged.
JsonUtils::GetValue(json, two);
// two is populated, nullopt or an exception is thrown
// two is populated, nullopt or unchanged
auto three = JsonUtils::GetValue<std::string>(json);
// three is populated or an exception is thrown
// three is populated or zero-initialized
auto four = JsonUtils::GetValue<std::optional<std::string>>(json);
// four is populated or nullopt
@@ -226,14 +225,14 @@ auto v = JsonUtils::GetValue<int>(json, conv);
-|json type invalid|json null|valid
-|-|-|-
`T`|❌ exception|❌ exception|✔ converted
`T`|❌ exception|🔵 unchanged|✔ converted
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
### GetValue&lt;T&gt;() (returning)
-|json type invalid|json null|valid
-|-|-|-
`T`|❌ exception|❌ exception|✔ converted
`T`|❌ exception|🟨 `T{}` (zero value)|✔ converted
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
### GetValueForKey(T&) (type-deducing)
@@ -243,14 +242,14 @@ 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_
`T`|🔵 unchanged|_❌ exception_|_🔵 unchanged_|_✔ converted_
`std::optional<T>`|_🔵 unchanged_|_❌ exception_|_🟨 `nullopt`_|_✔ converted_
### GetValueForKey&lt;T&gt;() (return value)
val type|key not found|_json type invalid_|_json null_|_valid_
-|-|-|-|-
`T`|🟨 `T{}` (zero value)|_❌ exception_|_❌ exception_|_✔ converted_
`T`|🟨 `T{}` (zero value)|_❌ exception_|_🟨 `T{}` (zero value)_|_✔ converted_
`std::optional<T>`|🟨 `nullopt`|_❌ exception_|_🟨 `nullopt`_|_✔ converted_
### Future Direction

View File

@@ -166,7 +166,7 @@ should be working just the same as before.
Now that you have a static library project, you can start building your unittest
dll. Start by creating a new directory for your unittest code, and creating a
`.vcxproj` for a TAEF unittest dll. For the Terminal solution, we use the TAEF
nuget package `Microsoft.Taef`.
nuget package `Taef.Redist.Wlk`.
### Referencing your C++/WinRT static lib
@@ -380,7 +380,7 @@ Here's the AppxManifest we're using:
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>
@@ -517,7 +517,7 @@ This is because of a few key lines we already put in the appxmanifest:
```xml
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>

File diff suppressed because it is too large Load Diff

View File

@@ -1,65 +0,0 @@
# til::feature
Feature flags are controlled by an XML document stored at `src/features.xml`.
## Example Document
```xml
<?xml version="1.0"?>
<featureStaging xmlns="http://microsoft.com/TilFeatureStaging-Schema.xsd">
<feature>
<!-- This will produce Feature_XYZ::IsEnabled() and TIL_FEATURE_XYZ_ENABLED (preprocessor) -->
<name>Feature_XYZ</name>
<description>Does a cool thing</description>
<!-- GitHub deliverable number; optional -->
<id>1234</id>
<!-- Whether the feature defaults to enabled or disabled -->
<stage>AlwaysEnabled|AlwaysDisabled</stage>
<!-- Branch wildcards where the feature should be *DISABLED* -->
<alwaysDisabledBranchTokens>
<branchToken>branch/with/wildcard/*</branchToken>
<!-- ... more branchTokens ... -->
</alwaysDisabledBranchTokens>
<!-- Just like alwaysDisabledBranchTokens, but for *ENABLING* the feature. -->
<alwaysEnabledBranchTokens>
<branchToken>...</branchToken>
</alwaysEnabledBranchTokens>
<!-- Brandings where the feature should be *DISABLED* -->
<alwaysDisabledBrandingTokens>
<!-- Valid brandings include Dev, Preview, Release, WindowsInbox -->
<brandingToken>Release</brandingToken>
<!-- ... more brandingTokens ... -->
</alwaysDisabledBrandingTokens>
<!-- Just like alwaysDisabledBrandingTokens, but for *ENABLING* the feature -->
<alwaysEnabledBrandingTokens>
<branchToken>...</branchToken>
</alwaysEnabledBrandingTokens>
<!-- Unequivocally disable this feature in Release -->
<alwaysDisabledReleaseTokens />
</feature>
</featureStaging>
```
## Notes
Features that are disabled for Release using `alwaysDisabledReleaseTokens` are
*always* disabled in Release, even if they come from a branch that would have
been enabled by the wildcard.
### Precedence
1. `alwaysDisabledReleaseTokens`
2. Enabled branches
3. Disabled branches
* The longest branch token that matches your branch will win.
3. Enabled brandings
4. Disabled brandings
5. The feature's default state

View File

@@ -1,239 +0,0 @@
#requires -version 6.1
<#
.SYNOPSIS
Scan source code and build a list of supported VT sequences.
.DESCRIPTION
Scan source code and build a list of supported VT sequences.
TODO: add more details
#>
[cmdletbinding(DefaultParameterSetName="stdout")]
param(
[parameter(ParameterSetName="file", mandatory)]
[string]$OutFile,
[parameter(ParameterSetName="file")]
[switch]$Force, # for overwriting $OutFile if it exists
[parameter(ParameterSetName="stdout")]
[parameter(ParameterSetName="file")]
[switch]$NoLogo, # no logo in summary
[parameter(ParameterSetName="stdout")]
[switch]$SummaryOnly, # no markdown generated
[parameter(ParameterSetName="stdout")]
[parameter(ParameterSetName="file")]
[switch]$Quiet, # no summary or logo
[parameter(ParameterSetName="file")]
[parameter(ParameterSetName="stdout")]
[string]$SolutionRoot = "..\..",
[parameter(ParameterSetName="file")]
[parameter(ParameterSetName="stdout")]
[string]$InterfacePath = $(join-path $solutionRoot "src\terminal\adapter\ITermDispatch.hpp"),
[parameter(ParameterSetName="file")]
[parameter(ParameterSetName="stdout")]
[string]$ConsoleAdapterPath = $(join-path $solutionRoot "src\terminal\adapter\adaptDispatch.hpp"),
[parameter(ParameterSetName="file")]
[parameter(ParameterSetName="stdout")]
[string]$TerminalAdapterPath = $(join-path $solutionRoot "src\cascadia\terminalcore\terminalDispatch.hpp")
)
if ($PSCmdlet.ParameterSetName -eq "stdout") {
Write-Verbose "Emitting markdown to STDOUT"
}
<#
GLOBALS
#>
[semver]$myVer = "0.6-beta"
$sequences = import-csv ".\master-sequence-list.csv"
$base = @{}
$conhost = @{}
$terminal = @{}
$prefix = "https://vt100.net/docs/vt510-rm/"
$repo = "https://github.com/oising/terminal/tree/master"
$conhostUrl = $ConsoleAdapterPath.TrimStart($SolutionRoot).replace("\", "/")
$terminalUrl = $TerminalAdapterPath.TrimStart($SolutionRoot).replace("\", "/")
function Read-SourceFiles {
# extract base interface
$baseScanner = [regex]'(?x)virtual\s\w+\s(?<method>\w+)(?s)[^;]+;(?-s).*?(?<seq>(?<=\/\/\s).+)'
$baseScanner.Matches(($src = get-content -raw $interfacePath)) | foreach-object {
$match = $_
#$line = (($src[0..$_.Index] -join "") -split "`n").Length
#$decl = $_.groups[0].value
$_.groups["seq"].value.split(",") | ForEach-Object {
$SCRIPT:base[$_.trim()] = $match.groups["method"].value
}
}
# match overrides of ITermDispatch
$scanner = [regex]'(?x)\s+\w+\s(?<method>\w+)(?s)[^;]+override;'
$scanner.Matches(($src = Get-Content -raw $consoleAdapterPath)) | ForEach-Object {
$line = (($src[0..$_.Index] -join "") -split "`n").Length
$SCRIPT:conhost[$_.groups["method"].value] = $line
}
$scanner.Matches(($src = Get-Content -raw $terminalAdapterPath)) | ForEach-Object {
$line = (($src[0..$_.Index] -join "") -split "`n").Length
#write-verbose $_.groups[0].value
$SCRIPT:terminal[$_.groups["method"].value] = $line
}
}
function Get-SequenceIndexMarkdown {
# "Sequence","Parent","Description","Origin","Heading","Subheading", "ImplementedBy", "ConsoleHost","Terminal"
$heading = $null
$subheading = $null
<#
Emit markdown
TODO:
- auto-generate TOC
#>
@"
# VT Function Support
## Table of Contents
* [Code Extension Functions](#code-extension-functions)
* [Control Coding](#control-coding)
* [Character Coding](#character-coding)
* [Graphic Character Sets](#graphic-character-sets)
* [Terminal Management Functions](#terminal-management-functions)
* [Identification, status, and Initialization](#identification-status-and-initialization)
* [Emulations](#emulations)
* [Set-Up](#set-up)
* [Display Coordinate System and Addressing](#display-coordinate-system-and-addressing)
* [Active Position and Cursor](#active-position-and-cursor)
* [Margins and Scrolling](#margins-and-scrolling)
* [Cursor Movement](#cursor-movement)
* [Horizontal Tabulation](#horizontal-tabulation)
* [Page Size and Arrangement](#page-size-and-arrangement)
* [Page Movement](#page-movement)
* [Status Display](#status-display)
* [Right to Left](#right-to-left)
* [Window Management](#window-management)
* [Visual Attributes and Renditions](#visual-attributes-and-renditions)
* [Line Renditions](#line-renditions)
* [Character Renditions](#character-renditions)
* [Audible Indicators](#audible-indicators)
* [Mode States](#mode-states)
* [ANSI](#ansi)
* [DEC Private](#dec-private)
* [Editing Functions](#editing-functions)
* [OLTP Features](#OLTP-features)
* [Rectangular Area Operations](#rectangular-area-operations)
* [Data Integrity](#data-integrity)
* [Macros](#macros)
* [Saving and Restoring Terminal State](#saving-and-restoring-terminal-state)
* [Cursor Save Buffer](#cursor-save-buffer)
* [Terminal State Interrogation](#terminal-state-interrogation)
* [Keyboard Processing Functions](#keyboard-processing-functions)
* [Soft Key Mapping (UDK)](#soft-key-mapping-UDK)
* [Soft Fonts (DRCS)](#soft-fonts-drcs)
* [Printing](#printing)
* [Terminal Communication and Synchronization](#terminal-communication-and-synchronization)
* [Text Locator Extension](#text-locator-extension)
* [Session Management Extension](#session-management-extension)
* [Documented Exceptions](#documented-exceptions)
$($sequences | ForEach-Object {
if ($method = $base[$_.sequence]) {
$_.ImplementedBy = $method
$_.ConsoleHost = $conhost[$method]
$_.Terminal = $terminal[$method]
}
# "Sequence","Associated","Description","Origin","Heading","Subheading", "ImplementedBy", "ConsoleHost","Terminal"
$c0 = "[$($_.Sequence)]($prefix$($_.sequence).html ""View page on vt100.net"")"
$c1 = "$($_.description)"
$c2 = "$($_.origin)"
$c3 = $(if ($_.consolehost) {"[&#x2713;](${repo}/${conhostUrl}#L$($_.consolehost) ""View console host implementation"")"})
$c4 = $(if ($_.terminal) {"[&#x2713;](${repo}/${terminalUrl}#L$($_.terminal)} ""View windows terminal implementation"")"})
$shouldRenderHeader = $false
if ($heading -ne $_.heading) {
$heading = $_.heading
@"
## $heading
"@
$shouldRenderHeader = $true
}
if ($subheading -ne $_.subheading) {
$subheading = $_.subheading
@"
### $subheading
"@
$shouldRenderHeader = $true
}
if ($shouldRenderHeader) {
@"
|Symbol|Function|Origin&nbsp;&#x1F5B3;|Console Host|Terminal|
|:-|:--|:--:|:--:|:--:|
"@
}
@"
|$c0|$c1|$c2|$c3|$c4|
"@
})
---
Generated on $(get-date -DisplayHint DateTime)
"@
}
function Show-Summary {
write-host "`n$(' '*7)Windows Terminal Sequencer v${myVer}"
if (-not $NoLogo.IsPresent) {
Get-Content .\windows-terminal-logo.ans | ForEach-Object { Write-Host $_ }
}
$summary = @"
`e[1mSequence Support:`e[0m
`e[7m {0:000} `e[0m known in master-sequence-list.csv.
`e[7m {1:000} `e[0m common members in ITermDispatch base, of which:
`e[7m {2:000} `e[0m are implemented by ConsoleHost.
`e[7m {3:000} `e[0m are implemented by Windows Terminal.
"@ -f $sequences.Count, $base.count, $conhost.count, $terminal.Count
write-host $summary
}
<#
Entry Point
#>
Read-SourceFiles
if (-not $SummaryOnly.IsPresent) {
$markdown = Get-SequenceIndexMarkdown
if ($PSCmdlet.ParameterSetName -eq "file") {
# send to file and overwrite
$markdown | Out-File -FilePath $OutFile -Force:$Force.IsPresent -Encoding utf8NoBOM
} else {
# send to STDOUT
$markdown
}
if (-not $Quiet.IsPresent) {
Show-Summary
}
} else {
# summary only
Show-Summary
}

View File

@@ -1,224 +0,0 @@
"Sequence","Parent","Description","Origin","Heading","Subheading","ImplementedBy","ConsoleHost","Terminal"
"CAN","","Cancel","`VT100`","Code Extension Functions","Control Coding","","",""
"SUB","","Substitute","`VT100`","Code Extension Functions","Control Coding","","",""
"ESC","","Escape","`VT100`","Code Extension Functions","Control Coding","","",""
"DCS","","Device Control String","`VT220`","Code Extension Functions","Control Coding","","",""
"CSI","","Control Sequence Introducer","`VT100`","Code Extension Functions","Control Coding","","",""
"ST","","String Terminator","`VT220`","Code Extension Functions","Control Coding","","",""
"OSC","","Operating System Command","`DECterm`","Code Extension Functions","Control Coding","","",""
"PM","","Privacy Message","``","Code Extension Functions","Control Coding","","",""
"APC","","Application Program Command","`VT420`","Code Extension Functions","Control Coding","","",""
"S7C1T","","Select 7-bit C1 Transmission","`VT220`","Code Extension Functions","Control Coding","","",""
"S8C1T","","Select 8-bit C1 Transmission","`VT220`","Code Extension Functions","Control Coding","","",""
"LS0","","Locking Shift Zero (SI)","`VT100`","Code Extension Functions","Character Coding","","",""
"LS1","","Locking Shift One (SO)","`VT100`","Code Extension Functions","Character Coding","","",""
"LS2","","Locking Shift Two","`VT220`","Code Extension Functions","Character Coding","","",""
"LS3","","Locking Shift Three","`VT220`","Code Extension Functions","Character Coding","","",""
"LS1R","","Locking Shift One Right","`VT220`","Code Extension Functions","Character Coding","","",""
"LS2R","","Locking Shift Two Right","`VT220`","Code Extension Functions","Character Coding","","",""
"LS3R","","Locking Shift Three Right","`VT220`","Code Extension Functions","Character Coding","","",""
"SS2","","Single Shift Two","`VT220`","Code Extension Functions","Character Coding","","",""
"SS3","","Single Shift Three","`VT220`","Code Extension Functions","Character Coding","","",""
"SCS","","Select Character Set","`VT100`","Code Extension Functions","Graphic Character Sets","","",""
"DECNRCM","","(National Replacement) Character Set Mode","`VT220`","Code Extension Functions","Graphic Character Sets","","",""
"DECAUPSS","","Assign User-Preference Supplemental Set","`VT320`","Code Extension Functions","Graphic Character Sets","","",""
"DECRQUPSS","","Request User-Preference Supplemental Set","`VT320`","Code Extension Functions","Graphic Character Sets","","",""
"DA1","","Primary Device Attributes","`VT100`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DA2","","Secondary Device Attributes","`VT220`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DA3","","Tertiary Device Attributes","`VT420`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DSR","","Device Status Report","`VT100`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECID","","Identify Device","`VT100`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECTID","","Select Terminal ID","`VT510`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECSCL","","Select Conformance Level","`VT220`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECSR","","Secure Reset","`VT420`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECSRC","","Secure Reset Confirmation","`VT420`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECSTR","","Soft Terminal Reset","`VT220`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECSTUI","","Set Terminal Unit ID (Restricted)","`VT420`","Terminal Management Functions","Identification, status, and Initialization","","",""
"RIS","","Reset to Initial state","`VT100`","Terminal Management Functions","Identification, status, and Initialization","","",""
"DECPCTERM","","Enter/Exit PC Term Mode from DEC VT mode","`VT420PC`","Terminal Management Functions","Emulations","","",""
"DECTME","","Terminal Mode Emulation","`VT510`","Terminal Management Functions","Emulations","","",""
"DECSSL","","Select Set-Up Language","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECCRTSM","","CRT Save Mode (not required)","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECOSCNM","","Overscan Mode","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECSRFR","","Select Refresh Rate","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECLTOD","","Load Time of Day","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECLBAN","","Load Banner Message","`VT510`","Terminal Management Functions","Set-Up","","",""
"DECTCEM","","Text Cursor Enable Mode","`VT220`","Display Coordinate System and Addressing","Active Position and Cursor","","",""
"DECSCUSR","","Set Cursor Style","`VT510`","Display Coordinate System and Addressing","Active Position and Cursor","","",""
"DECSTBM","","Set Top and Bottom Margin","`VT100`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECSLRM","","Set Left and Right Margin","`VT420`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECLRMM","","Left Right Margin Mode","`VT420`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECOM","","Origin Mode","`VT100`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECSCLM","","Scrolling Mode","`VT100`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"IND","","Index","`VT100`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"RI","","Reverse Index","`VT100`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECFI","","Forward Index","`VT420`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECBI","","Back Index","`VT420`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"DECSSCLS","","Set Scroll Speed","`VT510`","Display Coordinate System and Addressing","Margins and Scrolling","","",""
"BS","","Backspace","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"LF","","Line Feed","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"VT","","Vertical Tab","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"FF","","Form Feed","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CR","","Carriage Return","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"NEL","","Next Line","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"LNM","","Line Feed/New Line Mode","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CUU","","Cursor Up","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CUD","","Cursor Down","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CUF","","Cursor Forward","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CUB","","Cursor Backward","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CUP","","Cursor Position","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"HVP","","Horizontal/Vertical Position","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"DSR-CPR","","Device Status Report (Cursor Position Report)","`VT100`","Display Coordinate System and Addressing","Cursor Movement","","",""
"DSR-XCPR","","Device Status Report (Extended Cursor Position Report)","`VT340` `VT420`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CHA","","Cursor Horizontal Absolute","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CNL","","Cursor Next Line","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"CPL","","Cursor Previous Line","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"HPA","","Horizontal Position Absolute","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"HPR","","Horizontal Position Relative","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"VPA","","Vertical Line Position Absolute","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"VPR","","Vertical Position Relative","`VT510`","Display Coordinate System and Addressing","Cursor Movement","","",""
"HT","","Horizontal Tab","`VT100`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"HTS","","Horizontal Tabulation Set","`VT100`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"TBC","","Tabulation Clear","`VT100`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"CBT","","Cursor Backward Tabulation","`VT510`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"CHT","","Cursor Horizontal Forward Tabulation","`VT510`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"DECST8C","","Set Tab at every 8 columns","`VT420PC`","Display Coordinate System and Addressing","Horizontal Tabulation","","",""
"DECCOLM","","Column Mode","`VT100`","Display Coordinate System and Addressing","Page Size and Arrangement","","",""
"DECNCSM","","No Clear Screen on column Mode","`VT510`","Display Coordinate System and Addressing","Page Size and Arrangement","","",""
"DECSCPP","","Set Columns Per Page","`VT340` `VT420`","Display Coordinate System and Addressing","Page Size and Arrangement","","",""
"DECSLPP","","Set Lines Per Page","`VT340` `VT420`","Display Coordinate System and Addressing","Page Size and Arrangement","","",""
"NP","","Next Page","`VT340` `VT420`","Display Coordinate System and Addressing","Page Movement","","",""
"PP","","Preceding Page","`VT340` `VT420`","Display Coordinate System and Addressing","Page Movement","","",""
"PPA","","Page Position Absolute","`VT340` `VT420`","Display Coordinate System and Addressing","Page Movement","","",""
"PPR","","Page Position Relative","`VT340` `VT420`","Display Coordinate System and Addressing","Page Movement","","",""
"PPB","","Page Position Backward","`VT340` `VT420`","Display Coordinate System and Addressing","Page Movement","","",""
"DECSASD","","Select Active Status Display","`VT340` `VT320`","Display Coordinate System and Addressing","Status Display","","",""
"DECSSDT","","Select Status Display Type","`VT340` `VT320`","Display Coordinate System and Addressing","Status Display","","",""
"DECRLM","","Right to Left Mode","`VT510`","Display Coordinate System and Addressing","Right to Left","","",""
"DECRLCM","","Right to Left Copy Mode","`VT510`","Display Coordinate System and Addressing","Right to Left","","",""
"DDD1","","`VT100` mode Hebrew","`VT510`","Display Coordinate System and Addressing","Right to Left","","",""
"DDD2","","`VT100` mode Hebrew","`VT510`","Display Coordinate System and Addressing","Right to Left","","",""
"DDD3","","`VT100` mode Hebrew","`VT510`","Display Coordinate System and Addressing","Right to Left","","",""
"DECHCCM","","Horizontal Cursor Coupling Mode","`VT340` `VT420`","Window Management","Right to Left","","",""
"DECVCCM","","Vertical Cursor Coupling Mode","`VT340` `VT420`","Window Management","Right to Left","","",""
"DECPCCM","","Page Cursor Coupling Mode","`VT340` `VT420`","Window Management","Right to Left","","",""
"DECRQDE","","Request Displayed Extent","`VT340` `VT420`","Window Management","Right to Left","","",""
"DECSNLS","","Select Number of Lines per Screen (exception)","`VT420`","Window Management","Right to Left","","",""
"DECARSM","","Auto Resize Mode","`DECterm` `VT420`","Window Management","Right to Left","","",""
"SU","","Pan Down","`VT340` `VT420`","Window Management","Right to Left","","",""
"SD","","Pan Up","`VT340` `VT420`","Window Management","Right to Left","","",""
"DECSCNM","","Screen Mode","`VT100`","Visual Attributes and Renditions","Right to Left","","",""
"DECSWL","","Single Width Line","`VT100`","Visual Attributes and Renditions","Line Renditions","","",""
"DECDWL","","Double Width Line","`VT100`","Visual Attributes and Renditions","Line Renditions","","",""
"DECDHLT","","Double Height Line Top","`VT100`","Visual Attributes and Renditions","Line Renditions","","",""
"DECDHLB","","Double Height Line Bottom","`VT100`","Visual Attributes and Renditions","Line Renditions","","",""
"SGR","","Select Graphic Rendition","`VT100`","Visual Attributes and Renditions","Character Renditions","","",""
"BEL","","Warning Bell","`VT100`","Audible Indicators","Character Renditions","","",""
"DECSKCV","","Set Keyclick Volume","`VT510`","Audible Indicators","Character Renditions","","",""
"DECSWBV","","Set Warning Bell Volume","`VT510`","Audible Indicators","Character Renditions","","",""
"DECSMBV","","Set Margin Bell Volume","`VT510`","Audible Indicators","Character Renditions","","",""
"IRM","","Insert/Replacement Mode","`VT102`","Editing Functions","DEC Private","","",""
"ICH","","Insert Character","`VT102`","Editing Functions","DEC Private","","",""
"DCH","","Delete Character","`VT102`","Editing Functions","DEC Private","","",""
"IL","","Insert Line","`VT100`","Editing Functions","DEC Private","","",""
"DL","","Delete Line","`VT100`","Editing Functions","DEC Private","","",""
"DECIC","","Insert Column","`VT420`","Editing Functions","DEC Private","","",""
"DECDC","","Delete Column","`VT420`","Editing Functions","DEC Private","","",""
"ECH","","Erase Character","`VT100`","Editing Functions","DEC Private","","",""
"EL","","Erase in Line","`VT100`","Editing Functions","DEC Private","","",""
"DECSEL","","Selective Erase in Line","`VT220`","Editing Functions","DEC Private","","",""
"ED","","Erase in Display","`VT100`","Editing Functions","DEC Private","","",""
"DECSED","","Selective Erase in Display","`VT220`","Editing Functions","DEC Private","","",""
"DECSCA","","Select Character Attribute (selective erase)","`VT220`","Editing Functions","DEC Private","","",""
"DECCRA","","Copy Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECFRA","","Fill Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECERA","","Erase Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECSERA","","Selective Erase Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECCARA","","Change Attribute in Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECRARA","","Reverse Attribute in Rectangular Area","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECSACE","","Select Attribute Change Extent Mode","`VT420`","OLTP Features","Rectangular Area Operations","","",""
"DECRQCRA","","Request Checksum of Rectangular Area","`VT420`","OLTP Features","Data Integrity","","",""
"DSR-DECCKSR","","Device Status Report (Memory Checksum)","`VT420`","OLTP Features","Data Integrity","","",""
"DECDMAC","","Define Macro","`VT420`","OLTP Features","Macros","","",""
"DECINVM","","Invoke Macro","`VT420`","OLTP Features","Macros","","",""
"DSR-MSR","","Device Status Report (Macro Space Report)","`VT420`","OLTP Features","Macros","","",""
"DECSC","","Save Cursor","`VT100`","Saving and Restoring Terminal State","Cursor Save Buffer","","",""
"DECRC","","Restore Cursor","`VT100`","Saving and Restoring Terminal State","Cursor Save Buffer","","",""
"DECRQM","","Request Mode","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECNKM","","Numeric Keypad Mode","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECRQSS","","Request Selection or Setting","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECRQPSR","","Request Presentation State Report","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECRSPS","","Restore Presentation State","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECRQTSR","","Request Terminal State Report","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECRSTS","","Restore Terminal State","`VT320`","Saving and Restoring Terminal State","Terminal State Interrogation","","",""
"DECARM","","Autorepeat Mode","`VT100`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECBKM","","Backarrow Key Mode","`VT420`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECCKM","","Cursor Keys Mode","`VT100`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKBUM","","Keyboard Usage Mode","`VT320`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKPAM","","Keypad Application Mode","`VT100`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKPM","","Key Position Mode","`VT420`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKPNM","","Keypad Numeric Mode","`VT100`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECNKM","","Numeric Keypad Mode","`VT320`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DSR-KBD","","Device Status Report (keyboard status)","`VT220`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"KAM","","Keyboard Action Mode","`VT220`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECLFC","","Local Functions Control","`VT420`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECLFKC","","Local Function Key Control","`VT420`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECSMKR","","Select Modifier Key Reporting","`VT420`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECHEBM","","Hebrew Keyboard Map mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECHCEM","","Hebrew Encoding Mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECNAKB","","NA/Greek Selection","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECESKM","","Secondary Keyboard Language Mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECSLCK","","Set Lock Key Style","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKBD","","Keyboard Dialect Selection","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECNUMLK","","NumLock Mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECCAPSLK","","CapsLock Mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECKLHIM","","Keyboard LEDs Host Indicator Mode","`VT510`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECLL","","Load LEDs","`VT100`","Keyboard Processing Functions","Terminal State Interrogation","","",""
"DECUDK","","User Defined Keys","`VT220`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DSR-UDK","","Device Status Report (UDK lock)","`VT220`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECPKA","","Program Key Action","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECPFK","","Program Function Key","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECPAK","","Program Alphanumeric Key","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECCKD","","Copy Key Default","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECRQPKFM","","Program Key Free Memory Inquiry","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECRQKT","","Inquire a Key Type","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECRQKD","","Inquire a Key Definition","`VT510`","Soft Key Mapping (UDK)","Terminal State Interrogation","","",""
"DECDLD","","Downline Load","`VT220`","Soft Fonts (DRCS)","Terminal State Interrogation","","",""
"DECPEX","","Print Extent Mode","`VT220`","Printing","Terminal State Interrogation","","",""
"DECPFF","","Print Form Feed Mode","`VT220`","Printing","Terminal State Interrogation","","",""
"DSR-PP","","Device Status Report (printer port)","`VT220`","Printing","Terminal State Interrogation","","",""
"MC","","Media Copy","`VT220`","Printing","Terminal State Interrogation","","",""
"DECSPRTT","","Select Printer Type","`VT510`","Printing","Terminal State Interrogation","","",""
"DECSDPT","","Select Digital Printed Data Type","`VT510`","Printing","Terminal State Interrogation","","",""
"DECSPPCS","","Select Proprinter Character Set","`VT510`","Printing","Terminal State Interrogation","","",""
"BREAK","","BREAK","`VT100`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"XON","","XON","`VT100`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"XOFF","","XOFF","`VT100`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"ENQ","","Enquiry","`VT100`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"SRM","","Send Receive Mode","`VT220`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECXRLM","","Transmit Rate Limiting Mode","`VT420`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECMCM","","Modem Control Mode","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECAAM","","Auto Answerback Mode","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECLANS","","Load Answerback Message","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECCANSM","","Conceal Answerback Message Mode","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECNULM","","Ignore Null Mode","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECHPDXM","","Half Duplex Mode","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSFC","","Select Flow Control","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSDDT","","Select Disconnect Delay Time","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSTRL","","Set Transmit Rate Limit","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSCS","","Select Communication Speed","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSCP","","Select Communication Port","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECSPP","","Set Port Parameter","`VT510`","Terminal Communication and Synchronization","Terminal State Interrogation","","",""
"DECEFR","","Enable Filter Rectangle","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECELR","","Enable Locator Reports","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECLKD","","Locator Key Definition","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECLRP","","Locator Report","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECRQLP","","Request Locator Position","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECSLE","","Select Locator Events","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DSR-LS","","Device Status Report (Locator Status)","`UWS`","Text Locator Extension","Terminal State Interrogation","","",""
"DECES","","Enable Sessions","`VT340` `VT420`","Session Management Extension","Terminal State Interrogation","","",""
"DECANM","","`ANSI`/`VT52` Mode","`VT100`","Documented Exceptions","Terminal State Interrogation","","",""
"DECALN","","Screen Alignment","`VT100`","Documented Exceptions","Terminal State Interrogation","","",""
"DECAWM","","Autowrap Mode","`VT100`","Documented Exceptions","Terminal State Interrogation","","",""
"DECTST","","Invoke Confidence Test","`VT100`","Documented Exceptions","Terminal State Interrogation","","",""
"CRM","","Control Representation Mode","`VT100`","Documented Exceptions","Terminal State Interrogation","","",""
1 Sequence Parent Description Origin Heading Subheading ImplementedBy ConsoleHost Terminal
2 CAN Cancel `VT100` Code Extension Functions Control Coding
3 SUB Substitute `VT100` Code Extension Functions Control Coding
4 ESC Escape `VT100` Code Extension Functions Control Coding
5 DCS Device Control String `VT220` Code Extension Functions Control Coding
6 CSI Control Sequence Introducer `VT100` Code Extension Functions Control Coding
7 ST String Terminator `VT220` Code Extension Functions Control Coding
8 OSC Operating System Command `DECterm` Code Extension Functions Control Coding
9 PM Privacy Message `` Code Extension Functions Control Coding
10 APC Application Program Command `VT420` Code Extension Functions Control Coding
11 S7C1T Select 7-bit C1 Transmission `VT220` Code Extension Functions Control Coding
12 S8C1T Select 8-bit C1 Transmission `VT220` Code Extension Functions Control Coding
13 LS0 Locking Shift Zero (SI) `VT100` Code Extension Functions Character Coding
14 LS1 Locking Shift One (SO) `VT100` Code Extension Functions Character Coding
15 LS2 Locking Shift Two `VT220` Code Extension Functions Character Coding
16 LS3 Locking Shift Three `VT220` Code Extension Functions Character Coding
17 LS1R Locking Shift One Right `VT220` Code Extension Functions Character Coding
18 LS2R Locking Shift Two Right `VT220` Code Extension Functions Character Coding
19 LS3R Locking Shift Three Right `VT220` Code Extension Functions Character Coding
20 SS2 Single Shift Two `VT220` Code Extension Functions Character Coding
21 SS3 Single Shift Three `VT220` Code Extension Functions Character Coding
22 SCS Select Character Set `VT100` Code Extension Functions Graphic Character Sets
23 DECNRCM (National Replacement) Character Set Mode `VT220` Code Extension Functions Graphic Character Sets
24 DECAUPSS Assign User-Preference Supplemental Set `VT320` Code Extension Functions Graphic Character Sets
25 DECRQUPSS Request User-Preference Supplemental Set `VT320` Code Extension Functions Graphic Character Sets
26 DA1 Primary Device Attributes `VT100` Terminal Management Functions Identification, status, and Initialization
27 DA2 Secondary Device Attributes `VT220` Terminal Management Functions Identification, status, and Initialization
28 DA3 Tertiary Device Attributes `VT420` Terminal Management Functions Identification, status, and Initialization
29 DSR Device Status Report `VT100` Terminal Management Functions Identification, status, and Initialization
30 DECID Identify Device `VT100` Terminal Management Functions Identification, status, and Initialization
31 DECTID Select Terminal ID `VT510` Terminal Management Functions Identification, status, and Initialization
32 DECSCL Select Conformance Level `VT220` Terminal Management Functions Identification, status, and Initialization
33 DECSR Secure Reset `VT420` Terminal Management Functions Identification, status, and Initialization
34 DECSRC Secure Reset Confirmation `VT420` Terminal Management Functions Identification, status, and Initialization
35 DECSTR Soft Terminal Reset `VT220` Terminal Management Functions Identification, status, and Initialization
36 DECSTUI Set Terminal Unit ID (Restricted) `VT420` Terminal Management Functions Identification, status, and Initialization
37 RIS Reset to Initial state `VT100` Terminal Management Functions Identification, status, and Initialization
38 DECPCTERM Enter/Exit PC Term Mode from DEC VT mode `VT420PC` Terminal Management Functions Emulations
39 DECTME Terminal Mode Emulation `VT510` Terminal Management Functions Emulations
40 DECSSL Select Set-Up Language `VT510` Terminal Management Functions Set-Up
41 DECCRTSM CRT Save Mode (not required) `VT510` Terminal Management Functions Set-Up
42 DECOSCNM Overscan Mode `VT510` Terminal Management Functions Set-Up
43 DECSRFR Select Refresh Rate `VT510` Terminal Management Functions Set-Up
44 DECLTOD Load Time of Day `VT510` Terminal Management Functions Set-Up
45 DECLBAN Load Banner Message `VT510` Terminal Management Functions Set-Up
46 DECTCEM Text Cursor Enable Mode `VT220` Display Coordinate System and Addressing Active Position and Cursor
47 DECSCUSR Set Cursor Style `VT510` Display Coordinate System and Addressing Active Position and Cursor
48 DECSTBM Set Top and Bottom Margin `VT100` Display Coordinate System and Addressing Margins and Scrolling
49 DECSLRM Set Left and Right Margin `VT420` Display Coordinate System and Addressing Margins and Scrolling
50 DECLRMM Left Right Margin Mode `VT420` Display Coordinate System and Addressing Margins and Scrolling
51 DECOM Origin Mode `VT100` Display Coordinate System and Addressing Margins and Scrolling
52 DECSCLM Scrolling Mode `VT100` Display Coordinate System and Addressing Margins and Scrolling
53 IND Index `VT100` Display Coordinate System and Addressing Margins and Scrolling
54 RI Reverse Index `VT100` Display Coordinate System and Addressing Margins and Scrolling
55 DECFI Forward Index `VT420` Display Coordinate System and Addressing Margins and Scrolling
56 DECBI Back Index `VT420` Display Coordinate System and Addressing Margins and Scrolling
57 DECSSCLS Set Scroll Speed `VT510` Display Coordinate System and Addressing Margins and Scrolling
58 BS Backspace `VT100` Display Coordinate System and Addressing Cursor Movement
59 LF Line Feed `VT100` Display Coordinate System and Addressing Cursor Movement
60 VT Vertical Tab `VT100` Display Coordinate System and Addressing Cursor Movement
61 FF Form Feed `VT100` Display Coordinate System and Addressing Cursor Movement
62 CR Carriage Return `VT100` Display Coordinate System and Addressing Cursor Movement
63 NEL Next Line `VT100` Display Coordinate System and Addressing Cursor Movement
64 LNM Line Feed/New Line Mode `VT100` Display Coordinate System and Addressing Cursor Movement
65 CUU Cursor Up `VT100` Display Coordinate System and Addressing Cursor Movement
66 CUD Cursor Down `VT100` Display Coordinate System and Addressing Cursor Movement
67 CUF Cursor Forward `VT100` Display Coordinate System and Addressing Cursor Movement
68 CUB Cursor Backward `VT100` Display Coordinate System and Addressing Cursor Movement
69 CUP Cursor Position `VT100` Display Coordinate System and Addressing Cursor Movement
70 HVP Horizontal/Vertical Position `VT100` Display Coordinate System and Addressing Cursor Movement
71 DSR-CPR Device Status Report (Cursor Position Report) `VT100` Display Coordinate System and Addressing Cursor Movement
72 DSR-XCPR Device Status Report (Extended Cursor Position Report) `VT340` `VT420` Display Coordinate System and Addressing Cursor Movement
73 CHA Cursor Horizontal Absolute `VT510` Display Coordinate System and Addressing Cursor Movement
74 CNL Cursor Next Line `VT510` Display Coordinate System and Addressing Cursor Movement
75 CPL Cursor Previous Line `VT510` Display Coordinate System and Addressing Cursor Movement
76 HPA Horizontal Position Absolute `VT510` Display Coordinate System and Addressing Cursor Movement
77 HPR Horizontal Position Relative `VT510` Display Coordinate System and Addressing Cursor Movement
78 VPA Vertical Line Position Absolute `VT510` Display Coordinate System and Addressing Cursor Movement
79 VPR Vertical Position Relative `VT510` Display Coordinate System and Addressing Cursor Movement
80 HT Horizontal Tab `VT100` Display Coordinate System and Addressing Horizontal Tabulation
81 HTS Horizontal Tabulation Set `VT100` Display Coordinate System and Addressing Horizontal Tabulation
82 TBC Tabulation Clear `VT100` Display Coordinate System and Addressing Horizontal Tabulation
83 CBT Cursor Backward Tabulation `VT510` Display Coordinate System and Addressing Horizontal Tabulation
84 CHT Cursor Horizontal Forward Tabulation `VT510` Display Coordinate System and Addressing Horizontal Tabulation
85 DECST8C Set Tab at every 8 columns `VT420PC` Display Coordinate System and Addressing Horizontal Tabulation
86 DECCOLM Column Mode `VT100` Display Coordinate System and Addressing Page Size and Arrangement
87 DECNCSM No Clear Screen on column Mode `VT510` Display Coordinate System and Addressing Page Size and Arrangement
88 DECSCPP Set Columns Per Page `VT340` `VT420` Display Coordinate System and Addressing Page Size and Arrangement
89 DECSLPP Set Lines Per Page `VT340` `VT420` Display Coordinate System and Addressing Page Size and Arrangement
90 NP Next Page `VT340` `VT420` Display Coordinate System and Addressing Page Movement
91 PP Preceding Page `VT340` `VT420` Display Coordinate System and Addressing Page Movement
92 PPA Page Position Absolute `VT340` `VT420` Display Coordinate System and Addressing Page Movement
93 PPR Page Position Relative `VT340` `VT420` Display Coordinate System and Addressing Page Movement
94 PPB Page Position Backward `VT340` `VT420` Display Coordinate System and Addressing Page Movement
95 DECSASD Select Active Status Display `VT340` `VT320` Display Coordinate System and Addressing Status Display
96 DECSSDT Select Status Display Type `VT340` `VT320` Display Coordinate System and Addressing Status Display
97 DECRLM Right to Left Mode `VT510` Display Coordinate System and Addressing Right to Left
98 DECRLCM Right to Left Copy Mode `VT510` Display Coordinate System and Addressing Right to Left
99 DDD1 `VT100` mode Hebrew `VT510` Display Coordinate System and Addressing Right to Left
100 DDD2 `VT100` mode Hebrew `VT510` Display Coordinate System and Addressing Right to Left
101 DDD3 `VT100` mode Hebrew `VT510` Display Coordinate System and Addressing Right to Left
102 DECHCCM Horizontal Cursor Coupling Mode `VT340` `VT420` Window Management Right to Left
103 DECVCCM Vertical Cursor Coupling Mode `VT340` `VT420` Window Management Right to Left
104 DECPCCM Page Cursor Coupling Mode `VT340` `VT420` Window Management Right to Left
105 DECRQDE Request Displayed Extent `VT340` `VT420` Window Management Right to Left
106 DECSNLS Select Number of Lines per Screen (exception) `VT420` Window Management Right to Left
107 DECARSM Auto Resize Mode `DECterm` `VT420` Window Management Right to Left
108 SU Pan Down `VT340` `VT420` Window Management Right to Left
109 SD Pan Up `VT340` `VT420` Window Management Right to Left
110 DECSCNM Screen Mode `VT100` Visual Attributes and Renditions Right to Left
111 DECSWL Single Width Line `VT100` Visual Attributes and Renditions Line Renditions
112 DECDWL Double Width Line `VT100` Visual Attributes and Renditions Line Renditions
113 DECDHLT Double Height Line Top `VT100` Visual Attributes and Renditions Line Renditions
114 DECDHLB Double Height Line Bottom `VT100` Visual Attributes and Renditions Line Renditions
115 SGR Select Graphic Rendition `VT100` Visual Attributes and Renditions Character Renditions
116 BEL Warning Bell `VT100` Audible Indicators Character Renditions
117 DECSKCV Set Keyclick Volume `VT510` Audible Indicators Character Renditions
118 DECSWBV Set Warning Bell Volume `VT510` Audible Indicators Character Renditions
119 DECSMBV Set Margin Bell Volume `VT510` Audible Indicators Character Renditions
120 IRM Insert/Replacement Mode `VT102` Editing Functions DEC Private
121 ICH Insert Character `VT102` Editing Functions DEC Private
122 DCH Delete Character `VT102` Editing Functions DEC Private
123 IL Insert Line `VT100` Editing Functions DEC Private
124 DL Delete Line `VT100` Editing Functions DEC Private
125 DECIC Insert Column `VT420` Editing Functions DEC Private
126 DECDC Delete Column `VT420` Editing Functions DEC Private
127 ECH Erase Character `VT100` Editing Functions DEC Private
128 EL Erase in Line `VT100` Editing Functions DEC Private
129 DECSEL Selective Erase in Line `VT220` Editing Functions DEC Private
130 ED Erase in Display `VT100` Editing Functions DEC Private
131 DECSED Selective Erase in Display `VT220` Editing Functions DEC Private
132 DECSCA Select Character Attribute (selective erase) `VT220` Editing Functions DEC Private
133 DECCRA Copy Rectangular Area `VT420` OLTP Features Rectangular Area Operations
134 DECFRA Fill Rectangular Area `VT420` OLTP Features Rectangular Area Operations
135 DECERA Erase Rectangular Area `VT420` OLTP Features Rectangular Area Operations
136 DECSERA Selective Erase Rectangular Area `VT420` OLTP Features Rectangular Area Operations
137 DECCARA Change Attribute in Rectangular Area `VT420` OLTP Features Rectangular Area Operations
138 DECRARA Reverse Attribute in Rectangular Area `VT420` OLTP Features Rectangular Area Operations
139 DECSACE Select Attribute Change Extent Mode `VT420` OLTP Features Rectangular Area Operations
140 DECRQCRA Request Checksum of Rectangular Area `VT420` OLTP Features Data Integrity
141 DSR-DECCKSR Device Status Report (Memory Checksum) `VT420` OLTP Features Data Integrity
142 DECDMAC Define Macro `VT420` OLTP Features Macros
143 DECINVM Invoke Macro `VT420` OLTP Features Macros
144 DSR-MSR Device Status Report (Macro Space Report) `VT420` OLTP Features Macros
145 DECSC Save Cursor `VT100` Saving and Restoring Terminal State Cursor Save Buffer
146 DECRC Restore Cursor `VT100` Saving and Restoring Terminal State Cursor Save Buffer
147 DECRQM Request Mode `VT320` Saving and Restoring Terminal State Terminal State Interrogation
148 DECNKM Numeric Keypad Mode `VT320` Saving and Restoring Terminal State Terminal State Interrogation
149 DECRQSS Request Selection or Setting `VT320` Saving and Restoring Terminal State Terminal State Interrogation
150 DECRQPSR Request Presentation State Report `VT320` Saving and Restoring Terminal State Terminal State Interrogation
151 DECRSPS Restore Presentation State `VT320` Saving and Restoring Terminal State Terminal State Interrogation
152 DECRQTSR Request Terminal State Report `VT320` Saving and Restoring Terminal State Terminal State Interrogation
153 DECRSTS Restore Terminal State `VT320` Saving and Restoring Terminal State Terminal State Interrogation
154 DECARM Autorepeat Mode `VT100` Keyboard Processing Functions Terminal State Interrogation
155 DECBKM Backarrow Key Mode `VT420` Keyboard Processing Functions Terminal State Interrogation
156 DECCKM Cursor Keys Mode `VT100` Keyboard Processing Functions Terminal State Interrogation
157 DECKBUM Keyboard Usage Mode `VT320` Keyboard Processing Functions Terminal State Interrogation
158 DECKPAM Keypad Application Mode `VT100` Keyboard Processing Functions Terminal State Interrogation
159 DECKPM Key Position Mode `VT420` Keyboard Processing Functions Terminal State Interrogation
160 DECKPNM Keypad Numeric Mode `VT100` Keyboard Processing Functions Terminal State Interrogation
161 DECNKM Numeric Keypad Mode `VT320` Keyboard Processing Functions Terminal State Interrogation
162 DSR-KBD Device Status Report (keyboard status) `VT220` Keyboard Processing Functions Terminal State Interrogation
163 KAM Keyboard Action Mode `VT220` Keyboard Processing Functions Terminal State Interrogation
164 DECLFC Local Functions Control `VT420` Keyboard Processing Functions Terminal State Interrogation
165 DECLFKC Local Function Key Control `VT420` Keyboard Processing Functions Terminal State Interrogation
166 DECSMKR Select Modifier Key Reporting `VT420` Keyboard Processing Functions Terminal State Interrogation
167 DECHEBM Hebrew Keyboard Map mode `VT510` Keyboard Processing Functions Terminal State Interrogation
168 DECHCEM Hebrew Encoding Mode `VT510` Keyboard Processing Functions Terminal State Interrogation
169 DECNAKB NA/Greek Selection `VT510` Keyboard Processing Functions Terminal State Interrogation
170 DECESKM Secondary Keyboard Language Mode `VT510` Keyboard Processing Functions Terminal State Interrogation
171 DECSLCK Set Lock Key Style `VT510` Keyboard Processing Functions Terminal State Interrogation
172 DECKBD Keyboard Dialect Selection `VT510` Keyboard Processing Functions Terminal State Interrogation
173 DECNUMLK NumLock Mode `VT510` Keyboard Processing Functions Terminal State Interrogation
174 DECCAPSLK CapsLock Mode `VT510` Keyboard Processing Functions Terminal State Interrogation
175 DECKLHIM Keyboard LEDs Host Indicator Mode `VT510` Keyboard Processing Functions Terminal State Interrogation
176 DECLL Load LEDs `VT100` Keyboard Processing Functions Terminal State Interrogation
177 DECUDK User Defined Keys `VT220` Soft Key Mapping (UDK) Terminal State Interrogation
178 DSR-UDK Device Status Report (UDK lock) `VT220` Soft Key Mapping (UDK) Terminal State Interrogation
179 DECPKA Program Key Action `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
180 DECPFK Program Function Key `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
181 DECPAK Program Alphanumeric Key `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
182 DECCKD Copy Key Default `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
183 DECRQPKFM Program Key Free Memory Inquiry `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
184 DECRQKT Inquire a Key Type `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
185 DECRQKD Inquire a Key Definition `VT510` Soft Key Mapping (UDK) Terminal State Interrogation
186 DECDLD Downline Load `VT220` Soft Fonts (DRCS) Terminal State Interrogation
187 DECPEX Print Extent Mode `VT220` Printing Terminal State Interrogation
188 DECPFF Print Form Feed Mode `VT220` Printing Terminal State Interrogation
189 DSR-PP Device Status Report (printer port) `VT220` Printing Terminal State Interrogation
190 MC Media Copy `VT220` Printing Terminal State Interrogation
191 DECSPRTT Select Printer Type `VT510` Printing Terminal State Interrogation
192 DECSDPT Select Digital Printed Data Type `VT510` Printing Terminal State Interrogation
193 DECSPPCS Select Proprinter Character Set `VT510` Printing Terminal State Interrogation
194 BREAK BREAK `VT100` Terminal Communication and Synchronization Terminal State Interrogation
195 XON XON `VT100` Terminal Communication and Synchronization Terminal State Interrogation
196 XOFF XOFF `VT100` Terminal Communication and Synchronization Terminal State Interrogation
197 ENQ Enquiry `VT100` Terminal Communication and Synchronization Terminal State Interrogation
198 SRM Send Receive Mode `VT220` Terminal Communication and Synchronization Terminal State Interrogation
199 DECXRLM Transmit Rate Limiting Mode `VT420` Terminal Communication and Synchronization Terminal State Interrogation
200 DECMCM Modem Control Mode `VT510` Terminal Communication and Synchronization Terminal State Interrogation
201 DECAAM Auto Answerback Mode `VT510` Terminal Communication and Synchronization Terminal State Interrogation
202 DECLANS Load Answerback Message `VT510` Terminal Communication and Synchronization Terminal State Interrogation
203 DECCANSM Conceal Answerback Message Mode `VT510` Terminal Communication and Synchronization Terminal State Interrogation
204 DECNULM Ignore Null Mode `VT510` Terminal Communication and Synchronization Terminal State Interrogation
205 DECHPDXM Half Duplex Mode `VT510` Terminal Communication and Synchronization Terminal State Interrogation
206 DECSFC Select Flow Control `VT510` Terminal Communication and Synchronization Terminal State Interrogation
207 DECSDDT Select Disconnect Delay Time `VT510` Terminal Communication and Synchronization Terminal State Interrogation
208 DECSTRL Set Transmit Rate Limit `VT510` Terminal Communication and Synchronization Terminal State Interrogation
209 DECSCS Select Communication Speed `VT510` Terminal Communication and Synchronization Terminal State Interrogation
210 DECSCP Select Communication Port `VT510` Terminal Communication and Synchronization Terminal State Interrogation
211 DECSPP Set Port Parameter `VT510` Terminal Communication and Synchronization Terminal State Interrogation
212 DECEFR Enable Filter Rectangle `UWS` Text Locator Extension Terminal State Interrogation
213 DECELR Enable Locator Reports `UWS` Text Locator Extension Terminal State Interrogation
214 DECLKD Locator Key Definition `UWS` Text Locator Extension Terminal State Interrogation
215 DECLRP Locator Report `UWS` Text Locator Extension Terminal State Interrogation
216 DECRQLP Request Locator Position `UWS` Text Locator Extension Terminal State Interrogation
217 DECSLE Select Locator Events `UWS` Text Locator Extension Terminal State Interrogation
218 DSR-LS Device Status Report (Locator Status) `UWS` Text Locator Extension Terminal State Interrogation
219 DECES Enable Sessions `VT340` `VT420` Session Management Extension Terminal State Interrogation
220 DECANM `ANSI`/`VT52` Mode `VT100` Documented Exceptions Terminal State Interrogation
221 DECALN Screen Alignment `VT100` Documented Exceptions Terminal State Interrogation
222 DECAWM Autowrap Mode `VT100` Documented Exceptions Terminal State Interrogation
223 DECTST Invoke Confidence Test `VT100` Documented Exceptions Terminal State Interrogation
224 CRM Control Representation Mode `VT100` Documented Exceptions Terminal State Interrogation

View File

@@ -1,15 +0,0 @@
                                                  
       ▀                                  ▀       
                                                  
       ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀  ▀  ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀        
       ▀ ▀▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀▀ ▀▀ ▀▀ ▀▀        
        ▀▀▀▀▀▀▀▀▀▀  ▀  ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀  ▀         
        ▀ ▀▀▀▀▀▀▀▀▀▀▀ ▀▀ ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀       
       ▀▀  ▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀  ▀ ▀▀ ▀▀       
       ▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀  ▀  ▀        
       ▀ ▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀  ▀ ▀▀ ▀▀ ▀▀ ▀▀        
        ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀ ▀       
       ▀▀▀▀▀▀▀▀▀▀▀▀  ▀▀▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀ ▀▀       
       ▀   ▀▀▀▀▀▀▀ ▀ ▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀ ▀▀       
       ▀ ▀ ▀▀▀▀▀ ▀▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀ ▀▀▀       
                                                  

View File

@@ -9,7 +9,7 @@ issue id: #1043
## Abstract
This spec is for task #1043 “Be able to set an initial position for the terminal”. It goes over the details of a new feature that allows users to set the initial position and size of the terminal. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
This spec is for task #1043 “Be able to set an initial position for the terminal”. It goes over the details of a new feature that allows users to set the initial position and size of the terminal. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
## Inspiration
@@ -17,7 +17,7 @@ The idea is to allow users to set the initial position of the Terminal when they
## Solution Design
For now, the Terminal window is put on a default initial position. The program uses CW_USEDEFAULT in the screen coordinates for top-left corner. We have two different types of window client window and non-client window. However, code path for window creation (WM_CREATE message is shared by the two types of windows) are almost the same for the two types of windows, except that there are some differences in calculation of the width and height of the window.
For now, the Terminal window is put on a default initial position. The program uses CW_USEDEFAULT in the screen coordinates for top-left corner. We have two different types of window client window and non-client window. However, code path for window creation (WM_CREATE message is shared by the two types of windows) are almost the same for the two types of windows, except that there are some differences in calculation of the width and height of the window.
Two new properties should be added in the json settings file:
@@ -92,9 +92,9 @@ For now, this feature only allows the user to set initial position and choose wh
3. We may also consider more launch modes. Like full screen mode and minimized mode.
GitHub issue for future follow-ups: https://github.com/microsoft/terminal/issues/766
Github issue for future follow-ups: https://github.com/microsoft/terminal/issues/766
## Resources
GitHub issue:
Github issue:
https://github.com/microsoft/terminal/issues/1043

Binary file not shown.

Before

Width:  |  Height:  |  Size: 222 KiB

View File

@@ -1,146 +0,0 @@
---
authors: Carlos Zamora (@carlos-zamora) and Kayla Cinnamon (@cinnamon-msft)
created on: 2020-11-10
last updated: 2020-11-19
issue id: 1564
---
# Cascading Settings
## Abstract
Windows Terminal's settings model adheres to a cascading settings architecture. This allows a settings object to be defined incrementally across multiple layers of declarations. The value for any global setting like `copyOnSelect`, for example, is set to your settings.json value if one is defined, otherwise defaults.json, and otherwise a system set value. Profiles in particular are more complicated in that they must also take into account the values in `profiles.defaults` and dynamic profile generators.
This spec explores how to represent this feature in the Settings UI.
## Inspiration
Cascading settings (and `profiles.defaults` by extension) provide some major benefits:
1. opt-in behavior for settings values provided in-box (i.e. reset to default)
2. easy way to apply a setting to all your profiles
3. (possible future feature) simple way to base a profile off of another profile
The following terminal emulators approach this issue as follows.
| Terminal Emulator(s) | Relevant Features/Approach |
|--|--|
| ConEmu, Cmder | "Clone" a separate profile |
| Fluent Terminal | "Restore Defaults" button on each page |
| iTerm2 | "Bulk Copy from Selected Profile..." and "Duplicate Profile" |
Other Settings UIs have approached this issue as follows:
| Project | Relevant Approach |
|--|--|
| Visual Studio | Present a dropdown with your options. An extra "\<inherit\>" option is shown to inherit a value from another place. |
## Solution Design
The XAML implementation will consist of introducing a `ContentControl` for each setting. The `ContentControl` simply wraps the XAML control used for a setting, then adds the chosen UI approach below.
The `ContentControl` will take advantage of the following TerminalSettingsModel APIs for each setting:
```c++
// Note: String and "Name" are replaced for each setting
bool HasName();
void ClearName();
String Name();
void Name(String val);
```
## UI/UX Design Proposals
The proposals below will be used in combination with each other.
### 1: Text under a setting control
This design renames the "Global" page under Profiles to "Base layer". Settings that override those in profile.defaults will get text under the control saying "Overrides Base layer.". Next to the titles of controls that override the base layer is a reset button with a tooltip that says "Reset".
![Text inheritance](./inheritance-text.png)
### Add New --> Duplicate Profile
The Add new profile button in the navigation menu would take you to a new page. This page will have radio buttons listing your profiles along with a default settings option. The user can choose to either duplicate a profile or create a new one from the default settings. Once the user makes a selection, the settings UI will take them to their new profile page. The fields on that profile page will be filled according to which profile selection the user made.
![Add new profile](./add-new-profile.png)
### Reset Profile button
On the Advanced pivot of a profile's page, there will be a button at the bottom for resetting a profile called "Reset to default settings". This button will remove the user's custom settings inside this profile's object and reset it to defaults, prioritizing profile.defaults then defaults.json.
### "Apply to all profiles" button
A way we could apply settings to all profiles is by adding a "Copy settings to..." button to the Advanced page of each profile. This button will open a content dialog with a tree view listing every profile setting. The user can select which settings they would like to copy over to another profile. At the bottom of the content dialog will list the user's profiles with checkboxes, allowing them to pick which profiles they'd like to copy settings to.
![Copy settings button](./copy-settings-1.png)
![Copy settings modal](./copy-settings-2.png)
## Previously considered ideas
These ideas were considered however we will not be moving forward with them.
### 1: \<inherit\> option
Each setting is an Editable ComboBox (except for boolean and enumerable settings). For booleans, the items will be Enabled and Disabled in a regular ComboBox. Enumerable settings will have their options listed in a regular ComboBox. For integers, most commonly used numbers will be listed.
![Dropdown inheritance](./inheritance-dropdown.png)
**Pros**
- Doesn't clutter the screen.
**Cons**
- Every setting is a dropdown.
**Pitfalls**
- How will color pickers work with this scenario?
**Other considerations**
Each dropdown has either "inherit" or "custom". If the user selects "custom", the original control will appear (i.e. a color picker for colors or a number picker for integers).
This option was not chosen because it added too much overhead for changing a setting. For example, if you wanted to enable acrylic, you'd have to click the dropdown, select custom, watch the checkbox appear, and then select the checkbox.
### 2: Lock Button
Every setting will have a lock button next to it. If the lock is locked, that means the setting is being inherited from Global, and the control is disabled. If the user wants to edit the setting, they can click the lock, which will changed it to the unlocked lock icon, and the control will become enabled.
![Locks inheritance](./inheritance-locks.png)
**Pros**
- Least amount of clutter on the screen while still keeping the original controls
**Cons**
- The lock concept is slightly confusing. Some may assume locking the setting means that it *won't* be inherited from Global and that it's "locked" to the profile. This is the opposite case for its current design. However, flipping the logic of the locks wouldn't make sense with an unlocked lock and a disabled control.
## Capabilities
### Accessibility
All of these additions to the settings UI will have to be accessibility tested.
### Security
These changes will not impact security.
### Reliability
These changes will not impact reliability.
### Compatibility
The partial parity with JSON route will give the settings UI a different compatibility from the JSON file itself. This is not necessarily a bad thing. The settings UI is intended to be a simplistic way for people to successfully edit their settings. If too many options are added to give it fully parity with JSON, it could compromise the simplistic benefit the settings UI provides.
### Performance, Power, and Efficiency
These changes will not impact performance, power, nor efficiency.
## Potential Issues
## Future considerations
When we add profile inheritance later, we can implement a layering page using a rearrangeable TreeView.
## Resources

Binary file not shown.

Before

Width:  |  Height:  |  Size: 364 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 362 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 266 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 267 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 268 KiB

View File

@@ -1,105 +0,0 @@
---
author: Pankaj Bhojwani, pabhojwa@microsoft.com
created on: 2021-6-17
last updated: 2021-6-23
issue id: #1790
---
# Font features and axes of variation
## Abstract
This spec outlines how we can allow users to specify font features and axes of variation for fonts in Windows Terminal. Font features include things like being able to specify whether ligatures should be used as well as the specific stylistic set used for a font. Axes of variation commonly include things like weight and slant but can also include fancier things like shadow distance, depending on the font.
## Inspiration
Reference: [#1790](https://github.com/microsoft/terminal/issues/1790)
Currently, if a font has ligatures, we offer no way for a user to disable them. Many users would like the option to do so, and would also like the ability to choose stylistic sets for fonts - for example, at the time of this writing, Cascadia Code offers 4 stylistic sets but we offer no way for users to specify any of them.
In a similar vein, many fonts allow for setting variations on the font along certain attributes, commonly referred to as 'axes of variation'. We can offer users more font customization options by allowing them to configure these font variations.
## Solution Design
### Font features
It is already possible to pass in a list of [font feature structs](https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ns-dwrite-dwrite_font_feature) to DWrite for it to handle. A font feature struct contains only 2 things:
1. A font feature tag
2. A parameter value
A font feature tag is constructed using a 4-character feature tag and the parameter value defines how the feature is applied. For most features, the parameter value is simply treated as a binary value - a value of 0 means the feature is not applied and a non-zero value means the feature is applied. For example, a font feature struct like {'ss03', 1} enables stylistic set 3 for the font and a font feature struct like {'liga', 0} disables ligatures. (Technically, the feature tag is _constructed_ with the 4-character tag and is not the 4-character tag itself, but they are treated the same in the example here for brevity's sake).
Currently, we pass in to DWrite a null value for the list of features to apply to the font. This causes DWrite to automatically apply a ['standard' list](https://github.com/fdwr/TextLayoutSampler/blob/master/DrawableObject.ixx#L802) of font features to the font. Naturally, passing in our own list of font features to DWrite means DWrite will _only_ apply the features we defined, and no longer apply the standard list. Since the standard list contains 11 features, we need to consider how we can allow users to specify 1 additional feature or delete 1 of the standard features without needing to redefine all the others.
We will do this by allowing users to define a dictionary in their settings.json file, where the keys are the 4-character feature tags and the values are the parameter values. This dictionary will then get applied to our internal dictionary (which will contain the standard list of 11 features with their parameter values), meaning that any new key-value pairs will get added to our dictionary and any existing key-value pairs will get updated. Finally, this 'merged' dictionary will be what we use to construct the list of features to pass into DWrite.
### Axes of variation
Specifying axes of variation is done in an extremely similar manner to the way font features are specified - a 4-character tag is used to specify which font axis is being modified and a numerical value is provided to specify the value the axis should be set to. For example, {'slnt', 20} specifies that the 'slant' axis should be set to 20.
There is also a standard list of axes of variation, and each axis has its own default. We will approach this the same way we approached font features, by allowing users to specify additional features or omit features without needing to redefine the defaults.
## UI/UX Design
Users will be able to add a new setting to their font objects (added in [#10433](https://github.com/microsoft/terminal/pull/10433)). The resultant font object may look something like this
```json
"font": {
"face": "Cascadia Code",
"size": 12,
"features": {
"ss03": 1,
"liga": 0
},
"axes": {
"slnt": 20.5
}
}
```
There is one point to note here about clashing. For example, if a user has the old "weight" setting defined _as well as_ a "wght" axis defined, we will only use the "wght" axis value. We prioritize that value for a few reasons:
1. It is the more recent addition to our settings model. Thus, it is likely that a user that has defined both values probably just forgot to remove the old value.
2. It is the more precise value, it is a specific float value whereas the the old "weight" setting is an enum (that eventually gets mapped to a float value).
## Capabilities
### Accessibility
Should not affect accessibility.
### Security
Should not affect security.
### Reliability
Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existant feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
### Compatibility
Older versions of Windows may not have the DWrite updates that allow for defining font features and axes of variation. We must make sure to fallback to the current implementation in these cases.
### Performance, Power, and Efficiency
Currently when rendering a run of text, if we detect that the given run is simple we will use a shortcut to obtain the glyphs needed, skipping over an expensive `GetGlyphs` call to DWrite. However, when the default feature list is changed in any way (either by adding a new feature or removing one of the defaults), there is no way for us to detect beforehand how the font glyphs would change.
This means that as long as the user requests a change to the default font feature list, we will _always_ skip the shortcut and call the expensive `GetGlyphs` function for every run of text.
This will naturally cause a performance cost that we will have to bear for this feature. However, it is worth noting that there are a fair number of glyphs that will cause a run of text to be deemed "not simple" (and thus cause us to call `GetGlyphs` anyway), for example when using Cascadia Code, any run of text that has the letters 'i', 'j', 'l', 'n', 'w' or 'x' is not considered simple (because those glyphs have localized variants).
## Potential Issues
See performance issues above.
## Future considerations
DWrite additionally offers the ability to vary the font features across runs of text. However, for our initial implementation of this feature, we will only apply font features to the entire buffer. If/when we decide to allow specifying font features for particular runs of text, we can lean into our existing mechanisms of splitting up runs of text to implement that.
We will also need to consider how we want to represent this in the settings UI. This is slightly more complex than other settings since users should be allowed to manually input 4-character tags.
## Resources
[DWRITE_FONT_FEATURE structure](https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ns-dwrite-dwrite_font_feature)
[DWRITE_FONT_AXIS_VALUE structure](https://docs.microsoft.com/en-us/windows/win32/api/dwrite_3/ns-dwrite_3-dwrite_font_axis_value)

View File

@@ -1,302 +0,0 @@
---
author: Mike Griese @zadjii-msft
created on: 2020-11-23
last updated: 2020-12-15
issue id: #2871
---
# Focus Pane Actions
## Abstract
Currently, the Terminal only allows users to navigate through panes
_directionally_. However, we might also want to allow a user to navigate through
panes in most recently used order ("MRU" order), or to navigate directly to a
specific pane. This spec proposes some additional actions in order to enable
these sorts of scenarios.
## Background
### Inspiration
`tmux` allows the user to navigate through panes using its `select-pane`
command. The `select-pane` command works in the following way:
```
select-pane [-DLlMmRU] [-T title] [-t target-pane]
Make pane target-pane the active pane in window target-window, or set its
style (with -P). If one of -D, -L, -R, or -U is used, respectively the
pane below, to the left, to the right, or above the target pane is used.
-l is the same as using the last-pane command.
-m and -M are used to set and clear the marked pane. There is one marked
pane at a time, setting a new marked pane clears the last. The marked pane
is the default target for -s to join-pane, swap-pane and swap-window.
```
_from `man tmux`_.
The Terminal currently allows the user to navigate through panes with the
`moveFocus` action, which only accepts a `direction` to move in.
Additionally, the Terminal allows movement between tabs with the `nextTab` and
`prevTab` actions, who move between tabs either in-order or in MRU order.
Furthermore, these actions may or may not display the "tab switcher" user
interface, based on the value of `tabSwitcherMode`.
### User Stories
* **Scenario 1**: A user who wants to be able to split the window into 4 equal
corners from the commandline. Currently this isn't possible, because the user
cannot move focus during the startup actions - `split-pane` actions always end
up splitting the current leaf in the tree of panes. (see [#5464])
* **Scenario 2**: A user who wants to quickly navigate to the previous pane they
had opened. (see [#2871])
* **Scenario 3**: A user who wants to bind a keybinding like <kbd>alt+1</kbd>,
<kbd>alt+2</kbd>, etc to immediately focus the first, second, etc. pane in a
tab. (see [#5803])
### Future Considerations
There's been talk of updating the advanced tab switcher to also display panes,
in addition to just tabs. This would allow users to navigate through the ATS
directly to a pane, and see all the panes in a tab. Currently, `tabSwitcherMode`
changes the behavior of `nextTab`, `prevTab` - should we just build the
`paneSwitcherMode` directly into the action we end up designing?
## Solution Design
Does using the pane switcher with a theoretical `focusPane(target=id)` action
even make sense? Certainly not! That's like `switchToTab(index=id)`, the user
already knows which tab they want to go to, there's no reason to pop an
ephemeral UI in front of them.
Similarly, it almost certainly doesn't make sense to display the pane switcher
while moving focus directionally. Consider moving focus with a key bound to the
arrow keys. Displaying another UI in front of them while moving focus with the
arrow keys would be confusing.
Addressing Scenario 1 is relatively easy. So long as we add any of the proposed
actions, including the existing `moveFocus` action as a subcommand that can be
passed to `wt.exe`, then the user should be able to navigate through the panes
they've created with the startup commandline, and build the tree of panes
however they see fit.
Scenario 2 is more complicated, because MRU switching is always more
complicated. Without a UI of some sort, there's no way to switch to another pane
in the MRU order without also updating the MRU order as you go. So this would
almost certainly necessitate a "pane switcher", like the tab switcher.
### Proposal A: Add next, prev to moveFocus
* `moveFocus(direction="up|down|left|right|next|prev")`
* **Pros**:
- Definitely gets the "MRU Pane Switching" scenario working
* **Cons**:
- Doesn't really address any of the other scenarios
- How will it play with pane switching in the UI?
- MRU switching without a dialog to track & display the MRU stack doesn't
really work - this only allows to the user to navigate to the most recently
used pane, or through all the panes in least-recently-used order. This is
because switching to the MRU pane _will update the MRU pane_.
❌ This proposal is no longer being considered.
### Proposal B: focusNextPane, focusPrevPane with order, useSwitcher args
```json
// Focus pane 1
// - This is sensible, no arguments here
{ "command": { "action": "focusPane", "id": 1 } },
// Focus the next MRU pane
// - Without the switcher, this can only go one pane deep in the MRU stack
// - presumably once there's a pane switcher, it would default to enabled?
{ "command": { "action": "focusNextPane", "order": "mru" } },
// Focus the prev inOrder pane
// - this seems straightforward
{ "command": { "action": "focusPrevPane", "order": "inOrder" } },
// Focus the next pane, in mru order, explicitly disable the switcher
// - The user opted in to only being able to MRU switch one deep. That's fine, that's what they want.
{ "command": { "action": "focusNextPane", "order": "mru", "useSwitcher": false} },
// Focus the prev inOrder pane, explicitly with the switcher
// - Maybe they disabled the switcher globally, but what it on for this action?
{ "command": { "action": "focusPrevPane", "order": "inOrder", "useSwitcher": true } },
```
_From [discussion in the implementation
PR](https://github.com/microsoft/terminal/pull/8183#issuecomment-729672645)_
Boiled down, that's three actions:
* `focusPane(target=id)`
* `focusNextPane(order="inOrder|mru", useSwitcher=true|false)`
* `focusPrevPane(order="inOrder|mru", useSwitcher=true|false)`
* **Pros**:
- Everything is explicit, including the option to use the pane switcher (when
available)
- Adds support for in-order pane switching
- No "conditional parameters" - where providing one argument makes other
arguments invalid or ambiguous.
* **Cons**:
- Doesn't really address any of the other scenarios
- What does the "next most-recently-used tab" even mean? How is it different
than "previous most-recently-used tab"? Semantically, these are the same
thing!
- No one's even asked for in-order pane switching. Is that a UX that even
really makes sense?
❌ This proposal is no longer being considered.
> 👉 **NOTE**: At this point, we stopped considering navigating in both MRU
> "directions", since both the next and prev MRU pane are the same thing. We're
> now using "last" to mean "the previous MRU pane".
### Proposal C: One actions, combine the args
* `moveFocus(target=id|"up|down|left|right|last")`
* **Pros**:
- Absolutely the least complicated action to author. There's only one
parameter, `target`.
- No "conditional parameters".
* **Cons**:
- How do we express this in the Settings UI? Mixed-type enums work fine for
the font weight, where each enum value has a distinct integer value it maps
to, but in this case, using `id` is entirely different from the other
directional values
❌ This proposal is no longer being considered.
### Proposal D: Two actions
* `focusPane(target=id)`
* `moveFocus(direction="up|down|left|right|last")`
* **Pros**:
- Each action does explicitly one thing.
* **Cons**:
- two actions for _similar_ behavior
- This now forks the "Direction" enum into "MoveFocusDirection" and
"ResizeDirection" (because `resizePane(last)` doesn't make any sense).
This proposal doesn't really have any special consideration for the pane
switcher UX. Neither of these actions would summon the pane switcher UX.
### Proposal E: Three actions
* `focusPane(target=id)`
* `moveFocus(direction="up|down|left|right")`
* `focusLastPane(usePaneSwitcher=false|true)`
In this design, neither `focusPane` nor `moveFocus` will summon the pane
switcher UI (even once it's added). However, the `focusLastPane` one _could_,
and subsequent keypresses could pop you through the MRU stack, while it's
visible? The pane switcher could then display the panes for the tab in MRU
order, and the user could just use the arrow keys to navigate the list if they
so choose.
* **Pros**:
- Each action does explicitly one thing.
- Design accounts for future pane switcher UX
* **Cons**:
- Three separate actions for similar behavior
❌ This proposal is no longer being considered.
### Proposal F: It's literally just tmux
_Also known as the "one action to rule them all" proposal_
`focusPane(target=id, direction="up|down|left|right|last")`
Previously, this design was avoided, because what does `focusPane(target=4,
direction=down)` do? Does it focus pane 4, or does it move focus down?
`tmux` solves this in one action by just doing both!
```
Make pane target-pane the active pane ... If one of -D, -L, -R, or -U is used,
respectively the pane below, to the left, to the right, or above the target pane
is used.
```
_from `man tmux`_.
So `focusPane(target=1, direction=up)` will attempt to focus the pane above pane
1. This action would not summon the pane switcher UX, even for
`focusPane(direction=last)`
* **Pros**:
- Fewest redundant actions
* **Cons**:
- Is this intuitive? That combining the params would do both, with `target`
happening "first"?
- Assumes that there will be a separate action added in the future for "Open
the pane switcher (with some given ordering)"
> 👉 **NOTE**: At this point, the author considered "Do we even want a separate
> action to engage the tab switcher with panes expanded?" Perhaps panes being
> visible in the tab switcher is just part fo the tab switcher's behavior. Maybe
> there shouldn't be a separate "open the tab switcher with the panes expanded
> to the pane I'm currently on, and the panes listed in MRU order" action.
❌ This proposal is no longer being considered.
## Conclusion
After much discussion as a team, we decided that **Proposal D** would be the
best option. We felt that there wasn't a need to add any extra configuration to
invoke the "pane switcher" as anything different than the "tab switcher". The
"pane switcher" should really just exist as a part of the functionality of the
advanced tab switcher, not as it's own thing.
Additionally, we concurred that the new "direction" value should be `prev`, not
`last`, for consistency's sake.
## UI/UX Design
The only real UX being added with the agreed upon design is allowing the user to
execute an action to move to the previously active pane within a single tab. No
additional UX (including the pane switcher) is being prescribed in this spec at
this time.
## Potential Issues
<table>
<tr>
<td><strong>Compatibility</strong></td>
<td>
We've only adding a single enum value to an existing enum. Since we're not
changing the meaning of any of the existing values, we do not expect any
compatibility issues there. Additionally, we're not changing the default value
of the `direction` param of the `moveFocus` action, so there are no further
compatibility concerns there. Furthermore, no additional parameters are being
added to the `moveFocus` action that would potentially give it a different
meaning.
</td>
</tr>
</table>
In the current design, there's no way to move through all the panes with a
single keybinding. For example, if a user wanted to bind <kbd>Alt+]</kbd> to
move to the "next" pane, and <kbd>Alt+[</kbd> to move to the "previous" one.
These movements would necessarily need to be in-order traversals, since there's
no way of doing multiple MRU steps.
Fortunately, no one's really asked for traversing the panes in-order, so we're
not really worried about this. Otherwise, it would maybe make sense for `last`
to be the "previous MRU pane", and reserve `next`/`prev` for in-order traversal.
[#2871]: https://github.com/microsoft/terminal/issues/2871
[#5464]: https://github.com/microsoft/terminal/issues/5464
[#5803]: https://github.com/microsoft/terminal/issues/5803

View File

@@ -1,128 +0,0 @@
---
author: Pankaj Bhojwani, pabhojwa@microsoft.com
created on: 2020-11-20
last updated: 2021-2-5
issue id: #8345
---
# Appearance configuration objects for profiles
## Abstract
This spec outlines how we can support 'configuration objects' in our profiles, which
will allow us to render differently depending on the state of the control. For example, a
control can be rendered differently if it's focused as compared to when it's unfocused.
## Inspiration
Reference: [#3062](https://github.com/microsoft/terminal/issues/3062)
Users want there to be a more visible indicator than the one we have currently for which
pane is focused and which panes are unfocused. This change would grant us that feature.
## Solution Design
The implementation design for appearance config objects centers around the recent change where inheritance was added to the
`TerminalSettings` class in the Terminal Settings Model - i.e. different `TerminalSettings` objects can inherit from each other.
The reason for this change was that we did not want a settings reload to erase any overrides `TermControl` may have made
to the settings during runtime. By instead passing a child of the `TerminalSettings` object to the control, we can change
the parent of the child during a settings reload without the overrides being erased (since those overrides live in the child).
The idea behind unfocused appearance configurations is similar. We will pass in another `TerminalSettings` object to the control,
which is simply a child that already has some overrides in it. When the control gains or loses focus, it simply switches between
the two settings objects appropriately.
### Allowed parameters
For now, these states are meant to be entirely appearance-based. So, not all parameters which can be
defined in a `Profile` can be defined in this new object (for example, we do not want parameters which
would cause a resize in this object.) Here is the list of parameters we will allow:
- Anything regarding colors: `colorScheme`, `foreground`, `background`, `cursorColor` etc
- Anything regarding background image: `path`, `opacity`, `alignment`, `stretchMode`
- `cursorShape`
We may wish to allow further parameters in these objects in the future (like `bellStyle`?). The addition
of further parameters can be discussed in the future and is out of scope for this spec.
### Inheritance
The inheritance model can be thought of as an 'all-or-nothing' approach in the sense that the `unfocusedAppearance` object
is considered as a *single* setting instead of an object with many settings. We have chosen this model because it is cleaner
and easier to understand than the alternative, where each setting within an `unfocusedAppearance` object has a parent from which
it obtains its value.
Note that when `TerminalApp` initializes a control, it creates a `TerminalSettings` object for that profile and passes the
control a child of that object (so that the control can store overrides in the child, as described earlier). If an unfocused
config is defined in the profile (or in globals/profile defaults), then `TerminalApp` will create a *child of that child*,
put the relevant overrides in it, and pass that into the control as well. Thus, the inheritance of any undefined parameters
in the unfocused config will be as follows:
1. The unfocused config specified in the profile (or in globals/profile defaults)
2. Overrides made by the terminal control
3. The parent profile
## UI/UX Design
Users will be able to add a new setting to their profiles that will look like this:
```
"unfocusedAppearance":
{
"colorScheme": "Campbell",
"cursorColor": "#888",
"cursorShape": "emptyBox",
"foreground": "#C0C0C0",
"background": "#000000"
}
```
When certain appearance settings are changed via OSC sequences (such as the background color), only the focused/regular
appearance will change and the unfocused one will remain unchanged. However, since the unfocused settings object inherits
from the regular one, it will still apply the change (provided it does not define its own value for that setting).
## Capabilities
### Accessibility
Does not affect accessibility.
### Security
Does not affect security.
### Reliability
This is another location in the settings where parsing/loading the settings may fail. However, this is the case
for any new setting we add so I would say that this is a reasonable cost for this feature.
### Compatibility
Should not affect compatibility.
### Performance, Power, and Efficiency
Rapidly switching between many panes, causing several successive appearance changes in a short period of time, could
potentially impact performance. However, regular/reasonable pane switching should not have a noticeable effect.
## Potential Issues
Inactive tabs will be 'rendered' in the background with the `UnfocusedRenderingParams` object, we need to make
sure that switching to an inactive tab (and so causing the renderer to update with the 'normal' parameters)
does not cause the window to flash/show a jarring indicator that the rendering values changed.
## Future considerations
We will need to decide how this will look in the settings UI.
We may wish to add more states in the future (like 'elevated'). When that happens, we will need to deal with how
these appearance objects can scale/layer over each other. We had a lot of discussion about this and could not find
a suitable solution to the problem of multiple states being valid at the same time (like unfocused and elevated).
This, along with the fact that it is uncertain if there even will be more states we would want to add led us to
the conclusion that we should only support the unfocused state for now, and come back to this issue later. If there
are no more states other than unfocused and elevated, we could allow combining them (like having an 'unfocused elevated' state).
If there are more states, we could do the implementation as an extension rather than inherently supporting it.
## Resources

View File

@@ -1,562 +0,0 @@
---
author: Mike Griese @zadjii-msft
created on: 2020-10-30
last updated: 2020-02-05
issue id: #4472
---
# Windows Terminal Session Management
## Abstract
This document is intended to serve as an addition to the [Process Model 2.0
Spec]. That document provides a big-picture overview of changes to the entirety
of the Windows Terminal process architecture, including both the split of
window/content processes, as well as the introduction of monarch/peasant
processes. The focus of that document was to identify solutions to a set of
scenarios that were closely intertwined, and establish these solutions would
work together, without preventing any one scenario from working. What that
document did not do was prescribe specific solutions to the given scenarios.
This document offers a deeper dive on a subset of the issues in [#5000], to
describe specifics for managing multiple windows with the Windows Terminal. This
includes features such as:
* Run `wt` in the current window ([#4472])
* Single Instance Mode ([#2227])
## Solution Design
### Monarch and Peasant Processes
This document assumes the reader is already familiar with the "Monarch and
Peasant" architecture as detailed in the [Windows Terminal Process Model 2.0
Spec]. As a quick summary:
* Every Windows Terminal window is a "Peasant" process.
* One of the Windows Terminal window processes is also the "Monarch" process.
The Monarch is picked randomly from the Terminal windows, and there is only
ever one Monarch process at a time.
* Peasants can communicate with the monarch when certain state changes (such as
their window being activated), and the monarch can send commands to any of the
peasants.
This architecture will be used to enable each of the following scenarios.
### Scenario: Open new tabs in most recently used window
A common feature of many browsers is that when a web URL is clicked somewhere,
the web page is opened as a new tab in the most recently used window of the
browser. This functionality is often referred to as "glomming", as the new tab
"gloms" onto the existing window.
Currently, the terminal does not support such a feature - every `wt` invocation
creates a new window. With the monarch/peasant architecture, it'll now be
possible to enable such a scenario.
As each window is activated, it will call a method on the `Monarch` object
(hosted by the monarch process) which will indicate that "I am peasant N, and
I've been focused". The monarch will use those method calls to update its own
internal stack of the most recently used windows.
Whenever a new `wt.exe` process is launched, that process will _first_ ask the
monarch if it should run the commandline in an existing window, or create its
own window.
![auto-glom-wt-exe](auto-glom-wt-exe.png)
If glomming is enabled, the monarch will dispatch the commandline to the
appropriate window for them to handle instead. To the user, it'll seem as if the
tab just opened in the most recent window.
Users should certainly be able to specify if they want new instances to glom
onto the MRU window or not. You could imagine that currently, we default to the
hypothetical value `"windowingBehavior": "useNew"`, meaning that each new wt gets
its own new window.
If glomming is disabled, then the Monarch will call back to the peasant and tell
it to run the provided commandline. The monarch will use the return value of
`ExecuteCommandline` to indicate that the calling process should create a window
and become a peasant process, and run the commandline itself.
#### Glomming within the same virtual desktop
When links are opened in the new Edge browser, they will only glom onto an
existing window if that window is open in the current virtual desktop. This
seems like a good idea of a feature for the Terminal to follow as well.
There must be some way for an application to determine which virtual desktop it
is open on. We could use that information to have the monarch track the last
active window _per-desktop_, and only glom when there's one on the current
desktop.
We could make the `windowingBehavior` property accept a variety of
configurations:
- `"useExisting"`: always glom to the most recent window, regardless of desktop.
- `"useExistingOnSameDesktop"`: Only glom if there's an existing window on this
virtual desktop, otherwise create a new window. This will be the new default
value.
- `"useNew"`: Never glom, always create a new window. This is technically the
current behavior of the Terminal.
### Handling the current working directory
Consider the following scenario: the user runs `wt -d .` in the address bar of
explorer, and the monarch determines that this new tab should be created in an
existing window. For clarity during this example, we will label the existing
window WT[1], and the second `wt.exe` process WT[2].
An example of this scenario is given in the following diagram:
![single-instance-mode-cwd](single-instance-mode-cwd.png)
In this scenario, we want the new tab to be spawned in the current working
directory of WT[2], not WT[1]. So when WT[1] is about to run the commands that
were passed to WT[2], WT[1] will need to:
* First, stash its own CWD
* Change to the CWD of WT[2]
* Run the commands from WT[2]
* Then return to its original CWD.
So, as a part of the interface that a peasant uses to communicate the startup
commandline to the monarch, we should also include the current working
directory.
### Scenario: Run `wt` in the current window
One often requested scenario is the ability to run a `wt.exe` commandline in the
current window, as opposed to always creating a new window. Presume we have the
ability to communicate between different window processes. The logical extension
of this scenario would be "run a `wt` commandline in _any_ given WT window".
Each window process will have its own unique ID assigned to it by the monarch.
This ID will be a positive number. Windows can also have names assigned to them.
These names are strings that the user specifies. A window will always have an
ID, but not necessarily a name. Running a command in a given window with ID N
should be as easy as something like:
```sh
wt.exe --window N new-tab ; split-pane
```
(or for shorthand, `wt -w N new-tab ; split-pane`).
More formally, we will add the following parameter to the top-level `wt`
command:
#### `--window,-w <window-id>`
Run these commands in the given Windows Terminal session. This enables opening
new tabs, splits, etc. in already running Windows Terminal windows.
* If `window-id` is `0`, run the given commands in _the current window_.
* If `window-id` is a negative number, or the reserved name `new`, run the
commands in a _new_ Terminal window.
* If `window-id` is the ID or name of an existing window, then run the
commandline in that window.
* If `window-id` is _not_ the ID or name of an existing window, create a new
window. That window will be assigned the ID or name provided in the
commandline. The provided subcommands will be run in that new window.
* If `window-id` is omitted, then obey the value of `windowingBehavior` when
determining which window to run the command in.
_Whenever_ `wt.exe` is started, it must _always_ pass the provided commandline
first to the monarch process for handling. This is important for glomming
scenarios (as noted above). The monarch will parse the commandline, determine
which window the commandline is destined for, then call `ExecuteCommandline` on
that peasant, who will then run the command.
#### Running commands in the current window:`wt --window 0`
If `wt -w 0 <commands>` is run _outside_ a WT instance, it could attempt to glom
onto _the most recent WT window_ instead. This seems more logical than something
like `wt --window last` or some other special value indicating "run this in the
MRU window".<sup>[[2]](#footnote-2)</sup>
That might be a simple, but **wrong**, implementation for "the current window".
If the peasants always raise an event when their window is focused, and the
monarch keeps track of the MRU order for peasants, then one could naively assume
that the execution of `wt -w 0 <commands>` would always return the window the
user was typing in, the current one. However, if someone were to do something
like `sleep 10 ; wt -w 0 <commands>`, then the user could easily focus another
WT window during the sleep, which would cause the MRU window to not be the same
as the window executing the command.
To solve this issue, we'll other than
attempting to use the `WT_SESSION` environment variable. If a `wt.exe` process
is spawned and that's in its environment variables, it could try and ask the
monarch for the peasant who's hosting the session corresponding to that GUID.
This is more of a theoretical solution than anything else.
In the past we've been reluctant to rely too heavily on `WT_SESSION`. However,
an environment variable does seem to be the only reliable way to be confident
where the window was created from. We could introduce another environment
variable instead - `WT_WINDOW_ID`. That would allow us to shortcut the session
ID lookup. However, I worry about exposing the window ID as an environment
variable. If we do that, users will inevitably use that instead of the `wt -0`
alias, which should take care of the work for them. Additionally, `WT_WINDOW_ID`
wouldn't update in the child processes as tabs are torn out of windows to create
new windows.
Both solutions are prone to the user changing the value of the variable to some
garbage value. If they do that, this lookup will most certainly not work as
expected. Using the session ID (a GUID) instead of the window ID (an int) makes
it less likely that they guess the ID of an existing instance.
#### Running commands in a new window:`wt --window -1` / `wt --window new`
If the user passes a negative number, or the reserved name `new` to the
`--window` parameter, then we will always create a new window for that
commandline, regardless of the value of `windowingBehavior`. This will allow
users to do something like `wt -w -1 new-tab` to _always_ create a new window.
#### `--window` in subcommands
The `--window` parameter is a setting to `wt.exe` itself, not to one of its
subcommands (like `new-tab` or `split-pane`). This means that all of the
subcommands in a particular `wt` commandline will all be handled by the same
session. For example, let us consider a user who wants to open a new tab in
window 2, and split a new pane in window 3, all at once. The user _cannot_ do
something like:
```cmd
wt -w 2 new-tab ; -w 3 split-pane
```
Instead, the user will need to separate the commands (by whatever their shell's
own command delimiter is) and run two different `wt.exe` instances:
```cmd
wt -w 2 new-tab & wt -w 3 split-pane
```
This is done to make the parsing of the subcommands easier, and for the internal
passing of arguments simpler. If the `--window` parameter were a part of each
subcommand, then each individual subcommand's parser would need to be
enlightened about that parameter, and then it would need to be possible for any
single part of the commandline to call out to another process. It would be
especially tricky then to coordinate the work being done across process here.
The source process would need some sort of way to wait for the other process to
notify the source that a particular subcommand completed, before allowing the
source to dispatch the next part of the commandline.
Overall, this is seen as unnecessarily complex, and dispatching whole sets of
commands as a simpler solution.
### Naming Windows
It's not user-friendly to rely on automatically generated, invisible numbers to
identify windows. There's not a great way of identifying which window is which.
The user would need to track the IDs in their head manually. Instead, we'll
allow the user to provide a string name for the window. This name can be used to
address a window in addition to the ID.
Names can be provided on the commandline, in the original commandline. For
example, `wt -w foo nt` would name the new window "foo". Names can also be set
with a new action, `NameWindow`<sup>[[3]](#footnote-3)</sup>. `name-window`
could also be used as a subcommand. For example, `wt -w 4 name-window bar` would
name window 4 "bar".
To keep identities mentally distinct, we will disallow names that are integers
(positive or negative). This will prevent users from renaming a window to `2`,
then having `wt -w 2` be ambiguous as to which window it refers to.
Names must also be unique. If a user attempts to set the name of the window to
an already-used name, we'll need to ignore the name change. We could also
display a "toast" or some other type of low-impact message to the user. That
message would have some text like: "Unable to rename window. Another window with
that name already exists".
The Terminal will reserve the name `new`. It will also reserve any names
starting with the character `_`. The user will not be allowed to set the window
name to any of these reserved names. Reserving `_*` allows us to add other
keywords in the future, without introducing a breaking change.
## UI/UX Design
### `windowingBehavior` details
The following list gives greater breakdown of the values of `windowingBehavior`,
and how they operate:
* `"windowingBehavior": "useExisting", "useExistingOnSameDesktop"`:
**Browser-like glomming**
- New instances open in the current window by default.
- `newWindow` opens a new window.
- Tabs can be torn out to create new windows.
- `wt -w -1` opens a new window.
* `"windowingBehavior": "useNew"`: No auto-glomming. This is **the current
behavior** of the Terminal.
- New instances open in new windows by default
- `newWindow` opens a new window
- Tabs can be torn out to create new windows.
- `wt -w -1` opens a new window.
We'll be changing the default behavior from `useNew` to
`useExistingOnSameDesktop`. This will be more consistent with other tabbed
applications.
## Concerns
<table>
<tr>
<td><strong>Accessibility</strong></td>
<td>
There is no expected accessibility impact from this feature. Each window will
handle UIA access as it normally does.
In the future, we could consider exposing the window IDs and/or names via UIA.
</td>
</tr>
<tr>
<td><strong>Security</strong></td>
<td>
Many security concerns have already be covered in greater detail in the parent
spec, [Process Model 2.0 Spec].
When attempting to instantiate the Monarch, COM will only return the object from
a server running at the same elevation level. We don't need to worry about
unelevated peasants connecting to the elevated Monarch, or vice-versa.
</td>
</tr>
<tr>
<td><strong>Reliability</strong></td>
<td>
We will need to be careful when working with objects hosted by another process.
Any work we do with it MUST be in a try/catch, because at _any_ time, the other
process could be killed. At any point, a window process could be killed. Both
the monarch and peasant code will need to be redundant to such a scenario, and
if the other process is killed, make sure to display an appropriate error and
either recover or exit gracefully.
In any and all these situations, we will want to try and be as verbose as
possible in the logging. This will make tracking which process had the error
occur easier.
</td>
</tr>
<tr>
<td><strong>Compatibility</strong></td>
<td>
We will be changing the default behavior of the Terminal to auto-glom to the
most-recently used window on the same desktop in the course of this work, which
will be a breaking UX change. This is behavior that can be reverted with the
`"windowingBehavior": "useNew"` setting.
We acknowledge that this is a pretty massive change to the default experience of
the Terminal. We're planning on doing some polling of users to determine which
behavior they want by default. Additionally, we'll be staging the rollout of
this feature, using the Preview builds of the Terminal. The release notes that
first include it will call extra attention to this feature. We'll ask that users
provide their feedback in a dedicated thread, so we have time to collect
opinions from users before rolling the change out to all users.
We may choose to only change the default to `useExistingOnSameDesktop` once tab
tear out is available, so users who are particularly unhappy about this change
can still tear out the tab (if they can't be bothered to change the setting).
</td>
</tr>
<tr>
<td><strong>Performance, Power, and Efficiency</strong></td>
<td>
There's no dramatic change expected here. There may be a minor delay in the
spawning of new terminal instances, due to requiring cross-process hops for the
communication between monarch and peasant processes.
</td>
</tr>
</table>
## Potential Issues
### Mixed Elevation Levels
As of December 2020, we're no longer pursuing a "mixed-elevation" scenario for
the Terminal. This makes many of the cross-elevation scenarios simpler. Elevated
and unelevated `wt` instances will always remain separate. The different
elevation levels will maintain separate lists of window IDs. If the user is
running both an elevated and unelevated window, then there will be two monarchs.
One elevated, and the other unelevated.
There will also be some edge cases when handling the commandline that will need
special care. Say the user wanted to open a new tab in the elevated window, from
and unelevated `explorer.exe`. That would be a commandline like:
```sh
wt -w 0 new-tab -d . --elevated
```
Typically we first determine which window the commandline is intended for, then
dispatch it to that window. In this case, the `-w 0` will cause us to pass the
commandline to the current unelevated window. Then, that window will try to open
an elevated tab, fail, and create a new `wt.exe` process. This second `wt.exe`
process will lose the `-w 0` context. It won't inform the elevated monarch that
this commandline should be run in the active session.
We will need to make sure that special care is taken when creating elevated
instances that we maintain the `--window` parameter passed to the Terminal.
### `wt` Startup Commandline Options
There are a few commandline options which can be provided to `wt.exe` which
don't make sense to pass to another session. These options include (but are not
limited to):
* `--initialSize r,c`
* `--initialPosition x,y`
* `--fullscreen`, `--maximized`, etc.
When we're passing a commandline to another instance to handle, these arguments
will be ignored. they only apply to the initial creation of a window.
`--initialSize 32, 120` doesn't make sense if the window already has a size.
On startup of a new window, we currently assume that the first command is always
`new-tab`. When passing commandlines to existing windows, we won't need to make
that assumption anymore. There will already be existing tabs.
### Monarch MRU Window Tracking
As stated above, the monarch is responsible for tracking the MRU window stack.
However, when the monarch is closed, this state will be lost. The new monarch
will be elected, but it will be unable to ask the old monarch for the MRU
order of the windows.
We had previously considered an _acceptable_ UX when this would occur. We would
randomize the order (with the new monarch becoming the MRU window). If someone
noticed this bug and complained, then we had a theoretical solution prepared.
The peasants could inform not only the monarch, but _all other peasants_ when
they become activated. This would mean all peasants are simultaneously tracking
the MRU stack. This would mean that any given peasant would be prepared always
to become the monarch.
A simpler solution though would be to not track the MRU stack in the Monarch at
all. Instead, each peasant could just track internally when they were last
activated. The Monarch wouldn't track any state itself. It would be distributed
across all the peasants. The Monarch could then iterate over the list of
peasants and find the one with the newest `LastActivated` timestamp.
Now, when a Monarch dies, the new Peasant doesn't have to come up with the stack
itself. All the other Peasants keep their state. The new Monarch can query them
and get the same answer the old Monarch would have.
We could further optimize this by having the Monarch also track the stack. Then,
the monarch could query the MRU window quickly. The `LastActivated` timestamps
would only be used by a new Monarch when it is elected, to reconstruct the MRU
stack.
## Implementation Plan
This is a list of actionable tasks generated as described by this spec:
* [ ] Add support for `wt.exe` processes to be Monarchs and Peasants, and
communicate that state between themselves. This task does not otherwise add
any user-facing features, merely an architectural update.
* [ ] Add support for the `windowingBehavior` setting as a boolean. Opening new
WT windows will conditionally glom to existing windows.
* [ ] Add support for per-desktop `windowingBehavior`, by adding the support for
the enum values `"useExisting"`, `"useExistingOnSameDesktop"` and `"useNew"`.
* [ ] Add support for `wt.exe` to pass commandlines intended for another window
to the monarch, then to the intended window, with the `--window,-w
window-id` commandline parameter.
* [ ] Add support for targeting and naming windows via the `-w` parameter on the
commandline
* [ ] Add a `NameWindow` action, subcommand that allows the user to set the name
for the window.
* [ ] Add an action that will cause all windows to briefly display a overlay
with the current window ID and name. This would be something like the
"identify" feature of the Windows "Display" settings.
## Future considerations
* What if the user wanted to pipe a command to a pane in an existing window?
```sh
man ping > wt -w 0 split-pane cat
```
Is there some way for WT to pass its stdin/out handles to the child process
it's creating? This is _not_ related to the current spec at hand, just
something the author considered while writing the spec. This likely belongs
over in [#492], or in its own spec.
- Or I suppose, with less confusion, someone could run `wt -w 0 split-pane --
man ping > cat`. That's certainly more sensible, and wouldn't require any
extra work.
* "Single Instance Mode" is a scenario in which there is only ever one single WT
window. A user might want this functionality to only ever allow a single
terminal window to be open on their desktop. This is especially frequently
requested in combination with "quake mode", as discussed in [#653]. When Single
Instance Mode is active, and the user runs a new `wt.exe` commandline, it will
always end up running in the existing window, if there is one.
An earlier version of this spec proposed a new value of `glomToLastWindow`.
(`glomToLastWindow` was later renamed `windowingBehavior`). The `always` value
would disable tab tear out<sup>[[1]](#footnote-1)</sup>. It would additionally
disable the `newWindow` action, and prevent `wt -w new` from opening a new
window.
In discussion, it was concluded that this setting didn't make sense. Why did the
`glomToLastWindow` setting change the behavior of tear out? Single Instance Mode
is most frequently requested in regards to quake mode. We're leaving the
implementation of true single instance mode to that spec.
* It was suggested in review that we could auto-generate names for windows, from
some list of words. Prior art could be the URLS for gfycat.com or
what3words.com, which use three random words. I believe `docker` also assigns
names from a random selection of `adjective`+`name`. This is an interesting
idea, and something that could be pursued in the future.
- This would be a massive pain to localize though, hence why this is left as
a future consideration.
* We will _need_ to provide a commandline tool to list windows and their IDs &
names. We're thinking a list of windows, their IDs, names, PIDs, and the title
of the window.
Currently we're stuck with `wt.exe` which is a GUI application, and cannot
print to the console. Our need is now fairly high for the ability to print
info to the console. To remedy this, we'll need to ship another helper exe as
a commandline tool for working with the terminal. The design for this is left
for the future.
## Footnotes
<a name="footnote-1"><a>[1]: While tear-out is a separate track of work from
session management in general, this setting could be implemented along with this
set of features, and later used to control tear out as well.
<a name="footnote-2"><a>[2]: Since we're reserving the keyword `new` to mean "a
new window", then we could also reserve `last` or `current` as an alias for "the
current window".
<a name="footnote-3"><a>[3]: We currently have two actions for renaming _tabs_
in the Terminal: `renameTab(name)`, and `openTabRenamer()`. We will likely
similarly need `nameWindow(name)` and `openWindowNamer()`. `openWindowNamer`
could display a dialog to allow the user to rename the current window at
runtime.
## Resources
* [Tab Tear-out in the community toolkit] - this document proved invaluable to
the background of tearing a tab out of an application to create a new window.
<!-- Footnotes -->
[#5000]: https://github.com/microsoft/terminal/issues/5000
[#1256]: https://github.com/microsoft/terminal/issues/1256
[#4472]: https://github.com/microsoft/terminal/issues/4472
[#2227]: https://github.com/microsoft/terminal/issues/2227
[#653]: https://github.com/microsoft/terminal/issues/653
[#1032]: https://github.com/microsoft/terminal/issues/1032
[#632]: https://github.com/microsoft/terminal/issues/632
[#492]: https://github.com/microsoft/terminal/issues/492
[#4000]: https://github.com/microsoft/terminal/issues/4000
[#7972]: https://github.com/microsoft/terminal/pull/7972
[#961]: https://github.com/microsoft/terminal/issues/961
[`30b8335`]: https://github.com/microsoft/terminal/commit/30b833547928d6dcbf88d49df0dbd5b3f6a7c879
[Tab Tear-out in the community toolkit]: https://github.com/windows-toolkit/Sample-TabView-TearOff
[Quake mode scenarios]: https://github.com/microsoft/terminal/issues/653#issuecomment-661370107
[`ISwapChainPanelNative2::SetSwapChainHandle`]: https://docs.microsoft.com/en-us/windows/win32/api/windows.ui.xaml.media.dxinterop/nf-windows-ui-xaml-media-dxinterop-iswapchainpanelnative2-setswapchainhandle
[Process Model 2.0 Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md

Binary file not shown.

Before

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 93 KiB

View File

@@ -1,95 +0,0 @@
---
author: Kayla Cinnamon @cinnamon-msft
created on: 2020-01-03
last updated: 2020-01-03
issue id: 597
---
# Tab Sizing
## Abstract
This spec outlines the tab sizing feature. This is an application-level feature that is not profile-specific (at least for now).
Global properties that encompass tab sizing:
* `tabWidthMode` (accepts pre-defined values for tab sizing behavior)
* `tabWidthMin` (can never be smaller than the icon width)
* `tabWidthMax` (can never be wider than the tab bar)
Acceptable values for `tabWidthMode`:
* [default] `equal` (all tabs are sized the same, regardless of tab title length)
* `titleLength` (width of tab contains entire tab title)
## Inspiration
Other browsers and terminals have varying tab width behavior, so we should give people options.
## Solution Design
`tabWidthMode` will be a global setting that will accept the following strings:
* `equal`
* All tabs are equal in width
* If the tab bar has filled, tabs will shrink as additional tabs are added
* Utilizes the `equal` setting from WinUI's TabView
* `titleLength`
* Tab width varies depending on title length
* Width of tab will fit the whole tab title
* Utilizes the `sizeToContent` setting from WinUI's TabView
In addition to `tabWidthMode`, the following global properties will also be available:
* `tabWidthMin`
* Accepts an integer
* Value correlates to the minimum amount of pixels the tab width can be
* If value is less than the width of the icon, the minimum width will be the width of the icon
* If value is greater than the width of the tab bar, the maximum width will be the width of the tab bar
* If not set, the tab will have the system-defined minimum width
* `tabWidthMax`
* Accepts an integer
* Value correlates to the maximum amount of pixels the tab width can be
* If value is less than the width of the icon, the minimum width will be the width of the icon
* If value is greater than the width of the tab bar, the maximum width will be the width of the tab bar
* If not set, the tab will have the system-defined maximum width
If `tabWidthMode` is set to `titleLength`, the tab widths will fall between the `tabWidthMin` and `tabWidthMax` values if they are set, depending on the length of the tab title.
If `tabWidthMode` isn't set, the default experience will be `equal`. Justification for the default experience is the results from this [twitter poll](https://twitter.com/cinnamon_msft/status/1203093459055210496).
## UI/UX Design
[This tweet](https://twitter.com/cinnamon_msft/status/1203094776117022720) displays how the `equal` and `titleLength` values behave for the `tabWidthMode` property.
## Capabilities
### Accessibility
This feature could impact accessibility if the tab title isn't stored within the metadata of the tab. If the tab width is the width of the icon, then the title isn't visible. The tab title will have to be accessible by a screen reader.
### Security
This feature will not impact security.
### Reliability
This feature will not impact reliability. It provides users with additional customization options.
### Compatibility
This feature will not break existing compatibility.
### Performance, Power, and Efficiency
## Potential Issues
This feature will not impact performance, power, nor efficiency.
## Future considerations
* Provide tab sizing options per-profile
* A `tabWidthMode` value that will evenly divide the entirety of the tab bar by the number of open tabs
* i.e. One tab will take the full width of the tab bar, two tabs will each take up half the width of the tab bar, etc.

View File

@@ -123,4 +123,4 @@ This open issue tracks the phase features of Search: https://github.com/microsof
## Resources
GitHub Issue: https://github.com/microsoft/terminal/issues/605
Github Issue: https://github.com/microsoft/terminal/issues/605

View File

@@ -1,736 +0,0 @@
---
author: Mike Griese @zadjii-msft
created on: 2021-02-23
last updated: 2021-05-13
issue id: #653
---
# Quake Mode
## Abstract
Many existing terminals support a feature whereby a user can press a keybinding
anywhere in the OS, and summon their terminal application. Oftentimes the act of
summoning this window is accompanied by a "dropdown" animation, where the window
slides in to view from the top of the screen. This global summon action is often
referred to as "quake mode", a reference to the video game Quake, who's console
slid in from the top.
This spec addresses both of the following two issues:
* "Quake Mode" ([#653])
* "Minimize to tray" ([#5727])
Readers should make sure to have read the [Process Model 2.0 Spec], for
background on Monarch and Peasant processes.
## Background
### Inspiration
For an example of the original Quake console in action, take a look at the
following video (noisy video warning): [Quake 3 sample]. Additionally, plenty of
existing terminal emulators support similar functionality:
* **Tilda** allows the user to specify different keys to summon the window on
different monitors.
* **Guake** alternatively allows the user to either summon the terminal window to
a specific monitor, or whichever monitor the mouse is on. Guake only allows
one single instance, so pressing the global hotkey always summons the same
instance.
### User Stories
The original quake mode thread (#653) is absolutely _filled_ with variations on
how users want to be able to summon their terminal windows. These include, but
are not limited to:
* **Story A** Press a hotkey anywhere to activate the single Terminal window
wherever it was
* **Story B** Press a hotkey anywhere to activate the single Terminal window _on
the current monitor_. If it wasn't previously on that monitor, move it there.
* **Story C** When the Terminal is summoned using the hotkey, have it "slide in"
from the top. Similarly, slide out on deactivate.
* **Story D** <kbd>Ctrl+1</kbd> to activate the terminal on monitor 1,
<kbd>Ctrl+2</kbd> to activate the terminal on monitor 2.
* **Story E** Variable dropdown speed
* **Story F** Minimize to tray, press a hotkey to activate the terminal window
(#5727)
* **Story G** Terminal doesn't appear in alt+tab view, press a hotkey to
activate the single terminal window / the nearest terminal window (I'm not
sure this is distinct from the above)
## Solution Design
To implement this feature, we'll add the following settings:
* a new action, named `globalSummon`.
* a new global, app setting named `minimizeToTray`
* a new global, app setting named `alwaysShowTrayIcon`
* a new action, named `quakeMode`, and a specially named `_quake` window.
### `globalSummon` Action
The `globalSummon` action will be a keybinding the user can use to summon a
Terminal window from anywhere in the OS. Various arguments to the action will
specify which window is summoned, to where, and how the window should behave on
summon.
From a technical perspective, the action will work by using the
[`RegisterHotKey`] function. This API allows us to bind a particular hotkey with
the OS. Whenever that hotkey is pressed, our window message loop will receive a
`WM_HOTKEY`. We'll use the payload of that window message to lookup the action
arguments for that hotkey. Then we'll use those arguments to control which
window is invoked, where, and how the window behaves.
Since `RegisterHotKey` can only be used to register a hotkey _once_ with the OS,
we'll need to make sure it's only ever set up by the Monarch process. We know
that there will only ever be one Monarch for the Terminal at a time, so it's the
perfect process to have the responsibility of managing the global hotkey.
The Monarch will be responsible for calling `RegisterHotKey`, and processing the
`WM_HOTKEY` messages. It will then dispatch method calls to the appropriate
window to summon it. When a Monarch dies and a new process becomes the Monarch,
the new Monarch will re-register for the hotkeys.
#### Where in the settings?
Since users may want to bind multiple keys to summon different windows, we'll
need to allow the user to specify multiple keybindings simultaneously, each with
their own set of args.
We stick all the `globalSummon`s in the actions array, like they're any other
keybinding.
However, these are not keys that are handled by the TerminalApp layer itself.
These are keys that need to be registered with the OS. So while they will be in
the normal `KeyMap`, they will need to be retrieved from that object and
manually passed to the window layer.
> A previous iteration of this spec considered placing the `globalSummon`
> actions in their own top-level array of the settings file, separate from the
> keybindings. This is no longer being considered, because it would not work for
> the case where the user has something like:
> ```json
> { "keys": "ctrl+c", "command": { "action": "globalSummon", "monitor": 1 } },
> { "keys": "ctrl+v", "command": { "action": "copy" } },
> ```
#### Which window, and where?
When looking at the list of requested scenarios, there are lots of different
ways people would like to use the global summon action. Some want the most
recent window activated, always. Others want to have one window _per monitor_.
Some would like to move the window to where the user is currently interacting
with the PC, and others want to activate the window where it already exists.
Trying to properly express all these possible configurations is complex. The
settings should be unambiguous as to what will happen when you press the
keybinding.
I believe that in order to accurately support all the variations that people
might want, we'll need two properties in the `globalSummon` action. These
properties will specify _which_ window we're summoning, and _where_ to summon
the window. To try and satisfy all these scenarios, I'm proposing the following
two arguments to the `globalSummon` action:
```json
"monitor": "any"|"toCurrent"|"toMouse"|"onCurrent"|int,
"desktop": "any"|"toCurrent"|"onCurrent"
```
The way these settings can be combined is in a table below. As an overview:
* `monitor`: This controls the monitor that the window will be summoned from/to
- `"any"`: Summon the MRU window, regardless of which monitor it's currently
on.
- `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor
with the current **foreground** window.
- `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse**
cursor is.
- `"onCurrent"`: Summon the MRU window **ALREADY ON** the current monitor.
- `int`: Summon the MRU window for the given monitor (as identified by the
"Identify" displays feature in the OS settings)
* `desktop`: This controls how the terminal should interact with virtual desktops.
- `"any"`: Leave the window on whatever desktop it's already on - we'll switch
to that desktop as we activate the window.
- > NOTE: A previous version of this spec had this enum value as `null`.
This was changed to `"any"` for parity with the `monitor` property.
- `"toCurrent"`/omitted: (_default_): Move the window **to** the current
virtual desktop
- `"onCurrent"`: Only summon the window if it's **already on** the current
virtual desktop
Neither `desktop` nor `monitor` is a required parameter - if either is omitted,
the omitted property will default to `toCurrent`.
Together, these settings interact in the following ways:
<!-- This table is formatted for viewing as rendered HTML. It's too complicated
for pure markdown, sorry. -->
<table>
<tr>
<td></td>
<th colspan=3><code>"desktop"</code></th>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<th><code>"monitor"</code></th>
<td><code>any</code><br><strong>Leave where it is</strong></td>
<td><code>"toCurrent"</code><br><strong>Move to current desktop</strong></td>
<td><code>"onCurrent"</code><br><strong>On current desktop only</strong></td>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<td><code>"any"</code><br> Summon the MRU window</td>
<td>Go to the desktop the window is on (leave position alone)</td>
<td>Move the window to this desktop (leave position alone)</td>
<td>
If there isn't one on this desktop:
* create a new one (default position)
Else:
* activate the one on this desktop (don't move it)
</td>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<td><code>"toCurrent"</code><br> Summon the MRU window TO the monitor with the foreground window</td>
<td>Go to the desktop the window is on, move to the monitor with the foreground window</td>
<td>Move the window to this desktop, move to the monitor with the foreground window</td>
<td>
If there isn't one on this desktop:
* create a new one (on the monitor with the foreground window)
Else:
* activate the one on this desktop, move to the monitor with the foreground window
</td>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<td>
<code>"toMouse"</code>
<sup><a href="#footnote-2">[2]</a></sup> <br>
Summon the MRU window TO the monitor with the mouse</td>
<td>Go to the desktop the window is on, move to the monitor with the mouse</td>
<td>Move the window to this desktop, move to the monitor with the mouse</td>
<td>
If there isn't one on this desktop:
* create a new one (on the monitor with the mouse)
Else:
* activate the one on this desktop, move to the monitor with the mouse
</td>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<td><code>"onCurrent"</code><br> Summon the MRU window for the current monitor</td>
<td>
If there is a window on this monitor on any desktop,
* Go to the desktop the window is on (leave position alone)
else
* Create a new window on this monitor & desktop
</td>
<td>
If there is a window on this monitor on any desktop,
* Move the window to this desktop (leave position alone)
else
* Create a new window on this monitor & desktop
</td>
<td>
If there isn't one on this desktop, (even if there is one on this monitor on
another desktop),
* create a new one on this monitor
Else if ( there is one on this desktop, not this monitor)
* create a new one on this monitor
Else (one on this desktop & monitor)
* Activate the one on this desktop (don't move)
</td>
</tr>
<!-- ----------------------------------------------------------------------- -->
<tr>
<td><code>int</code><br> Summon the MRU window for monitor N</td>
<td>
If there is a window on monitor N on any desktop,
* Go to the desktop the window is on (leave position alone)
else
* Create a new window on this monitor & desktop
</td>
<td>
If there is a window on monitor N on any desktop,
* Move the window to this desktop (leave position alone)
else
* Create a new window on this monitor & desktop
</td>
<td>
If there isn't one on this desktop, (even if there is one on monitor N on
another desktop),
* create a new one on monitor N
Else if ( there is one on this desktop, not monitor N)
* create a new one on monitor N
Else (one on this desktop & monitor N)
* Activate the one on this desktop (don't move)
</td>
</tr>
</table>
##### Stories, revisited
With the above settings, let's re-examine the original user stories, and see how
they fit into the above settings. (_Stories that are omitted aren't relevant to
the discussion of these settings_)
> When the `desktop` param is omitted below, that can be interpreted as "any
> `desktop` value will make sense here"
* **Story A** Press a hotkey anywhere to activate the single Terminal window
wherever it was
- This is `{ "monitor": "any", "desktop": "any" }`
* **Story B** Press a hotkey anywhere to activate the single Terminal window _on
the current monitor_. If it wasn't previously on that monitor, move it there.
- This is `{ "monitor": "toCurrent" }`
* **Story D** <kbd>Ctrl+1</kbd> to activate the terminal on monitor 1,
<kbd>Ctrl+2</kbd> to activate the terminal on monitor 2.
- This is `[ { "keys": "ctrl+1", monitor": 1 }, { "keys": "ctrl+2", monitor": 2 } ]`
As some additional examples:
```json
// Go to the MRU window, wherever it is
{ "keys": "win+1", "command":{ "action":"globalSummon", "monitor":"any", "desktop": "any" } },
// activate the MRU window, and move it to this desktop & this monitor
{ "keys": "win+2", "command":{ "action":"globalSummon", "monitor":"toCurrent", "desktop": "toCurrent" } },
// Since "toCurrent" & "toCurrent" are the default values, just placing a single
// entry here will bind the same behavior:
{ "keys": "win+2", "command": "globalSummon" },
// activate the MRU window on this desktop
{ "keys": "win+3", "command":{ "action":"globalSummon", "monitor":"any", "desktop": "onCurrent" } },
// Activate the MRU window on monitor 2 (from any desktop), and place it on the
// current desktop. If there isn't one on monitor 2, make a new one.
{ "keys": "win+4", "command":{ "action":"globalSummon", "monitor": 2, "desktop": "toCurrent" } },
// Activate the MRU window on monitor 3 (ONLY THIS desktop), or make a new one.
{ "keys": "win+5", "command":{ "action":"globalSummon", "monitor": 3, "desktop": "onCurrent" } },
// Activate the MRU window on this monitor (from any desktop), and place it on
// the current desktop. If there isn't one on this monitor, make a new one.
{ "keys": "win+6", "command":{ "action":"globalSummon", "monitor": "onCurrent", "desktop": "toCurrent" } },
```
#### Summoning a specific window
What if you want to press a keybinding to always summon a specific, named
window? This window might not be the most recent terminal window, nor one that
would be selected by the `monitor` and `desktop` selectors. You could name a
window "Epona", and press `win+e` to always summon the "Epona" window.
We'll add the following property to address this scenario
* `"window": string|int`
- When omitted (_default_): Use monitor and desktop to find the appropriate
MRU window to summon.
- When provided: Always summon the window who's name or ID matches the given
`window` value. If no such window exists, then create a new window with that
name/id.
When provided _with_ `monitor` and `desktop`, `window` behaves in the following
ways:
* `desktop`
- `"any"`: Go to the desktop the given window is already on.
- `"toCurrent"`: If the window is on another virtual desktop, then move it to
the currently active one.
- `"onCurrent"`: If the window is on another virtual desktop, then move it to
the currently active one.
* `monitor`
- `"any"`: Leave the window on the monitor it is already on.
- `"toCurrent"`: If the window is on another monitor, then move it to the
currently active one.
- `"onCurrent"`: If the window is on another monitor, then move it to the
currently active one.
- `<int>`: If the window is on another monitor, then move it to the specified
monitor.
> NOTE: You read that right, `onCurrent` and `toCurrent` both do the same thing
> when `window` is provided. They both already know which window to select, the
> context of moving to the "current" monitor is all that those parameters add.
#### Other properties
Some users would like the terminal to just appear when the global hotkey is
pressed. Others would like the true quake-like experience, where the terminal
window "slides-in" from the top of the monitor. Furthermore, some users would
like to configure the speed at which that dropdown happens. To support this
functionality, the `globalSummon` action will support the following property:
* `"dropdownDuration": float`
- When omitted, `0`, or a negative number: No animation is used
when summoning the window. The summoned window is focused immediately where
it is.
- When a positive number is provided, the terminal will use that value as a
duration (in seconds) to slide the terminal into position when activated.
- The default would be some sensible value. The pane animation is .2s, so
`0.2` might be a reasonable default here.
We could have alternatively provided a `"dropdownSpeed"` setting, that provided
a number of pixels per second. In my opinion, that would be harder for users to
use correctly. I believe that it's easier for users to mentally picture "I'd
like the dropdown to last 100ms" vs "My monitor is 1504px tall, so I need to set
this to 15040 to make the window traverse the entire display in .1s"
> NOTE: `dropdownDuration` will be ignored when the user has animations disabled
> in the OS. In that case, the terminal will just appear, as if it was set to 0.
Some users might want to be able to use the global hotkey to hide the window
when the window is already visible. This would let the hotkey act as a sort of
global toggle for the Terminal window. Others might not like that behavior, and
just want the action to always bring the Terminal into focus, and do nothing if
the terminal is already focused. To facilitate both these use cases, we'll add
the following property:
* `"toggleVisibility": bool`
- When `true`: (_default_) When this hotkey is pressed, and the terminal
window is currently active, minimize the window.
- When `dropdownDuration` is not `0`, then the window will slide back off
the top at the same speed as it would come down.
- When `false`: When this hotkey is pressed, and the terminal window is
currently active, do nothing.
### Quake Mode
In addition to just summoning the window from anywhere, some terminals also
support a special "quake mode" buffer or window. This window is one that closely
emulates the console from quake:
* It's docked to the top of the screen
* It takes the full width of the monitor, and only the bottom can be resized
* It often doesn't have any other UI elements, like tabs
For fun, we'll also be adding a special `"_quake"` window with the same
behavior. If the user names a window `_quake`, then it will behave in the
following special ways:
* On launch, it will ignore the `initialPosition` and
`initialRows`/`initialCols` setting, and instead resize to the top half of the
monitor.
* On launch, it will ignore the `launchMode` setting, and always launch in focus
mode.
- Users can disable focus mode on the `_quake` window if they do want tabs.
* It will not be resizable from any side except the bottom of the window, nor
will it be drag-able.
* It will not be a valid target for the "most recent window" for window
glomming. If it's the only open window, with `"windowingBehavior":
"useExisting*"`, then a new window will be created instead.
- It _is_ still a valid target for something like `wt -w _quake new-tab`
A window at runtime can be renamed to become the `_quake` window (if no other
`_quake` window exists). When it does, it will resize to the position of the
quake window, and enter focus mode.
We'll also be adding a special action `quakeMode`. This action is a special case
of the `globalSummon` action, to specifically invoke the quake window in the
current place. It is basically the same thing as the more elaborate:
```json
{
"monitor": "toCurrent",
"desktop": "toCurrent",
"window": "_quake",
"toggleVisibility": true,
"dropdownDuration": 0.5
},
```
### Minimize to Tray
Many users have requested that the terminal additionally supports minimizing the
window "to the tray icon". This is a bit like when you close the Teams window,
but Teams is actually still running in the system tray, or the "notification
area".
![The Teams tray icon](tray-icon-000.png)
_fig 1: an example of the Teams tray icon in the notification area_.
When users want to be able to "minimize to the tray", they want:
* The window to no longer appear on the taskbar
* The window to no longer appear in the alt-tab order
When minimized to the tray, it's almost as if there's no window for the Terminal
at all. This can be combined with the global hotkey (or the tray icon's context
menu) to quickly restore the window.
The tray icon could be used for a variety of purposes. As a simple start, we
could include the following three options:
```
Focus Terminal
---
Windows > Window 1 - <un-named window>
Window 2 - "This-window-does-have-a-name"
---
Quit
```
Just clicking on the icon would summon the recent terminal window. Right
clicking would show the menu with "Focus Terminal", "Windows" and "Quit" in it, and
"Windows" would have nested entries for each Terminal window.
* "Focus Terminal" would do just that - summon the most recent terminal window,
wherever it is.
* "Windows" would have nested popups for each open Terminal window. Each of
these nested entries would display the name and ID of the window. Clicking
them would summon that window (wherever it may be)
* "Quit" would be akin to quit in browsers - close all open windows
<sup>[[1]](#footnote-1)</sup>.
The tray notification would be visible always when the user has
`"minimizeToTray": true` set in their settings. If the user has that set to
false, but would still like the tray, they can specify `"alwaysShowTrayIcon":
true`. That will cause the tray icon to always be added to the system tray.
There's not a combination of settings where the Terminal is "minimized to the
tray", and there's _no tray icon visible_. We don't want to let users get into a
state where the Terminal is running, but is totally hidden from their control.
From a technical standpoint, the tray icon is managed similar to the global
hotkey. The Monarch process is responsible for setting it up, and processing the
messages. When a Monarch dies and a new process becomes the Monarch, then it
will re-create the tray icon.
## UI/UX Design
To summarize, we're proposing the following set of settings:
```jsonc
{
"minimizeToTray": bool,
"alwaysShowTrayIcon": bool,
"actions": [
{
"keys": KeyChord,
"command": {
"action": "globalSummon",
"dropdownDuration": float,
"toggleVisibility": bool,
"monitor": "any"|"toCurrent"|"onCurrent"|int,
"desktop": "any"|"toCurrent"|"onCurrent"
}
},
{
"keys": KeyChord,
"command": {
"action": "quakeMode"
}
}
]
}
```
## Potential Issues
<table>
<tr>
<td><strong>Compatibility</strong></td>
<td>
As part of this set of changes, we'll also be allowing the <kbd>Win</kbd> key in
keybindings. Generally, the OS reserves the Windows key for its own shortcuts.
For example, <kbd>Win+R</kbd> for the run dialog, <kbd>Win+A</kbd> for the
Action Center, <kbd>Win+V</kbd> for the cloud clipboard, etc. Users will now be
able to use the win key themselves, but they should be aware that the OS has
"first dibs" on any hotkeys involving the Windows key.
</td>
</tr>
<tr>
<td><strong>Mixed elevation</strong></td>
<td>
Only one app at a time gets to register for global hotkeys. However, from the
Terminal's perspective, unelevated and elevated windows will act like different
apps. Each privilege level has its own Monarch. The two are unable to
communicate across the elevation boundary.
This means that if the user often runs terminals in both contexts, then only one
will have the global hotkeys bound. The naive implementation would have the
first elevation level "win" the keybindings.
A different option would be to have elevated windows not register global hotkeys
_at all_. I don't believe that there's any sort of security implication for
having a global hotkey for an elevated window.
A third option would be to have some sort of `"whenElevated": bool?` property
for global hotkeys. This would explicitly enable a given hotkey for unelevated
vs elevated windows.
* `"whenElevated": null`: behave as normal - the first context level to run wins
* `"whenElevated": true`: only register the hotkey when running elevated
* `"whenElevated": false`: only register the hotkey when running unelevated
</td>
</tr>
<tr>
<td><strong>OneCore / Windows 10X</strong></td>
<td>
I'm fairly certain that none of these APIs would work on Windows 10X at all.
These features would have to initially be disabled in a pure UWP version of the
Terminal, until we could find workarounds. Since the window layer is the one
responsible for the management of the hotkeys and the tray icon, we're not too
worried about this.
</td>
</tr>
</table>
* If there are any other applications running that have already registered
hotkeys with `RegisterHotKey`, then it's possible that the Terminal's attempt
to register that hotkey will fail. If that should happen, then we should
display a warning dialog to the user indicating which hotkey will not work
(because it's already used for something else).
* Which is the "current" monitor? The one with the mouse or the one with the
active window? This isn't something that has an obvious answer. Guake
implements this feature where the "current monitor" is the one with the mouse
on it. At least for the first iterations of this action, that's what we'll
use.
`monitor: onCurrent|onCurrentWindow|toCurrent|<int>`
* Currently, running both the Release and Preview versions of the Terminal at
the same time side-by-side is not generally supported. (For example, `wt.exe`
can only ever point at one of two.) If a user binds the same key to a
`globalSummon` or `quakeMode` action, then only one of the apps will actually
be able to successfully claim the global hotkey.
## Implementation plan
Currently, in [`dev/migrie/f/653-QUAKE-MODE`], I have some sample rudimentary
code to implement quake mode support. It allows for only a single global hotkey
that summons the MRU window, without dropdown. That would be a good place for
anyone starting to work on this feature. From there, I imagine the following
work would be needed:
* [ ] Add a `globalSummon` action. `AppHost` would need to be able to get _all_
of these actions, and register all of them. Each one would need to be assigned
a unique ID, so `WM_HOTKEY` can identify which hotkey was pressed.
- This could be committed without any other args to the `globalHotkeys`. In
this initial version, the behavior would be summoning the MRU window,
where it is, no dropdown, to start with. From there, we'd add the
remaining properties:
* [ ] Add support for the `toggleVisibility` property
* [ ] Add support for the `desktop` property to control how window summoning
interacts with virtual desktops
* [ ] Add support for the `monitor` which monitor the window appears on.
* [ ] Add support for the `dropdownDuration` property
* [ ] Add the `minimizeToTray` setting, and implement it without any sort of flyout
* [ ] Add a list of windows to the right-click flyout on the tray icon
* [ ] Add support for the `alwaysShowTrayIcon` setting
* [ ] When the user creates a window named `_quake`, ignore the initial size,
position, and launch mode, and create the window in quake mode instead.
* [ ] Exempt the `_quake` window from window glomming
* [ ] Add the `quakeMode` action, which `globalSummon`'s the `_quake` window.
* [ ] Prevent the `_quake` window from being dragged or resized on the
top/left/right.
### Future Considerations
I don't believe there are any other tracked requests that are planned that
aren't already included in this spec.
* Should the tray icon's list of windows include window titles? Both the name
and title? Maybe something like `({name}|{id}): {title}`? I'd bet that most
people don't end up naming their windows.
* Dropdown duration could be a `float|bool`, with `true`->(whatever the default
is), `false`->0.
- We could have the setting appear as a pair of radio buttons, with the first
disabling dropdown, and the second enabling a text box for inputting an
animation duration.
* It might be an interesting idea to have the ability to dock the quake window
to a specific side of the monitor, not just the top. We could probably do that
with a global setting `"quakeModeDockSide": "top"|"left"|"bottom"|"right"` or
something like that.
* We might want to pre-load the quake window into the tray icon as an entry for
"Quake Mode", and otherwise exclude it from the list of windows in that menu.
* We might think of other things for the Quake Mode window in the future - this
spec is by no means comprehensive. For example, it might make sense for the
quake mode window to automatically open in "always on top" mode.
* It was suggested that the quake mode window could auto-hide when it loses
focus. That's a really neat idea, but we're a little worried about the
implementation. What happens when the IME window gets focus? Or the Start
Menu? Would those end up causing the quake window to prematurely minimize
itself? For that reason, we're leaving this as a future consideration.
* Perhaps there could be a top-level object in the settings like
```json
{
"quakeMode": {
"hideOnFocusLost": true,
"useFocusMode": false,
"profile": "my quake mode profile" ,
"quakeModeDockSide": "bottom"
}
}
```
That would allow the user some further customizations on the quake mode
behaviors.
- This was later converted to the idea in [#9992] - Add per-window-name global
settings
* Another proposed idea was a simplification of some of the summoning modes. `{
"monitor": "any", "desktop": "any" }` is a little long, and maybe not the most
apparent naming. Perhaps we could add another property like `summonMode` that
would act like an alias for a `monitor`, `desktop` combo.
- `"summonMode": "activateInMyFace"`: `{ "monitor": "toCurrent", "desktop": "toCurrent" }`
- `"summonMode": "activateWherever"`: `{ "monitor": "any", "desktop": "any" }`
## Resources
Docs on adding a system tray item:
* https://docs.microsoft.com/en-us/windows/win32/shell/notification-area
* https://www.codeproject.com/Articles/18783/Example-of-a-SysTray-App-in-Win32
Docs regarding hiding a window from the taskbar:
* https://docs.microsoft.com/en-us/previous-versions//bb776822(v=vs.85)#managing-taskbar-buttons
### Footnotes
<a name="footnote-1"><a>[1]: Quitting the terminal is different than closing the
windows one-by-one. Quiting implies an atomic action, for closing all the
windows. Once [#766] lands, this will give us a chance to persist the state of
_all_ open windows. This will allow us to re-open with all the user's windows,
not just the one that happened to be closed last.
<a name="footnote-2"><a>[2]: **Addenda, May 2021**: In the course of
implementation, it became apparent that there's an important UX difference
between summoning _to the monitor with the cursor_ vs _to the monitor with the
foreground window_. `"monitor": "toMouse"` was added as an option, to allow the
user to differentiate between the two behaviors.
[#653]: https://github.com/microsoft/terminal/issues/653
[#766]: https://github.com/microsoft/terminal/issues/766
[#5727]: https://github.com/microsoft/terminal/issues/5727
[#9992]: https://github.com/microsoft/terminal/issues/9992
[Process Model 2.0 Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md
[Quake 3 sample]: https://youtu.be/ZmR6HQbuHPA?t=27
[`RegisterHotKey`]: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey
[`dev/migrie/f/653-QUAKE-MODE`]: https://github.com/microsoft/terminal/tree/dev/migrie/f/653-QUAKE-MODE

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

View File

@@ -1,99 +0,0 @@
---
author: Dustin Howett @DHowett
created on: 2020-10-19
last updated: 2020-11-18
issue id: #8324
---
# Application State (in the Terminal Settings Model)
## Abstract
Terminal is going to need a place to store application "state", including:
* Dialogs the user has chosen to hide with a `[ ] Do not ask again` checkbox, as proposed in [issue 6641]
* Which dynamic profiles have been generated, as a way to resolve [user dissatisfaction] around profiles "coming back"
* On-screen position of the window, active session state, layout, etc. for [eventual restoration]
This specification provides for a place to store these things.
## Inspiration
Many other applications store cross-session state somewhere.
## Solution Design
It is the author's opinion that the above-mentioned settings are inappropriate for storage in the user's settings.json;
they do not need to be propagated immediately to other instances of Windows Terminal, they are not intended to be
edited, and storing them outside of settings.json defers the risk inherent in patching the user's settings file.
Therefore, this document proposes that a separate application state archive (`state.json`) be stored next to
`settings.json`.
It would be accessed by way of an API hosted in the `Microsoft.Terminal.Settings` namespace.
```idl
namespace Microsoft.Terminal.Settings {
[default_interface]
runtimeclass ApplicationState {
// GetForCurrentApplication will return an object deserialized from state.json.
static ApplicationState GetForCurrentApplication();
void Clear();
IVector<guid> GeneratedProfiles;
Boolean ShowCloseOnExitWarning;
// ... further settings ...
}
}
```
> 📝 The sole motivation for exposing this from Microsoft.Terminal.Settings is to concentrate JSON de-/serialization in one
place.
Of note: there is no explicit `Save` or `Commit` mechanism. Changes to the application state are committed durably a
short duration after they're made.
## UI/UX Design
This has no direct impact on the UI/UX; however, we may want to add a button to general settings page titled "reset all
dialogs" or "don't not ask me again about those things that, some time ago, I told you to not ask me about".
We do not intend this file to be edited by hand, so it does not have to be user-friendly or serialized with indentation.
## Capabilities
### Accessibility
It is not expected that this proposal will impact accessibility.
### Security
It is not expected that this proposal will impact security, as it uses our _existing_ JSON parser in a new place.
### Reliability
[comment]: # Will the proposed change improve reliability? If not, why make the change?
The comment in this section heavily suggests that we should only make changes that improve reliability, not ones that
maintain it.
### Compatibility
Some users who were expecting profiles to keep coming back after they delete them will need to adjust their behavior.
### Performance, Power, and Efficiency
## Potential Issues
Another file on disk is another file users might edit. We'll need to throw out the entire application state payload if
it's been damaged, instead of trying to salvage it, so that we more often "do the right thing."
## Future considerations
This will allow us to implement a number of the features mentioned at the head of this document.
## Resources
[issue 6641]: https://github.com/microsoft/terminal/issues/6641
[user dissatisfaction]: https://github.com/microsoft/terminal/issues/3231
[eventual restoration]: https://github.com/microsoft/terminal/issues/961

View File

@@ -1,344 +0,0 @@
---
author: Carlos Zamora @carlos-zamora
created on: 2021-03-12
last updated: 2021-03-17
issue id: [#885]
---
# Actions in the Settings Model
## Abstract
This spec proposes a refactor of how Windows Terminal actions are stored in the settings model.
The new representation would mainly allow the serialization and deserialization of commands and keybindings.
## Inspiration
A major component that is missing from the Settings UI is the representation of keybindings and commands.
The JSON represents both of these as a combined entry as follows:
```js
{ "icon": "path/to/icon.png", "name": "Copy the selected text", "command": "copy", "keys": "ctrl+c" },
```
In the example above, the copy action is...
- bound to <kbd>ctrl+c</kbd>
- presented as "Copy the selected text" with the "path/to/icon.png" icon
However, at the time of writing this spec, the settings model represents it as...
- (key binding) a `KeyChord` to `ActionAndArgs` entry in a `KeyMapping`
- (command) a `Command` with an associated icon, name, and action (`ActionAndArgs`)
This introduces the following issues:
1. Serialization
- We have no way of knowing when a command and a key binding point to the same action. Thus, we don't
know when to write a "name" to the json.
- We also don't know if the name was auto-generated or set by the user. This can make the JSON much more bloated by
actions with names that would normally be autogenerated.
2. Handling Duplicates
- The same action can be bound to multiple key chords. The command palette combines all of these actions into one entry
because they have the same name. In reality, this same action is just being referenced in different ways.
## Solution Design
I propose that the issues stated above be handled via the following approach.
### Step 1: Consolidating actions
`Command` will be updated to look like the following:
```c++
runtimeclass Command
{
// The path to the icon (or icon itself, if it's an emoji)
String IconPath;
// The associated name. If none is defined, one is auto-generated.
String Name;
// The key binding that can be used to invoke this action.
// NOTE: We're actually holding the KeyChord instead of just the text.
// KeyChordText just serializes the relevant keychord
Microsoft.Terminal.Control.KeyChord Keys;
String KeyChordText;
// The action itself.
ActionAndArgs ActionAndArgs;
// NOTE: nested and iterable command logic will still be here,
// But they are omitted to make this section seem cleaner.
// Future Considerations:
// - [#6899]: Action IDs --> add an identifier here
}
```
The goal here is to consolidate key binding actions and command palette actions into a single class.
This will also require the following supplemental changes:
- `Command::LayerJson`
- This must combine the logic of `KeyMapping::LayerJson` and `Command::LayerJson`.
- Key Chord data
- Internally, store a `vector<KeyChord> _keyMappings` to keep track of all the key chords associated with this action.
- `RegisterKey` and `EraseKey` update `_keyMappings`, and ensure that the latest key registered is at the end of the list.
- `Keys()` simply returns the last entry of `_keyMappings`, which is the latest key chord this action is bound to.
- `KeyChordText())` is exposed to pass the text directly to the command palette.
This depends on `Keys` and, thus, propagate changes automatically.
- Observable properties
- `Command` has observable properties today, but does not need them because `Command` will never change while the app is running.
- Nested and iterable commands
- `HasNestedCommands`, `NestedCommands{ get; }`, `IterateOn` will continue to be exposed.
- A setter for these customizations will not be exposed until we find it necessary (i.e. adding support for customizing it in the Settings UI)
- Command expansion can continue to be exposed here to reduce implementation cost.
- An additional `IsNestedCommand` is necessary to record a case where a nested command is being unbound `{ "commands": null, "name": "foo" }`.
Overall, the `Command` class is simply being promoted to include the `KeyChord` it has.
This allows the implementation cost of this step to be relatively small.
Completion of this step should only cause relatively minor changes to anything that depends on `Command`, because
it is largely the same class. However, key bindings will largely be impacted because we represent key bindings as
a map of `KeyChord`s to `ActionAndArgs`. This leads us to step 2 of this process.
### Step 2: Querying actions
Key bindings and commands are deserialized by basically storing individual actions to a map.
- `KeyMapping` is basically an `IMap<KeyChord, ActionAndArgs>` with a few extra functions. In fact, it actually
stores key binding data to a `std::map<KeyChord, ActionAndArgs>` and directly interacts with it.
- `Command::LayerJson` populates an `IMap<String, Command>` during deserialization as it iterates over every action.
Note that `Command` can be interpreted as a wrapper for `ActionAndArgs` with more stuff here.
It makes sense to store these actions as maps. So, following step 1 above, we can also store and expose actions
something like the following:
```c++
runtimeclass ActionMap
{
ActionAndArgs GetActionByKeyChord(KeyChord keys);
KeyChord GetKeyBindingForAction(ShortcutAction action);
KeyChord GetKeyBindingForAction(ShortcutAction action, IActionArgs actionArgs);
IMapView<String, Command> NameMap { get; };
// Future Considerations:
// - [#6899]: Action IDs --> GetActionByID()
}
```
The getters will return null if a matching action or key chord is not found. Since iterable commands need to be expanded at in TerminalApp, we'll just expose `NameMap`, then let TerminalApp perform the expansion as they do now. Internally, we can store the actions as follows:
```c++
std::map<KeyChord, InternalActionID> _KeyMap;
std::map<InternalActionID, Command> _ActionMap;
```
`InternalActionID` will be a hash of `ActionAndArgs` such that two `ActionAndArgs` with the same `ShortcutAction` and `IActionArgs` output the same hash value.
`GetActionByKeyChord` will use `_KeyMap` to find the `InternalActionID`, then use the `_ActionMap` to find the bound `Command`.
`GetKeyBindingForAction` will hash the provided `ActionAndArgs` (constructed by the given parameters) and check `_ActionMap` for the given `InternalActionID`.
`NameMap` will need to ensure every action in `_ActionMap` is added to the output name map if it has an associated name. This is done by simply iterating over `_ActionMap`. Nested commands must be added separately because they cannot be hashed.
`ActionMap` will have an `AddAction(Command cmd)` that will update the internal state whenever a command is registered. If the given command is valid, we will check for collisions and resolve them. Otherwise, we will consider this an "unbound" action and update the internal state normally. It is important that we don't handle "unbound" actions differently because this ensures that we are explicitly unbinding a key chord.
### Step 3: Settings UI needs
After the former two steps are completed, the new representation of actions in the settings model is now on-par with
what we have today. In order to bind these new actions to the Settings UI, we need the following:
1. Exposing the maps
- `ActionMap::KeyBindings` and `ActionMap::Commands` may need to be added to pass the full list of actions to the Settings UI.
- In doing this, we can already update the Settings UI to include a better view of our actions.
2. Creating a copy of the settings model
- The Settings UI operates by binding the XAML controls to a copy of the settings model.
- Copying the `ActionMap` is fairly simple. Just copy the internal state and ensure that `Command::Copy` is called such that no reference to the original WinRT objects persist. Since we are using `InternalActionID`, we will not have to worry about multiple `Command` references existing within the same `ActionMap`.
3. Modifying the `Command`s
- `ActionMap` must be responsible for changing `Command`s so that we can ensure `ActionMap` always has a correct internal state:
- It is important that `Command` only exposes getters (not setters) to ensure `ActionMap` is up to date.
- If a key chord is being changed, update the `_KeyMap` and the `Command` itself.
- If a key binding is being deleted, add an unbound action to the given key chord.
- This is similar to how color schemes are maintained today.
- In the event that name/key-chord is set to something that's already taken, we need to propagate those changes to
the rest of `ActionMap`. As we do with the JSON, we respect the last name/key-chord set by the user. See [Modifying Actions](#modifying-actions)
in potential issues.
- For the purposes of the key bindings page, we will introduce a `KeyBindingViewModel` to serve as an intermediator between the settings UI and the settings model. The view model will be responsible for things like...
- exposing relevant information to the UI controls
- converting UI control interactions into proper API calls to the settings model
4. Serialization
- `Command::ToJson()` and `ActionMap::ToJson()` should perform most of the work for us. Simply iterate over the `_ActionMap` and call `Command::ToJson` on each action.
- See [Unbinding actions](#unbinding-actions) in potential issues.
## UI/UX Design
N/A
## Capabilities
N/A
### Accessibility
N/A
### Security
N/A
### Reliability
N/A
### Compatibility
N/A
### Performance, Power, and Efficiency
## Potential Issues
### Layering Actions
We need a way to determine where an action came from to minimize how many actions we serialize when we
write to disk. This is a two part approach that happens as we're loading the settings
1. Load defaults.json
- For each of the actions in the JSON...
- Construct the `Command` (basically the `Command::LayerJson` we have today)
- Add it to the `ActionMap`
- this should update the internal state of `ActionMap` appropriately
- if the newly added key chord conflicts with a pre-existing one,
redirect `_KeyMap` to the newly added `Command` instead,
and update the conflicting one.
2. Load settings.json
- Create a child for the `ActionMap`
- The purpose of a parent is to continue a search when the current `ActionMap` can't find a `Command` for a query. The parent is intended to be immutable.
- Load the actions array like normal into the child (see step 1)
Introducing a parent mechanism to `ActionMap` allows it to understand where a `Command` came from. This allows us to minimize the number of actions we serialize when we write to disk, as opposed to serializing the entire list of actions.
`ActionMap` queries will need to check their parent when they cannot find a matching `InternalActionID` in their `_ActionMap`.
Since `NameMap` is generated upon request, we will need to use a `std::set<InternalActionID>` as we generate the `NameMap`. This will ensure that each `Command` is only added to the `NameMap` once. The name map will be generated as follows:
1. Get an accumulated list of `Command`s from our parents
2. Iterate over the list...
- Update `NameMap` with any new `Command`s (tracked by the `std::set<InternalActionID>`)
Nested commands will be saved to their own map since they do not have an `InternalActionID`.
- During `ActionMap`'s population, we must ensure to resolve any conflicts immediately. This means that any new `Command`s that generate a name conflicting with a nested command will take priority (and we'll remove the nested command from its own map). Conversely, if a new nested command conflicts with an existing standard `Command`, we can ignore it because our generation of `NameMap` will handle it.
- When populating `NameMap`, we must first add all of the standard `Command`s. To ensure layering is accomplished correctly, we will need to start from the top-most parent and update `NameMap`. As we go down the inheritance tree, any conflicts are resolved by prioritizing the current layer (the child). This ensures that the current layer takes priority.
- After adding all of the standard `Command`s to the `NameMap`, we can then register all of the nested commands. Since nested commands have no identifier other than a name, we cannot use the `InternalActionID` heuristic. However, as mentioned earlier, we are updating our internal nested command map as we add new actions. So when we are generating the name map, we can assume that all of these nested commands now have priority. Thus, we simply add all of these nested commands to the name map. Any conflicts are resolved in favor of th nested command.
### Modifying Actions
There are several ways a command can be modified:
- change/remove the key chord
- change the name
- change the icon
- change the action
It is important that these modifications are done through `ActionMap` instead of `Command`.
This is to ensure that the `ActionMap` is always aligned with `Command`'s values. `Command` should only expose getters in the projected type to enforce this. Thus, we can add the following functions to `ActionMap`:
```c++
runtimeclass ActionMap
{
void SetKeyChord(Command cmd, KeyChord keys);
void SetName(Command cmd, String name);
void SetIcon(Command cmd, String iconPath);
void SetAction(Command cmd, ShortcutAction action, IActionArgs actionArgs);
}
```
`SetKeyChord` will need to make sure to modify the `_KeyMap` and the provided `Command`.
If the new key chord was already taken, we also need to update the conflicting `Command`
and remove its key chord.
`SetName` will need to make sure to modify the `Command` in `_ActionMap` and regenerate `NameMap`.
`SetIcon` will only need to modify the provided `Command`. We can choose to not expose this in the `ActionMap`, but doing so makes the API consistent.
`SetAction` will need to begin by updating the provided `Command`'s `ActionAndArgs`.
If the generated name is being used, the name will need to be updated. `_ActionMap` will need to be updated with a new `InternalActionID` for the new action. This is a major operation and so all views exposed will need to be regenerated.
Regarding [Layering Actions](#layering-actions), if the `Command` does not exist in the current layer,
but exists in a parent layer, we need to...
0. check if it exists
- use the hash `InternalActionID` to see if it exists in the current layer
- if it doesn't (which is the case we're trying to solve here), call `_GetActionByID(InternalActionID)` to retrieve the `Command` wherever it may be. This helper function simply checks the current layer, if none is found, it recursively checks its parents until a match is found.
1. duplicate it with `Command::Copy`
2. store the duplicate in the current layer
- `ActionMap::AddAction(duplicate)`
3. make the modification to the duplicate
This ensures that the change persists post-serialization.
TerminalApp has no reason to ever call these setters. To ensure that relationship, we will introduce an `IActionMapView` interface that will only expose `ActionMap` query functions. Conversely, `ActionMap` will be exposed to the TerminalSettingsEditor to allow for modifications.
### Unbinding actions
Removing a name is currently omitted from this spec because there
is no Settings UI use case for it at the moment. This scenario is
designed for Command Palette customization.
The only kind of unbinding currently in scope is freeing a key chord such that
no action is executed on that key stroke. To do this, simply `ActionMap::AddAction` a `Command` with...
- `ActionAndArgs`: `ShortcutAction = Invalid` and `IActionArgs = nullptr`
- `Keys` being the provided key chord
In explicitly storing an "unbound" action, we are explicitly saying that this key chord
must be passed through and this string must be removed from the command palette. `AddAction` automatically handles updating the internal state of `ActionMap` and any conflicting `Commands`.
This allows us to output something like this in the JSON:
```js
{ "command": "unbound", "keys": "ctrl+c" }
```
### Consolidated Actions
`AddAction` must be a bit smarter when it comes to the following scenario:
- Given a command that unbinds a key chord: `{ "command": "unbound", "keys": "ctrl+c" }`
- And... that key chord was set in a parent layer `{ "command": "copy", "keys": "ctrl+c" }`
- But... the action has another key chord from a parent layer `{ "command": "copy", "keys": "ctrl+shift+c" }`
`_ActionMap` does not contain any information about a parent layer; it only contains actions introduced in the current layer. Thus, in the scenario above, unbinding `ctrl+c` is what is relevant to `_ActionMap`. However, this may cause some complications for `GetKeyChordForAction`. We cannot simply check our internal `_ActionMap`, because the primary key chord in the entry may be incorrect. Again, this is because `_ActionMap` is only aware of what was bound in the current layer.
To get around this issue, we've introduced `_ConsolidatedActions`. In a way, `_ConsolidatedActions` is similar to `_ActionMap`, except that it consolidates the `Command` data into one entry constructed across the current layer and the parent layers. Specifically, in the scenario above, `_ActionMap` will say that `copy` has no key chords. In fact, `_ActionMap` has no reason to have `copy` at all, because it was not introduced in this layer. Conversely, `_ConsolidatedActions` holds `copy` with a `ctrl+shift+c` binding, which is then returned to `GetKeyChordForAction`.
To maintain `_ConsolidatedActions`, any new action added to the Action Map must also update `_ConsolidatedActions`. It is especially important to handle and propagate collisions to `_ConsolidatedActions`.
When querying Action Map for an ID, we should always check in the following order:
- `_ConsolidatedActions`
- `_ActionMap`
- repeat this process for each parent
This is to ensure that we are returning the correct and wholistic view of a `Command` on a query. Rather than acquiring a `Command` constructed in this layer, we receive one that contains all of the data acquired across the entire Action Map and its parents.
## Future considerations
There are a number of ideas regarding actions that would be fairly trivial to implement given this refactor:
- [#6899]: Action IDs
- As actions grow to become more widespread within Windows Terminal (i.e. dropdown and jumplist integration),
a formal ID system would help users reference the same action throughout the app. With the internal
ID system introduced earlier, we would simply introduce a new
`std:map<string, InternalActionID> _ExternalIDMap` that is updated like the others, and add a `String ID`
property to `Action`.
- [#8100] Source Tracking
- Identifying where a setting came from can be very beneficial in the settings model and UI. For example,
profile settings now have an `OverrideSource` getter that describes what `Profile` object the setting
came from (i.e. base layer, profile generator, etc...). A similar system can be used for `Action` in
that we record if the action was last modified in defaults.json or settings.json.
- There seems to be no desire for action inheritance (i.e. inheriting the name/key-chord from the parent).
So this should be sufficient.
## Resources
[#885]: https://github.com/microsoft/terminal/issues/885
[#6899]: https://github.com/microsoft/terminal/issues/6899
[#8100]: https://github.com/microsoft/terminal/issues/8100
[#8767]: https://github.com/microsoft/terminal/issues/8767
Other references:
[Settings UI: Actions Page]: https://github.com/microsoft/terminal/issues/6900
[Settings UI: Actions Page Design]: https://github.com/microsoft/terminal/pulls/9427
[Action ID Spec]: https://github.com/microsoft/terminal/issues/7175

View File

@@ -1,76 +0,0 @@
---
author: <first-name> <last-name> <github-id>/<email>
created on: <yyyy-mm-dd>
last updated: <yyyy-mm-dd>
issue id: <github issue id>
---
[comment]: # Use this template for proposing a new setting, or new values for an existing setting
# Spec Title
## Abstract
[comment]: # Outline what this spec describes.
## Background
### Inspiration
[comment]: # Are there existing precedents for this type of configuration? These may be in the Terminal, or in other applications
### User Stories
[comment]: # List off the use cases where two users might want a feature to have different behavior based on user preference. Include links to issues that might be relevant.
### Future Considerations
[comment]: # Are there other future features planned that might affect the current design of this setting? The team can help with this section during the review.
## Solution Design
[comment]: # Add notes that might be relevant to the proposed solutions.
[comment]: # Also, outline various different proposed designs for this setting. These won't all be winners, but may help during the decision making process. For each proposed design:
### Proposal 1: <name of proposal>
[comment]: # Describe the values for the properties, how it'll be exposed in both JSON and the Settings UI, and list pros and cons for this design. If there are technical details for this proposal, include them here.
* **Pros**:
* **Cons**:
## Conclusion
[comment]: # Of the above proposals, which should we decide on, and why?
## UI/UX Design
[comment]: # How will different values of this setting affect the end user?
## Potential Issues
<table>
<tr>
<td><strong>Compatibility</strong></td>
<td>
[comment]: # Will the proposed change break existing code/behaviors? If so, how, and is the breaking change "worth it"?
</td>
</tr>
</table>
[comment]: # If there are any other potential issues, make sure to include them here.
## Resources
[comment]: # Be sure to add links to references, resources, footnotes, etc.
### Footnotes
<a name="footnote-1"><a>[1]:

View File

@@ -2,16 +2,17 @@
## Overview
This document outlines the roadmap towards delivering Windows Terminal 2.0 by Winter 2021.
This document outlines the roadmap towards delivering Windows Terminal 2.0 by Spring 2021.
## Milestones
Windows Terminal is engineered and delivered as a set of 6-week milestones. New features will go into [Windows Terminal Preview](https://aka.ms/terminal-preview) first, then a month after they've been in Preview, those features will move into [Windows Terminal](https://aka.ms/terminal).
The Windows Terminal project is engineered and delivered as a set of 4-week milestones. New features will go into [Windows Terminal Preview](https://aka.ms/terminal-preview) first, then a month after they've been in Preview, those features will move into [Windows Terminal](https://aka.ms/terminal).
| Duration | Activity | Releases |
| --- | --- | --- |
| 4 weeks | Dev Work<br/> <ul><li>Fixes / Features for future Windows Releases</li><li>Fixes / Features for Windows Terminal</li></ul> | Release to Internal Selfhosters at end of week 4 |
| 1 week | Quality & Stability<br/> <ul><li>Bug Fixes</li><li>Perf & Stability</li><li>UI Polish</li><li>Tests</li><li>etc.</li></ul>| Push to Microsoft Store at end of week 5 |
| 2 weeks | Dev Work<br/> <ul><li>Fixes / Features for future Windows Releases</li><li>Fixes / Features for Windows Terminal</li></ul> | Release to Internal Selfhosters at end of week 2 |
| 1 week | Quality & Stability<br/> <ul><li>Bug Fixes</li><li>Perf & Stability</li><li>UI Polish</li><li>Tests</li><li>etc.</li></ul>| Push to Microsoft Store at end of week 3 |
| 1 week | Release <br/> <ul><li>Available from [Microsoft Store](https://aka.ms/terminal) & [GitHub Releases](https://github.com/microsoft/terminal/releases)</li><li>Release Notes & Announcement Blog published</li><li>Engineering System Maintenance</li><li>Community Engagement</li><li>Docs</li><li>Future Milestone Planning</li></ul> | Release available from Microsoft Store & GitHub Releases |
## Terminal Roadmap / Timeline
@@ -24,16 +25,13 @@ Below is the schedule for when milestones will be included in release builds of
| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/) |
| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-3-release/) |
| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-4-release/) |
| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-5-release/) |
| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-6-release/) |
| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-7-release/) |
| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-8-release/) |
| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
| 2021-07-31 | 1.10 in Windows Terminal Preview<br>[1.9] in Windows Terminal | |
| 2021-08-30 | 1.11 in Windows Terminal Preview<br>1.10 in Windows Terminal | |
| 2021-10-31 | 1.12 in Windows Terminal Preview<br>1.11 in Windows Terminal | |
| 2021-11-30 | 2.0 RC in Windows Terminal Preview<br>2.0 RC in Windows Terminal | |
| 2021-12-31 | [2.0] in Windows Terminal Preview<br>[2.0] in Windows Terminal | |
| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | |
| 2020-12-31 | 1.6 in Windows Terminal Preview<br>[1.5] in Windows Terminal | |
| 2021-01-31 | 1.7 in Windows Terminal Preview<br>1.6 in Windows Terminal | |
| 2021-02-28 | 1.8 in Windows Terminal Preview<br>1.8 in Windows Terminal | |
| 2021-03-31 | 1.9 in Windows Terminal Preview<br>1.9 in Windows Terminal | |
| 2021-04-30 | 2.0 RC in Windows Terminal Preview<br>2.0 RC in Windows Terminal | |
| 2021-05-31 | [2.0] in Windows Terminal Preview<br>[2.0] in Windows Terminal | |
## Issue Triage & Prioritization
@@ -51,15 +49,14 @@ The following are a list of the key scenarios we're aiming to deliver for Termin
| Priority\* | Scenario | Description/Notes |
| ---------- | -------- | ----------------- |
| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370], [#8048] |
| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370] |
| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193]<br>Implementation: [#6635] |
| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256], [#5000]<br>Spec: [#2080], [#7240] |
| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256]<br>Spec: [#2080] |
| 1 | Clickable links | Hyperlinking any links that appear in the text buffer. When clicking on the link, the link will open in your default browser.<br><br>Issue: [#574]<br>Implementation: [#7251] |
| 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal<br><br>Issue: [#492]<br>Spec: [#2080], [#7414] |
| 1 | Overall theme support | Tab coloring, title bar coloring, pane border coloring, pane border width, definition of what makes a theme<br><br>Issue: [#3327]<br>Spec: [#5772] |
| 1 | Open profile elevated | Configure profiles to always open elevated (if Terminal was run unelevated)<br><br>Issue: [#5000], [#632]<br>Spec: [#8455] |
| 1 | Open tab in existing window | Open new tabs in existing Terminal windows<br><br>Issue: [#5000], [#4472]<br>Spec: [#8135] |
| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] <br>**Current State**: Blocked on WinUI 3.0 |
| 1 | Open tab as admin/other user | Open tab in existing Windows Terminal instance as admin (if Terminal was run unelevated) or as another user.<br><br>Issue: [#5000] |
| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] |
| 2 | SnapOnOutput, scroll lock | Pause output or scrolling on click.<br><br>Issue: [#980]<br>Spec: [#2529]<br>Implementation: [#6062] |
| 2 | Infinite scrollback | Have an infinite history for the text buffer.<br><br>Issue: [#1410] |
| 2 | Pane management | All issues listed out in the original issue. Some features include pane resizing with mouse, pane zooming, and opening a pane by prompting which profile to use.<br><br>Issue: [#1000] |
@@ -85,10 +82,6 @@ Feature Notes:
[1.3]: https://github.com/microsoft/terminal/milestone/26
[1.4]: https://github.com/microsoft/terminal/milestone/28
[1.5]: https://github.com/microsoft/terminal/milestone/30
[1.6]: https://github.com/microsoft/terminal/milestone/31
[1.7]: https://github.com/microsoft/terminal/milestone/32
[1.8]: https://github.com/microsoft/terminal/milestone/33
[1.9]: https://github.com/microsoft/terminal/milestone/34
[2.0]: https://github.com/microsoft/terminal/milestone/22
[#1564]: https://github.com/microsoft/terminal/issues/1564
[#6720]: https://github.com/microsoft/terminal/pull/6720
@@ -125,9 +118,3 @@ Feature Notes:
[#766]: https://github.com/microsoft/terminal/issues/766
[#653]: https://github.com/microsoft/terminal/issues/653
[#1553]: https://github.com/microsoft/terminal/issues/1553
[#7240]: https://github.com/microsoft/terminal/pull/7240
[#8135]: https://github.com/microsoft/terminal/pull/8135
[#8455]: https://github.com/microsoft/terminal/pull/8455
[#632]: https://github.com/microsoft/terminal/issues/632
[#4472]: https://github.com/microsoft/terminal/issues/4472
[#8048]: https://github.com/microsoft/terminal/pull/8048

View File

@@ -1,15 +0,0 @@
### Notes for Future Maintainers
This was originally imported by @Austin-Lamb in December 2020.
The provenance information (where it came from and which commit) is stored in the file `cgmanifest.json` in the same directory as this readme.
Please update the provenance information in that file when ingesting an updated version of the dependent library.
That provenance file is automatically read and inventoried by Microsoft systems to ensure compliance with appropiate governance standards.
## What should be done to update this in the future?
1. Download the version of boost you want from boost.org.
2. Take the parts you want, but leave most of it behind since it's HUGE and will bloat the repo to take it all. At the time of this writing, we only use small_vector.hpp and its dependencies as a header-only library.
3. Validate that the license in the root of the repository didn't change and update it if so. It is sitting in a version-specific subdirectory below this readme.
If it changed dramatically, ensure that it is still compatible with our license scheme. Also update the NOTICE file in the root of our repository to declare the third-party usage.
4. Submit the pull.

View File

@@ -1,23 +0,0 @@
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
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, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

View File

@@ -1,11 +0,0 @@
# Boost C++ Libraries
The Boost project provides free peer-reviewed portable C++ source libraries.
We emphasize libraries that work well with the C++ Standard Library. Boost
libraries are intended to be widely useful, and usable across a broad spectrum
of applications. The Boost license encourages both commercial and non-commercial use
and does not require attribution for binary use.
The project website is www.boost.org, where you can obtain more information and
[download](https://www.boost.org/users/download/) the current release.

View File

@@ -1,85 +0,0 @@
//
// boost/assert.hpp - BOOST_ASSERT(expr)
// BOOST_ASSERT_MSG(expr, msg)
// BOOST_VERIFY(expr)
// BOOST_VERIFY_MSG(expr, msg)
// BOOST_ASSERT_IS_VOID
//
// Copyright (c) 2001, 2002 Peter Dimov and Multi Media Ltd.
// Copyright (c) 2007, 2014 Peter Dimov
// Copyright (c) Beman Dawes 2011
// Copyright (c) 2015 Ion Gaztanaga
//
// Distributed under the Boost Software License, Version 1.0.
// See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt
//
// Note: There are no include guards. This is intentional.
//
// See http://www.boost.org/libs/assert/assert.html for documentation.
//
//
// Stop inspect complaining about use of 'assert':
//
// boostinspect:naassert_macro
//
//
// BOOST_ASSERT, BOOST_ASSERT_MSG, BOOST_ASSERT_IS_VOID
//
#undef BOOST_ASSERT
#undef BOOST_ASSERT_MSG
#undef BOOST_ASSERT_IS_VOID
#if defined(BOOST_DISABLE_ASSERTS) || ( defined(BOOST_ENABLE_ASSERT_DEBUG_HANDLER) && defined(NDEBUG) )
# define BOOST_ASSERT(expr) ((void)0)
# define BOOST_ASSERT_MSG(expr, msg) ((void)0)
# define BOOST_ASSERT_IS_VOID
#elif defined(BOOST_ENABLE_ASSERT_HANDLER) || ( defined(BOOST_ENABLE_ASSERT_DEBUG_HANDLER) && !defined(NDEBUG) )
#include <boost/config.hpp> // for BOOST_LIKELY
#include <boost/current_function.hpp>
namespace boost
{
void assertion_failed(char const * expr, char const * function, char const * file, long line); // user defined
void assertion_failed_msg(char const * expr, char const * msg, char const * function, char const * file, long line); // user defined
} // namespace boost
#define BOOST_ASSERT(expr) (BOOST_LIKELY(!!(expr))? ((void)0): ::boost::assertion_failed(#expr, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__))
#define BOOST_ASSERT_MSG(expr, msg) (BOOST_LIKELY(!!(expr))? ((void)0): ::boost::assertion_failed_msg(#expr, msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__))
#else
# include <assert.h> // .h to support old libraries w/o <cassert> - effect is the same
# define BOOST_ASSERT(expr) assert(expr)
# define BOOST_ASSERT_MSG(expr, msg) assert((expr)&&(msg))
#if defined(NDEBUG)
# define BOOST_ASSERT_IS_VOID
#endif
#endif
//
// BOOST_VERIFY, BOOST_VERIFY_MSG
//
#undef BOOST_VERIFY
#undef BOOST_VERIFY_MSG
#if defined(BOOST_DISABLE_ASSERTS) || ( !defined(BOOST_ENABLE_ASSERT_HANDLER) && defined(NDEBUG) )
# define BOOST_VERIFY(expr) ((void)(expr))
# define BOOST_VERIFY_MSG(expr, msg) ((void)(expr))
#else
# define BOOST_VERIFY(expr) BOOST_ASSERT(expr)
# define BOOST_VERIFY_MSG(expr, msg) BOOST_ASSERT_MSG(expr,msg)
#endif

View File

@@ -1,67 +0,0 @@
// Boost config.hpp configuration header file ------------------------------//
// (C) Copyright John Maddock 2002.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
// See http://www.boost.org/libs/config for most recent version.
// Boost config.hpp policy and rationale documentation has been moved to
// http://www.boost.org/libs/config
//
// CAUTION: This file is intended to be completely stable -
// DO NOT MODIFY THIS FILE!
//
#ifndef BOOST_CONFIG_HPP
#define BOOST_CONFIG_HPP
// if we don't have a user config, then use the default location:
#if !defined(BOOST_USER_CONFIG) && !defined(BOOST_NO_USER_CONFIG)
# define BOOST_USER_CONFIG <boost/config/user.hpp>
#if 0
// For dependency trackers:
# include <boost/config/user.hpp>
#endif
#endif
// include it first:
#ifdef BOOST_USER_CONFIG
# include BOOST_USER_CONFIG
#endif
// if we don't have a compiler config set, try and find one:
#if !defined(BOOST_COMPILER_CONFIG) && !defined(BOOST_NO_COMPILER_CONFIG) && !defined(BOOST_NO_CONFIG)
# include <boost/config/detail/select_compiler_config.hpp>
#endif
// if we have a compiler config, include it now:
#ifdef BOOST_COMPILER_CONFIG
# include BOOST_COMPILER_CONFIG
#endif
// if we don't have a std library config set, try and find one:
#if !defined(BOOST_STDLIB_CONFIG) && !defined(BOOST_NO_STDLIB_CONFIG) && !defined(BOOST_NO_CONFIG) && defined(__cplusplus)
# include <boost/config/detail/select_stdlib_config.hpp>
#endif
// if we have a std library config, include it now:
#ifdef BOOST_STDLIB_CONFIG
# include BOOST_STDLIB_CONFIG
#endif
// if we don't have a platform config set, try and find one:
#if !defined(BOOST_PLATFORM_CONFIG) && !defined(BOOST_NO_PLATFORM_CONFIG) && !defined(BOOST_NO_CONFIG)
# include <boost/config/detail/select_platform_config.hpp>
#endif
// if we have a platform config, include it now:
#ifdef BOOST_PLATFORM_CONFIG
# include BOOST_PLATFORM_CONFIG
#endif
// get config suffix code:
#include <boost/config/detail/suffix.hpp>
#ifdef BOOST_HAS_PRAGMA_ONCE
#pragma once
#endif
#endif // BOOST_CONFIG_HPP

View File

@@ -1,27 +0,0 @@
// (C) Copyright John Maddock 2003.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
// for C++ Builder the following options effect the ABI:
//
// -b (on or off - effect emum sizes)
// -Vx (on or off - empty members)
// -Ve (on or off - empty base classes)
// -aX (alignment - 5 options).
// -pX (Calling convention - 4 options)
// -VmX (member pointer size and layout - 5 options)
// -VC (on or off, changes name mangling)
// -Vl (on or off, changes struct layout).
// In addition the following warnings are sufficiently annoying (and
// unfixable) to have them turned off by default:
//
// 8027 - functions containing [for|while] loops are not expanded inline
// 8026 - functions taking class by value arguments are not expanded inline
#pragma nopushoptwarn
# pragma option push -a8 -Vx- -Ve- -b- -pc -Vmv -VC- -Vl- -w-8027 -w-8026

View File

@@ -1,12 +0,0 @@
// (C) Copyright John Maddock 2003.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
# pragma option pop
#pragma nopushoptwarn

View File

@@ -1,22 +0,0 @@
// (C) Copyright John Maddock 2003.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//
// Boost binaries are built with the compiler's default ABI settings,
// if the user changes their default alignment in the VS IDE then their
// code will no longer be binary compatible with the bjam built binaries
// unless this header is included to force Boost code into a consistent ABI.
//
// Note that inclusion of this header is only necessary for libraries with
// separate source, header only libraries DO NOT need this as long as all
// translation units are built with the same options.
//
#if defined(_M_X64)
# pragma pack(push,16)
#else
# pragma pack(push,8)
#endif

View File

@@ -1,8 +0,0 @@
// (C) Copyright John Maddock 2003.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
#pragma pack(pop)

View File

@@ -1,25 +0,0 @@
// abi_prefix header -------------------------------------------------------//
// (c) Copyright John Maddock 2003
// Use, modification and distribution are subject to the Boost Software License,
// Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt).
#ifndef BOOST_CONFIG_ABI_PREFIX_HPP
# define BOOST_CONFIG_ABI_PREFIX_HPP
#else
# error double inclusion of header boost/config/abi_prefix.hpp is an error
#endif
#include <boost/config.hpp>
// this must occur after all other includes and before any code appears:
#ifdef BOOST_HAS_ABI_HEADERS
# include BOOST_ABI_PREFIX
#endif
#if defined( __BORLANDC__ )
#pragma nopushoptwarn
#endif

View File

@@ -1,27 +0,0 @@
// abi_sufffix header -------------------------------------------------------//
// (c) Copyright John Maddock 2003
// Use, modification and distribution are subject to the Boost Software License,
// Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt).
// This header should be #included AFTER code that was preceded by a #include
// <boost/config/abi_prefix.hpp>.
#ifndef BOOST_CONFIG_ABI_PREFIX_HPP
# error Header boost/config/abi_suffix.hpp must only be used after boost/config/abi_prefix.hpp
#else
# undef BOOST_CONFIG_ABI_PREFIX_HPP
#endif
// the suffix header occurs after all of our code:
#ifdef BOOST_HAS_ABI_HEADERS
# include BOOST_ABI_SUFFIX
#endif
#if defined( __BORLANDC__ )
#pragma nopushoptwarn
#endif

View File

@@ -1,485 +0,0 @@
// (C) Copyright John Maddock 2003.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
/*
* LOCATION: see http://www.boost.org for most recent version.
* FILE auto_link.hpp
* VERSION see <boost/version.hpp>
* DESCRIPTION: Automatic library inclusion for Borland/Microsoft compilers.
*/
/*************************************************************************
USAGE:
~~~~~~
Before including this header you must define one or more of define the following macros:
BOOST_LIB_NAME: Required: A string containing the basename of the library,
for example boost_regex.
BOOST_LIB_TOOLSET: Optional: the base name of the toolset.
BOOST_DYN_LINK: Optional: when set link to dll rather than static library.
BOOST_LIB_DIAGNOSTIC: Optional: when set the header will print out the name
of the library selected (useful for debugging).
BOOST_AUTO_LINK_NOMANGLE: Specifies that we should link to BOOST_LIB_NAME.lib,
rather than a mangled-name version.
BOOST_AUTO_LINK_TAGGED: Specifies that we link to libraries built with the --layout=tagged option.
This is essentially the same as the default name-mangled version, but without
the compiler name and version, or the Boost version. Just the build options.
BOOST_AUTO_LINK_SYSTEM: Specifies that we link to libraries built with the --layout=system option.
This is essentially the same as the non-name-mangled version, but with
the prefix to differentiate static and dll builds
These macros will be undef'ed at the end of the header, further this header
has no include guards - so be sure to include it only once from your library!
Algorithm:
~~~~~~~~~~
Libraries for Borland and Microsoft compilers are automatically
selected here, the name of the lib is selected according to the following
formula:
BOOST_LIB_PREFIX
+ BOOST_LIB_NAME
+ "_"
+ BOOST_LIB_TOOLSET
+ BOOST_LIB_THREAD_OPT
+ BOOST_LIB_RT_OPT
+ BOOST_LIB_ARCH_AND_MODEL_OPT
"-"
+ BOOST_LIB_VERSION
These are defined as:
BOOST_LIB_PREFIX: "lib" for static libraries otherwise "".
BOOST_LIB_NAME: The base name of the lib ( for example boost_regex).
BOOST_LIB_TOOLSET: The compiler toolset name (vc6, vc7, bcb5 etc).
BOOST_LIB_THREAD_OPT: "-mt" for multithread builds, otherwise nothing.
BOOST_LIB_RT_OPT: A suffix that indicates the runtime library used,
contains one or more of the following letters after
a hyphen:
s static runtime (dynamic if not present).
g debug/diagnostic runtime (release if not present).
y Python debug/diagnostic runtime (release if not present).
d debug build (release if not present).
p STLport build.
n STLport build without its IOStreams.
BOOST_LIB_ARCH_AND_MODEL_OPT: The architecture and address model
(-x32 or -x64 for x86/32 and x86/64 respectively)
BOOST_LIB_VERSION: The Boost version, in the form x_y, for Boost version x.y.
***************************************************************************/
#ifdef __cplusplus
# ifndef BOOST_CONFIG_HPP
# include <boost/config.hpp>
# endif
#elif defined(_MSC_VER) && !defined(__MWERKS__) && !defined(__EDG_VERSION__)
//
// C language compatability (no, honestly)
//
# define BOOST_MSVC _MSC_VER
# define BOOST_STRINGIZE(X) BOOST_DO_STRINGIZE(X)
# define BOOST_DO_STRINGIZE(X) #X
#endif
//
// Only include what follows for known and supported compilers:
//
#if defined(BOOST_MSVC) \
|| defined(__BORLANDC__) \
|| (defined(__MWERKS__) && defined(_WIN32) && (__MWERKS__ >= 0x3000)) \
|| (defined(__ICL) && defined(_MSC_EXTENSIONS) && (_MSC_VER >= 1200)) \
|| (defined(BOOST_CLANG) && defined(BOOST_WINDOWS) && defined(_MSC_VER) && (__clang_major__ >= 4))
#ifndef BOOST_VERSION_HPP
# include <boost/version.hpp>
#endif
#ifndef BOOST_LIB_NAME
# error "Macro BOOST_LIB_NAME not set (internal error)"
#endif
//
// error check:
//
#if defined(__MSVC_RUNTIME_CHECKS) && !defined(_DEBUG)
# pragma message("Using the /RTC option without specifying a debug runtime will lead to linker errors")
# pragma message("Hint: go to the code generation options and switch to one of the debugging runtimes")
# error "Incompatible build options"
#endif
//
// select toolset if not defined already:
//
#ifndef BOOST_LIB_TOOLSET
# if defined(BOOST_MSVC) && (BOOST_MSVC < 1200)
// Note: no compilers before 1200 are supported
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1300)
# ifdef UNDER_CE
// eVC4:
# define BOOST_LIB_TOOLSET "evc4"
# else
// vc6:
# define BOOST_LIB_TOOLSET "vc6"
# endif
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1310)
// vc7:
# define BOOST_LIB_TOOLSET "vc7"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1400)
// vc71:
# define BOOST_LIB_TOOLSET "vc71"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1500)
// vc80:
# define BOOST_LIB_TOOLSET "vc80"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1600)
// vc90:
# define BOOST_LIB_TOOLSET "vc90"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1700)
// vc10:
# define BOOST_LIB_TOOLSET "vc100"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1800)
// vc11:
# define BOOST_LIB_TOOLSET "vc110"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1900)
// vc12:
# define BOOST_LIB_TOOLSET "vc120"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1910)
// vc14:
# define BOOST_LIB_TOOLSET "vc140"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1920)
// vc14.1:
# define BOOST_LIB_TOOLSET "vc141"
# elif defined(BOOST_MSVC)
// vc14.2:
# define BOOST_LIB_TOOLSET "vc142"
# elif defined(__BORLANDC__)
// CBuilder 6:
# define BOOST_LIB_TOOLSET "bcb"
# elif defined(__ICL)
// Intel C++, no version number:
# define BOOST_LIB_TOOLSET "iw"
# elif defined(__MWERKS__) && (__MWERKS__ <= 0x31FF )
// Metrowerks CodeWarrior 8.x
# define BOOST_LIB_TOOLSET "cw8"
# elif defined(__MWERKS__) && (__MWERKS__ <= 0x32FF )
// Metrowerks CodeWarrior 9.x
# define BOOST_LIB_TOOLSET "cw9"
# elif defined(BOOST_CLANG) && defined(BOOST_WINDOWS) && defined(_MSC_VER) && (__clang_major__ >= 4)
// Clang on Windows
# define BOOST_LIB_TOOLSET "clangw" BOOST_STRINGIZE(__clang_major__)
# endif
#endif // BOOST_LIB_TOOLSET
//
// select thread opt:
//
#if defined(_MT) || defined(__MT__)
# define BOOST_LIB_THREAD_OPT "-mt"
#else
# define BOOST_LIB_THREAD_OPT
#endif
#if defined(_MSC_VER) || defined(__MWERKS__)
# ifdef _DLL
# if (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) && (defined(_STLP_OWN_IOSTREAMS) || defined(__STL_OWN_IOSTREAMS))
# if defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-gydp"
# elif defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))
# define BOOST_LIB_RT_OPT "-gdp"
# elif defined(_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-gydp"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-gdp"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# else
# define BOOST_LIB_RT_OPT "-p"
# endif
# elif defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)
# if defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-gydpn"
# elif defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))
# define BOOST_LIB_RT_OPT "-gdpn"
# elif defined(_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-gydpn"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-gdpn"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# else
# define BOOST_LIB_RT_OPT "-pn"
# endif
# else
# if defined(_DEBUG) && defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-gyd"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-gd"
# else
# define BOOST_LIB_RT_OPT
# endif
# endif
# else
# if (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) && (defined(_STLP_OWN_IOSTREAMS) || defined(__STL_OWN_IOSTREAMS))
# if defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sgydp"
# elif defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))
# define BOOST_LIB_RT_OPT "-sgdp"
# elif defined(_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sgydp"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-sgdp"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# else
# define BOOST_LIB_RT_OPT "-sp"
# endif
# elif defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)
# if defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sgydpn"
# elif defined(_DEBUG) && (defined(__STL_DEBUG) || defined(_STLP_DEBUG))
# define BOOST_LIB_RT_OPT "-sgdpn"
# elif defined(_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sgydpn"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-sgdpn"
# pragma message("warning: STLport debug versions are built with /D_STLP_DEBUG=1")
# error "Build options aren't compatible with pre-built libraries"
# else
# define BOOST_LIB_RT_OPT "-spn"
# endif
# else
# if defined(_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sgyd"
# elif defined(_DEBUG)
# define BOOST_LIB_RT_OPT "-sgd"
# else
# define BOOST_LIB_RT_OPT "-s"
# endif
# endif
# endif
#elif defined(__BORLANDC__)
//
// figure out whether we want the debug builds or not:
//
#if __BORLANDC__ > 0x561
#pragma defineonoption BOOST_BORLAND_DEBUG -v
#endif
//
// sanity check:
//
#if defined(__STL_DEBUG) || defined(_STLP_DEBUG)
#error "Pre-built versions of the Boost libraries are not provided in STLport-debug form"
#endif
# ifdef _RTLDLL
# if defined(BOOST_BORLAND_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-yd"
# elif defined(BOOST_BORLAND_DEBUG)
# define BOOST_LIB_RT_OPT "-d"
# elif defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT -y
# else
# define BOOST_LIB_RT_OPT
# endif
# else
# if defined(BOOST_BORLAND_DEBUG)\
&& defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-syd"
# elif defined(BOOST_BORLAND_DEBUG)
# define BOOST_LIB_RT_OPT "-sd"
# elif defined(BOOST_DEBUG_PYTHON) && defined(BOOST_LINKING_PYTHON)
# define BOOST_LIB_RT_OPT "-sy"
# else
# define BOOST_LIB_RT_OPT "-s"
# endif
# endif
#endif
//
// BOOST_LIB_ARCH_AND_MODEL_OPT
//
#if defined( _M_IX86 )
# define BOOST_LIB_ARCH_AND_MODEL_OPT "-x32"
#elif defined( _M_X64 )
# define BOOST_LIB_ARCH_AND_MODEL_OPT "-x64"
#elif defined( _M_ARM )
# define BOOST_LIB_ARCH_AND_MODEL_OPT "-a32"
#elif defined( _M_ARM64 )
# define BOOST_LIB_ARCH_AND_MODEL_OPT "-a64"
#endif
//
// select linkage opt:
//
#if (defined(_DLL) || defined(_RTLDLL)) && defined(BOOST_DYN_LINK)
# define BOOST_LIB_PREFIX
#elif defined(BOOST_DYN_LINK)
# error "Mixing a dll boost library with a static runtime is a really bad idea..."
#else
# define BOOST_LIB_PREFIX "lib"
#endif
//
// now include the lib:
//
#if defined(BOOST_LIB_NAME) \
&& defined(BOOST_LIB_PREFIX) \
&& defined(BOOST_LIB_TOOLSET) \
&& defined(BOOST_LIB_THREAD_OPT) \
&& defined(BOOST_LIB_RT_OPT) \
&& defined(BOOST_LIB_ARCH_AND_MODEL_OPT) \
&& defined(BOOST_LIB_VERSION)
#ifdef BOOST_AUTO_LINK_TAGGED
# pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT ".lib")
# ifdef BOOST_LIB_DIAGNOSTIC
# pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT ".lib")
# endif
#elif defined(BOOST_AUTO_LINK_SYSTEM)
# pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib")
# ifdef BOOST_LIB_DIAGNOSTIC
# pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib")
# endif
#elif defined(BOOST_AUTO_LINK_NOMANGLE)
# pragma comment(lib, BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib")
# ifdef BOOST_LIB_DIAGNOSTIC
# pragma message ("Linking to lib file: " BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib")
# endif
#elif defined(BOOST_LIB_BUILDID)
# pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT "-" BOOST_LIB_VERSION "-" BOOST_STRINGIZE(BOOST_LIB_BUILDID) ".lib")
# ifdef BOOST_LIB_DIAGNOSTIC
# pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT "-" BOOST_LIB_VERSION "-" BOOST_STRINGIZE(BOOST_LIB_BUILDID) ".lib")
# endif
#else
# pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT "-" BOOST_LIB_VERSION ".lib")
# ifdef BOOST_LIB_DIAGNOSTIC
# pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT BOOST_LIB_ARCH_AND_MODEL_OPT "-" BOOST_LIB_VERSION ".lib")
# endif
#endif
#else
# error "some required macros where not defined (internal logic error)."
#endif
#endif // _MSC_VER || __BORLANDC__
//
// finally undef any macros we may have set:
//
#ifdef BOOST_LIB_PREFIX
# undef BOOST_LIB_PREFIX
#endif
#if defined(BOOST_LIB_NAME)
# undef BOOST_LIB_NAME
#endif
// Don't undef this one: it can be set by the user and should be the
// same for all libraries:
//#if defined(BOOST_LIB_TOOLSET)
//# undef BOOST_LIB_TOOLSET
//#endif
#if defined(BOOST_LIB_THREAD_OPT)
# undef BOOST_LIB_THREAD_OPT
#endif
#if defined(BOOST_LIB_RT_OPT)
# undef BOOST_LIB_RT_OPT
#endif
#if defined(BOOST_LIB_ARCH_AND_MODEL_OPT)
# undef BOOST_LIB_ARCH_AND_MODEL_OPT
#endif
#if defined(BOOST_LIB_LINK_OPT)
# undef BOOST_LIB_LINK_OPT
#endif
#if defined(BOOST_LIB_DEBUG_OPT)
# undef BOOST_LIB_DEBUG_OPT
#endif
#if defined(BOOST_DYN_LINK)
# undef BOOST_DYN_LINK
#endif

View File

@@ -1,336 +0,0 @@
// (C) Copyright John Maddock 2001 - 2003.
// (C) Copyright David Abrahams 2002 - 2003.
// (C) Copyright Aleksey Gurtovoy 2002.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
// See http://www.boost.org for most recent version.
// Borland C++ compiler setup:
//
// versions check:
// we don't support Borland prior to version 5.4:
#if __BORLANDC__ < 0x540
# error "Compiler not supported or configured - please reconfigure"
#endif
// last known compiler version:
#if (__BORLANDC__ > 0x613)
//# if defined(BOOST_ASSERT_CONFIG)
# error "boost: Unknown compiler version - please run the configure tests and report the results"
//# else
//# pragma message( "boost: Unknown compiler version - please run the configure tests and report the results")
//# endif
#elif (__BORLANDC__ == 0x600)
# error "CBuilderX preview compiler is no longer supported"
#endif
//
// Support macros to help with standard library detection
#if (__BORLANDC__ < 0x560) || defined(_USE_OLD_RW_STL)
# define BOOST_BCB_WITH_ROGUE_WAVE
#elif __BORLANDC__ < 0x570
# define BOOST_BCB_WITH_STLPORT
#else
# define BOOST_BCB_WITH_DINKUMWARE
#endif
//
// Version 5.0 and below:
# if __BORLANDC__ <= 0x0550
// Borland C++Builder 4 and 5:
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# if __BORLANDC__ == 0x0550
// Borland C++Builder 5, command-line compiler 5.5:
# define BOOST_NO_OPERATORS_IN_NAMESPACE
# endif
// Variadic macros do not exist for C++ Builder versions 5 and below
#define BOOST_NO_CXX11_VARIADIC_MACROS
# endif
// Version 5.51 and below:
#if (__BORLANDC__ <= 0x551)
# define BOOST_NO_CV_SPECIALIZATIONS
# define BOOST_NO_CV_VOID_SPECIALIZATIONS
# define BOOST_NO_DEDUCED_TYPENAME
// workaround for missing WCHAR_MAX/WCHAR_MIN:
#ifdef __cplusplus
#include <climits>
#include <cwchar>
#else
#include <limits.h>
#include <wchar.h>
#endif // __cplusplus
#ifndef WCHAR_MAX
# define WCHAR_MAX 0xffff
#endif
#ifndef WCHAR_MIN
# define WCHAR_MIN 0
#endif
#endif
// Borland C++ Builder 6 and below:
#if (__BORLANDC__ <= 0x564)
# if defined(NDEBUG) && defined(__cplusplus)
// fix broken <cstring> so that Boost.test works:
# include <cstring>
# undef strcmp
# endif
// fix broken errno declaration:
# include <errno.h>
# ifndef errno
# define errno errno
# endif
#endif
//
// new bug in 5.61:
#if (__BORLANDC__ >= 0x561) && (__BORLANDC__ <= 0x580)
// this seems to be needed by the command line compiler, but not the IDE:
# define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS
#endif
// Borland C++ Builder 2006 Update 2 and below:
#if (__BORLANDC__ <= 0x582)
# define BOOST_NO_SFINAE
# define BOOST_BCB_PARTIAL_SPECIALIZATION_BUG
# define BOOST_NO_TEMPLATE_TEMPLATES
# define BOOST_NO_PRIVATE_IN_AGGREGATE
# ifdef _WIN32
# define BOOST_NO_SWPRINTF
# elif defined(linux) || defined(__linux__) || defined(__linux)
// we should really be able to do without this
// but the wcs* functions aren't imported into std::
# define BOOST_NO_STDC_NAMESPACE
// _CPPUNWIND doesn't get automatically set for some reason:
# pragma defineonoption BOOST_CPPUNWIND -x
# endif
#endif
#if (__BORLANDC__ <= 0x613) // Beman has asked Alisdair for more info
// we shouldn't really need this - but too many things choke
// without it, this needs more investigation:
# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
# define BOOST_NO_IS_ABSTRACT
# define BOOST_NO_FUNCTION_TYPE_SPECIALIZATIONS
# define BOOST_NO_USING_TEMPLATE
# define BOOST_SP_NO_SP_CONVERTIBLE
// Temporary workaround
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#endif
// Borland C++ Builder 2008 and below:
# define BOOST_NO_INTEGRAL_INT64_T
# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
# define BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
# define BOOST_NO_NESTED_FRIENDSHIP
# define BOOST_NO_TYPENAME_WITH_CTOR
#if (__BORLANDC__ < 0x600)
# define BOOST_ILLEGAL_CV_REFERENCES
#endif
//
// Positive Feature detection
//
// Borland C++ Builder 2008 and below:
#if (__BORLANDC__ >= 0x599)
# pragma defineonoption BOOST_CODEGEAR_0X_SUPPORT -Ax
#endif
//
// C++0x Macros:
//
#if !defined( BOOST_CODEGEAR_0X_SUPPORT ) || (__BORLANDC__ < 0x610)
# define BOOST_NO_CXX11_CHAR16_T
# define BOOST_NO_CXX11_CHAR32_T
# define BOOST_NO_CXX11_DECLTYPE
# define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS
# define BOOST_NO_CXX11_EXTERN_TEMPLATE
# define BOOST_NO_CXX11_RVALUE_REFERENCES
# define BOOST_NO_CXX11_SCOPED_ENUMS
# define BOOST_NO_CXX11_STATIC_ASSERT
#else
# define BOOST_HAS_ALIGNOF
# define BOOST_HAS_CHAR16_T
# define BOOST_HAS_CHAR32_T
# define BOOST_HAS_DECLTYPE
# define BOOST_HAS_EXPLICIT_CONVERSION_OPS
# define BOOST_HAS_REF_QUALIFIER
# define BOOST_HAS_RVALUE_REFS
# define BOOST_HAS_STATIC_ASSERT
#endif
#define BOOST_NO_CXX11_AUTO_DECLARATIONS
#define BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS
#define BOOST_NO_CXX11_CONSTEXPR
#define BOOST_NO_CXX11_DECLTYPE_N3276
#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS
#define BOOST_NO_CXX11_DEFAULTED_MOVES
#define BOOST_NO_CXX11_DELETED_FUNCTIONS
#define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
#define BOOST_NO_CXX11_HDR_INITIALIZER_LIST
#define BOOST_NO_CXX11_LAMBDAS
#define BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS
#define BOOST_NO_CXX11_NULLPTR
#define BOOST_NO_CXX11_RANGE_BASED_FOR
#define BOOST_NO_CXX11_RAW_LITERALS
#define BOOST_NO_CXX11_RVALUE_REFERENCES
#define BOOST_NO_CXX11_SCOPED_ENUMS
#define BOOST_NO_SFINAE_EXPR
#define BOOST_NO_CXX11_SFINAE_EXPR
#define BOOST_NO_CXX11_TEMPLATE_ALIASES
#define BOOST_NO_CXX11_UNICODE_LITERALS // UTF-8 still not supported
#define BOOST_NO_CXX11_VARIADIC_TEMPLATES
#define BOOST_NO_CXX11_NOEXCEPT
#define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX
#define BOOST_NO_CXX11_USER_DEFINED_LITERALS
#define BOOST_NO_CXX11_ALIGNAS
#define BOOST_NO_CXX11_TRAILING_RESULT_TYPES
#define BOOST_NO_CXX11_INLINE_NAMESPACES
#define BOOST_NO_CXX11_REF_QUALIFIERS
#define BOOST_NO_CXX11_FINAL
#define BOOST_NO_CXX11_THREAD_LOCAL
#define BOOST_NO_CXX11_UNRESTRICTED_UNION
// C++ 14:
#if !defined(__cpp_aggregate_nsdmi) || (__cpp_aggregate_nsdmi < 201304)
# define BOOST_NO_CXX14_AGGREGATE_NSDMI
#endif
#if !defined(__cpp_binary_literals) || (__cpp_binary_literals < 201304)
# define BOOST_NO_CXX14_BINARY_LITERALS
#endif
#if !defined(__cpp_constexpr) || (__cpp_constexpr < 201304)
# define BOOST_NO_CXX14_CONSTEXPR
#endif
#if !defined(__cpp_decltype_auto) || (__cpp_decltype_auto < 201304)
# define BOOST_NO_CXX14_DECLTYPE_AUTO
#endif
#if (__cplusplus < 201304) // There's no SD6 check for this....
# define BOOST_NO_CXX14_DIGIT_SEPARATORS
#endif
#if !defined(__cpp_generic_lambdas) || (__cpp_generic_lambdas < 201304)
# define BOOST_NO_CXX14_GENERIC_LAMBDAS
#endif
#if !defined(__cpp_init_captures) || (__cpp_init_captures < 201304)
# define BOOST_NO_CXX14_INITIALIZED_LAMBDA_CAPTURES
#endif
#if !defined(__cpp_return_type_deduction) || (__cpp_return_type_deduction < 201304)
# define BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION
#endif
#if !defined(__cpp_variable_templates) || (__cpp_variable_templates < 201304)
# define BOOST_NO_CXX14_VARIABLE_TEMPLATES
#endif
// C++17
#if !defined(__cpp_structured_bindings) || (__cpp_structured_bindings < 201606)
# define BOOST_NO_CXX17_STRUCTURED_BINDINGS
#endif
#if !defined(__cpp_inline_variables) || (__cpp_inline_variables < 201606)
# define BOOST_NO_CXX17_INLINE_VARIABLES
#endif
#if !defined(__cpp_fold_expressions) || (__cpp_fold_expressions < 201603)
# define BOOST_NO_CXX17_FOLD_EXPRESSIONS
#endif
#if !defined(__cpp_if_constexpr) || (__cpp_if_constexpr < 201606)
# define BOOST_NO_CXX17_IF_CONSTEXPR
#endif
#if __BORLANDC__ >= 0x590
# define BOOST_HAS_TR1_HASH
# define BOOST_HAS_MACRO_USE_FACET
#endif
//
// Post 0x561 we have long long and stdint.h:
#if __BORLANDC__ >= 0x561
# ifndef __NO_LONG_LONG
# define BOOST_HAS_LONG_LONG
# else
# define BOOST_NO_LONG_LONG
# endif
// On non-Win32 platforms let the platform config figure this out:
# ifdef _WIN32
# define BOOST_HAS_STDINT_H
# endif
#endif
// Borland C++Builder 6 defaults to using STLPort. If _USE_OLD_RW_STL is
// defined, then we have 0x560 or greater with the Rogue Wave implementation
// which presumably has the std::DBL_MAX bug.
#if defined( BOOST_BCB_WITH_ROGUE_WAVE )
// <climits> is partly broken, some macros define symbols that are really in
// namespace std, so you end up having to use illegal constructs like
// std::DBL_MAX, as a fix we'll just include float.h and have done with:
#include <float.h>
#endif
//
// __int64:
//
#if (__BORLANDC__ >= 0x530) && !defined(__STRICT_ANSI__)
# define BOOST_HAS_MS_INT64
#endif
//
// check for exception handling support:
//
#if !defined(_CPPUNWIND) && !defined(BOOST_CPPUNWIND) && !defined(__EXCEPTIONS) && !defined(BOOST_NO_EXCEPTIONS)
# define BOOST_NO_EXCEPTIONS
#endif
//
// all versions have a <dirent.h>:
//
#ifndef __STRICT_ANSI__
# define BOOST_HAS_DIRENT_H
#endif
//
// all versions support __declspec:
//
#if defined(__STRICT_ANSI__)
// config/platform/win32.hpp will define BOOST_SYMBOL_EXPORT, etc., unless already defined
# define BOOST_SYMBOL_EXPORT
#endif
//
// ABI fixing headers:
//
#if __BORLANDC__ != 0x600 // not implemented for version 6 compiler yet
#ifndef BOOST_ABI_PREFIX
# define BOOST_ABI_PREFIX "boost/config/abi/borland_prefix.hpp"
#endif
#ifndef BOOST_ABI_SUFFIX
# define BOOST_ABI_SUFFIX "boost/config/abi/borland_suffix.hpp"
#endif
#endif
//
// Disable Win32 support in ANSI mode:
//
#if __BORLANDC__ < 0x600
# pragma defineonoption BOOST_DISABLE_WIN32 -A
#elif defined(__STRICT_ANSI__)
# define BOOST_DISABLE_WIN32
#endif
//
// MSVC compatibility mode does some nasty things:
// TODO: look up if this doesn't apply to the whole 12xx range
//
#if defined(_MSC_VER) && (_MSC_VER <= 1200)
# define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
# define BOOST_NO_VOID_RETURNS
#endif
// Borland did not implement value-initialization completely, as I reported
// in 2007, Borland Report 51854, "Value-initialization: POD struct should be
// zero-initialized", http://qc.embarcadero.com/wc/qcmain.aspx?d=51854
// See also: http://www.boost.org/libs/utility/value_init.htm#compiler_issues
// (Niels Dekker, LKEB, April 2010)
#define BOOST_NO_COMPLETE_VALUE_INITIALIZATION
#define BOOST_COMPILER "Borland C++ version " BOOST_STRINGIZE(__BORLANDC__)

View File

@@ -1,352 +0,0 @@
// (C) Copyright Douglas Gregor 2010
//
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
// See http://www.boost.org for most recent version.
// Clang compiler setup.
#define BOOST_HAS_PRAGMA_ONCE
// Detecting `-fms-extension` compiler flag assuming that _MSC_VER defined when that flag is used.
#if defined (_MSC_VER) && (__clang_major__ > 3 || (__clang_major__ == 3 && __clang_minor__ >= 4))
# define BOOST_HAS_PRAGMA_DETECT_MISMATCH
#endif
// When compiling with clang before __has_extension was defined,
// even if one writes 'defined(__has_extension) && __has_extension(xxx)',
// clang reports a compiler error. So the only workaround found is:
#ifndef __has_extension
#define __has_extension __has_feature
#endif
#ifndef __has_attribute
#define __has_attribute(x) 0
#endif
#ifndef __has_cpp_attribute
#define __has_cpp_attribute(x) 0
#endif
#if !__has_feature(cxx_exceptions) && !defined(BOOST_NO_EXCEPTIONS)
# define BOOST_NO_EXCEPTIONS
#endif
#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_RTTI)
# define BOOST_NO_RTTI
#endif
#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_TYPEID)
# define BOOST_NO_TYPEID
#endif
#if !__has_feature(cxx_thread_local)
# define BOOST_NO_CXX11_THREAD_LOCAL
#endif
#ifdef __is_identifier
#if !__is_identifier(__int64) && !defined(__GNUC__)
# define BOOST_HAS_MS_INT64
#endif
#endif
#if __has_include(<stdint.h>)
# define BOOST_HAS_STDINT_H
#endif
#if (defined(linux) || defined(__linux) || defined(__linux__) || defined(__GNU__) || defined(__GLIBC__)) && !defined(_CRAYC)
#if (__clang_major__ >= 4) && defined(__has_include)
#if __has_include(<quadmath.h>)
# define BOOST_HAS_FLOAT128
#endif
#endif
#endif
#define BOOST_HAS_NRVO
// Branch prediction hints
#if !defined (__c2__) && defined(__has_builtin)
#if __has_builtin(__builtin_expect)
#define BOOST_LIKELY(x) __builtin_expect(x, 1)
#define BOOST_UNLIKELY(x) __builtin_expect(x, 0)
#endif
#endif
// Clang supports "long long" in all compilation modes.
#define BOOST_HAS_LONG_LONG
//
// We disable this if the compiler is really nvcc with C++03 as it
// doesn't actually support __int128 as of CUDA_VERSION=7500
// even though it defines __SIZEOF_INT128__.
// See https://svn.boost.org/trac/boost/ticket/10418
// https://svn.boost.org/trac/boost/ticket/11852
// Only re-enable this for nvcc if you're absolutely sure
// of the circumstances under which it's supported.
// Similarly __SIZEOF_INT128__ is defined when targetting msvc
// compatibility even though the required support functions are absent.
//
#if defined(__CUDACC__)
# if defined(BOOST_GCC_CXX11)
# define BOOST_NVCC_CXX11
# else
# define BOOST_NVCC_CXX03
# endif
#endif
#if defined(__SIZEOF_INT128__) && !defined(BOOST_NVCC_CXX03) && !defined(_MSC_VER)
# define BOOST_HAS_INT128
#endif
//
// Dynamic shared object (DSO) and dynamic-link library (DLL) support
//
#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__)
# define BOOST_HAS_DECLSPEC
# define BOOST_SYMBOL_EXPORT __attribute__((__dllexport__))
# define BOOST_SYMBOL_IMPORT __attribute__((__dllimport__))
#else
# define BOOST_SYMBOL_EXPORT __attribute__((__visibility__("default")))
# define BOOST_SYMBOL_VISIBLE __attribute__((__visibility__("default")))
# define BOOST_SYMBOL_IMPORT
#endif
//
// The BOOST_FALLTHROUGH macro can be used to annotate implicit fall-through
// between switch labels.
//
#if __cplusplus >= 201103L && defined(__has_warning)
# if __has_feature(cxx_attributes) && __has_warning("-Wimplicit-fallthrough")
# define BOOST_FALLTHROUGH [[clang::fallthrough]]
# endif
#endif
#if !__has_feature(cxx_auto_type)
# define BOOST_NO_CXX11_AUTO_DECLARATIONS
# define BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS
#endif
//
// Currently clang on Windows using VC++ RTL does not support C++11's char16_t or char32_t
//
#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || !(defined(__GXX_EXPERIMENTAL_CXX0X__) || __cplusplus >= 201103L)
# define BOOST_NO_CXX11_CHAR16_T
# define BOOST_NO_CXX11_CHAR32_T
#endif
#if defined(_MSC_VER) && (_MSC_VER >= 1800) && !defined(__GNUC__)
#define BOOST_HAS_EXPM1
#define BOOST_HAS_LOG1P
#endif
#if !__has_feature(cxx_constexpr)
# define BOOST_NO_CXX11_CONSTEXPR
#endif
#if !__has_feature(cxx_decltype)
# define BOOST_NO_CXX11_DECLTYPE
#endif
#if !__has_feature(cxx_decltype_incomplete_return_types)
# define BOOST_NO_CXX11_DECLTYPE_N3276
#endif
#if !__has_feature(cxx_defaulted_functions)
# define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS
#endif
#if !__has_feature(cxx_deleted_functions)
# define BOOST_NO_CXX11_DELETED_FUNCTIONS
#endif
#if !__has_feature(cxx_explicit_conversions)
# define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS
#endif
#if !__has_feature(cxx_default_function_template_args)
# define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
#endif
#if !__has_feature(cxx_generalized_initializers)
# define BOOST_NO_CXX11_HDR_INITIALIZER_LIST
#endif
#if !__has_feature(cxx_lambdas)
# define BOOST_NO_CXX11_LAMBDAS
#endif
#if !__has_feature(cxx_local_type_template_args)
# define BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS
#endif
#if !__has_feature(cxx_noexcept)
# define BOOST_NO_CXX11_NOEXCEPT
#endif
#if !__has_feature(cxx_nullptr)
# define BOOST_NO_CXX11_NULLPTR
#endif
#if !__has_feature(cxx_range_for)
# define BOOST_NO_CXX11_RANGE_BASED_FOR
#endif
#if !__has_feature(cxx_raw_string_literals)
# define BOOST_NO_CXX11_RAW_LITERALS
#endif
#if !__has_feature(cxx_reference_qualified_functions)
# define BOOST_NO_CXX11_REF_QUALIFIERS
#endif
#if !__has_feature(cxx_generalized_initializers)
# define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX
#endif
#if !__has_feature(cxx_rvalue_references)
# define BOOST_NO_CXX11_RVALUE_REFERENCES
#endif
#if !__has_feature(cxx_strong_enums)
# define BOOST_NO_CXX11_SCOPED_ENUMS
#endif
#if !__has_feature(cxx_static_assert)
# define BOOST_NO_CXX11_STATIC_ASSERT
#endif
#if !__has_feature(cxx_alias_templates)
# define BOOST_NO_CXX11_TEMPLATE_ALIASES
#endif
#if !__has_feature(cxx_unicode_literals)
# define BOOST_NO_CXX11_UNICODE_LITERALS
#endif
#if !__has_feature(cxx_variadic_templates)
# define BOOST_NO_CXX11_VARIADIC_TEMPLATES
#endif
#if !__has_feature(cxx_user_literals)
# define BOOST_NO_CXX11_USER_DEFINED_LITERALS
#endif
#if !__has_feature(cxx_alignas)
# define BOOST_NO_CXX11_ALIGNAS
#endif
#if !__has_feature(cxx_trailing_return)
# define BOOST_NO_CXX11_TRAILING_RESULT_TYPES
#endif
#if !__has_feature(cxx_inline_namespaces)
# define BOOST_NO_CXX11_INLINE_NAMESPACES
#endif
#if !__has_feature(cxx_override_control)
# define BOOST_NO_CXX11_FINAL
#endif
#if !__has_feature(cxx_unrestricted_unions)
# define BOOST_NO_CXX11_UNRESTRICTED_UNION
#endif
#if !(__has_feature(__cxx_binary_literals__) || __has_extension(__cxx_binary_literals__))
# define BOOST_NO_CXX14_BINARY_LITERALS
#endif
#if !__has_feature(__cxx_decltype_auto__)
# define BOOST_NO_CXX14_DECLTYPE_AUTO
#endif
#if !__has_feature(__cxx_aggregate_nsdmi__)
# define BOOST_NO_CXX14_AGGREGATE_NSDMI
#endif
#if !__has_feature(__cxx_init_captures__)
# define BOOST_NO_CXX14_INITIALIZED_LAMBDA_CAPTURES
#endif
#if !__has_feature(__cxx_generic_lambdas__)
# define BOOST_NO_CXX14_GENERIC_LAMBDAS
#endif
// clang < 3.5 has a defect with dependent type, like following.
//
// template <class T>
// constexpr typename enable_if<pred<T> >::type foo(T &)
// { } // error: no return statement in constexpr function
//
// This issue also affects C++11 mode, but C++11 constexpr requires return stmt.
// Therefore we don't care such case.
//
// Note that we can't check Clang version directly as the numbering system changes depending who's
// creating the Clang release (see https://github.com/boostorg/config/pull/39#issuecomment-59927873)
// so instead verify that we have a feature that was introduced at the same time as working C++14
// constexpr (generic lambda's in this case):
//
#if !__has_feature(__cxx_generic_lambdas__) || !__has_feature(__cxx_relaxed_constexpr__)
# define BOOST_NO_CXX14_CONSTEXPR
#endif
#if !__has_feature(__cxx_return_type_deduction__)
# define BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION
#endif
#if !__has_feature(__cxx_variable_templates__)
# define BOOST_NO_CXX14_VARIABLE_TEMPLATES
#endif
#if !defined(__cpp_structured_bindings) || (__cpp_structured_bindings < 201606)
# define BOOST_NO_CXX17_STRUCTURED_BINDINGS
#endif
#if !defined(__cpp_if_constexpr) || (__cpp_if_constexpr < 201606)
# define BOOST_NO_CXX17_IF_CONSTEXPR
#endif
// Clang 3.9+ in c++1z
#if !__has_cpp_attribute(fallthrough) || __cplusplus < 201406L
# define BOOST_NO_CXX17_INLINE_VARIABLES
# define BOOST_NO_CXX17_FOLD_EXPRESSIONS
#endif
#if __cplusplus < 201103L
#define BOOST_NO_CXX11_SFINAE_EXPR
#endif
#if __cplusplus < 201400
// All versions with __cplusplus above this value seem to support this:
# define BOOST_NO_CXX14_DIGIT_SEPARATORS
#endif
//
// __builtin_unreachable:
#if defined(__has_builtin) && __has_builtin(__builtin_unreachable)
#define BOOST_UNREACHABLE_RETURN(x) __builtin_unreachable();
#endif
#if (__clang_major__ == 3) && (__clang_minor__ == 0)
// Apparently a clang bug:
# define BOOST_NO_CXX11_FIXED_LENGTH_VARIADIC_TEMPLATE_EXPANSION_PACKS
#endif
// Clang has supported the 'unused' attribute since the first release.
#define BOOST_ATTRIBUTE_UNUSED __attribute__((__unused__))
// Type aliasing hint.
#if __has_attribute(__may_alias__)
# define BOOST_MAY_ALIAS __attribute__((__may_alias__))
#endif
#ifndef BOOST_COMPILER
# define BOOST_COMPILER "Clang version " __clang_version__
#endif
// Macro used to identify the Clang compiler.
#define BOOST_CLANG 1

Some files were not shown because too many files have changed in this diff Show More