Skip to content

Commit

Permalink
Merge branch 'main' into dev/migrie/s/1032-elevation-qol
Browse files Browse the repository at this point in the history
  • Loading branch information
zadjii-msft committed Dec 15, 2020
2 parents b85e665 + 540cc33 commit 73b7b3a
Show file tree
Hide file tree
Showing 755 changed files with 122,456 additions and 1,178 deletions.
2 changes: 2 additions & 0 deletions .github/actions/spell-check/dictionary/apis.txt
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ NCRBUTTONDBLCLK
NOAGGREGATION
NOPROGRESS
NOREDIRECTIONBITMAP
ntprivapi
oaidl
ocidl
otms
Expand All @@ -60,6 +61,7 @@ rx
schandle
semver
serializer
shobjidl
SIZENS
spsc
sregex
Expand Down
4 changes: 4 additions & 0 deletions .github/actions/spell-check/expect/expect.txt
Original file line number Diff line number Diff line change
Expand Up @@ -167,6 +167,7 @@ bmp
BOLDFONT
BOOLIFY
bools
boostorg
Bopomofo
Borland
BOTTOMLEFT
Expand Down Expand Up @@ -1062,7 +1063,9 @@ IFont
ifstream
IGNOREEND
IHigh
IHosted
iid
IInitialize
IInput
IInspectable
IInteract
Expand Down Expand Up @@ -2836,3 +2839,4 @@ BBBBBCCC
abcd
LPMINMAXINFO
MINMAXINFO
lstrcmpi
34 changes: 34 additions & 0 deletions NOTICE.md
Original file line number Diff line number Diff line change
Expand Up @@ -217,3 +217,37 @@ 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.
```
2 changes: 1 addition & 1 deletion OpenConsole.sln
Original file line number Diff line number Diff line change
Expand Up @@ -307,7 +307,7 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAzBridge", "src\cas
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "fmt", "src\dep\fmt\fmt.vcxproj", "{6BAE5851-50D5-4934-8D5E-30361A8A40F3}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "src\cascadia\WpfTerminalTestNetCore\WpfTerminalTestNetCore\WpfTerminalTestNetCore.csproj", "{1588FD7C-241E-4E7D-9113-43735F3E6BAD}"
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "src\cascadia\WpfTerminalTestNetCore\WpfTerminalTestNetCore.csproj", "{1588FD7C-241E-4E7D-9113-43735F3E6BAD}"
ProjectSection(ProjectDependencies) = postProject
{A22EC5F6-7851-4B88-AC52-47249D437A52} = {A22EC5F6-7851-4B88-AC52-47249D437A52}
{84848BFA-931D-42CE-9ADF-01EE54DE7890} = {84848BFA-931D-42CE-9ADF-01EE54DE7890}
Expand Down
5 changes: 0 additions & 5 deletions build/config/SignConfig.NuGet.xml

This file was deleted.

5 changes: 0 additions & 5 deletions build/config/SignConfig.WindowsTerminal.xml

This file was deleted.

6 changes: 3 additions & 3 deletions doc/AddASetting.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@
`.../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
Expand Down
4 changes: 2 additions & 2 deletions doc/WIL.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
50 changes: 49 additions & 1 deletion doc/cascadia/profiles.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,7 @@
"duplicateTab",
"find",
"moveFocus",
"moveTab",
"newTab",
"nextTab",
"openNewTabDropdown",
Expand Down Expand Up @@ -117,6 +118,13 @@
],
"type": "string"
},
"MoveTabDirection": {
"enum": [
"forward",
"backward"
],
"type": "string"
},
"SplitState": {
"enum": [
"vertical",
Expand Down Expand Up @@ -159,6 +167,13 @@
],
"type": "string"
},
"CommandPaletteLaunchMode": {
"enum": [
"action",
"commandLine"
],
"type": "string"
},
"NewTerminalArgs": {
"properties": {
"commandline": {
Expand Down Expand Up @@ -498,6 +513,38 @@
}
]
},
"MoveTabAction": {
"description": "Arguments for moving a tab",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "moveTab" },
"direction": {
"$ref": "#/definitions/MoveTabDirection",
"description": "The direction to move the tab"
}
}
}
],
"required": [ "direction" ]
},
"CommandPaletteAction": {
"description": "Arguments for a commandPalette action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "commandPalette" },
"launchMode": {
"$ref": "#/definitions/CommandPaletteLaunchMode",
"default": "action",
"description": "Toggle command palette in either action or command line mode. If no value is provided, the palette will launch in action mode."
}
}
}
]
},
"Keybinding": {
"additionalProperties": false,
"properties": {
Expand All @@ -521,6 +568,7 @@
{ "$ref": "#/definitions/CloseTabsAfterAction" },
{ "$ref": "#/definitions/ScrollUpAction" },
{ "$ref": "#/definitions/ScrollDownAction" },
{ "$ref": "#/definitions/MoveTabAction" },
{ "type": "null" }
]
},
Expand Down Expand Up @@ -649,7 +697,7 @@
},
"rowsToScroll": {
"default": "system",
"description": "This parameter once allowed you to override the systemwide \"choose how many lines to scroll at one time\" setting. It no longer does so.",
"description": "This parameter once allowed you to override the systemwide \"choose how many lines to scroll at one time\" setting. It no longer does so. However, you can customize the number of lines to scroll in \"scrollUp\" and \"scrollDown\" bindings.",
"maximum": 999,
"minimum": 0,
"type": [ "integer", "string" ],
Expand Down
99 changes: 99 additions & 0 deletions doc/specs/#8324 - Application State (TSM).md
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
---
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
76 changes: 76 additions & 0 deletions doc/specs/settings-spec-template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
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]:
Loading

1 comment on commit 73b7b3a

@github-actions

This comment was marked as outdated.

Please sign in to comment.