Compare commits

..

135 Commits

Author SHA1 Message Date
Dustin L. Howett
21fa31b3b3 Migrate spelling-0.0.21 changes from main 2020-06-19 11:09:25 -05:00
Dustin L. Howett
bae1077228 Migrate spelling-0.0.19 changes from main 2020-06-19 11:09:25 -05:00
Mike Griese
45243bbee6 Merge remote-tracking branch 'origin/master' into dev/migrie/f/2046-Command-Palette-v2
# Conflicts:
#	src/cascadia/TerminalApp/ActionAndArgs.cpp
2020-06-19 11:09:25 -05:00
Mike Griese
52eb2e5faa Merge commit '827cc42' into dev/migrie/f/2046-Command-Palette-v2
# Conflicts:
#	doc/specs/#2046 - Command Palette.md
2020-06-19 11:07:48 -05:00
Mike Griese
8b094fdfde Merge commit 'db518c0' into dev/migrie/f/2046-Command-Palette-v2 2020-06-19 10:59:07 -05:00
Kayla Cinnamon
acd3ba7bd9 Update PR template with link to docs (#6583) 2020-06-19 08:19:28 -07:00
Kayla Cinnamon
e337faaaf8 Add 1.1 blog post to 2.0 roadmap (#6581) 2020-06-19 08:18:58 -07:00
Devon DeJohn
1fdceb0ea9 doc: copyedit the roadmap a little bit (#6587) 2020-06-18 22:17:48 -07:00
Leonard Hecker
4eaa0b83c7 Use early returns in TermControl::_KeyHandler (#6575)
## Summary of the Pull Request

This PR changes `TermControl::_KeyHandler` to use early returns, which you can think of as "guard clauses".
This has the benefit of a reduced nesting level, easier to understand control flow and opens op the way to more complex conditions.

## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

## Validation Steps Performed

Everything still works as expected.
2020-06-18 22:24:12 +00:00
Leonard Hecker
78ca722028 Fixed #6377: TerminalCore::_altGrAliasing is undefined by default (#6571)
## Summary of the Pull Request

Fixes #6377. `TerminalCore` does not initialize `_altGrAliasing`. The impact is minimized in WT because it defaults to `true` in higher layers. It's not initialized when WPF is driving.

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #6377
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
2020-06-18 22:09:45 +00:00
Dustin L. Howett
10bc1a6532 Introduce JsonUtilsNew as documented in #5875 (#6355)
Read the [JsonUtils Spec] for more details.

This pull request introduces the next version of JsonUtils. It is in a
separate file for ease of review and testing.

JsonUtilsNew will be renamed in a subsequent commit that rewrites our
JSON deserializers.

### Implementer's Notes

I went with telescoping exceptions for the key parsing code, because
it's totally possible that you can be five keys deep and encounter a
type error. This lets us encode information about all failures in the
chain instead of just the topmost one.

The original JsonUtilsNew code changed to use `decay` everywhere because
the tests wouldn't compile. We want to treat `GetValue<const guid>` _the
same as_ `GetValue<guid>`, and this lets us do so. `decay` is awesome.

I've been developing this with a shim that redirects `JsonUtils.h` to
`JsonUtilsNew.h`. I am not comfortable deleting the original until we've
moved off of it, and that _will_ be the subject of a followup PR.

## Validation Steps Performed

So many tests.

[JsonUtils Spec]: https://github.com/microsoft/terminal/blob/master/doc/cascadia/Json-Utility-API.md

Refs #2550
2020-06-18 00:27:42 +00:00
Leon Liang
6485a2b440 Spec: Advanced Tab Switcher (#3753)
<!-- 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 is the spec for the Advanced Tab Switcher. This would allow the user to navigate through a vertical list of tabs through a UI, similar to those found in VSCode and Visual Studio.

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References
#1502: Feature Request: Advanced Tab Switcher
#973: Ctrl+Tab toggling between two tabs

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Spec for #1502
* [x] CLA signed.
2020-06-17 17:30:24 +00:00
Dustin L. Howett
ffaba38fd4 Remove the WinTelnetEngine (#6526)
Nobody was using it.

Discussed in #2661.
2020-06-17 16:29:49 +00:00
Carlos Zamora
c1076a823d Fix openSettings misspelling in defaults (#6520)
Fixes #6486.
2020-06-15 15:35:15 -07:00
Mike Griese
888e72417d Only snap on key _downs_ (#6517)
## Summary of the Pull Request
Prior to #6309, we'd only snap on input for non-modifier key_down_ events. #6423 fixed this for modifier keys, but didn't fix this for keyups.

## References
* #6423 was an incomplete fix to this problem, which caused this regression

## PR Checklist
* [x] Closes #6481
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
2020-06-15 19:55:20 +00:00
Mike Griese
332d1744d9 Fix sending a NUL on alt key up (#6516)
## Summary of the Pull Request

Make sure to set the scancode for the manual alt-up's we're sending. If you don't, then terminalInput in the conpty is going to treat that keypress as an actual NUL, and send that to the connected client.

## References
* regressed in #6421 

## PR Checklist
* [x] Closes #6513
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed
Tested `showkeys -a`
2020-06-15 19:54:51 +00:00
Mike Griese
6d2fc5d1b9 Extract ActionAndArgs::FromJson into its own class (#6351)
## Summary of the Pull Request

Pulls the `ActionAndArgs` deserializing into its own class, separate from `AppKeyBindings`. Some 2.0 features are going to need to re-use these actions in their json, so we'll want one unified way of deserializing them.

## References

* Done primarily as part of the work on #2046/#5400/#5674 
* Also related: #1571/#5888 
* Will aggressively conflict with any open PRs that introduced keybindings (looking at #6299)

## PR Checklist
* [x] Closes nothing, this is code refactoring
* [x] I work here
* [x] Current tests passed
* [n/a] Requires documentation to be updated
2020-06-15 13:33:30 +00:00
Dustin L. Howett
5e2c4c66e3 Reintroduce the check for VT_INPUT_MODE in AdaptDispatch (#6485)
This commit reverts the removal of the "SSH hack" in #5383. It was
originally added as a solution to #4911, when we realized that SSH would
request the SS3 cursor key encoding but we weren't equipped to handle
it.

A number of folks have filed issues that, in summary, say "when I use
SSH, I can't select/copy/paste text". It turns out that SSH will _also_
pass through requests for mouse input. Terminal dutifully responds to
those requests, of course, by disabling mouse selection/copy/paste. SSH
is **NOT** actually in VT_INPUT_MODE, so it will never receive the mouse
messages.

It's important to note that even with #376 fixed, we are still required
to keep this check. With the closure of #376, we'll be able to convert
VT mouse input back into Win32 mouse input for Win32 applications . . .
but SSH also doesn't know how to handle Win32 mouse input.

Fixes #6476.
Fixes #6196.
Fixes #5704.
Fixes #5608.
2020-06-15 13:04:38 +00:00
greg904
c0ffc9b6dc Clear cached runs after translate_y (#6501)
"While re-reading the code, I found out that I forgot to do clear cached runs
after translate_y in c360b7588ff8d389b49a4ed60cdee51401a5e172."
2020-06-14 00:17:26 -07:00
greg904
c360b7588f Add fast path to til::bitmap::translate using bitshifts (#6493)
This commit adds a fast path to `til::bitmap::translate`: use bit shifts
when the delta is vertical.

Performance while printing the content of a big file, with the patch
from #6492 which hasn't been merged yet, in Release mode:

Before:
* translate represents 13.08% of samples in InvalidateScroll

After:
* translate represents  0.32% of samples in InvalidateScroll

## Validation

Tests passed.
2020-06-13 23:45:10 -07:00
Carlos Zamora
19fcbce459 Add keybinding arg to openSettings (#6299)
## Summary of the Pull Request
Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`.

## References
#5915 - mini-spec

## PR Checklist
* [x] Closes #2557 
* [x] Tests added/passed

## Detailed Description of the Pull Request / Additional comments
Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available.

## Validation Steps Performed
Added the following to my settings.json:
```json
{ "command": "openSettings", "keys":... },
{ "command": { "action": "openSettings" }, "keys":... },
{ "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "allFiles" }, "keys":... }
```
2020-06-12 21:19:18 +00:00
greg904
25df527743 Throttle scrollbar updates in TermControl to ~one per 8ms (#4608)
In addition to the below (original) description, this commit introduces
a ThrottledFunc template that can throttle _any_ function. It applies
that type to muffle updates to the scrollbar.

---

Redo #3531 but without the bug that it caused (#3622) which is why it
was reverted.

I'm sorry if I explain this badly. If you don't understand a part, make
sure to let me know and I will explain it better.

### Explanation

How it worked before: `Terminal` signals that viewport changed ->
`TermControl::_TerminalScrollPositionChanged` gets called on the
terminal thread -> it dispatches work for later to be ran the UI thread
to updates the scrollbar's values

Why it's bad:
* If we have many viewport changes, it will create a long stack of
  operations to run. Instead, we should just update the scroll bar with
  the most recent information that we know.
* Imagine if the rate that the work gets pushed on the UI thread is
  greater than the rate that it can handle: it might freeze?
* No need to be real time, we can wait just a little bit (8ms) to
  accumulate viewport changes before we actually change the scroll bar's
  value because it appears to be expensive (see perf below).

Now: `Terminal` signals that viewport changed ->
`TermControl::_TerminalScrollPositionChanged` gets called on the
terminal thread -> it tells the `ScrollBarUpdater` about a new update ->
the `ScrollBarUpdater` only runs one job (I don't know if that's the
right term) on the UI thread at a time. If a job is already running but
hasn't updated the scroll bar yet, it changes the setting in the already
existing job to update the scroll bar with the new values. A job "waits"
some time before doing the update to throttle updates because we don't
need real time scroll bar updates. -> eventually, it updates the scroll
bar If the user scrolls when a scroll bar update is pending, we keep the
scroll bar's Maximum and Minimum but let the user choose its new Value
with the `CancelPendingValueChange` method.

### Note

Also I changed a little bit the code from the Terminal to notify the
TermControl less often when possible.

I tried to scroll with the scroll bar, with the mouse wheel. I tried to
scroll while content is being outputted.

I tried to reproduce the crash from #2248 without success (good).

Co-authored-by: Leonard Hecker <leonard@hecker.io>

Closes #3622
2020-06-12 12:51:37 -07:00
Mike Griese
e8ece1645c Pass <Alt> to the application (#6461)
For mysterious reasons lost to the sands of time, XAML will _never_ pass
us a VK_MENU event. This is something that'll probably get fixed in
WinUI 3, but considering we're stuck on system XAML for the time being,
the only way to work around this bug is to pass the event through
manually. This change generalizes the F7 handler into a "direct key
event" handler that uses the same focus and tunneling method to send
different key events, and then uses it to send VK_MENU.

## Validation Steps Performed

Opened the debug tap, verified that I was seeing alt key ups.
Also used some alt keybindings to make sure I didn't break them.

Closes #6421
2020-06-11 15:41:16 -07:00
Mike Griese
827cc42a45 Finalize Command Palette Spec (#5674)
## Summary of the Pull Request

This PR aims to move the command palette spec out of the draft state and into a finalized state for inclusion in the 2.0 version of the Windows Terminal. 

Notably, I've added sections regarding the ability to run `wt` commandlines using the Command Palette UI, something we hadn't considered in the original draft, because `wt` commandlines didn't land for like _4 months_ after this first draft.

## References
* #2046 - the original command palette thread
* #2193 - the original draft PR
* #5400 - the new command palette megathread for WT 2.0, which I'll be updating with follow-up tasks as we work on implementing this.

## PR Checklist
* [x] Specs #2046
* [x] I work here
* [x] Is documentation

## Detailed Description of the Pull Request / Additional comments

_read the spec_
2020-06-11 21:33:20 +00:00
Mike Griese
7a94b8f725 stash these tests in progress 2020-06-11 16:29:06 -05:00
Mike Griese
db518c0b06 Fix 3 different bugs in the WPF control (#6464)
* [wpf] WM_KEYUP crashes on x64 #6444
  - Turns out that doing the `(uint)lParam` cast worked fine for the
    keydowns, because the value of lParam usually didn't have super
    high-order bits set. That's not the case for keyups, where the 30th
    bit is _always_ set. This is fixed by explicitly getting the byte
    with the scancode in it.
* [wpf] WM_KEYUP generates wrong value in Win32 input mode #6445
  - This was fixed by basically the same thing as the above.
* [wpf] WPF control crashes on startup trying to render cursor #6446
  - This was a regression from #6337. I forgot to initialize the brush
    used to paint the cursor, because the UWP version always uses color
    (but the WPF one relies on the text foreground color).
* Also adds a minor change to the WPF test app, so that the user can
  actually exit `win32-input-mode`.

* #6337 regressed #6446 
* #6309 regressed the other two.

Closes #6444
Closes #6445
Closes #6446
2020-06-11 18:05:43 +00:00
Mike Griese
e2f5f75471 start adding tests 2020-06-11 12:40:57 -05:00
Mike Griese
7ac7fd1de9 Merge remote-tracking branch 'origin/master' into dev/migrie/f/2046-Command-Palette-v2 2020-06-11 12:15:27 -05:00
Carlos Zamora
bcdccc533e Add Mini-Spec for openSettings (#5915)
The spec introduces a keybinding argument of 'target' to be able to open a specific settings file. When the Settings UI gets implemented, it will also become an option.

Alternative designs were presented but the 'target' model was decided on.
2020-06-11 10:12:08 -07:00
Dustin L. Howett
60630cf7c4 Fix the x86 build and re-enable x86 CI (#6467)
This was a miss.
2020-06-11 17:04:42 +00:00
WSLUser
7fc735525d Deps: Bump Newtonsoft.Json from 10.0.3 to 12.0.3 (#6369)
Bump Newtonsoft.Json from 10.0.3 to 12.0.3

## References
Part of #5297

## PR Checklist
* [ ] Closes (none)
* [x] CLA signed
* [ ] Tests added/passed N/A
* [ ] Requires documentation to be updated N/A
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

## Validation Steps Performed
CI builds successfully
2020-06-10 23:54:02 +00:00
greg904
30a6c1e10a Open the system menu when user right clicks the drag bar (#6443)
Related to #1375 ("Click/Right click icon should display
Minimize/Maximize/Close menu")
2020-06-10 22:56:36 +00:00
greg904
a921bbfebb Reduce latency with DXGI 1.3 GetFrameLatencyWaitableObject (#6435)
This pull request reduces input lag, especially with selection, by using
`IDXGISwapChain2::GetFrameLatencyWaitableObject`.

This is based on the [DXGI 1.3 documentation].

Excerpt from the [DXGI 1.3 improvement list]:
> The following functionality has been added in Microsoft DirectX
Graphics Infrastructure (DXGI) 1.3, which is included starting in
Windows 8.1.

Before, during rendering:
1. render frame
2. call `Present` on swap chain:
   2.a. blocks until it can present
   2.b. meanwhile, selection/text in terminal might have changed, but
     we're still using the frame that we rendered before blocking
   2.c. presents

After, during rendering:
1. block until we can present
2. render frame with latest data
3. call `Present` on swap chain:
  3.a. present without blocking

[DXGI 1.3 documentation]: https://docs.microsoft.com/en-us/windows/uwp/gaming/reduce-latency-with-dxgi-1-3-swap-chains
[DXGI 1.3 improvement list]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-1-3-improvements:
2020-06-10 22:35:14 +00:00
Michael Niksa
0c93b2ebbe Improve perf by avoiding vector reallocation in renderer clusters and VT output graphics options (#6420)
## Summary of the Pull Request
Caches vectors in the class and uses a new helper to opportunistically shrink/grow as viewport sizes change in order to save performance on alloc/free of commonly used vectors.

## PR Checklist
* [x] Scratches a perf itch.
* [x] I work here.
* [x] wil tests added
* [x] No add'l doc.
* [x] Am core contributor.

## Detailed Description of the Pull Request / Additional comments
Two fixes:
1. For outputting lots of text, the base renderer class spent a lot of time allocating and freeing and reallocating the `Cluster` vector that adapts the text buffer information into render clusters. I've now cached this vector in the base render class itself and I shrink/grow it based on the viewport update that happens at the top of every frame. To prevent too much thrashing in the downward/shrink direction, I wrote the `til::manage_vector` helper that contains a threshold to only shrink if it asks for small enough of a size relative to the existing one. I used 80% of the existing size as the threshold for this one.
2. For outputting lots of changing colors, the VT graphics output engine spent a bunch of time allocating and reallocating the vector for `GraphicsOptions`. This one doesn't really have a predictable size, but I never expect it to get extremely big. So I just held it in the base class.

## Validation Steps Performed
* [x] Ran the til unit test
* [x] Checked render cluster vector time before/after against `big.txt` from #1064
* [x] Checked VT graphics output vector time before/after against `cacafire`

Case | Before | After
---|---|---|
`big.txt` | ![image](https://user-images.githubusercontent.com/18221333/84088632-cbaa8400-a9a1-11ea-8932-04b2e12a0477.png) | ![image](https://user-images.githubusercontent.com/18221333/84088996-b6822500-a9a2-11ea-837c-5e32a110156e.png)
`cacafire` | ![image](https://user-images.githubusercontent.com/18221333/84089153-22648d80-a9a3-11ea-8567-c3d80efa16a6.png) | ![image](https://user-images.githubusercontent.com/18221333/84089190-34463080-a9a3-11ea-98e5-a236b12330d6.png)
2020-06-10 22:02:05 +00:00
Dustin L. Howett
8dcfd61278 WpfTest: Add an x86/Win32 build, make DPI aware (#6455)
This matches more closely how Visual Studio uses the WPF control.
It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 21:08:16 +00:00
Dustin L. Howett
9ce884c4fb Tie up some A11y loose threads (#6417)
This pull request moves WindowUiaProvider back into Win32 interactivity
and deletes all mention of it from Windows Terminal. Terminal does not
have a single toplevel window that requires Console-like UIA, as each
Xaml control inside it is in charge of its own destiny.

I've also merged `IUiaWindow` and `IConsoleWindow` back together, as
well as `WindowUiaProviderBase` and `WindowUiaProvider`.

Things look a lot more like they did before we tore them apart.

## PR Checklist
* [x] Closes #3564
* [x] CLA
* [x] Tests added/passed (manual)
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already

## Validation

Carlos validated conhost and terminal on this branch.
2020-06-10 15:15:26 +00:00
Mike Griese
dd684cbca1 implement a weighted ordering for command palette entries 2020-06-10 09:59:55 -05:00
Mike Griese
edc8b557e1 Add much better key chord text to the command palette 2020-06-10 08:53:34 -05:00
Mike Griese
7b791f572d Don't send a manual F7 keyup (#6442)
## Summary of the Pull Request

When someone asked "Do we need to send a F7 keyup too" in #6309, the right answer was actually _no_. Turns out that while XAML will eat the F7 key**down**, it _won't_ eat the F7 key**up**. 

## References

* regressed in #6309

## PR Checklist
* [x] Closes #6438 
* [x] I work here
* [ ] Tested manually
* [n/a] Requires documentation to be updated

## Validation Steps Performed

* Checked this with the debug tap
2020-06-09 23:16:38 +00:00
Mike Griese
82f968d8d5 If a key is bound to that action, then display the keybinding in the palette 2020-06-09 16:58:51 -05:00
Mike Griese
e03e46b69e Don't snap on input nor dismiss selection for just a modifier key (#6431)
Does what it says on the label. Pure modifier keys weren't making it
this far at all prior to #6309. This PR changes these methods to make
sure that we only dismiss a selection or snap on input when the key
pressed isn't a modifier key.

## References

* regressed in #6309

## PR Checklist
* [x] Closes #6423
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed

* Tried to repro this in the Terminal, couldn't anymore.
2020-06-09 21:49:39 +00:00
greg904
f9b1238f30 Set tab title as early as possible (#6433)
When opening a new tab, it takes a few milliseconds before title to
appears. This PR makes it instantaneous.

* Updated the Terminal so that it can load the title from the settings
  before it is initialized.
* Load terminal settings in TermControl constructor before the terminal
  is initialized (see above).
* Update Tab so that it sets the TabViewItem's title in the constructor
  (in Tab::_MakeTabViewItem) instead of waiting for the VT sequence to
  set the title (from what I understand).

NOTE 1: there is a similar problem with the tabview icon which is not
fixed by this PR.

NOTE 2: This is only a problem with animations disabled because
otherwise the title fades in so there is enough time for it to be set
when it becomes visible.

## Validation

I ran the terminal and opened a new tab. The title appears instantly.
2020-06-09 21:47:13 +00:00
Mike Griese
67c7969879 I couldn't tell you how long this took 2020-06-09 16:30:55 -05:00
Dustin L. Howett
48b99faed1 wpf: add a .NET Core WPF Test project for the WPF Control (#6441)
This commit introduces a new project that lets you F5 a working instance
of the Wpf Terminal Control.

To make the experience as seamless as possible, I've introduced another
solution platform called "DotNet_x64Test". It is set to build the WPF
projects for "Any CPU" and every project that PublicTerminalCore
requires (including itself) for "x64". This is the only way to ensure
that when you press F5, all of the native and managed dependencies get
updated.

It's all quite cool when it works.
2020-06-09 13:41:42 -07:00
Kayla Cinnamon
8b201c1eb0 Upload Windows Terminal 2.0 roadmap (#6419)
<!-- 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
Upload the roadmap for Windows Terminal 2.0 and link to it on the README.

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

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

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
2020-06-09 20:27:00 +00:00
Carlos Zamora
968462fffd Remove parentheses from Preview and Dev build (#6418)
## Summary of the Pull Request
Remove parentheses from the Preview and Dev build. Now they're called Windows Terminal Preview and Windows Terminal Dev Build respectively.

Also removed them from other identifiers of Terminal for consistency.

## PR Checklist
* [X] Closes #5974
2020-06-09 18:32:27 +00:00
Mike Griese
b3d8f0e279 Merge remote-tracking branch 'origin/master' into dev/migrie/f/2046-Command-Palette-v2 2020-06-09 12:33:36 -05:00
Mike Griese
f32761849f Add support for win32-input-mode to conhost, ConPTY, Terminal (#6309)
Adds support for `win32-input-mode` to conhost, conpty, and the Windows
Terminal.

* The shared `terminalInput` class supports sending these sequences when
  a VT client application requests this mode.
* ConPTY supports synthesizing `INPUT_RECORD`s from the input sent to it
  from a terminal
* ConPTY requests this mode immediately on startup (if started with a
  new flag, `PSEUDOCONSOLE_WIN32_INPUT_MODE`)
* The Terminal now supports sending this input as well, when conpty asks
  for it.

Also adds a new ConPTY flag `PSEUDOCONSOLE_WIN32_INPUT_MODE` which
requests this functionality from conpty, and the Terminal requests this
by default.

Also adds `experimental.input.forceVT` as a global setting to let a user
opt-out of this behavior, if they don't want it / this ends up breaking
horribly.

## Validation Steps Performed
* played with this mode in vtpipeterm
* played with this mode in Terminal
* checked a bunch of scenarios, as outlined in a [comment] on #4999

[comment]: https://github.com/microsoft/terminal/issues/4999#issuecomment-628718631

References #4999: The megathread
References #5887: The spec

Closes #879
Closes #2865
Closes #530 
Closes #3079
Closes #1119
Closes #1694 
Closes #3608 
Closes #4334
Closes #4446
2020-06-08 22:31:28 +00:00
Mike Griese
55d8df4628 Remove the shell extension from directory backgrounds (#6415)
We're removing this because of MSFT:24623699, which prevents us from being able to do the right thing when we're called on the background of a directory for a range of OS builds. 

#6414 will track re-adding this to the Terminal when the original issue is closed.

* [x] closes #6245
* I work here
2020-06-08 21:35:39 +00:00
Dustin L. Howett
e3ee5838a7 Move all wildcards into targets or expand them (#6406)
Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must
be generated by targets.

We mostly use wildcards for pulling in PRI files that are dumped on disk
by the translation tool. We don't want to check those in, so we can't
expand references to them.

To that end, I've introduced a new target that will take a list of
folders containing resw files and expand wildcards under them.

All[1] other wildcards have been moved into their respective targets
_or_ simply expanded.

[1]: Nothing has complained about the resource wildcards in
CascadiaResources.build.items, so I haven't exploded it yet.

Fixes #6214.
2020-06-08 14:01:47 -07:00
James Holderness
ccea66710c Improve the legacy color conversions (#6358)
This PR provides a faster algorithm for converting 8-bit and 24-bit
colors into the 4-bit legacy values that are required by the Win32
console APIs. It also fixes areas of the code that were incorrectly
using a simple 16-color conversion that didn't handle 8-bit and 24-bit
values.

The faster conversion algorithm should be an improvement for issues #783
and #3950.

One of the main points of this PR was to fix the
`ReadConsoleOutputAttribute` API, which was using a simplified legacy
color conversion (the original `TextAttribute:GetLegacyAttributes`
method), which could only handle values from the 16-color table. RGB
values, and colors from the 256-color table, would be mapped to
completely nonsensical values. This API has now been updated to use the
more correct `Settings::GenerateLegacyAttributes` method.

But there were also a couple of other places in the code that were using
`GetLegacyAttributes` when they really had no reason to be working with
legacy attributes at all. This could result in colors being downgraded
to 4-bit values (often badly, as explained above), when the code was
already perfectly capable of displaying the full 24-bits.

This included the fill colors in the IME composer (in `ConsoleImeInfo`),
and the construction of the highlighting colors in the color
search/selection handler (`Selection::_HandleColorSelection`). I also
got rid of some legacy attribute code in the `Popup` class, which was
originally intended to update colors below the popup when the settings
changed, but actually caused more problems than it solved.

The other major goal of this PR was to improve the performance of the
`GenerateLegacyAttributes` method, since the existing implementation
could be quite slow when dealing with RGB values.

The simple cases are handled much the same as they were before. For an
`IsDefault` color, we get the default index from the
`Settings::_wFillAttribute` field. For an `IsIndex16` color, the index
can just be returned as is.

For an `IsRgb` color, the RGB components are compressed down to 8 bits
(3 red, 3 green, 2 blue), simply by dropping the least significant bits.
This 8-bit value is then used to lookup a representative 16-color value
from a hard-coded table. An `IsIndex256` color is also converted with a
lookup table, just using the existing 8-bit index.

The RGB mapping table was calculated by taking each compressed 8-bit
color, and picking a entry from the _Campbell_ palette that best
approximated that color. This was done by looking at a range of 24-bit
colors that mapped to the 8-bit value, finding the best _Campbell_ match
for each of them (using a [CIEDE2000] color difference calculation), and
then the most common match became the index that the 8-bit value would
map to.

The 256-color table was just a simpler version of this process. For each
entry in the table, we take the default RGB palette value, and find it's
closest match in the _Campbell_ palette.

Because these tables are hard-coded, the results won't adjust to changes
in the palette. However, they should still produce reasonable results
for palettes that follow the standard ANSI color range. And since
they're only a very loose approximation of the colors anyway, the exact
value really isn't that important.

That said, I have tried to make sure that if you take an RGB value for a
particular index in a reasonable color scheme, then the legacy color
mapped from that value should ideally match the same index. This will
never be possible for all color schemes, but I have tweaked a few of the
table entries to improve the results for some of the common schemes.

One other point worth making regarding the hard-coded tables: even if we
wanted to take the active palette into account, that wouldn't actually
be possible over a conpty connection, because we can't easily know what
color scheme the client application is using. At least this way the
results in conhost are guaranteed to be the same as in the Windows
Terminal.

[CIEDE2000]: https://en.wikipedia.org/wiki/Color_difference#CIEDE2000

## Validation Steps Performed

This code still passes the `TextAttributeTests` that check the basic
`GetLegacyAttribute` behaviour and verify the all legacy attributes
roundtrip correctly. However, some of the values in the `RgbColorTests`
had to be updated, since we're now intentionally returning different
values as a result of the changes to the RGB conversion algorithm.

I haven't added additional unit tests, but I have done a lot of manual
testing to see how well the new algorithm works with a range of colors
and a variety of different color schemes. It's not perfect in every
situation, but I think it works well enough for the purpose it serves.

I've also confirmed that the issues reported in #5940 and #6247 are now
fixed by these changes. 

Closes #5940 
Closes #6247
2020-06-08 19:05:06 +00:00
Dustin Howett
4a1f2d3c09 Merge remote-tracking branch 'openconsole/inbox' 2020-06-05 16:25:45 -07:00
Dustin Howett
2aaad9688a Reflect OS build fixes back from f90f3bf99
Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 272dfa1c4ad5e4202c4c56f3db7a445dc0b003cf
2020-06-05 23:25:23 +00:00
Dustin L. Howett
2d18874c8e Make the conversion from WORD to TextAttribute explicit (#6380)
In Windows, we build with /Zc:wchar_t- (which makes wchar_t an unsigned
short typedef.) This causes build breaks when we compare two wchar_t
values (or a wchar_t and an enum class that's of type wchar_t) and the
compiler decides that it might want to _promote them to TextAttribute_
before doing the comparison.
2020-06-05 23:20:32 +00:00
Dustin Howett
935702cde9 Merged PR 4770883: Migrate OSS changes up to f90f3bf99
Dustin Howett (1):
      Merge remote-tracking branch 'openconsole/inbox' into HEAD

James Holderness (1):
      Improve support for VT character sets (CC-4496)

Related work items: MSFT:26791619
2020-06-05 21:40:03 +00:00
Mike Griese
f90f3bf998 Update the tab's close button color to match the tab text color (#5789)
## Summary of the Pull Request

When we select a color for the tab, we update the foreground color of the text so that it maintains acceptable contrast with the new tab color. However, we weren't also updating the foreground color of the close button.

This is understandable though, because apparently this wasn't fixable until MUX 2.4 arrived. I'm not a XAML expert, but I know that setting this key only works when we're using MUX 2.4, so I'm assuming something about the TabView implementation changed in that release. _This PR is marked as a draft until #5778 is merged, then I'll re-target to master._

## References
* #5778 - PR to move to MUX 2.4
* This bug was introduced with the tab color picker in #3789

## PR Checklist
* [x] Closes #5780
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed
A light tab color:
![image](https://user-images.githubusercontent.com/18356694/81303943-00918700-9042-11ea-86e6-7bdfe343c4ca.png)

A dark tab color:
![image](https://user-images.githubusercontent.com/18356694/81303953-04250e00-9042-11ea-8db2-be97af519fae.png)
2020-06-05 19:12:28 +00:00
Dustin Howett
b47df4b19d Last round of master spelling fixes 2020-06-05 12:03:20 -07:00
Dustin Howett
b822cfb178 spelling II 2020-06-05 11:58:25 -07:00
Dustin Howett
026ba34de1 spelling I 2020-06-05 11:57:17 -07:00
Mike Griese
bb4c73cc79 Add support for compact tab sizing (#5787)
## Summary of the Pull Request

Really couldn't be more starightforward. MUX 2.4 added support for "compact" sized tabs. This PR (targeting the 2.4 PR currently, will move to `master` when that merges) enables users to specify `"tabWidthMode": "compact"` in their global settings to get this behavior.

## References
* #5778 - PR to move to MUX 2.4
* [microsoft-ui-xaml#2016](https://github.com/microsoft/microsoft-ui-xaml/pull/2016) - the MUX PR for compact tab sizing.
* #597 - Tab sizing options?

## PR Checklist
* [x] I don't think we have an issue for this, though I could be wrong.
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

In this screenshot, I'm hovering over tab 2, but the ubuntu tab is focused:
![image](https://user-images.githubusercontent.com/18356694/81302365-e6ef4000-903f-11ea-9ce3-5f5ce92e5ba4.png)

In this screenshot, tab 2 is focused:
![image](https://user-images.githubusercontent.com/18356694/81302383-ea82c700-903f-11ea-9820-92348d5adc64.png)
2020-06-05 18:51:04 +00:00
Michael Niksa
c3ea7310c1 fix spell things I forced into master. 2020-06-05 11:28:19 -07:00
Mike Griese
038d6e5faf First draft of a spec for panes with non-terminal content (#1080)
Co-authored-by: Michael Niksa <miniksa@microsoft.com>

putting outdated draft spec into drafts folder and closing PR. CI has no function on docs.
2020-06-05 11:14:01 -07:00
Michael Niksa
b051e78d40 Spec for tab tear off and default app (#2080)
docs have no build, cleaning out draft spec from PR queue
2020-06-05 11:08:32 -07:00
Dustin L. Howett (MSFT)
1711c76234 Move to Microsoft.UI.Xaml 2.4.0 (#5778)
This brings support for "Compact" tab sizing, which compresses all inactive tabs to just the size of their icons plus the close button. Neat!

It also just keeps us generally up-to-date and good citizens.
2020-06-05 17:07:03 +00:00
Leonard Hecker
e455d4b159 Allow Ctrl+Alt <> AltGr aliasing to be disabled (#6212)
## Summary of the Pull Request

Some people wish to use Ctrl+Alt combinations without Windows treating those as an alias for AltGr combinations. This PR adds a new `altGrAliasing` setting allowing one to control this behavior.

## PR Checklist
* [x] Closes #6211
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Manual testing
* [x] Requires documentation to be updated: https://github.com/MicrosoftDocs/terminal/issues/50
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

## Validation Steps Performed

* Choose a German keyboard layout
* Using `showkey -a` ensured that both `Ctrl+Alt+Q/E` and `AltGr+Q/E` produce `@/€`
* Added `"altGrAliasing": false` to the WSL profile
* Using `showkey -a` ensured `Ctrl+Alt+Q/E` now produces `^[^Q/E` while `AltGr+Q/E` continues to produce `@/€`
2020-06-05 16:11:41 +00:00
Dustin Howett
f1c9fbd080 Merge remote-tracking branch 'openconsole/inbox' into HEAD 2020-06-04 15:10:11 -07:00
Dustin Howett
efce279c5c Reflect OS build fixes on 7b489128ac back to inbox
Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 677d15a4e298a0e1e3ce093bc1dff8d832e3c2b1

Related work items: #26765368
2020-06-04 22:09:17 +00:00
James Holderness
96a77cb74b Improve support for VT character sets (#4496)
This PR improves our VT character set support, enabling the [`SCS`]
escape sequences to designate into all four G-sets with both 94- and
96-character sets, and supports invoking those G-sets into both the GL
and GR areas of the code table, with [locking shifts] and [single
shifts]. It also adds [`DOCS`] sequences to switch between UTF-8 and the
ISO-2022 coding system (which is what the VT character sets require),
and adds support for a lot more characters sets, up to around the level
of a VT510.

[`SCS`]: https://vt100.net/docs/vt510-rm/SCS.html
[locking shifts]: https://vt100.net/docs/vt510-rm/LS.html
[single shifts]: https://vt100.net/docs/vt510-rm/SS.html
[`DOCS`]: https://en.wikipedia.org/wiki/ISO/IEC_2022#Interaction_with_other_coding_systems

## Detailed Description of the Pull Request / Additional comments

To make it easier for us to declare a bunch of character sets, I've made
a little `constexpr` class that can build up a mapping table from a base
character set (ASCII or Latin1), along with a collection of mappings for
the characters the deviate from the base set. Many of the character sets
are simple variations of ASCII, so they're easy to define this way.

This class then casts directly to a `wstring_view` which is how the
translation tables are represented in most of the code. We have an array
of four of these tables representing the four G-sets, two instances for
the active left and right tables, and one instance for the single shift
table.

Initially we had just one `DesignateCharset` method, which could select
the active character set. We now have two designate methods (for 94- and
96- character sets), and each takes a G-set number specifying the target
of the designation, and a pair of characters identifying the character
set that will be designated (at the higher VT levels, character sets are
often identified by more than one character).

There are then two new `LockingShift` methods to invoke these G-sets
into either the GL or GR area of the code table, and a `SingleShift`
method which invokes a G-set temporarily (for just the next character
that is output).

I should mention here that I had to make some changes to the state
machine to make these single shift sequences work. The problem is that
the input state machine treats `SS3` as the start of a control sequence,
while the output state machine needs it to be dispatched immediately
(it's literally the _Single Shift 3_ escape sequence). To make that
work, I've added a `ParseControlSequenceAfterSs3` callback in the
`IStateMachineEngine` interface to decide which behavior is appropriate.

When it comes to mapping a character, it's simply an array reference
into the appropriate `wstring_view` table. If the single shift table is
set, that takes preference. Otherwise the GL table is used for
characters in the range 0x20 to 0x7F, and the GR table for characters
0xA0 to 0xFF (technically some character sets will only map up to 0x7E
and 0xFE, but that's easily controlled by the length of the
`wstring_view`).

The `DEL` character is a bit of a special case. By default it's meant to
be ignored like the `NUL` character (it's essentially a time-fill
character). However, it's possible that it could be remapped to a
printable character in a 96-character set, so we need to check for that
after the translation. This is handled in the `AdaptDispatch::Print`
method, so it doesn't interfere with the primary `PrintString` code
path.

The biggest problem with this whole process, though, is that the GR
mappings only really make sense if you have access to the raw output,
but by the time the output gets to us, it would already have been
translated to Unicode by the active code page. And in the case of UTF-8,
the characters we eventually receive may originally have been composed
from two or more code points.

The way I've dealt with this was to disable the GR translations by
default, and then added support for a pair of ISO-2022 `DOCS` sequences,
which can switch the code page between UTF-8 and ISO-8859-1. When the
code page is ISO-8859-1, we're essentially receiving the raw output
bytes, so it's safe to enable the GR translations. This is not strictly
correct ISO-2022 behavior, and there are edge cases where it's not going
to work, but it's the best solution I could come up with.

## Validation Steps Performed

As a result of the `SS3` changes in the state machine engine, I've had
to move the existing `SS3` tests from the `OutputEngineTest` to the
`InputEngineTest`, otherwise they would now fail (technically they
should never have been output tests).

I've added no additional unit tests, but I have done a lot of manual
testing, and made sure we passed all the character set tests in Vttest
(at least for the character sets we currently support). Note that this
required a slightly hacked version of the app, since by default it
doesn't expose a lot of the test to low-level terminals, and we
currently identify as a VT100.

Closes #3377
Closes #3487
2020-06-04 19:40:15 +00:00
Dustin Howett
b1715479bd Merged PR 4764832: Migrate OSS changes up to 7b489128ac
Related work items: #26765368
2020-06-04 19:21:33 +00:00
Mike Griese
d71d8d7b32 Ready for review. 2020-06-04 12:29:22 -05:00
Mike Griese
7b489128ac Add a test to ensure support for trailing commas in settings.json (#6312)
## Summary of the Pull Request

Adds support for trailing commas in our json files. 

## References

* Enabled due to the excellent work over in https://github.com/open-source-parsers/jsoncpp/pull/1098

## PR Checklist
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
2020-06-04 16:57:06 +00:00
Mike Griese
9d411d405c Make the commands a map, so we can override on "name" 2020-06-04 11:48:38 -05:00
Mike Griese
58be8cd117 Tons of commenting 2020-06-04 11:21:46 -05:00
Mike Griese
487f33ee89 Merge commit '6e6979abe' into dev/migrie/f/2046-Command-Palette-v2
# Conflicts:
#	src/cascadia/TerminalApp/ActionAndArgs.cpp
#	src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp
2020-06-04 10:15:40 -05:00
Mike Griese
829beda501 Merge remote-tracking branch 'origin/master' into dev/migrie/f/2046-Command-Palette-v2
# Conflicts:
#	src/cascadia/TerminalApp/GlobalAppSettings.cpp
#	src/cascadia/TerminalApp/GlobalAppSettings.h
2020-06-04 10:02:40 -05:00
Mike Griese
6e6979abe8 Extract ActionAndArgs::FromJson into it's own class, so it can be re-used later 2020-06-04 09:28:21 -05:00
Mike Griese
1fcd95704d Draw the cursor underneath text, and above the background (#6337)
## Summary of the Pull Request

![textAboveCursor003](https://user-images.githubusercontent.com/18356694/83681722-67a24d00-a5a8-11ea-8d9b-2d294065e4e4.gif)

This is the plan that @miniksa suggested to me. Instead of trying to do lots of work in all the renderers to do backgrounds as one pass, and foregrounds as another, we can localize this change to basically just the DX renderer. 
1. First, we give the DX engine a "heads up" on where the cursor is going to be drawn during the frame, in `PrepareRenderInfo`.
  - This function is left unimplemented in the other render engines.
2. While printing runs of text, the DX renderer will try to paint the cursor in `CustomTextRenderer::DrawGlyphRun` INSTEAD of `DxEngine::PaintCursor`. This lets us weave the cursor background between the text background and the text. 

## References

* #6151 was a spec in this general area. I should probably go back and update it, and we should probably approve that first.
* #6193 is also right up in this mess

## PR Checklist
* [x] Closes #1203
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

* This is essentially `"cursorTextColor": "textForeground"` from #6151.
* A follow up work item is needed to add support for the current behavior, (`"cursorTextColor": null`), and hooking up that setting to the renderer.
2020-06-04 12:58:22 +00:00
Mike Griese
e1888b0a29 Spec for Improved keyboard handling in Conpty (#5887)
## Summary of the Pull Request

We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences. 

This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again. 

## PR Checklist
* [x] Specs #4999
* [x] I work here
* [x] is a spec

## Detailed Description of the Pull Request / Additional comments
_read the spec_
2020-06-04 12:42:33 +00:00
Mike Griese
52c0145c64 Add a helper to skip nuget restore during local builds (#6339)
Running `nuget restore` on every build is pretty unnecessary - usually, you _know_ when you need to run it. For the inner dev loop, this is a few seconds on every `bx` build. 

This adds a environment variable you can set to skip the `nuget restore` part of a `bcz` build.

Add the following to your `.razzlerc.cmd`:
```cmd
set _SKIP_NUGET_RESTORE=1
```

and `bcz` (and the other helpers) _won't_ perform a nuget restore on every build.
2020-06-04 07:39:30 -05:00
Dustin L. Howett (MSFT)
fe86844996 doc: Propose a JsonUtils replacement by writing documentation (#5875) 2020-06-03 22:54:54 -07:00
Dustin L. Howett (MSFT)
18e75bb954 Replace manual get/set code in GlobalAppSettings with GETSET_PROPERTY (#5931)
## Summary of the Pull Request

This pull request removes all of the custom `Get` and `Set` implementations from GlobalAppSettings and replaces them with `GETSET_PROPERTY`. This will be required if we ever convert it to a WinRT class, but for now it's simply niceness-improving.

## References

Required #5847 to land.

## PR Checklist
* [ ] Closes norhing
* [x] CLAd
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already
2020-06-03 22:51:46 +00:00
Michael Niksa
9b075e985a Fix line drawing during IME operations. (#6223)
## Summary of the Pull Request
Restores proper line drawing during IME operations in `conhost`

## PR Checklist
* [x] Closes #803
* [x] I work here.
* [x] Tested manually.
* [x] Check the performance of this and see if it's worse-enough to merit a more confusing algorithm. It was worse for the majority case so I scoped it.
* [x] No doc, it should have worked this way.
* [x] Am core contributor.

## Detailed Description of the Pull Request / Additional comments
- Changed `ConsoleImeInfo::s_ConvertToCells` to be less confusing. It's doing about the same thing, but it's way easier to read now and the compiler/linker/optimizer should just be the same.
- Edited `Renderer::_PaintBufferOutputHelper` to check each attribute for line drawing characters as the right half of a two-col character might have different line drawing characters than the left-half.

## Validation Steps Performed
- [x] Manual operation of IME in conhost with Japanese IME.
- [x] Manual operation of IME in conhost with Chinese IME.
- [x] Manual operation of IME in conhost with Chinese (Traditional) IME.
- [x] Manual operation of IME in conhost with and Korean IME. - @leonMSFT says Korean doesn't work this way. But Korean is broken worse in that it's not showing suggestions at all. Filing new bug. #6227 
- [x] Validated against API-filling calls through `SetConsoleTextAttribute` per @j4james's sample code
2020-06-03 22:21:04 +00:00
Dustin L. Howett
413b658805 Remove more serializers missed in 6394e5d70 (#6321)
Every time somebody sees these they think they have to write new ones for their new things.
2020-06-03 16:08:20 +00:00
Dustin L. Howett
eccfb537ad tools: add a powershell script to generate CPWD from the UCD (#5946)
This commit introduces Generate-CodepointWidthsFromUCD, a powershell
(7+) script that will parse a UCD XML database in the UAX 42 format from
https://www.unicode.org/Public/UCD/latest/ucdxml/ and generate
CodepointWidthDetector's giant width array.

By default, it will emit one UnicodeRange for every range of non-narrow
glyphs with a different Width + Emoji + Emoji Presentation class;
however, it can be run in "packing" and "full" mode.

* Packing mode: ignore the width/emoji/pres class and combine adjacent
  runs that CPWD will treat the same.
     * This is for optimizing the number of individual ranges emitted
       into code.
* Full mode: include narrow codepoints (helpful for visualization)

It also supports overrides, provided in an XML document of the same format
as the UCD itself. Entries in the overrides files are applied after the
entire UCD is read and will replace any impacted ranges.

The output (when packing) looks like this:

```c++
// Generated by Generate-CodepointWidthsFromUCD -Pack:True -Full:False
// on 05/17/2020 02:47:55 (UTC) from Unicode 13.0.0.
// 66182 (0x10286) codepoints covered.
static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{
    UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous },
    UnicodeRange{ 0xa4, 0xa4, CodepointWidth::Ambiguous },
    UnicodeRange{ 0xa7, 0xa8, CodepointWidth::Ambiguous },
    .
    .
    .
    UnicodeRange{ 0x1f210, 0x1f23b, CodepointWidth::Wide },
    UnicodeRange{ 0x1f37e, 0x1f393, CodepointWidth::Wide },
    UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous },
};
```

The output (when overriding) looks like this:

```c++
// Generated by Generate-CodepointWidthsFromUCD.ps1 -Pack:True -Full:False -NoOverrides:False
// on 5/22/2020 11:17:39 PM (UTC) from Unicode 13.0.0.
// 321205 (0x4E6B5) codepoints covered.
// 240 (0xF0) codepoints overridden.
static constexpr std::array<UnicodeRange, 23> s_wideAndAmbiguousTable{
    UnicodeRange{ 0xa1, 0xa1, CodepointWidth::Ambiguous },
    ...
    UnicodeRange{ 0xfe20, 0xfe2f, CodepointWidth::Narrow }, // narrow combining ligatures (split into left/right halves, which take 2 columns together)
    ...
    UnicodeRange{ 0x100000, 0x10fffd, CodepointWidth::Ambiguous },
};
```
2020-06-03 07:16:14 +00:00
Mike Griese
f5dad2f586 Fix a crash with this method when running unpackaged (#6314)
## Summary of the Pull Request

I was debugging the terminal unpackaged, and noticed that this method crashes immediately. I'm gonna bet that this functionality only works when the app is installed as a package. Wrapping this whole method up in one big ol' `try/catch` seems to fix the immediate crash.

## References

* Introduced in #4908 

## PR Checklist
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

We _could_ display a warning if the user has this property set and is running the terminal unpackaged, to clue them in that it won't work? I'm willing to file a follow-up for that, but I think we should fix the crash _now_.

## Validation Steps Performed
* Ran the terminal successfully unpackaged.
2020-06-03 00:17:52 +00:00
Mike Griese
88db0e6102 Add support for --title to the wt.exe commandline args (#6296)
## Summary of the Pull Request

Adds support for setting the terminal `title` with the commandline argument `--title <title>`.

## PR Checklist
* [x] Closes #6183
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated - probably does, yea

## Detailed Description of the Pull Request / Additional comments

* I wasn't sure how we felt about `-t` being the short version of this argument, so I left it out. If we're cool with that, adding it wouldn't be hard.

## Validation Steps Performed

![image](https://user-images.githubusercontent.com/18356694/83450866-afe03480-a41b-11ea-84e7-9134474fdd7a.png)
2020-06-02 18:52:08 +00:00
Mike Griese
5e51ba4d1f DEPS: Update CLI11 to 1.9 (#6307)
Updates CLI11 to 1.9. Doesn't look like any of the tests broke.

* [x] I work here
* [x] Ran existing tests
2020-06-02 18:51:17 +00:00
Anurag Thakur
a34f1e2ad4 Animate Hover state change of CaptionButtons (#6303)
<!-- 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
As discussed in #6293 , this PR adds a fade animation to button background when pointer hover ends
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #6293
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- 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
Added storyboarded coloranimations to the visualstategroup of captionbuttons
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Tested manually
2020-06-02 18:50:18 +00:00
Mike Griese
7a258f934b DEPS: Update jsoncpp to 1.9.3 (#6308)
Updates jsoncpp to 1.9.3. Doesn't look like any of the tests broke.

* [x] I work here
* [x] Ran existing tests

I'll file a follow-up PR for adding trailing comma support, as mentioned in https://github.com/microsoft/terminal/issues/4232#issuecomment-634126486
2020-06-02 18:50:06 +00:00
Michael Niksa
48b3262eaa Update wil. Fixes GDI handle leak (#6229)
## Summary of the Pull Request
When resizing the window title, a GDI object would be leaked. This has to do with our island message handler using `wil` to track these objects and `wil` having a bug.

## References
microsoft/wil#100

## PR Checklist
* [x] Closes #5949 
* [x] I work here.
* [x] Tested manually
* [x] Doc not required.
* [x] Am core contributor.

## Validation Steps Performed
* [x] Added the GDI Objects column to Task Manager, set the Terminal to use the `titleWidth` size tabs, then changed the title a bunch with PowerShell. Confirmed repro before (increasing GDI count). Confirmed it's gone after (no change to object count).
2020-06-01 22:29:05 +00:00
Mike Griese
8987486e85 Add support for --fullscreen, --maximized (#6139)
## Summary of the Pull Request

Adds two new flags to the `wt.exe` alias:

* `--maximized,-M`: Launch the new Terminal window maximized. This flag cannot be combined with `--fullscreen`.
* `--fullscreen,-F`: Launch the new Terminal window fullscreen. This flag cannot be combined with `--maximized`.

## References
* This builds on the work done in #6060.
* The cmdline args megathread: #4632

## PR Checklist
* [x] Closes #5801
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

* I had to move the commandline arg parsing up a layer from `TerminalPage` to `AppLogic`, because `AppLogic` controls the Terminal's settings, including launch mode settings. This seems like a reasonable change, to put both the settings from the file and the commandline in the same place.
  - **Most of the diff is that movement of code**

* _"What happens when you try to pass both flags, like `wtd -M -F new-tab`?"_:
![image](https://user-images.githubusercontent.com/18356694/82679939-3cffde00-9c11-11ea-8d88-03ec7db83e59.png)

## Validation Steps Performed
* Ran a bunch of commandlines to see what happened.
2020-06-01 21:57:30 +00:00
James Holderness
d92c8293ce Add support for VT52 emulation (#4789)
## Summary of the Pull Request

This PR adds support for the core VT52 commands, and implements the `DECANM` private mode sequence, which switches the terminal between ANSI mode and VT52-compatible mode.

## References

PR #2017 defined the initial specification for VT52 support.
PR #4044 removed the original VT52 cursor ops that conflicted with VT100 sequences.

## PR Checklist
* [x] Closes #976
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #2017

## Detailed Description of the Pull Request / Additional comments

Most of the work involves updates to the parsing state machine, which behaves differently in VT52 mode. `CSI`, `OSC`, and `SS3` sequences are not applicable, and there is one special-case escape sequence (_Direct Cursor Address_), which requires an additional state to handle parameters that come _after_ the final character.

Once the parsing is handled though, it's mostly just a matter of dispatching the commands to existing methods in the `ITermDispatch` interface. Only one new method was required in the interface to handle the _Identify_ command.

The only real new functionality is in the `TerminalInput` class, which needs to generate different escape sequences for certain keys in VT52 mode. This does not yet support _all_ of the VT52 key sequences, because the VT100 support is itself not yet complete. But the basics are in place, and I think the rest is best left for a follow-up issue, and potentially a refactor of the `TerminalInput` class.

I should point out that the original spec called for a new _Graphic Mode_ character set, but I've since discovered that the VT terminals that _emulate_ VT52 just use the existing VT100 _Special Graphics_ set, so that is really what we should be doing too. We can always consider adding the VT52 graphic set as a option later, if there is demand for strict VT52 compatibility. 

## Validation Steps Performed

I've added state machine and adapter tests to confirm that the `DECANM` mode changing sequences are correctly dispatched and forwarded to the `ConGetSet` handler. I've also added state machine tests that confirm the VT52 escape sequences are dispatched correctly when the ANSI mode is reset.

For fuzzing support, I've extended the VT command fuzzer to generate the different kinds of VT52 sequences, as well as mode change sequences to switch between the ANSI and VT52 modes.

In terms of manual testing, I've confirmed that the _Test of VT52 mode_ in Vttest now works as expected.
2020-06-01 21:20:40 +00:00
Carlos Zamora
44dcc861ad Adds Alt+Click to auto split pane (#5928)
## Summary of the Pull Request
Users can now open an auto split pane with the mouse.
When opening the dropdown, alt+invoke the profile of choice and it should open in an auto sized pane.

## References
#5025 - further discussion there as to whether this actually closes it.

## Detailed Description of the Pull Request / Additional comments
Had to do a special check for debugTap because that's triggered by holding both alts.

## Validation Steps Performed
alt+click/enter on a new profile. Looks great!
2020-06-01 20:26:21 +00:00
Dustin L. Howett (MSFT)
9ed776bf3e Allow the default profile to be specified by name (#5706)
## Summary of the Pull Request

This looks like a big diff, but there's a bunch of existing code that
just got moved around, and there's a cool new Utils template.

The tests all pass, and this passed manual validation. I tried weird
things like "making a profile named `{                            }`"
(w/ enough spaces to look like a guid), and yeah it doesn't let you
specify that one as a name, but _why would you do that?!_

Okay, this pull request abstracts the conversion of a profile name into
an optional profile guid out of the "New Terminal Tab Args" handler and
into a common space for all of CascadiaSettings to use.

It also cleans up the conversion of indices and names into optional
GUIDs and turns _those_ into further helpers.

It also introduces a cool new template for running value_or multiple
times on a chain of optionals. CoalesceOptionals is a "choose first,
with fallback" for N>1 optionals.

On top of all this, I've built support for an "unparsed default GUID":
we load the user's defaultProfile as a string, and as part of settings
validation we unpack that string using the helpers outlined above.

## References

Couples well with #5690.

## PR Checklist
* [x] Incidentally fixes #2876
* [x] Core Contributor
* [x] Tests added/passed
* [x] Requires documentation to be updated (done)
* [x] I've discussed this with core contributors already

## Validation Steps Performed

Added additional test collateral to make sure that this works.
2020-06-01 20:26:00 +00:00
Josh Elster
fc8fff17db Add startup task, setting to launch application on login (#4908)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This PR adds a new boolean global setting, startOnUserLogin, along with associated AppLogic to request enabling or disabling of the StartupTask. Added UAP5 extensions to AppX manifests. 
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

#2189 

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #2189
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #2189

<!-- 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
Please note, I'm a non-practicing C++ developer, there are a number of things I wasn't sure how to handle in the appropriate fashion, mostly around error handling and what probably looks like an incredibly naive (and messy) way to implement the async co_await behavior. 

Error handling-wise, I found (don't ask me how!) that if you somehow mismatch the startup task's ID between the manifest and the call to `StartupTask::GetAsync(hstring taskId)`, you'll get a very opaque WinRT exception that boils down to a generic invalid argument message. This isn't likely to happen in the wild, but worth mentioning...

I had enough trouble getting myself familiarized with the project, environment, and C++/WinRT in general didn't want to try to tackle adding tests for this quite yet since (as I mentioned) I don't really know what I'm doing. I'm happy to give it a try with perhaps a bit of assistance in getting started 😃 

Further work in this area of the application outside of this immediate PR might need to include adding an additional setting to contain launch args that the startup task can pass to the app so that users can specify a non-default profile to launch on start, window position (e.g., #653).

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

✔️ Default settings:
Given the user does not have the `startOnUserLogin` setting in their profile.json,
When the default settings are opened (via alt+click on Settings), 
Then the global settings should contain the `"startOnUserLogin": false` token

✔️ Applying setting on application launch
Given the `startOnUserLogin` is `true` and 
  the `Windows Terminal` startup task is `disabled` and 
  the application is not running
When the application is launched
Then the `Windows Terminal` entry in the user's Startup list should be `enabled`

✔️ Applying setting on settings change
Given the `startOnUserLogin` is `true` and
  the `Windows Terminal` startup task is `enabled` and
  the application is running
When the `startOnUserLogin` setting is changed to `false` and
  the settings file is saved to disk
Then the `Windows Terminal` startup task entry should be `disabled`

✔️ Setting is ignored when user has manually disabled startup
Given the `startOnUserLogin` is `true` and
  the application is not running and
  the `Windows Terminal` startup task has been set to `disabled` via user action
When the application is launched
Then the startup task should remain disabled and
  the application should not throw an exception

#### note: Task Manager does not seem to re-scan startup task states after launch; the Settings -> Apps -> Startup page also requires closing or moving away to refresh the status of entries
2020-06-01 20:24:43 +00:00
Chester Liu
94eab6e391 Skip glyph shaping analysis when the entire text is simple (#6206)
## Summary of the Pull Request

As the title suggests, this PR will make CustomTextLayout skip glyph shaping analysis when the entire text is detected as simple.

## References

My main reference is [DirectX Factor - Who’s Afraid of Glyph Runs?](https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/november/directx-factor-who%e2%80%99s-afraid-of-glyph-runs)

And also #2959

## PR Checklist
* [x] Closes @skyline75489's continuous drive for perf gainz. 
* [x] CLA signed. 
* [x] Manual tests.
* [x] Nah on docs.
* [x] Discussed with core contributors in this PR.

## Detailed Description of the Pull Request / Additional comments

This can be seen as a followup of #2959. The idea is the same: make use of simple text (which makes up I think 95% of all terminal text) as much as possible.

The performance boost is huge. Cacafire is actually on fire this time (and remember I'm using 4K!). The frame rate is also boosted since more CPU time can be used for actual drawing.

Before:

![图片](https://user-images.githubusercontent.com/4710575/82913277-b21c3c00-9fa0-11ea-8785-a14b347bbcbd.png)

After:

![图片](https://user-images.githubusercontent.com/4710575/82912969-4afe8780-9fa0-11ea-8795-92617dde822f.png)

## Validation Steps Performed

Manually validated.
2020-06-01 18:36:28 +00:00
Malcolm Smith
601286ac69 Find icon from shortcut target if shortcut doesn't specify it (#6277)
Implements what I was suggesting in #6266 where if a shortcut doesn't
specify an icon, the shortcut target full path is used before searching
for a matching executable in the path.

## References

Found due to not getting the right icon in conhost from the Yori
installer.  It's fixed in the installer from
5af366b6a5
for all current users of conhost though, so this PR is just trying to
minimize surprises for the next guy.

## Detailed Description of the Pull Request / Additional comments

I know conhost and shortcut settings aren't really the team's focus
which is why I'm doing this.  I understand though if there's a better
way or there are factors that I hadn't considered.  Note that the path
searching code is used when programs are launched without using a
shortcut, and it will match if the working directory of the shortcut is
the directory containing the executable.

## Validation Steps Performed

Created a shortcut that didn't specify an icon to a binary that wasn't
in the path, and verified that the icon in the upper left of the console
window could resolve correctly when opening the shortcut.  I'm not aware
of a way to get into this path (of launching via a shortcut to a command
line process) without replacing the system conhost, which is what I did
to verify it.  In order to diagnose it, I used hardcoded DebugBreak()
since even ImageFileExecutionOptions didn't like running against conhost-
is there are better way to debug and test these cases without being so
invasive on the system?

Closes #6266
2020-06-01 17:19:05 +00:00
Mike Griese
1fbe8e415d Turns out, the shadow on the menuflyout isn't my fault, it's on everything that uses MUX 2020-05-29 12:45:39 -05:00
Mike Griese
fa93fdc034 Well, this is neat, and works, but requires 18362 and also casts a shadow on the menuflyout??? 2020-05-29 12:19:04 -05:00
Mike Griese
cf6e1f273a Try to do this with a shadow, but it crashes inexplicably 2020-05-29 11:44:38 -05:00
Mike Griese
99059451d8 Return focus to the active control when closed 2020-05-29 11:29:01 -05:00
Mike Griese
a309191461 Rename private methods, fix wraparound logic 2020-05-29 11:14:56 -05:00
Mike Griese
e1be26b184 Do this in WinRTUtils instead of hackily doing it manually 2020-05-29 09:48:30 -05:00
Mike Griese
bc546dbdb0 Add some stability
Don't die when we encounter an unexpected key
  Reload successfully
2020-05-29 09:42:47 -05:00
Mike Griese
00763fda9e Add duplicate pane to the default commands 2020-05-29 07:47:29 -05:00
Mike Griese
b88be4534b Make sure to scroll the selected item into view 2020-05-29 07:43:12 -05:00
Mike Griese
207666e34d Add a ton of default commands 2020-05-29 07:32:43 -05:00
alexzshl
af56088cb6 Fix syntax errors in font weight options (#6248) 2020-05-28 22:28:13 -07:00
Dustin L. Howett
ba03068940 Reintroduce accidentally removed uap7 namespace (#6243) 2020-05-28 15:18:35 -07:00
Mike Griese
d91e755fe7 Add missing namespaces to the Preview, Release manifests (#6241) 2020-05-28 15:02:40 -07:00
Mike Griese
62b9a0d1c0 Move the action into it's own sub-object 2020-05-28 16:44:38 -05:00
Mike Griese
02f47f49c3 Make the action names map public, so the ToJson in AKBSerialization can use it 2020-05-28 16:40:04 -05:00
Michael Niksa
e390111dfb Give cursor radio buttons their own sequential IDs in propsheet (#6231)
For a radio button group to work properly, they need sequential IDs.
This moves the cursor radio buttons on the `conhost` property sheet to
be sequential.

## References
- Introduced with #2663
- Found while investigating #4186

## PR Checklist
* [x] Closes unfiled issue found while investigating #4186
* [x] I work here.
* [x] Manual test.
* [x] No documentation required.
* [x] Am core contributor.

## Detailed Description of the Pull Request / Additional comments
- `CheckRadioButton` takes a contiguous group of IDs. It will set one
  item in the list and then uncheck the rest. When a new one was added
  to the group, it was added to the end of the segment in the IDs file,
  but not immediately after the existing radio buttons. This means it
  accidentally turned off all the other buttons in the middle.
- To resolve this, I moved all the cursor buttons into their own
  sequential group number and I deprecated the old values.

## Validation Steps Performed
- [x] Ensured that the "Discard Old Duplicates" value was set in the
  registry, walked through debugger as `conhost` packed the `TRUE` value
  into the property sheet blob, walked through the property sheet
  `console.dll` as it unpacked the `TRUE`, then observed that the
  checkbox was actually set instead of getting unset by the
  `CheckRadioButton` call that went from 107 to 119 and accidentally
  unchecked number 112, `IDD_HISTORY_NODUP` even though I swear it was
  just set.
2020-05-28 14:16:10 -07:00
Mike Griese
c30aff0c49 Make the Shell Extension methods STDMETHODIMP (#6238)
These methods need to be declared STDMETHODIMP so the x86 build will pass.
2020-05-28 14:09:52 -07:00
Mike Griese
f17b6c7d0d Enable tab renaming at runtime from the UI (#5775)
## Summary of the Pull Request

Adds support for setting, from the UI, a runtime override for the tab title text. The user can use this to effectively "rename" a tab.

If set, the tab will _always_ use the runtime override string. If the user has multiple panes with different titles in a pane, then the tab's override text will be used _regardless_ of which pane was focused when the tab was renamed.

The override text can be removed by just deleting the entire contents of the box. Then, the tab will revert to using the terminal's usual title. 

## References
* Wouldn't be possible without the context menu from #3789
* Focus doesn't return to the active terminal after hitting <kbd>enter</kbd>/<kbd>esc</kbd>, but that's tracked by #5750 

## PR Checklist
* [x] Closes #1079
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated

## TODO
* [x] `Tab::SetTabText` might be able to be greatly simplified/removed?
* [x] I'm _pretty sure_ if they set an override title, we won't bubble that up to set the window title.
* [x] I'm unsure how this behaves when the terminal's title changes _while_ the TextBox is visible. I don't think it should change the current contents of the box, but it might currently.
* [ ] **for discussion**: If the user doesn't actually change the text of the tab, then we probably shouldn't set the override text, right? 
  - EX: if they open the box and the text is "cmd", and immediately hit <kbd>enter</kbd>, then run `title foo`, should the text change to "foo" or stay "cmd"?

## Detailed Description of the Pull Request / Additional comments
![image](https://user-images.githubusercontent.com/18356694/81230615-713f9180-8fb7-11ea-8945-6681eec02a4f.png)
![image](https://user-images.githubusercontent.com/18356694/81230640-7ac8f980-8fb7-11ea-9e6b-22f0e0ed128a.png)
![image](https://user-images.githubusercontent.com/18356694/81230665-86b4bb80-8fb7-11ea-90f0-16d4ffb60d89.png)
![image](https://user-images.githubusercontent.com/18356694/81230686-9207e700-8fb7-11ea-94a9-f3f5a59be139.png)
![image](https://user-images.githubusercontent.com/18356694/81230732-a350f380-8fb7-11ea-9901-6dd4f36154f1.png)
![image](https://user-images.githubusercontent.com/18356694/81230746-a8ae3e00-8fb7-11ea-94fa-d2578f9241a7.png)
![image](https://user-images.githubusercontent.com/18356694/81230787-bc59a480-8fb7-11ea-8edf-2bd7fad343fc.png)
![image](https://user-images.githubusercontent.com/18356694/81230851-dc896380-8fb7-11ea-98c1-918b943543e4.png)
2020-05-28 21:06:17 +00:00
Mike Griese
6905065fcf Merge remote-tracking branch 'origin/master' into dev/migrie/f/2046-Command-Palette-v2
# Conflicts:
#	src/cascadia/TerminalApp/TerminalPage.h
2020-05-28 15:29:23 -05:00
Mike Griese
0416a944a2 Hook up the parsing of ActionAndArgss to the command palette 2020-05-28 15:09:45 -05:00
Mike Griese
3627d8abd5 This should have been in the previous commit 2020-05-28 15:08:57 -05:00
Mike Griese
33a9e32736 Get names from the resources if provided as an object, not a string 2020-05-28 12:56:17 -05:00
Mike Griese
75af4cabbb Hook up all the parsing once again 2020-05-28 12:31:49 -05:00
Mike Griese
807d2cf2d2 Add support for fullscreen launchMode (#6060)
## Summary of the Pull Request

Adds `"launchMode": "fullscreen"`, which does what it says on the box.

## PR Checklist
* [x] Closes #288
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

It's important to let the winow get created, _then_ fullscreen it, because otherwise, when the user exits fullscreen, the window is sized to like, 0x0 or something, and that's just annoying.
2020-05-28 16:53:01 +00:00
Mike Griese
43bd483962 Blind port these files from the old branch 2020-05-28 11:26:25 -05:00
Mike Griese
1fc0997969 Add a context menu entry to "Open Windows Terminal here" (#6100)
## Summary of the Pull Request

![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png)

I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll.

## References
* I'm going to need to file a bunch of follow-ups on this one.
  - We should add another entry to let the user select which profile
  - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying.
  - These strings should be localized.
  - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that.
* [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well
* [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt
* [This is PowerToys' manifest](d2a60c7287/installer/MSIX/appxmanifest.xml (L53-L65)) and then [their implementation](d16ebba9e0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful
* [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype)

## PR Checklist
* [x] Closes #1060
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry.

The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 15:42:13 +00:00
Mike Griese
0672812e6f good bot 2020-05-28 10:29:09 -05:00
Mike Griese
f53553f4e4 Merge remote-tracking branch 'origin/master' into dev/migrie/s/5400-CommandPalette-v1 2020-05-28 10:27:58 -05:00
Josh Soref
cc472c267b ci: spelling: update to 0.0.16a; update advice (#5922)
<!-- 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

Updates the check spelling action to [0.0.16-a](https://github.com/check-spelling/check-spelling/releases/tag/0.0.16-alpha)
* update advice -- [sample](57fc13f6c6 (commitcomment-39489723)) -- I really do encourage others to adjust it as desired
* rename `expect` (there are consumers who were not a fan of the `whitelist` nomenclature)
* prune stale items
* some `patterns` improvements to reduce the number of items in `expect`


<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
⚠️ Anyone with an inflight addition of a new file to the `whitelist` directory will be moderately unhappy as the action would only use items from there if it didn't find `expect` (and this PR includes the rename).

## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Runs should be ~30s faster.

I was hoping to be able to offer the ability to talk to the bot, but sadly that feature is still not quite ready -- and I suspect that I may want to let projects opt in/out of that feature.

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

* I added a commit with misspellings: 57fc13f6c6   and ran the command it suggested (in bash). 
* The commit [itself passes its own testing](78df00dcf6) ✔️ 

The commands were never `cmd`/`psh` friendly. This iteration is designed to make it easier for a bot to parse and eventually do the work in response to a GitHub request, sadly that feature is behind schedule.
2020-05-28 08:01:52 -05:00
James Holderness
fa7c1abdf8 Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661. 

The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.

## References

* This is another step towards fixing the conpty narrowing bugs in issue
  #2661.
* This is technically a fix for issue #5384, but that won't be apparent
  until #2661 is complete.

## PR Checklist
* [x] Closes #1223
* [x] CLA signed. 
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.

## Detailed Description of the Pull Request / Additional comments

The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.

There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.

In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.

The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with. 

With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.

I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations). 

## Validation Steps Performed

For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.

I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.

Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.

I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-27 22:34:45 +00:00
Mike Griese
e7c22fbadb Replace everything in TerminalSettings with GETSET_PROPERTY (#6110)
This is mostly a codehealth thing - we made these handy macros for just defining basic `{ get; set; }` properties, but we never used them in TerminalSettings, because that file was written before the macros were.

This cleans up that class.

* [x] I work here.
2020-05-27 21:46:39 +00:00
Mike Griese
11130a4895 Add some notes about the advanced tab switcher and how that might interplay with this 2020-05-20 09:15:27 -05:00
Mike Griese
0886e8f12d Merge remote-tracking branch 'origin/master' into dev/migrie/s/5400-CommandPalette-v1 2020-05-20 08:47:50 -05:00
Mike Griese
2e564368c8 Move this section to 'future considerations' 2020-05-07 12:17:00 -05:00
Mike Griese
ead76d7f16 Merge remote-tracking branch 'origin/master' into dev/migrie/s/5400-CommandPalette-v1 2020-05-07 12:11:48 -05:00
Mike Griese
614d1b21d6 last little todos for review 2020-04-30 15:20:25 -05:00
Mike Griese
fe640ff894 move this spec out of drafts/ 2020-04-30 15:03:52 -05:00
Mike Griese
c56eb8fd93 Add a ton of text regarding Commandline Mode vs Action Mode 2020-04-30 15:02:59 -05:00
337 changed files with 18635 additions and 9609 deletions

View File

@@ -9,7 +9,7 @@
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] Requires documentation to be updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] 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 -->

File diff suppressed because it is too large Load Diff

View File

@@ -62,6 +62,10 @@ If you have any issues when installing/upgrading the package please go to the [W
---
## Windows Terminal 2.0 Roadmap
The plan for delivering Windows Terminal 2.0 [is described here](/doc/terminal-v2-roadmap.md) and will be updated as the project proceeds.
## Project Build Status
Project|Build Status

View File

@@ -47,7 +47,6 @@ stages:
- stage: Build_x86
displayName: Build x86
dependsOn: []
condition: not(eq(variables['Build.Reason'], 'PullRequest'))
jobs:
- template: ./templates/build-console-ci.yml
parameters:

View File

@@ -0,0 +1,38 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="16.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
</PropertyGroup>
<Target Name="BeforeGenerateProjectPriFile" DependsOnTargets="OpenConsoleCollectWildcardPRIFiles" />
<!--
The vcxproj system does not support wildcards at the root level of a project.
This poses a problem, as we want to include resw files that are not checked into the
repository. Since they're usually localized and stored in directories named after
their languages, we can't exactly explicitly simultaneously list them all and remain
sane. We want to use wildcards to make our lives easier.
This rule takes OCResourceDirectory items and includes all resw files that live
underneath them.
** TIRED **
(does not work because of wildcards)
<PRIResource Include="Resources/*/Resources.resw" />
** WIRED **
(keep the en-US resource in the project, because it is checked in and VS will show it)
<PRIResource Include="Resources/en-US/Resources.resw" />
<OCResourceDirectory Include="Resources" />
-->
<Target Name="OpenConsoleCollectWildcardPRIFiles">
<CreateItem Include="@(OCResourceDirectory->'%(Identity)\**\*.resw')">
<Output TaskParameter="Include" ItemName="_OCFoundPRIFiles" />
</CreateItem>
<ItemGroup>
<_OCFoundPRIFiles Include="@(PRIResource)" />
<PRIResource Remove="@(PRIResource)" />
<PRIResource Include="@(_OCFoundPRIFiles->Distinct())" />
</ItemGroup>
<Message Text="$(ProjectName) (wildcard PRIs) -> @(PRIResource)" />
</Target>
</Project>

View File

@@ -36,6 +36,7 @@
".db",
".wrn",
".rec",
".err"
".err",
".xlsx"
]
}

File diff suppressed because it is too large Load Diff

View File

@@ -1,5 +1,5 @@
# CLI11
Taken from [release v1.8.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.8.0), source commit
[13becad](https://github.com/CLIUtils/CLI11/commit/13becaddb657eacd090537719a669d66d393b8b2)
Taken from [release v1.9.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.0), source commit
[dd0d8e4](https://github.com/CLIUtils/CLI11/commit/dd0d8e4fe729e5b1110232c7a5c9566dad884686)

13
dep/CLI11/cgmanifest.json Normal file
View File

@@ -0,0 +1,13 @@
{"Registrations":[
{
"component": {
"type": "git",
"git": {
"repositoryUrl": "https://github.com/CLIUtils/CLI11",
"commitHash": "dd0d8e4fe729e5b1110232c7a5c9566dad884686"
}
}
}
],
"Version": 1
}

View File

@@ -2,6 +2,15 @@
[Amalgamated](https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated)
from source commit
[ddabf50](https://github.com/open-source-parsers/jsoncpp/commit/ddabf50f72cf369bf652a95c4d9fe31a1865a781),
release 1.8.4.
[6aba23f](https://github.com/open-source-parsers/jsoncpp/commit/6aba23f4a8628d599a9ef7fa4811c4ff6e4070e2),
release 1.9.3.
> Generating amalgamated source and header JsonCpp is provided with a script to
> generate a single header and a single source file to ease inclusion into an
> existing project. The amalgamated source can be generated at any time by
> running the following command from the top-directory (this requires Python
> 3.4+):
>
> ```
> python amalgamate.py
> ```

View File

@@ -0,0 +1,13 @@
{"Registrations":[
{
"component": {
"type": "git",
"git": {
"repositoryUrl": "https://github.com/open-source-parsers/jsoncpp",
"commitHash": "6aba23f4a8628d599a9ef7fa4811c4ff6e4070e2"
}
}
}
],
"Version": 1
}

View File

@@ -79,6 +79,151 @@ license you like.
/// to prevent private header inclusion.
#define JSON_IS_AMALGAMATION
// //////////////////////////////////////////////////////////////////////
// Beginning of content of file: include/json/version.h
// //////////////////////////////////////////////////////////////////////
#ifndef JSON_VERSION_H_INCLUDED
#define JSON_VERSION_H_INCLUDED
// Note: version must be updated in three places when doing a release. This
// annoying process ensures that amalgamate, CMake, and meson all report the
// correct version.
// 1. /meson.build
// 2. /include/json/version.h
// 3. /CMakeLists.txt
// IMPORTANT: also update the SOVERSION!!
#define JSONCPP_VERSION_STRING "1.9.3"
#define JSONCPP_VERSION_MAJOR 1
#define JSONCPP_VERSION_MINOR 9
#define JSONCPP_VERSION_PATCH 3
#define JSONCPP_VERSION_QUALIFIER
#define JSONCPP_VERSION_HEXA \
((JSONCPP_VERSION_MAJOR << 24) | (JSONCPP_VERSION_MINOR << 16) | \
(JSONCPP_VERSION_PATCH << 8))
#ifdef JSONCPP_USING_SECURE_MEMORY
#undef JSONCPP_USING_SECURE_MEMORY
#endif
#define JSONCPP_USING_SECURE_MEMORY 0
// If non-zero, the library zeroes any memory that it has allocated before
// it frees its memory.
#endif // JSON_VERSION_H_INCLUDED
// //////////////////////////////////////////////////////////////////////
// End of content of file: include/json/version.h
// //////////////////////////////////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////
// Beginning of content of file: include/json/allocator.h
// //////////////////////////////////////////////////////////////////////
// Copyright 2007-2010 Baptiste Lepilleur and The JsonCpp Authors
// Distributed under MIT license, or public domain if desired and
// recognized in your jurisdiction.
// See file LICENSE for detail or copy at http://jsoncpp.sourceforge.net/LICENSE
#ifndef JSON_ALLOCATOR_H_INCLUDED
#define JSON_ALLOCATOR_H_INCLUDED
#include <cstring>
#include <memory>
#pragma pack(push, 8)
namespace Json {
template <typename T> class SecureAllocator {
public:
// Type definitions
using value_type = T;
using pointer = T*;
using const_pointer = const T*;
using reference = T&;
using const_reference = const T&;
using size_type = std::size_t;
using difference_type = std::ptrdiff_t;
/**
* Allocate memory for N items using the standard allocator.
*/
pointer allocate(size_type n) {
// allocate using "global operator new"
return static_cast<pointer>(::operator new(n * sizeof(T)));
}
/**
* Release memory which was allocated for N items at pointer P.
*
* The memory block is filled with zeroes before being released.
* The pointer argument is tagged as "volatile" to prevent the
* compiler optimizing out this critical step.
*/
void deallocate(volatile pointer p, size_type n) {
std::memset(p, 0, n * sizeof(T));
// free using "global operator delete"
::operator delete(p);
}
/**
* Construct an item in-place at pointer P.
*/
template <typename... Args> void construct(pointer p, Args&&... args) {
// construct using "placement new" and "perfect forwarding"
::new (static_cast<void*>(p)) T(std::forward<Args>(args)...);
}
size_type max_size() const { return size_t(-1) / sizeof(T); }
pointer address(reference x) const { return std::addressof(x); }
const_pointer address(const_reference x) const { return std::addressof(x); }
/**
* Destroy an item in-place at pointer P.
*/
void destroy(pointer p) {
// destroy using "explicit destructor"
p->~T();
}
// Boilerplate
SecureAllocator() {}
template <typename U> SecureAllocator(const SecureAllocator<U>&) {}
template <typename U> struct rebind { using other = SecureAllocator<U>; };
};
template <typename T, typename U>
bool operator==(const SecureAllocator<T>&, const SecureAllocator<U>&) {
return true;
}
template <typename T, typename U>
bool operator!=(const SecureAllocator<T>&, const SecureAllocator<U>&) {
return false;
}
} // namespace Json
#pragma pack(pop)
#endif // JSON_ALLOCATOR_H_INCLUDED
// //////////////////////////////////////////////////////////////////////
// End of content of file: include/json/allocator.h
// //////////////////////////////////////////////////////////////////////
// //////////////////////////////////////////////////////////////////////
// Beginning of content of file: include/json/config.h
// //////////////////////////////////////////////////////////////////////
@@ -90,19 +235,14 @@ license you like.
#ifndef JSON_CONFIG_H_INCLUDED
#define JSON_CONFIG_H_INCLUDED
#include <stddef.h>
#include <string> //typedef String
#include <stdint.h> //typedef int64_t, uint64_t
/// If defined, indicates that json library is embedded in CppTL library.
//# define JSON_IN_CPPTL 1
/// If defined, indicates that json may leverage CppTL library
//# define JSON_USE_CPPTL 1
/// If defined, indicates that cpptl vector based map should be used instead of
/// std::map
/// as Value container.
//# define JSON_USE_CPPTL_SMALLMAP 1
#include <cstddef>
#include <cstdint>
#include <istream>
#include <memory>
#include <ostream>
#include <sstream>
#include <string>
#include <type_traits>
// If non-zero, the library uses exceptions to report bad input instead of C
// assertion macros. The default is to use exceptions.
@@ -110,164 +250,132 @@ license you like.
#define JSON_USE_EXCEPTION 1
#endif
// Temporary, tracked for removal with issue #982.
#ifndef JSON_USE_NULLREF
#define JSON_USE_NULLREF 1
#endif
/// If defined, indicates that the source file is amalgamated
/// to prevent private header inclusion.
/// Remarks: it is automatically defined in the generated amalgamated header.
// #define JSON_IS_AMALGAMATION
#ifdef JSON_IN_CPPTL
#include <cpptl/config.h>
#ifndef JSON_USE_CPPTL
#define JSON_USE_CPPTL 1
#endif
#endif
#ifdef JSON_IN_CPPTL
#define JSON_API CPPTL_API
#elif defined(JSON_DLL_BUILD)
// Export macros for DLL visibility
#if defined(JSON_DLL_BUILD)
#if defined(_MSC_VER) || defined(__MINGW32__)
#define JSON_API __declspec(dllexport)
#define JSONCPP_DISABLE_DLL_INTERFACE_WARNING
#elif defined(__GNUC__) || defined(__clang__)
#define JSON_API __attribute__((visibility("default")))
#endif // if defined(_MSC_VER)
#elif defined(JSON_DLL)
#if defined(_MSC_VER) || defined(__MINGW32__)
#define JSON_API __declspec(dllimport)
#define JSONCPP_DISABLE_DLL_INTERFACE_WARNING
#endif // if defined(_MSC_VER)
#endif // ifdef JSON_IN_CPPTL
#endif // ifdef JSON_DLL_BUILD
#if !defined(JSON_API)
#define JSON_API
#endif
#if defined(_MSC_VER) && _MSC_VER < 1800
#error \
"ERROR: Visual Studio 12 (2013) with _MSC_VER=1800 is the oldest supported compiler with sufficient C++11 capabilities"
#endif
#if defined(_MSC_VER) && _MSC_VER < 1900
// As recommended at
// https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010
extern JSON_API int msvc_pre1900_c99_snprintf(char* outBuf, size_t size,
const char* format, ...);
#define jsoncpp_snprintf msvc_pre1900_c99_snprintf
#else
#define jsoncpp_snprintf std::snprintf
#endif
// If JSON_NO_INT64 is defined, then Json only support C++ "int" type for
// integer
// Storages, and 64 bits integer support is disabled.
// #define JSON_NO_INT64 1
#if defined(_MSC_VER) // MSVC
# if _MSC_VER <= 1200 // MSVC 6
// Microsoft Visual Studio 6 only support conversion from __int64 to double
// (no conversion from unsigned __int64).
# define JSON_USE_INT64_DOUBLE_CONVERSION 1
// Disable warning 4786 for VS6 caused by STL (identifier was truncated to '255'
// characters in the debug information)
// All projects I've ever seen with VS6 were using this globally (not bothering
// with pragma push/pop).
# pragma warning(disable : 4786)
# endif // MSVC 6
# if _MSC_VER >= 1500 // MSVC 2008
/// Indicates that the following function is deprecated.
# define JSONCPP_DEPRECATED(message) __declspec(deprecated(message))
# endif
#endif // defined(_MSC_VER)
// In c++11 the override keyword allows you to explicitly define that a function
// is intended to override the base-class version. This makes the code more
// managable and fixes a set of common hard-to-find bugs.
#if __cplusplus >= 201103L
# define JSONCPP_OVERRIDE override
# define JSONCPP_NOEXCEPT noexcept
#elif defined(_MSC_VER) && _MSC_VER > 1600 && _MSC_VER < 1900
# define JSONCPP_OVERRIDE override
# define JSONCPP_NOEXCEPT throw()
#elif defined(_MSC_VER) && _MSC_VER >= 1900
# define JSONCPP_OVERRIDE override
# define JSONCPP_NOEXCEPT noexcept
#else
# define JSONCPP_OVERRIDE
# define JSONCPP_NOEXCEPT throw()
#endif
#ifndef JSON_HAS_RVALUE_REFERENCES
#if defined(_MSC_VER) && _MSC_VER >= 1600 // MSVC >= 2010
#define JSON_HAS_RVALUE_REFERENCES 1
#endif // MSVC >= 2010
// JSONCPP_OVERRIDE is maintained for backwards compatibility of external tools.
// C++11 should be used directly in JSONCPP.
#define JSONCPP_OVERRIDE override
#ifdef __clang__
#if __has_feature(cxx_rvalue_references)
#define JSON_HAS_RVALUE_REFERENCES 1
#endif // has_feature
#elif defined __GNUC__ // not clang (gcc comes later since clang emulates gcc)
#if defined(__GXX_EXPERIMENTAL_CXX0X__) || (__cplusplus >= 201103L)
#define JSON_HAS_RVALUE_REFERENCES 1
#endif // GXX_EXPERIMENTAL
#endif // __clang__ || __GNUC__
#endif // not defined JSON_HAS_RVALUE_REFERENCES
#ifndef JSON_HAS_RVALUE_REFERENCES
#define JSON_HAS_RVALUE_REFERENCES 0
#if __has_extension(attribute_deprecated_with_message)
#define JSONCPP_DEPRECATED(message) __attribute__((deprecated(message)))
#endif
#ifdef __clang__
# if __has_extension(attribute_deprecated_with_message)
# define JSONCPP_DEPRECATED(message) __attribute__ ((deprecated(message)))
# endif
#elif defined __GNUC__ // not clang (gcc comes later since clang emulates gcc)
# if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5))
# define JSONCPP_DEPRECATED(message) __attribute__ ((deprecated(message)))
# elif (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
# define JSONCPP_DEPRECATED(message) __attribute__((__deprecated__))
# endif // GNUC version
#endif // __clang__ || __GNUC__
#elif defined(__GNUC__) // not clang (gcc comes later since clang emulates gcc)
#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5))
#define JSONCPP_DEPRECATED(message) __attribute__((deprecated(message)))
#elif (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))
#define JSONCPP_DEPRECATED(message) __attribute__((__deprecated__))
#endif // GNUC version
#elif defined(_MSC_VER) // MSVC (after clang because clang on Windows emulates
// MSVC)
#define JSONCPP_DEPRECATED(message) __declspec(deprecated(message))
#endif // __clang__ || __GNUC__ || _MSC_VER
#if !defined(JSONCPP_DEPRECATED)
#define JSONCPP_DEPRECATED(message)
#endif // if !defined(JSONCPP_DEPRECATED)
#if __GNUC__ >= 6
# define JSON_USE_INT64_DOUBLE_CONVERSION 1
#if defined(__clang__) || (defined(__GNUC__) && (__GNUC__ >= 6))
#define JSON_USE_INT64_DOUBLE_CONVERSION 1
#endif
#if !defined(JSON_IS_AMALGAMATION)
# include "version.h"
# if JSONCPP_USING_SECURE_MEMORY
# include "allocator.h" //typedef Allocator
# endif
#include "allocator.h"
#include "version.h"
#endif // if !defined(JSON_IS_AMALGAMATION)
namespace Json {
typedef int Int;
typedef unsigned int UInt;
using Int = int;
using UInt = unsigned int;
#if defined(JSON_NO_INT64)
typedef int LargestInt;
typedef unsigned int LargestUInt;
using LargestInt = int;
using LargestUInt = unsigned int;
#undef JSON_HAS_INT64
#else // if defined(JSON_NO_INT64)
// For Microsoft Visual use specific types as long long is not supported
#if defined(_MSC_VER) // Microsoft Visual Studio
typedef __int64 Int64;
typedef unsigned __int64 UInt64;
using Int64 = __int64;
using UInt64 = unsigned __int64;
#else // if defined(_MSC_VER) // Other platforms, use long long
typedef int64_t Int64;
typedef uint64_t UInt64;
#endif // if defined(_MSC_VER)
typedef Int64 LargestInt;
typedef UInt64 LargestUInt;
using Int64 = int64_t;
using UInt64 = uint64_t;
#endif // if defined(_MSC_VER)
using LargestInt = Int64;
using LargestUInt = UInt64;
#define JSON_HAS_INT64
#endif // if defined(JSON_NO_INT64)
#if JSONCPP_USING_SECURE_MEMORY
#define JSONCPP_STRING std::basic_string<char, std::char_traits<char>, Json::SecureAllocator<char> >
#define JSONCPP_OSTRINGSTREAM std::basic_ostringstream<char, std::char_traits<char>, Json::SecureAllocator<char> >
#define JSONCPP_OSTREAM std::basic_ostream<char, std::char_traits<char>>
#define JSONCPP_ISTRINGSTREAM std::basic_istringstream<char, std::char_traits<char>, Json::SecureAllocator<char> >
#define JSONCPP_ISTREAM std::istream
#else
#define JSONCPP_STRING std::string
#define JSONCPP_OSTRINGSTREAM std::ostringstream
#define JSONCPP_OSTREAM std::ostream
#define JSONCPP_ISTRINGSTREAM std::istringstream
#define JSONCPP_ISTREAM std::istream
#endif // if JSONCPP_USING_SECURE_MEMORY
} // end namespace Json
template <typename T>
using Allocator =
typename std::conditional<JSONCPP_USING_SECURE_MEMORY, SecureAllocator<T>,
std::allocator<T>>::type;
using String = std::basic_string<char, std::char_traits<char>, Allocator<char>>;
using IStringStream =
std::basic_istringstream<String::value_type, String::traits_type,
String::allocator_type>;
using OStringStream =
std::basic_ostringstream<String::value_type, String::traits_type,
String::allocator_type>;
using IStream = std::istream;
using OStream = std::ostream;
} // namespace Json
// Legacy names (formerly macros).
using JSONCPP_STRING = Json::String;
using JSONCPP_ISTRINGSTREAM = Json::IStringStream;
using JSONCPP_OSTRINGSTREAM = Json::OStringStream;
using JSONCPP_ISTREAM = Json::IStream;
using JSONCPP_OSTREAM = Json::OStream;
#endif // JSON_CONFIG_H_INCLUDED
@@ -299,17 +407,23 @@ typedef UInt64 LargestUInt;
namespace Json {
// writer.h
class StreamWriter;
class StreamWriterBuilder;
class Writer;
class FastWriter;
class StyledWriter;
class StyledStreamWriter;
// reader.h
class Reader;
class CharReader;
class CharReaderBuilder;
// features.h
// json_features.h
class Features;
// value.h
typedef unsigned int ArrayIndex;
using ArrayIndex = unsigned int;
class StaticString;
class Path;
class PathArgument;

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

Submodule dep/wil updated: e8c599bca6...3c00e7f1d8

View File

@@ -67,12 +67,12 @@ To update the version of a given package, use the following snippet
where:
- `$PackageName` is the name of the package, e.g. Microsoft.UI.Xaml
- `$OldVersionNumber` is the version number currently used, e.g. 2.3.191217003-prerelease
- `$OldVersionNumber` is the version number currently used, e.g. 2.4.2-prerelease.200604001
- `$NewVersionNumber` is the version number you want to migrate to, e.g. 2.4.200117003-prerelease
Example usage:
`git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.3.191217003-prerelease/2.4.200117003-prerelease/g'`
`git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.4.2-prerelease.200604001/2.4.200117003-prerelease/g'`
## Using .nupkg files instead of downloaded Nuget packages
If you want to use .nupkg files instead of the downloaded Nuget package, you can do this with the following steps:

View File

@@ -0,0 +1,257 @@
# New Json Utility API
## Raw value conversion (GetValue)
`GetValue` is a convenience helper that will either read a value into existing storage (type-deduced) or
return a JSON value coerced into the specified type.
When reading into existing storage, it returns a boolean indicating whether that storage was modified.
If the JSON value cannot be converted to the specified type, an exception will be generated.
```c++
std::string one;
std::optional<std::string> two;
JsonUtils::GetValue(json, one);
// one is populated or unchanged.
JsonUtils::GetValue(json, two);
// two is populated, nullopt or unchanged
auto three = JsonUtils::GetValue<std::string>(json);
// three is populated or zero-initialized
auto four = JsonUtils::GetValue<std::optional<std::string>>(json);
// four is populated or nullopt
```
## Key lookup (GetValueForKey)
`GetValueForKey` follows the same rules as `GetValue`, but takes an additional key.
It is assumed that the JSON value passed to GetValueForKey is of `object` type.
```c++
std::string one;
std::optional<std::string> two;
JsonUtils::GetValueForKey(json, "firstKey", one);
// one is populated or unchanged.
JsonUtils::GetValueForKey(json, "secondKey", two);
// two is populated, nullopt or unchanged
auto three = JsonUtils::GetValueForKey<std::string>(json, "thirdKey");
// three is populated or zero-initialized
auto four = JsonUtils::GetValueForKey<std::optional<std::string>>(json, "fourthKey");
// four is populated or nullopt
```
## Rationale: Value-Returning Getters
JsonUtils provides two types of `GetValue...`: value-returning and reference-filling.
The reference-filling fixtures use type deduction so that a developer does not
need to specify template parameters on every `GetValue` call. It excels at
populating class members during deserialization.
The value-returning fixtures, on the other hand, are very useful for partial
deserialization and key detection when you do not need to deserialize an entire
instance of a class or you need to reason about the presence of members.
To provide a concrete example of the latter, consider:
```c++
if (const auto guid{ GetValueForKey<std::optional<GUID>>(json, "guid") })
// This condition is only true if there was a "guid" member in the provided JSON object.
// It can be accessed through *guid.
}
```
If you are... | Use
--------------|-----
Deserializing | `GetValue(..., storage)`
Interrogating | `storage = GetValue<T>(...)`
## Converting User-Defined Types
All conversions are done using specializations of
`JsonUtils::ConversionTrait<T>`. To implement a converter for a user-defined
type, you must implement a specialization of `JsonUtils::ConversionTrait<T>`.
Every specialization over `T` must implement `static T FromJson(const Json::Value&)`
and `static bool CanConvert(const Json::Value&)`.
```c++
struct MyCustomType { int val; };
template<>
struct ConversionTrait<MyCustomType>
{
// This trait converts a string of the format "[0-9]" to a value of type MyCustomType.
static MyCustomType FromJson(const Json::Value& json)
{
return MyCustomType{ json.asString()[0] - '0' };
}
static bool CanConvert(const Json::Value& json)
{
return json.isString();
}
};
```
### Converting User-Defined Enumerations
Enumeration types represent a single choice out of multiple options.
In a JSON data model, they are typically represented as strings.
For parsing enumerations, JsonUtils provides the `JSON_ENUM_MAPPER` macro. It
can be used to establish a converter that will take a set of known strings and
convert them to values.
```c++
JSON_ENUM_MAPPER(CursorStyle)
{
// pair_type is provided by ENUM_MAPPER.
JSON_MAPPINGS(5) = {
pair_type{ "bar", CursorStyle::Bar },
pair_type{ "vintage", CursorStyle::Vintage },
pair_type{ "underscore", CursorStyle::Underscore },
pair_type{ "filledBox", CursorStyle::FilledBox },
pair_type{ "emptyBox", CursorStyle::EmptyBox }
};
};
```
If the enum mapper fails to convert the provided string, it will throw an
exception.
### Converting User-Defined Flag Sets
Flags represent a multiple-choice selection. They are typically implemented as
enums with bitfield values intended to be ORed together.
In JSON, a set of flags may be represented by a single string (`"flagName"`) or
an array of strings (`["flagOne", "flagTwo"]`).
JsonUtils provides a `JSON_FLAG_MAPPER` macro that can be used to produce a
specialization for a set of flags.
Given the following flag enum,
```c++
enum class JsonTestFlags : int
{
FlagOne = 1 << 0,
FlagTwo = 1 << 1
};
```
You can register a flag mapper with the `JSON_FLAG_MAPPER` macro as follows:
```c++
JSON_FLAG_MAPPER(JsonTestFlags)
{
JSON_MAPPINGS(2) = {
pair_type{ "flagOne", JsonTestFlags::FlagOne },
pair_type{ "flagTwo", JsonTestFlags::FlagTwo },
};
};
```
The `FLAG_MAPPER` also provides two convenience definitions, `AllSet` and
`AllClear`, that can be used to represent "all choices" and "no choices"
respectively.
```c++
JSON_FLAG_MAPPER(JsonTestFlags)
{
JSON_MAPPINGS(4) = {
pair_type{ "never", AllClear },
pair_type{ "flagOne", JsonTestFlags::FlagOne },
pair_type{ "flagTwo", JsonTestFlags::FlagTwo },
pair_type{ "always", AllSet },
};
};
```
Because flag values are additive, `["always", "flagOne"]` will result in the
same behavior as `"always"`.
If the flag mapper encounters an unknown flag, it will throw an exception.
If the flag mapper encounters a logical discontinuity such as `["never", "flagOne"]`
(as in the above example), it will throw an exception.
### Advanced Use
`GetValue` and `GetValueForKey` can be passed, as their final arguments, any
value whose type implements the same interface as `ConversionTrait<T>`--that
is, `FromJson(const Json::Value&)` and `CanConvert(const Json::Value&)`.
This allows for one-off conversions without a specialization of
`ConversionTrait` or even stateful converters.
#### Stateful Converter Sample
```c++
struct MultiplyingConverter {
int BaseValue;
bool CanConvert(const Json::Value&) { return true; }
int FromJson(const Json::Value& value)
{
return value.asInt() * BaseValue;
}
};
...
Json::Value json{ 66 }; // A JSON value containing the number 66
MultiplyingConverter conv{ 10 };
auto v = JsonUtils::GetValue<int>(json, conv);
// v is equal to 660.
```
## Behavior Chart
### GetValue(T&) (type-deducing)
-|json type invalid|json null|valid
-|-|-|-
`T`|❌ exception|🔵 unchanged|✔ converted
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
### GetValue&lt;T&gt;() (returning)
-|json type invalid|json null|valid
-|-|-|-
`T`|❌ exception|🟨 `T{}` (zero value)|✔ converted
`std::optional<T>`|❌ exception|🟨 `nullopt`|✔ converted
### GetValueForKey(T&) (type-deducing)
GetValueForKey builds on the behavior set from GetValue by adding
a "key not found" state. The remaining three cases are the same.
val type|key not found|_json type invalid_|_json null_|_valid_
-|-|-|-|-
`T`|🔵 unchanged|_❌ exception_|_🔵 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_|_🟨 `T{}` (zero value)_|_✔ converted_
`std::optional<T>`|🟨 `nullopt`|_❌ exception_|_🟨 `nullopt`_|_✔ converted_
### Future Direction
These converters lend themselves very well to automatic _serialization_.

View File

@@ -1,6 +1,7 @@
# Settings.json Documentation
## Globals
Properties listed below affect the entire window, regardless of the profile settings.
| Property | Necessity | Type | Default | Description |
@@ -18,14 +19,16 @@ Properties listed below affect the entire window, regardless of the profile sett
| `showTerminalTitleInTitlebar` | _Required_ | Boolean | `true` | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
| `showTabsInTitlebar` | Optional | Boolean | `true` | When set to `true`, the tabs are moved into the titlebar and the titlebar disappears. When set to `false`, the titlebar sits above the tabs. |
| `snapToGridOnResize` | Optional | Boolean | `false` | When set to `true`, the window will snap to the nearest character boundary on resize. When `false`, the window will resize "smoothly" |
| `tabWidthMode` | Optional | String | `equal` | Sets the width of the tabs. Possible values: `"equal"`, `"titleLength"` |
| `tabWidthMode` | Optional | String | `equal` | Sets the width of the tabs. Possible values: <br><ul><li>`"equal"`: sizes each tab to the same width</li><li>`"titleLength"`: sizes each tab to the length of its title</li><li>`"compact"`: sizes each tab to the length of its title when focused, and shrinks to the size of only the icon when the tab is unfocused.</li></ul> |
| `wordDelimiters` | Optional | String | <code>&nbsp;&#x2f;&#x5c;&#x28;&#x29;&#x22;&#x27;&#x2d;&#x3a;&#x2c;&#x2e;&#x3b;&#x3c;&#x3e;&#x7e;&#x21;&#x40;&#x23;&#x24;&#x25;&#x5e;&#x26;&#x2a;&#x7c;&#x2b;&#x3d;&#x5b;&#x5d;&#x7b;&#x7d;&#x7e;&#x3f;│</code><br>_(`│` is `U+2502 BOX DRAWINGS LIGHT VERTICAL`)_ | Determines the delimiters used in a double click selection. |
| `confirmCloseAllTabs` | Optional | Boolean | `true` | When set to `true` closing a window with multiple tabs open WILL require confirmation. When set to `false` closing a window with multiple tabs open WILL NOT require confirmation. |
| `startOnUserLogin` | Optional | Boolean | `false` | When set to `true` enables the launch of Windows Terminal at startup. Setting to `false` will disable the startup task entry. Note: if the Windows Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect. |
| `disabledProfileSources` | Optional | Array[String] | `[]` | Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup. This array can contain any combination of `Windows.Terminal.Wsl`, `Windows.Terminal.Azure`, or `Windows.Terminal.PowershellCore`. For more information, see [UsingJsonSettings.md](https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md#dynamic-profiles) |
| `experimental.rendering.forceFullRepaint` | Optional | Boolean | `false` | When set to true, we will redraw the entire screen each frame. When set to false, we will render only the updates to the screen between frames. |
| `experimental.rendering.software` | Optional | Boolean | `false` | When set to true, we will use the software renderer (a.k.a. WARP) instead of the hardware one. |
## Profiles
Properties listed below are specific to each unique profile.
| Property | Necessity | Type | Default | Description |
@@ -56,6 +59,7 @@ Properties listed below are specific to each unique profile.
| `scrollbarState` | Optional | String | `"visible"` | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
| `selectionBackground` | Optional | String | | Sets the selection background color of the profile. Overrides `selectionBackground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `snapOnInput` | Optional | Boolean | `true` | When set to `true`, the window will scroll to the command input line when typing. When set to `false`, the window will not scroll when you start typing. |
| `altGrAliasing` | Optional | Boolean | `true` | By default Windows treats Ctrl+Alt as an alias for AltGr. When altGrAliasing is set to false, this behavior will be disabled. |
| `source` | Optional | String | | Stores the name of the profile generator that originated this profile. _There are no discoverable values for this field._ |
| `startingDirectory` | Optional | String | `%USERPROFILE%` | The directory the shell starts in when it is loaded. |
| `suppressApplicationTitle` | Optional | Boolean | `false` | When set to `true`, `tabTitle` overrides the default title of the tab and any title change messages from the application will be suppressed. When set to `false`, `tabTitle` behaves as normal. |
@@ -64,6 +68,7 @@ Properties listed below are specific to each unique profile.
| `experimental.retroTerminalEffect` | Optional | Boolean | `false` | When set to `true`, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed. |
## Schemes
Properties listed below are specific to each color scheme. [ColorTool](https://github.com/microsoft/terminal/tree/master/src/tools/ColorTool) is a great tool you can use to create and explore new color schemes. All colors use hex color format.
| Property | Necessity | Type | Description |
@@ -91,6 +96,7 @@ Properties listed below are specific to each color scheme. [ColorTool](https://g
| `yellow` | _Required_ | String | Sets the color used as ANSI yellow. |
## Keybindings
Properties listed below are specific to each custom key binding.
| Property | Necessity | Type | Description |
@@ -146,6 +152,7 @@ For commands with arguments:
`ctrl+`, `shift+`, `alt+`
#### Keys
| Type | Keys |
| ---- | ---- |
| Function and Alphanumeric Keys | `f1-f24`, `a-z`, `0-9` |
@@ -155,6 +162,7 @@ For commands with arguments:
| Numpad Keys | `numpad_0-numpad_9`, `numpad0-numpad9`, `numpad_add`, `numpad_plus`, `numpad_decimal`, `numpad_period`, `numpad_divide`, `numpad_minus`, `numpad_subtract`, `numpad_multiply` |
## Background Images and Icons
Some Terminal settings allow you to specify custom background images and icons. It is recommended that custom images and icons are stored in system-provided folders and are referred to using the correct [URI Schemes](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes). URI Schemes provide a way to reference files independent of their physical paths (which may change in the future).
The most useful URI schemes to remember when customizing background images and icons are:
@@ -167,6 +175,7 @@ The most useful URI schemes to remember when customizing background images and i
> ⚠ Note: Do not rely on file references using the `ms-appx` URI Scheme (i.e. icons). These files are considered an internal implementation detail and may change name/location or may be omitted in the future.
### Icons
Terminal displays icons for each of your profiles which Terminal generates for any built-in shells - PowerShell Core, PowerShell, and any installed Linux/WSL distros. Each profile refers to a stock icon via the `ms-appx` URI Scheme.
> ⚠ Note: Do not rely on the files referenced by the `ms-appx` URI Scheme - they are considered an internal implementation detail and may change name/location or may be omitted in the future.
@@ -180,6 +189,7 @@ You can refer to you own icons if you wish, e.g.:
> 👉 Tip: Icons should be sized to 32x32px in an appropriate raster image format (e.g. .PNG, .GIF, or .ICO) to avoid having to scale your icons during runtime (causing a noticeable delay and loss of quality.)
### Custom Background Images
You can apply a background image to each of your profiles, allowing you to configure/brand/style each of your profiles independently from one another if you wish.
To do so, specify your preferred `backgroundImage`, position it using `backgroundImageAlignment`, set its opacity with `backgroundImageOpacity`, and/or specify how your image fill the available space using `backgroundImageStretchMode`.

View File

@@ -231,6 +231,32 @@
}
]
},
"OpenSettingsAction": {
"description": "Arguments corresponding to a Open Settings Action",
"allOf": [
{
"$ref": "#/definitions/ShortcutAction"
},
{
"properties": {
"action": {
"type": "string",
"pattern": "openSettings"
},
"target": {
"type": "string",
"default": "settingsFile",
"description": "The settings file to open.",
"enum": [
"settingsFile",
"defaultsFile",
"allFiles"
]
}
}
}
]
},
"Keybinding": {
"additionalProperties": false,
"properties": {
@@ -245,6 +271,7 @@
{ "$ref": "#/definitions/MoveFocusAction" },
{ "$ref": "#/definitions/ResizePaneAction" },
{ "$ref": "#/definitions/SplitPaneAction" },
{ "$ref": "#/definitions/OpenSettingsAction" },
{ "type": "null" }
]
},
@@ -290,8 +317,8 @@
"type": "boolean"
},
"defaultProfile": {
"$ref": "#/definitions/ProfileGuid",
"description": "Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\". The \"guid\" of the desired default profile is used as the value."
"description": "Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\".",
"type": "string"
},
"disabledProfileSources": {
"description": "Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup.",
@@ -376,8 +403,9 @@
},
"tabWidthMode": {
"default": "equal",
"description": "Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title",
"description": "Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title\n -\"compact\" sizes each tab to the length of its title when focused, and shrinks to the size of only the icon when the tab is unfocused.",
"enum": [
"compact",
"equal",
"titleLength"
],
@@ -534,7 +562,7 @@
"fontWeight": {
"default": "normal",
"description": "Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values:\n -\"thin\"\n -\"extra-light\"\n -\"light\"\n -\"semi-light\"\n -\"normal\" (default)\n -\"medium\"\n -\"semi-bold\"\n -\"bold\"\n -\"extra-bold\"\n -\"black\"\n -\"extra-black\" or the corresponding numeric representation of OpenType font weight.",
"oneOf": [
"oneOf": [
{
"enum": [
"thin",
@@ -556,7 +584,8 @@
"minimum": 100,
"type": "integer"
}
}
]
},
"foreground": {
"$ref": "#/definitions/Color",
"default": "#cccccc",
@@ -614,6 +643,11 @@
"description": "When set to true, the window will scroll to the command input line when typing. When set to false, the window will not scroll when you start typing.",
"type": "boolean"
},
"altGrAliasing": {
"default": true,
"description": "By default Windows treats Ctrl+Alt as an alias for AltGr. When altGrAliasing is set to false, this behavior will be disabled.",
"type": "boolean"
},
"source": {
"description": "Stores the name of the profile generator that originated this profile.",
"type": ["string", "null"]

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 345 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

View File

@@ -0,0 +1,227 @@
---
author: Leon Liang @leonMSFT
created on: 2019-11-27
last updated: 2020-06-16
issue id: 1502
---
# Advanced Tab Switcher
## Abstract
Currently the user is able to cycle through tabs on the tab bar. However, this horizontal cycling can be pretty inconvenient when the tab titles are long or when there are too many tabs on the tab bar. It could also get hard to see all your available tabs if the tab titles are long and your screen is small. In addition, there's a common use case to quickly switch between two tabs, e.g. when one tab is used as reference and the other is the actively worked-on tab. If the tabs are not right next to each other on the tab bar, it could be difficult to quickly swap between the two. Having the tabs displayed in Most Recently Used (MRU) order would help with this problem. It could also make the user experience better when there are a handful of tabs that are frequently used, but are nowhere near each other on the tab bar.
Having a tab switcher UI, like the ones in Visual Studio and Visual Studio Code, could help with the tab experience. Presenting the tabs vertically in their own little UI allows the user to see more of the tabs at once, compared to scanning the tab row horizontally and scrolling left/right to find the tab you want. The tab order in those tab switchers are also in MRU order by default.
To try to alleviate some of these user scenarios, we want to create a tab switcher similar to the ones found in VSCode and VS. This spec will cover the design of the switcher, and how a user would interact with the switcher. It would be primarily keyboard driven, and would give a pop-up display of a vertical list of tabs. The tab switcher would also be able to display the tabs in Most Recently Used (MRU) order.
## Inspiration
This was mainly inspired by the tab switcher that's found in Visual Studio Code and Visual Studio.
VS Code's tab switcher appears directly underneath the tab bar.
![Visual Studio Code Tab Switcher](img/VSCodeTabSwitcher.png)
Visual Studio's tab switcher presents itself as a box in the middle of the editor.
![Visual Studio Tab Switcher](img/VSTabSwitcher.png)
In terms of navigating the switcher, both VSCode and Visual Studio behave very similarly. Both open with the press of <kbd>ctrl+tab</kbd> and dismiss on release of <kbd>ctrl</kbd>. They both also allow the user to select the tab with the mouse and with <kbd>enter</kbd>. <kbd>esc</kbd> and a mouse click outside of the switcher both dismiss the window as well.
I'm partial towards looking like VSCode's Tab Switcher - specifically because it seems like both their Command Palette and Tab Switcher use the same UI. You can observe this by first bringing up the command palette, then hitting the keybinding to bring up the tab switcher. You'll notice that they're both using the same centered drop-down from the tab row. In fact, hitting the Tab Switcher keybinding in VSCode while the Command Palette is open simply auto fills the search box with "edit active", signifying that the user wants to select one of the tabs to edit, effectively "swapping" to the tab that's highlighted.
Since Terminal now has a command palette, it would be amazing to reuse that UI and simply fill it with the names of a user's currently open tabs!
## Solution Design
To extend upon the command palette, we simply need to create and maintain two Vector<Commands>, where each command will simply dispatch a `SwitchToTab` `ShortcutAction`. One vector will have the commands in tab row order, and the other will be in MRU order. They'll both have to be maintained along with our existing vector of tabs.
These vectors of commands can then be set as the commands to pull from in the command palette, and as long as the tab titles are available in these commands, the command palette will be able to naturally filter through the tabs as a user types in its search bar. Just like the command palette, a user will be able to navigate through the list of tabs with the arrow keys and pointer interactions. As part of this implementation, I can supplement these actions with "tab switcher specific" navigation keybindings that would only work if the command palette is in tab switcher mode.
The `TabSwitcherControl` will use `TerminalPage`'s `ShortcutActionDispatch` to dispatch a `SwitchToTab` `ShortcutAction`. This will eventually cause `TerminalPage::_OnTabSelectionChanged` to be called. We can update the MRU in this function to be sure that changing tabs from the TabSwitcher, clicking on a tab, or nextTab/prevTab-ing will keep the MRU up-to-date. Adding or closing tabs are handled in `_OpenNewTab` and `_CloseFocusedTab`, which will need to be modified to update the command vectors.
## UI/UX Design
The Tab Switcher will reuse a lot of the XAML code that's used in the command palette. This means it'll show up as a drop-down from the horizontal center of the tab row. It'll appear as a single overlay over the whole Terminal window. There will also be a search box on top of the list of tabs. Here's a rough mockup of how the command palette/tab switcher looks like:
![Mockup Command Palette with Tab Titles](img/CommandPaletteExample.png)
Each entry in the list will show the tab's titles and their assigned number for quick switching, and only one line will be highlighted to signify the tab that is currently selected. The top 9 tabs in the list are numbered for quick switching, and the rest of the tabs will simply have an empty space where a number would be.
The list would look (roughly) like this:
```
1 foo (highlighted)
2 boo
3 Windows
4 /c/Users/booboo
5 Git Moo
6 shoo
7 /c/
8 /d/
9 /e/
/f/
/g/
/h/
```
The highlighted line can move up or down, and if the user moves up while the highlighted line is already at the top of the list, the highlight will wrap around to the bottom of the list. Similarly, it will wrap to the top if the highlight is at the bottom of the list and the user moves down.
If there's more tabs than the UI can display, the list of tabs will scroll up/down as the user keeps iterating up/down. Even if some of the numbered tabs (the first 9 tabs) are not visible, the user can still press any number 1 through 9 to quick switch to that tab.
To give an example of what happens after scrolling past the end, imagine a user is starting from the state in the mock above. The user then iterates down past the end of the visible list four times. The below mock shows the result.
```
5 Git Moo
6 shoo
7 /c/
8 /d
9 /e/
/f/
/g/
/h/
/i/
/j/
/k/
/l/ (highlighted)
```
The tabs designated by numbers 1 through 4 are no longer visible (but still quick-switchable), and the list now starts with "Git Moo", which is associated with number 5.
### Using the Switcher
#### Opening the Tab Switcher
The user can press a keybinding named `tabSwitcher` to bring up the command palette UI with a list of tab titles.
The user can also bring up the command palette first, and type a "tab switcher" prefix like "@" into the search bar to switch into "tab switcher mode".
The user will be able to change it to whatever they like.
There will also be an optional `anchor` arg that may be provided to this keybinding.
#### Keeping it open
We use the term `anchor` to illustrate the idea that the UI stays visible as long as something is "anchoring" it down.
Here's an example of how to set the `anchor` key in the settings:
```
{"keys": ["ctrl+tab"], "command": {"action": "openTabSwitcher", "anchor": "ctrl" }}
```
This user provided the `anchor` key arg, and set it to <kbd>ctrl</kbd>. So, the user would open the UI with <kbd>ctrl+tab</kbd>, and as long as the user is holding <kbd>ctrl</kbd> down, the UI won't dismiss. The moment the user releases <kbd>ctrl</kbd>, the UI dismisses. The `anchor` key needs to be one of the keys in the `openTabSwitcher` keybinding. If it isn't, we'll display a warning dialog in this case saying that the `anchor` key isn't actually part of the keybinding, and the user might run into some weird behavior.
If `openTabSwitcher` is not given an `anchor` key, the switcher will stay visible even after the release of the keybinding.
#### Switching through Tabs
The user will be able to navigate through the switcher with the following keybindings:
- Switching Down: <kbd>tab</kbd> or <kbd>downArrow</kbd>
- Switching Up: <kbd>shift+tab</kbd> or <kbd>upArrow</kbd>
As the user is cycling through the tab list, the selected tab will be highlighted but the terminal won't actually switch focus to the selected tab. This also applies to pointer interaction. Hovering over an item with a mouse will highlight the item but not switch to the tab.
#### Closing the Switcher and Bringing a Tab into Focus
There are two _dismissal_ keybindings:
1. <kbd>enter</kbd> : brings the currently selected tab into focus and dismisses the UI.
2. <kbd>esc</kbd> : dismisses the UI without changing tab focus.
The following are ways a user can dismiss the UI, _whether or not_ the `Anchor` key is provided to `openTabSwitcher`.
1. The user can press a number associated with a tab to instantly switch to the tab and dismiss the switcher.
2. The user can click on a tab to instantly switch to the tab and dismiss the switcher.
3. The user can click outside of the UI to dismiss the switcher without bringing the selected tab into focus.
4. The user can press any of the dismissal keybindings.
If the `anchor` key is provided, then in addition to the above methods, the UI will dismiss upon the release of the `anchor` key.
Pressing the `openTabSwitcher` keychord again will not close the switcher, it'll do nothing.
### Most Recently Used Order
We'll provide a setting that will allow the list of tabs to be presented in either _in-order_ (how the tabs are ordered on the tab bar), or _Most Recently Used Order_ (MRU). MRU means that the tab that the terminal most recently visited will be on the top of the list, and the tab that the terminal has not visited for the longest time will be on the bottom.
There will be an argument for the `openTabSwitcher` action called `displayOrder`. This can be either `inOrder` or `mruOrder`. Making the setting an argument passed into `openTabSwitcher` would allow the user to have one keybinding to open an MRU Tab Switcher, and different one for the In-Order Tab Switcher. For example:
```
{"keys": ["ctrl+tab"], "command": {"action": "openTabSwitcher", "anchor":"ctrl", "displayOrder":"mruOrder"}}
{"keys": ["ctrl+shift+p"], "command": {"action": "openTabSwitcher", "anchor":"ctrl", "displayOrder":"inOrder"}}
```
By default (when the arg isn't specified), `displayOrder` will be "mruOrder".
### Numbered Tabs
Similar to how the user can currently switch to a particular tab with a combination of keys such as <kbd>ctrl+shift+1</kbd>, we want to have the tab switcher provide a number to the first nine tabs (1-9) in the list for quick switching. If there are more than nine tabs in the list, then the rest of the tabs will not have a number assigned.
## Capabilities
### Accessibility
- The tab switcher will be using WinUI, and so it'll be automatically linked to the UIA tree. This allows screen readers to find it, and so narrator will be able to navigate the switcher easily.
- The UI is also fully keyboard-driven, with the option of using a mouse to interact with the UI.
- When the tab switcher pops up, the focus immediately swaps to it.
- For the sake of more contrast with the background, we could use a ThemeShadow to bring the UI closer to the user, making the focus clearer.
### Security
This shouldn't introduce any security issues.
### Reliability
How we're updating the MRU is something to watch out for since it triggers on a lot of tab interactions. However, I don't foresee the update taking long at all, and I can't imagine that users can create and delete tabs fast enough to matter.
### Compatibility
- The existing way of navigating horizontally through the tabs on the tab bar should not break.
- These should also be separate keybindings from the keybindings associated with using the tab switcher.
- When a user reorders their tabs on the tab bar, the MRU order remains unchanged. For example:
- Tab Bar:`[cmd(focused), ps, wsl]` and MRU:`[cmd, ps, wsl]`
- Reordered Tab Bar:`[wsl, cmd(focused), ps]` and MRU:`[cmd, ps, wsl]`
### Performance, Power, and Efficiency
## Potential Issues
We'll need to be careful about how the UI is presented depending on different sizes of the terminal. We also should test how the UI looks as it's open and resizing is happening. Visual Studio's tab switcher is a fixed size, and is always in the middle. Even when the VS window is smaller than the tab switcher size, the tab switcher will show up larger than the VS window itself.
![Small Visual Studio Without Tab Switcher](img/VSMinimumSize.png)
![Small Visual Studio With Tab Switcher](img/VSMinimumSizeWithTabSwitcher.png)
Visual Studio Code only allows the user to shrink the window until it hits a minimum width and height. This minimum width and height gives its tab switcher enough space to show a meaningful amount of information.
![Small Visual Studio Code with Tab Switcher](img/VSCodeMinimumTabSwitcherSize.png)
Terminal can't really replicate Visual Studio's version of the tab switcher in this situation. The TabSwitcher needs to be contained within the Terminal. So, if the TabSwitcher is always centered and has a percentage padding from the borders of the Terminal, it'll shrink as Terminal shrinks. Since the Terminal also has a minimum width, the switcher should always have enough space to be usefully visible.
## Future considerations
### Pane Navigation
There was discussion in [#1502] that brought up the idea of pane navigation, inspired by tmux.
![Tmux Tab and Pane Switching](img/tmuxPaneSwitching.png)
Tmux allows the user to navigate directly to a pane and even give a preview of the pane. This would be extremely useful since it would allow the user to see a tree of their open tabs and panes. Currently there's no way to see what panes are open in each tab, so if you're looking for a particular pane, you'd need to cycle through your tabs to find it. If something like pane profile names (not sure what information to present in the switcher for panes) were presented in the TabSwitcher, the user could see all the panes in one box.
To support pane navigation, the tab switcher can simply have another column to the right of the tab list to show a list of panes inside the selected tab. As the user iterates through the tab list, they can simply hit right to dig deeper into the tab's panes, and hit left to come back to the tab list. Each tab's list of panes will be MRU or in-order, depending on which `displayOrder` arg was provided to the `openTabSwitcher` keybinding.
Pane navigation is a clear next step to build on top of the tab switcher, but this spec will specifically deal with just tab navigation in order to keep the scope tight. The tab switcher implementation just needs to allow for pane navigation to be added in later.
### Tab Preview on Hover
With this feature, having a tab highlighted in the switcher would make the Terminal display that tab as if it switched to it. I believe currently there is no way to set focus to a tab in a "preview" mode. This is important because MRU updates whenever a tab is focused, but we don't want the MRU to update on a preview. Given that this feature is a "nice thing to have", I'll leave it for
after the tab switcher has landed.
## Resources
Feature Request: An advanced tab switcher [#1502]
Ctrl+Tab toggle between last two windows like Alt+Tab [#973]
The Command Palette Thread [#2046]
The Command Palette Spec [#5674]
Feature Request: Search [#605]
<!-- Footnotes -->
[#605]: https://github.com/microsoft/terminal/issues/605
[#973]: https://github.com/microsoft/terminal/issues/973
[#1502]: https://github.com/microsoft/terminal/issues/1502
[#2046]: https://github.com/microsoft/terminal/issues/2046
[#5674]: https://github.com/microsoft/terminal/pull/5674

View File

@@ -0,0 +1,789 @@
---
author: Mike Griese @zadjii-msft
created on: 2019-08-01
last updated: 2020-06-10
issue id: 2046
---
# Command Palette
## Abstract
This spec covers the addition of a "command palette" to the Windows Terminal.
The Command Palette is a GUI that the user can activate to search for and
execute commands. Beneficially, the command palette allows the user to execute
commands _even if they aren't bound to a keybinding_.
## Inspiration
This feature is largely inspired by the "Command Palette" in text editors like
VsCode, Sublime Text and others.
This spec was initially drafted in [a
comment](https://github.com/microsoft/terminal/issues/2046#issuecomment-514219791)
in [#2046]. That was authored during the annual Microsoft Hackathon, where I
proceeded to prototype the solution. This spec is influenced by things I learned
prototyping.
Initially, the command palette was designed simply as a method for executing
certain actions that the user pre-defined. With the addition of [commandline
arguments](https://github.com/microsoft/terminal/issues/4632) to the Windows
Terminal in v0.9, we also considered what it might mean to be able to have the
command palette work as an effective UI not only for dispatching pre-defined
commands, but also `wt.exe` commandlines to the current terminal instance.
## Solution Design
Fundamentally, we need to address two different modes of using the command palette:
* In the first mode, the command palette can be used to quickly look up
pre-defined actions and dispatch them. We'll refer to this as "Action Mode".
* The second mode allows the user to run `wt` commandline commands and have them
apply immediately to the current Terminal window. We'll refer to this as
"commandline mode".
Both these options will be discussed in detail below.
### Action Mode
We'll introduce a new top-level array to the user settings, under the key
`commands`. `commands` will contain an array of commands, each with the
following schema:
```js
{
"name": string|object,
"action": string|object,
"icon": string
}
```
Command names should be human-friendly names of actions, though they don't need
to necessarily be related to the action that it fires. For example, a command
with `newTab` as the action could have `"Open New Tab"` as the name.
The command will be parsed into a new class, `Command`:
```c++
class Command
{
winrt::hstring Name();
winrt::TerminalApp::ActionAndArgs ActionAndArgs();
winrt::hstring IconSource();
}
```
We'll add another structure in GlobalAppSettings to hold all these actions. It
will just be a `std::vector<Command>` in `GlobalAppSettings`.
We'll need app to be able to turn this vector into a `ListView`, or similar, so
that we can display this list of actions. Each element in the view will be
intrinsically associated with the `Command` object it's associated with. In
order to support this, we'll make `Command` a winrt type that implements
`Windows.UI.Xaml.Data.INotifyPropertyChanged`. This will let us bind the XAML
element to the winrt type.
When an element is clicked on in the list of commands, we'll raise the event
corresponding to that `ShortcutAction`. `AppKeyBindings` already does a great
job of dispatching `ShortcutActions` (and their associated arguments), so we'll
re-use that. We'll pull the basic parts of dispatching `ActionAndArgs`
callbacks into another class, `ShortcutActionDispatch`, with a single
`DoAction(ActionAndArgs)` method (and events for each action).
`AppKeyBindings` will be initialized with a reference to the
`ShortcutActionDispatch` object, so that it can call `DoAction` on it.
Additionally, by having a singular `ShortcutActionDispatch` instance, we won't
need to re-hook up the ShortcutAction keybindings each time we re-load the
settings.
In `TerminalPage`, when someone clicks on an item in the list, we'll get the
`ActionAndArgs` associated with that list element, and call `DoAction` on
the app's `ShortcutActionDispatch`. This will trigger the event handler just the
same as pressing the keybinding.
#### Commands for each profile?
[#3879] Is a request for being able to launch a profile directly, via the
command palette. Essentially, the user will type the name of a profile, and hit
enter to launch that profile. I quite like this idea, but with the current spec,
this won't work great. We'd need to manually have one entry in the command
palette for each profile, and every time the user adds a profile, they'd need to
update the list of commands to add a new entry for that profile as well.
This is a fairly complicated addition to this feature, so I'd hold it for
"Command Palette v2", though I believe it's solution deserves special
consideration from the outset.
I suggest that we need a mechanism by which the user can specify a single
command that would be expanded to one command for every profile in the list of
profiles. Consider the following sample:
```json
"commands": [
{
"expandOn": "profiles",
"icon": "${profile.icon}",
"name": "New Tab with ${profile.name}",
"command": { "action": "newTab", "profile": "${profile.name}" }
},
{
"expandOn": "profiles",
"icon": "${profile.icon}",
"name": "New Vertical Split with ${profile.name}",
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
}
],
```
In this example:
* The `"expandOn": "profiles"` property indicates that each command should be
repeated for each individual profile.
* The `${profile.name}` value is treated as "when expanded, use the given
profile's name". This allows each command to use the `name` and `icon`
properties of a `Profile` to customize the text of the command.
To ensure that this works correctly, we'll need to make sure to expand these
commands after all the other settings have been parsed, presumably in the
`Validate` phase. If we do it earlier, it's possible that not all the profiles
from various sources will have been added yet, which would lead to an incomplete
command list.
We'll need to have a placeholder property to indicate that a command should be
expanded for each `Profile`. When the command is first parsed, we'll leave the
format strings `${...}` unexpanded at this time. Then, in the validate phase,
when we encounter a `"expandOn": "profiles"` command, we'll remove it from the
list, and use it as a prototype to generate commands for every `Profile` in our
profiles list. We'll do a string find-and-replace on the format strings to
replace them with the values from the profile, before adding the completed
command to the list of commands.
Of course, how does this work with localization? Considering the [section
below](#localization), we'd update the built-in commands to the following:
```json
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "NewTabWithProfileCommandName" },
"command": { "action": "newTab", "profile": "${profile.name}" }
},
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "NewVerticalSplitWithProfileCommandName" },
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
}
],
```
In this example, we'll look up the `NewTabWithProfileCommandName` resource when
we're first parsing the command, to find a string similar to `"New Tab with
${profile.name}"`. When we then later expand the command, we'll see the
`${profile.name}` bit from the resource, and expand that like we normally would.
Trickily, we'll need to make sure to have a helper for replacing strings like
this that can be used for general purpose arg parsing. As you can see, the
`profile` property of the `newTab` command also needs the name of the profile.
Either the command validation will need to go through and update these strings
manually, or we'll need another of enabling these `IActionArgs` classes to fill
those parameters in based on the profile being used. Perhaps the command
pre-expansion could just stash the json for the action, then expand it later?
This implementation detail is why this particular feature is not slated for
inclusion in an initial Command Palette implementation.
From initial prototyping, it seems like the best solution will be to stash the
command's original json around when parsing an expandable command like the above
examples. Then, we'll handle the expansion in the settings validation phase,
after all the profiles and color schemes have been loaded.
For each profile, we'll need to replace all the instances in the original json
of strings like `${profile.name}` with the profile's name to create a new json
string. We'll attempt to parse that new string into a new command to add to the
list of commands.
### Commandline Mode
One of our more highly requested features is the ability to run a `wt.exe`
commandline in the current WT window (see [#4472]). Typically, users want the
ability to do this straight from whatever shell they're currently running.
However, we don't really have an effective way currently to know if WT is itself
being called from another WT instance, and passing those arguments to the
hosting WT. Furthermore, in the long term, we see that feature as needing the
ability to not only run commands in the current WT window, but an _arbitrary_ WT
window.
The Command Palette seems like a natural fit for a stopgap measure while we
design the correct way to have a `wt` commandline apply to the window it's
running in.
In Commandline Mode, the user can simply type a `wt.exe` commandline, and when
they hit enter, we'll parse the commandline and dispatch it _to the current
window_. So if the user wants to open a new tab, they could type `new-tab` in
Commandline Mode, and it would open a new tab in the current window. They're
also free to chain multiple commands like they can with `wt` from a shell - by
entering something like `split-pane -p "Windows PowerShell" ; split-pane -H
wsl.exe`, the terminal would execute two `SplitPane` actions in the currently
focused pane, creating one with the "Windows PowerShell" profile and another
with the default profile running `wsl` in it.
## UI/UX Design
We'll add another action that can be used to toggle the visibility of the
command palette. Pressing that keybinding will bring up the command palette. We
should make sure to add a argument to this action that specifies whether the
palette should be opened directly in Action Mode or Commandline Mode.
When the command palette appears, we'll want it to appear as a single overlay
over all of the panes of the Terminal. The drop-down will be centered
horizontally, dropping down from the top (from the tab row). When commands are
entered, it will be implied that they are delivered to the focused terminal
pane. This will help avoid two problematic scenarios that could arise from
having the command palette attached to a single pane:
* When attached to a single pane, it might be very easy for the UI to quickly
become cluttered, especially at smaller pane sizes.
* This avoids the "find the overlay problem" which is common in editors like
VS where the dialog appears attached to the active editor pane.
The palette will consist of two main UI elements: a text box for
entering/searching for commands, and in action mode, a list of commands.
### Action Mode
The list of commands will be populated with all the commands by default. Each
command will appear like a `MenuFlyoutItem`, with an icon at the left (if it has
one) and the name visible. When opened, the palette will automatically highlight
the first entry in the list.
The user can navigate the list of entries with the arrow keys. Hitting enter
will close the palette and execute the action that's highlighted. Hitting escape
will dismiss the palette, returning control to the terminal. When the palette is
closed for any reason (executing a command, dismissing with either escape or the
`toggleCommandPalette` keybinding), we'll clear out any search text from the
palette, so the user can start fresh again.
We'll also want to enable the command palette to be filterable, so that the user
can type the name of a command, and the command palette will automatically
filter the list of commands. This should be more powerful then just a simple
string compare - the user should be able to type a search string, and get all
the commands that match a "fuzzy search" for that string. This will allow users
to find the command they're looking for without needing to type the entire
command.
For example, consider the following list of commands:
```json
"commands": [
{ "icon": null, "name": "New Tab", "action": "newTab" },
{ "icon": null, "name": "Close Tab", "action": "closeTab" },
{ "icon": null, "name": "Close Pane", "action": "closePane" },
{ "icon": null, "name": "[-] Split Horizontal", "action": { "action": "splitPane", "split": "horizontal" } },
{ "icon": null, "name": "[ | ] Split Vertical", "action": { "action": "splitPane", "split": "vertical" } },
{ "icon": null, "name": "Next Tab", "action": "nextTab" },
{ "icon": null, "name": "Prev Tab", "action": "prevTab" },
{ "icon": null, "name": "Open Settings", "action": "openSettings" },
{ "icon": null, "name": "Open Media Controls", "action": "openTestPane" }
],
```
* "open" should return both "**Open** Settings" and "**Open** Media Controls".
* "Tab" would return "New **Tab**", "Close **Tab**", "Next **Tab**" and "Prev
**Tab**".
* "P" would return "Close **P**ane", "[-] S**p**lit Horizontal", "[ | ]
S**p**lit Vertical", "**P**rev Tab", "O**p**en Settings" and "O**p**en Media
Controls".
* Even more powerfully, "sv" would return "[ | ] Split Vertical" (by matching
the **S** in "Split", then the **V** in "Vertical"). This is a great example
of how a user could execute a command with very few keystrokes.
As the user types, we should **bold** each matching character in the command
name, to show how their input correlates to the results on screen.
Additionally, it will be important for commands in the action list to display
the keybinding that's bound to them, if there is one.
### Commandline Mode
Commandline mode is much simpler. In this mode, we'll simply display a text input,
similar to the search box that's rendered for Action Mode. In this box, the
user will be able to type a `wt.exe` style commandline. The user does not need
to start this commandline with `wt` (or `wtd`, etc) - since we're already
running in WT, the user shouldn't really need to repeat themselves.
When the user hits <kbd>enter</kbd>, we'll attempt to parse the commandline. If
we're successful in parsing the commandline, we can close the palette and
dispatch the commandline. If the commandline had errors, we should reveal a text
box with an error message below the text input. We'll leave the palette open
with their entered command, so they can edit the commandline and try again. We
should _probably_ leave the message up for a few seconds once they've begun
editing the commandline, but eventually hide the message (ideally with a motion
animation).
### Switching Between Modes
**TODO**: This is a topic for _discussion_.
How do we differentiate Action Mode from Commandline Mode?
I think there should be a character that the user types that switches the mode.
This is reminiscent of how the command palette works in applications like VsCode
and Sublime Text. The same UI is used for a number of functions. In the case of
VsCode, when the user opens the palette, it's initially in a "navigate to file"
mode. When the user types the prefix character `@`, the menu seamlessly switches
to a "navigate to symbol mode". Similarly, users can use `:` for "go to line"
and `>` enters an "editor command" mode.
I believe we should use a similarly implemented UI. The UI would be in one of
the two modes by default, and typing the prefix character would enter the other
mode. If the user deletes the prefix character, then we'd switch back into the
default mode.
When the user is in Action Mode vs Commandline mode, if the input is empty
(besides potentially the prefix character), we should probably have some sort of
placeholder text visible to indicate which mode the user is in. Something like
_"Enter a command name..."_ for action mode, or _"Type a wt commandline..."_ for
commandline mode.
Initially, I favored having the palette in Action Mode by default, and typing a
`:` prefix to enter Commandline Mode. This is fairly similar to how tmux's
internal command prompt works, which is bound to `<prefix>-:` by default.
If we wanted to remain _similar_ to VsCode, we'd have no prefix character be the
Commandline Mode, and `>` would enter the Action mode. I'd think that might
actually be _backwards_ from what I'd expect, with `>` being the default
character for the end of the default `cmd` `%PROMPT%`.
**FOR DISCUSSION** What option makes the most sense to the team? I'm leaning
towards the VsCode style (where Action='>', Commandline='') currently.
Enabling the user to configure this prefix is discussed below in "[Future
Considerations](#Configuring-The-ActionCommandline-Mode-Prefix)".
### Layering and "Unbinding" Commands
As we'll be providing a list of default commands, the user will inevitably want
to change or remove some of these default commands.
Commands should be layered based upon the _evaluated_ value of the "name"
property. Since the default commands will all use localized strings in the
`"name": { "key": "KeyName" }` format, the user should be able to override the
command based on the localized string for that command.
So, assuming that `NewTabCommandName` is evaluated as "Open New Tab", the
following command
```json
{ "icon": null, "name": { "key": "NewTabCommandName" }, "action": "newTab" },
```
Could be overridden with the command:
```json
{ "icon": null, "name": "Open New Tab", "action": "splitPane" },
```
Similarly, if the user wants to remove that command from the command palette,
they could set the action to `null`:
```json
{ "icon": null, "name": "Open New Tab", "action": null },
```
This will remove the command from the command list.
## Capabilities
### Accessibility
As the entire command palette will be a native XAML element, it'll automatically
be hooked up to the UIA tree, allowing for screen readers to naturally find it.
* When the palette is opened, it will automatically receive focus.
* The terminal panes will not be able to be interacted with while the palette
is open, which will help keep the UIA tree simple while the palette is open.
### Security
This should not introduce any _new_ security concerns. We're relying on the
security of jsoncpp for parsing json. Adding new keys to the settings file
will rely on jsoncpp's ability to securely parse those json values.
### Reliability
We'll need to make sure that invalid commands are ignored. A command could be
invalid because:
* it has a null `name`, or a name with the empty string for a value.
* it has a null `action`, or an action specified that's not an actual
`ShortcutAction`.
We'll ignore invalid commands from the user's settings, instead of hard
crashing. I don't believe this is a scenario that warrants an error dialog to
indicate to the user that there's a problem with the json.
### Compatibility
We will need to define default _commands_ for all the existing keybinding
commands. With #754, we could add all the actions (that make sense) as commands
to the commands list, so that everyone wouldn't need to define them manually.
### Performance, Power, and Efficiency
We'll be adding a few extra XAML elements to our tree which will certainly
increase our runtime memory footprint while the palette is open.
We'll additionally be introducing a few extra json values to parse, so that could
increase our load times (though this will likely be negligible).
## Potential Issues
This will first require the work in [#1205] to work properly. Right now we
heavily lean on the "focused" element to determine which terminal is "active".
However, when the command palette is opened, focus will move out of the terminal
control into the command palette, which leads to some hard to debug crashes.
Additionally, we'll need to ensure that the "fuzzy search" algorithm proposed
above will work for non-english languages, where a single character might be
multiple `char`s long. As we'll be using a standard XAML text box for input, we
won't need to worry about handling the input ourselves.
### Localization
Because we'll be shipping a set of default commands with the terminal, we should
make sure that list of commands can be localizable. Each of the names we'll give
to the commands should be locale-specific.
To facilitate this, we'll use a special type of object in JSON that will let us
specify a resource name in JSON. We'll use a syntax like the following to
suggest that we should load a string from our resources, as opposed to using the
value from the file:
```json
"commands": [
{ "icon": null, "name": { "key": "NewTabCommandName" }, "action": "newTab" },
{ "icon": null, "name": { "key": "CloseTabCommandKey" }, "action": "closeTab" },
{ "icon": null, "name": { "key": "ClosePaneCommandKey" }, "action": "closePane" },
{ "icon": null, "name": { "key": "SplitHorizontalCommandKey" }, "action": { "action": "splitPane", "split": "horizontal" } },
{ "icon": null, "name": { "key": "SplitVerticalCommandKey" }, "action": { "action": "splitPane", "split": "vertical" } },
{ "icon": null, "name": { "key": "NextTabCommandKey" }, "action": "nextTab" },
{ "icon": null, "name": { "key": "PrevTabCommandKey" }, "action": "prevTab" },
{ "icon": null, "name": { "key": "OpenSettingsCommandKey" }, "action": "openSettings" },
],
```
We'll check at parse time if the `name` property is a string or an object. If
it's a string, we'll treat that string as the literal text. Otherwise, if it's
an object, we'll attempt to use the `key` property of that object to look up a
string from our `ResourceDictionary`. This way, we'll be able to ship localized
strings for all the built-in commands, while also allowing the user to easily
add their own commands.
During the spec review process, we considered other options for localization as
well. The original proposal included options such as having one `defaults.json`
file per-locale, and building the Terminal independently for each locale. Those
were not really feasible options, so we instead settled on this solution, as it
allowed us to leverage the existing localization support provided to us by the
platform.
The `{ "key": "resourceName" }` solution proposed here was also touched on in
[#5280].
### Proposed Defaults
These are the following commands I'm proposing adding to the command palette by
default. These are largely the actions that are bound by default.
```json
"commands": [
{ "icon": null, "name": { "key": "NewTabCommandKey" }, "action": "newTab" },
{ "icon": null, "name": { "key": "DuplicateTabCommandKey" }, "action": "duplicateTab" },
{ "icon": null, "name": { "key": "DuplicatePaneCommandKey" }, "action": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" } },
{ "icon": null, "name": { "key": "SplitHorizontalCommandKey" }, "action": { "action": "splitPane", "split": "horizontal" } },
{ "icon": null, "name": { "key": "SplitVerticalCommandKey" }, "action": { "action": "splitPane", "split": "vertical" } },
{ "icon": null, "name": { "key": "CloseWindowCommandKey" }, "action": "closeWindow" },
{ "icon": null, "name": { "key": "ClosePaneCommandKey" }, "action": "closePane" },
{ "icon": null, "name": { "key": "OpenNewTabDropdownCommandKey" }, "action": "openNewTabDropdown" },
{ "icon": null, "name": { "key": "OpenSettingsCommandKey" }, "action": "openSettings" },
{ "icon": null, "name": { "key": "FindCommandKey" }, "action": "find" },
{ "icon": null, "name": { "key": "NextTabCommandKey" }, "action": "nextTab" },
{ "icon": null, "name": { "key": "PrevTabCommandKey" }, "action": "prevTab" },
{ "icon": null, "name": { "key": "ToggleFullscreenCommandKey" }, "action": "toggleFullscreen" },
{ "icon": null, "name": { "key": "CopyTextCommandKey" }, "action": { "action": "copy", "singleLine": false } },
{ "icon": null, "name": { "key": "PasteCommandKey" }, "action": "paste" },
{ "icon": null, "name": { "key": "IncreaseFontSizeCommandKey" }, "action": { "action": "adjustFontSize", "delta": 1 } },
{ "icon": null, "name": { "key": "DecreaseFontSizeCommandKey" }, "action": { "action": "adjustFontSize", "delta": -1 } },
{ "icon": null, "name": { "key": "ResetFontSizeCommandKey" }, "action": "resetFontSize" },
{ "icon": null, "name": { "key": "ScrollDownCommandKey" }, "action": "scrollDown" },
{ "icon": null, "name": { "key": "ScrollDownPageCommandKey" }, "action": "scrollDownPage" },
{ "icon": null, "name": { "key": "ScrollUpCommandKey" }, "action": "scrollUp" },
{ "icon": null, "name": { "key": "ScrollUpPageCommandKey" }, "action": "scrollUpPage" }
]
```
## Future considerations
* Commands will provide an easy point for allowing an extension to add its
actions to the UI, without forcing the user to bind the extension's actions to
a keybinding
* Also discussed in [#2046] was the potential for adding a command that inputs a
certain commandline to be run by the shell. I felt that was out of scope for
this spec, so I'm not including it in detail. I believe that would be
accomplished by adding a `inputCommand` action, with two args: `commandline`,
a string, and `suppressNewline`, an optional bool, defaulted to false. The
`inputCommand` action would deliver the given `commandline` as input to the
connection, followed by a newline (as to execute the command).
`suppressNewline` would prevent the newline from being added. This would work
relatively well, so long as you're sitting at a shell prompt. If you were in
an application like `vim`, this might be handy for executing a sequence of
vim-specific keybindings. Otherwise, you're just going to end up writing a
commandline to the buffer of vim. It would be weird, but not unexpected.
* Additionally mentioned in [#2046] was the potential for profile-scoped
commands. While that's a great idea, I believe it's out of scope for this
spec.
* Once [#754] lands, we'll need to make sure to include commands for each action
manually in the default settings. This will add some overhead that the
developer will need to do whenever they add an action. That's unfortunate, but
will be largely beneficial to the end user.
* We could theoretically also display the keybinding for a certain command in
the `ListViewItem` for the command. We'd need some way to correlate a
command's action to a keybinding's action. This could be done in a follow-up
task.
* We might want to alter the fuzzy-search algorithm, to give higher precedence
in the results list to commands with more consecutive matching characters.
Alternatively we could give more weight to commands where the search matched
the initial character of words in the command.
- For example: `ot` would give more weight to "**O**pen **T**ab" than
"**O**pen Se**t**tings").
* We may want to add a button to the New Tab Button's dropdown to "Show Command
Palette". I'm hesitant to keep adding new buttons to that UI, but the command
palette is otherwise not highly discoverable.
- We could add another button to the UI to toggle the visibility of the
command palette. This was the idea initially proposed in [#2046].
- For both these options, we may want a global setting to hide that button, to
keep the UI as minimal as possible.
* [#1571] is a request for customizing the "new tab dropdown" menu. When we get
to discussing that design, we should consider also enabling users to add
commands from their list of commands to that menu as well.
- This is included in the spec in [#5888].
* I think it would be cool if there was a small timeout as the user was typing
in commandline mode before we try to auto-parse their commandline, to check
for errors. Might be useful to help sanity check users. We can always parse
their `wt` commandlines safely without having to execute them.
* It would be cool if the commands the user typed in Commandline Mode could be
saved to a history of some sort, so they could easily be re-entered.
- It would be especially cool if it could do this across launches.
- We don't really have any way of storing transient data like that in the
Terminal, so that would need to be figured out first.
- Typically the Command Palette is at the top of the view, with the
suggestions below it, so navigating through the history would be _backwards_
relative to a normal shell.
* Perhaps users will want the ability to configure which side of the window the
palette appears on?
- This might fit in better with [#3327].
* [#3753] is a pull request that covers the addition of an "Advanced Tab
Switcher". In an application like VsCode, their advanced tab switcher UI is
similar to their command palette UI. It might make sense that the user could
use the command palette UI to also navigate to active tabs or panes within the
terminal, by control name. We've already outlined how the Command Palette
could operate in "Action Mode" or "Commandline Mode" - we could also add
"Navigate Mode" on `@`, for navigating between tabs or panes.
- The tab switcher could probably largely re-use the command palette UI, but
maybe hide the input box by default.
* We should make sure to add a setting in the future that lets the user opt-in
to showing most-recently used commands _first_ in the search order, and
possibly even pre-populating the search box with whatever their last entry
was.
- I'm thinking these are two _separate_ settings.
### Nested Commands
Another idea for a future spec is the concept of "nested commands", where a
single command has many sub-commands. This would hide the children commands from
the entire list of commands, allowing for much more succinct top-level list of
commands, and allowing related commands to be grouped together.
- For example, I have a text editor plugin that enables rendering markdown to a
number of different styles. To use that command in my text editor, first I hit
enter on the "Render Markdown..." command, then I select which style I want to
render to, in another list of options. This way, I don't need to have three
options for "Render Markdown to github", "Render Markdown to gitlab", all in
the top-level list.
- We probably also want to allow a nested command set to be evaluated at runtime
somehow. Like if we had a "Open New Tab..." command that then had a nested
menu with the list of profiles.
The above might be able to be expressed through some JSON like the following:
```json
"commands": [
{
"icon": "...",
"name": { "key": "NewTabWithProfileRootCommandName" },
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "NewTabWithProfileCommandName" },
"command": { "action": "newTab", "profile": "${profile.name}" }
}
]
},
{
"icon": "...",
"name": "Connect to ssh...",
"commands": [
{
"icon": "...",
"name": "first.com",
"command": { "action": "newTab", "commandline": "ssh me@first.com" }
},
{
"icon": "...",
"name": "second.com",
"command": { "action": "newTab", "commandline": "ssh me@second.com" }
}
]
}
{
"icon": "...",
"name": { "key": "SplitPaneWithProfileRootCommandName" },
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "SplitPaneWithProfileCommandName" },
"commands": [
{
"icon": "...",
"name": { "key": "SplitPaneName" },
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "automatic" }
},
{
"icon": "...",
"name": { "key": "SplitPaneVerticalName" },
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "vertical" }
},
{
"icon": "...",
"name": { "key": "SplitPaneHorizontalName" },
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "horizontal" }
}
]
}
]
}
]
```
This would define three commands, each with a number of nested commands underneath it:
* For the first command:
- It uses the XAML resource `NewTabWithProfileRootCommandName` as it's name.
- Activating this command would cause us to remove all the other commands from
the command palette, and only show the nested commands.
- It contains nested commands, one for each profile.
- Each nested command would use the XAML resource
`NewTabWithProfileCommandName`, which then would also contain the string
`${profile.name}`, to be filled with the profile's name in the command's
name.
- It would also use the profile's icon as the command icon.
- Activating any of the nested commands would dispatch an action to create a
new tab with that profile
* The second command:
- It uses the string literal `"Connect to ssh..."` as it's name
- It contains two nested commands:
- Each nested command has it's own literal name
- Activating these commands would cause us to open a new tab with the
provided `commandline` instead of the default profile's `commandline`
* The third command:
- It uses the XAML resource `NewTabWithProfileRootCommandName` as it's name.
- It contains nested commands, one for each profile.
- Each one of these sub-commands each contains 3 subcommands - one that will
create a new split pane automatically, one vertically, and one
horizontally, each using the given profile.
So, you could imagine the entire tree as follows:
```
<Command Palette>
├─ New Tab With Profile...
│ ├─ Profile 1
│ ├─ Profile 2
│ └─ Profile 3
├─ Connect to ssh...
│ ├─ first.com
│ └─ second.com
└─ New Pane...
├─ Profile 1...
| ├─ Split Automatically
| ├─ Split Vertically
| └─ Split Horizontally
├─ Profile 2...
| ├─ Split Automatically
| ├─ Split Vertically
| └─ Split Horizontally
└─ Profile 3...
├─ Split Automatically
├─ Split Vertically
└─ Split Horizontally
```
Note that the palette isn't displayed like a tree - it only ever displays the
commands from one single level at a time. So at first, only:
* New Tab With Profile...
* Connect to ssh...
* New Pane...
are visible. Then, when the user <kbd>enter</kbd>'s on one of these (like "New
Pane"), the UI will change to display:
* Profile 1...
* Profile 2...
* Profile 3...
### Configuring the Action/Commandline Mode prefix
As always, I'm also on board with the "this should be configurable by the user"
route, so they can change what mode the command palette is in by default, and
what the prefixes for different modes are, but I'm not sure how we'd define that
cleanly in the settings.
```json
{
"commandPaletteActionModePrefix": "", // or null, for no prefix
"commandPaletteCommandlineModePrefix": ">"
}
```
We'd need to have validation on that though, what if both of them were set to
`null`? One of them would _need_ to be `null`, so if both have a character, do
we just assume one is the default?
## Resources
Initial post that inspired this spec: #[2046](https://github.com/microsoft/terminal/issues/2046)
Keybindings args: #[1349](https://github.com/microsoft/terminal/pull/1349)
Cascading User & Default Settings: #[754](https://github.com/microsoft/terminal/issues/754)
Untie "active control" from "currently XAML-focused control" #[1205](https://github.com/microsoft/terminal/issues/1205)
Allow dropdown menu customization in profiles.json [#1571](https://github.com/microsoft/terminal/issues/1571)
Search or run a command in Dropdown menu [#3879]
Spec: Introduce a mini-specification for localized resource use from JSON [#5280]
<!-- Footnotes -->
[#754]: https://github.com/microsoft/terminal/issues/754
[#1205]: https://github.com/microsoft/terminal/issues/1205
[#1142]: https://github.com/microsoft/terminal/pull/1349
[#2046]: https://github.com/microsoft/terminal/issues/2046
[#1571]: https://github.com/microsoft/terminal/issues/1571
[#3879]: https://github.com/microsoft/terminal/issues/3879
[#5280]: https://github.com/microsoft/terminal/pull/5280
[#4472]: https://github.com/microsoft/terminal/issues/4472
[#3327]: https://github.com/microsoft/terminal/issues/3327
[#3753]: https://github.com/microsoft/terminal/pulls/3753
[#5888]: https://github.com/microsoft/terminal/pulls/5888

View File

@@ -0,0 +1,135 @@
---
author: Carlos Zamora @carlos-zamora
created on: 2020-05-14
last updated: 2020-05-14
issue id: #2557
---
# Open Settings Keybinding
## Abstract
This spec outlines an expansion to the existing `openSettings` keybinding.
## Inspiration
As a Settings UI becomes more of a reality, the behavior of this keybinding will be expanded on to better interact with the UI. Prior to a Settings UI, there was only one concept of the modifiable user settings: settings.json.
Once the Settings UI is created, we can expect users to want to access the following scenarios:
- Settings UI: globals page
- Settings UI: profiles page
- Settings UI: color schemes page
- Settings UI: keybindings page
- settings.json
- defaults.json
These are provided as non-comprehensive examples of pages that might be in a future Settings UI. The rest of the doc assumes these are the pages in the Settings UI.
## Solution Design
Originally, #2557 was intended to allow for a keybinding arg to access defaults.json. I imagined a keybinding arg such as "openDefaults: true/false" to accomplish this. However, this is not expandable in the following scenarios:
- what if we decide to create more settings files in the future? (i.e. themes.json, extensions.json, etc...)
- when the Settings UI comes in, there is ambiguity as to what `openSettings` does (json? UI? Which page?)
### Proposition 1.1: the minimal `target` arg
Instead, what if we introduced a new `target` keybinding argument, that could be used as follows:
| Keybinding Command | Behavior |
|--|--|
| `"command": { "action": "openSettings", "target": "settingsFile" }` | opens "settings.json" in your default text editor |
| `"command": { "action": "openSettings", "target": "defaultsFile" }` | opens "defaults.json" in your default text editor |
| `"command": { "action": "openSettings", "target": "allSettingsFiles" }` | opens all of settings files in your default text editor |
| `"command": { "action": "openSettings", "target": "settingsUI" }` | opens the Settings UI |
This was based on Proposition 1 below, but reduced the overhead of people able to define specific pages to go to.
### Other options we considered were...
#### Proposition 1: the `target` arg
We considered making target be more specific like this:
| Keybinding Command | Behavior |
|--|--|
| `"command": { "action": "openSettings", "target": "settingsFile" }` | opens "settings.json" in your default text editor |
| `"command": { "action": "openSettings", "target": "defaultsFile" }` | opens "defaults.json" in your default text editor |
| `"command": { "action": "openSettings", "target": "uiSettings" }` | opens the Settings UI |
| `"command": { "action": "openSettings", "target": "uiGlobals" }` | opens the Settings UI to the Globals page |
| `"command": { "action": "openSettings", "target": "uiProfiles" }` | opens the Settings UI to the Profiles page |
| `"command": { "action": "openSettings", "target": "uiColorSchemes" }` | opens the Settings UI to the Color Schemes page |
If the Settings UI does not have a home page, `uiGlobals` and `uiSettings` will do the same thing.
This provides the user with more flexibility to decide what settings page to open and how to access it.
#### Proposition 2: the `format` and `page` args
Another approach would be to break up `target` into `format` and `page`.
`format` would be either `json` or `ui`, dictating how you can access the setting.
`page` would be any of the categories we have for settings: `settings`, `defaults`, `globals`, `profiles`, etc...
This could look like this:
| Keybinding Command | Behavior |
|--|--|
| `"command": { "action": "openSettings", "format": "json", "page": "settings" }` | opens "settings.json" in your default text editor |
| `"command": { "action": "openSettings", "format": "json", "page": "defaults" }` | opens "defaults.json" in your default text editor |
| `"command": { "action": "openSettings", "format": "ui", "page": "settings" }` | opens the Settings UI |
| `"command": { "action": "openSettings", "format": "ui", "page": "globals" }` | opens the Settings UI to the Globals page |
| `"command": { "action": "openSettings", "format": "ui", "page": "profiles" }` | opens the Settings UI to the Profiles page |
| `"command": { "action": "openSettings", "format": "ui", "page": "colorSchemes" }` | opens the Settings UI to the Color Schemes page |
The tricky thing for this approach is, what do we do in the following scenario:
```js
{ "command": { "action": "openSettings", "format": "json", "page": "colorSchemes" } }
```
In situations like this, where the user wants a `json` format, but chooses a `page` that is a part of a larger settings file, I propose we simply open `settings.json` (or whichever file contains the settings for the desired feature).
#### Proposition 3: minimal approach
What if we don't need to care about the page, and we really just cared about the format: UI vs json? Then, we still need a way to represent opening defaults.json. We could simplify Proposition 2 to be as follows:
- `format`: `json`, `ui`
- ~`page`~ `openDefaults`: `true`, `false`
Here, we take away the ability to specifically choose which page the user wants to open, but the result looks much cleaner.
If there are concerns about adding more settings files in the future, `openDefaults` could be renamed to be `target`, and this would still serve as a hybrid of Proposition 1 and 2, with less possible options.
## UI/UX Design
The user has full control over modifying and adding these keybindings.
However, the question arises for what the default experience should be. I propose the following:
| Keychord | Behavior |
| <kbd>ctrl+,</kbd> | Open settings.json |
| <kbd>ctrl+alt+,</kbd> | Open defaults.json |
When the Settings UI gets added in, they will be updated to open their respective pages in the Settings UI.
## Capabilities
### Accessibility
None.
### Security
None.
### Reliability
None.
### Compatibility
Users that expect a json file to open would have to update their keybinding to do so.
### Performance, Power, and Efficiency
## Potential Issues
None.
## Future considerations
When the Settings UI becomes available, a new value for `target` of `settingsUI` will be added and it will become the default target.
If the community finds value in opening to a specific page of the Settings UI, `target` will be responsible for providing that functionality.
## Resources
None.

View File

@@ -0,0 +1,559 @@
---
author: Mike Griese @zadjii-msft
created on: 2020-05-07
last updated: 2020-06-03
issue id: 4999
---
# Improved keyboard handling in Conpty
## Abstract
The Windows Console internally uses [`INPUT_RECORD`]s to represent the various
types of input that a user might send to a client application. This includes
things like keypresses, mouse events, window resizes, etc.
However, conpty's keyboard input is fundamentally backed by VT sequences, which
limits the range of keys that a terminal application can actually send relative
to what the console was capable of. This results in a number of keys that were
previously representable in the console as `INPUT_RECORD`s, but are impossible
to send to a client application that's running in conpty mode.
Some of these issues include, but are not limited to:
* Some keybindings used by PSReadLine aren't getting through [#879]
* Bug Report: Control+Space not sent to terminal emulator. [#2865]
* Shift+Enter always submits, breaking PSReadline features [#530]
* Powershell: Ctrl-Alt-? does not work in Windows Terminal [#3079]
* Bug: ctrl+break is not ctrl+c [#1119]
* Something wrong with keyboard modifiers processing? [#1694]
* Numeric input not accepted by choice.exe [#3608]
* Ctrl+Keys that can't be encoded as VT should still fall through as the unmodified character [#3483]
* Modifier keys are not properly propagated to application hosted in Windows Terminal [#4334] / [#4446]
This spec covers a mechanism by which we can add support to ConPTY so that a
terminal application could send `INPUT_RECORD`-like key events to conpty,
enabling client applications to receive the full range of keys once again.
Included at the bottom of this document is a collection of [options that were
investigated](#options-considered) as a part of preparing this document.
## Considerations
When evaluating existing encoding schemes for viability, the following things
were used to evaluate whether or not a particular encoding would work for our
needs:
* Would a particular encoding be mixable with other normal VT processing easily?
- How would the Terminal know when it should send a \<chosen_encoding> key vs
a normally encoded one?
- For ex, <kbd>Ctrl+space</kbd> - should we send `NUL` or
\<chosen_encoding's version of ctrl+space>
* If there's a scenario where Windows Terminal might _not_ be connected to a
conpty, then how does conpty enable \<chosen_encoding>?
* Is the goal "Full `INPUT_RECORD` fidelity" or "Make the above scenarios work"?
- One could imagine having the Terminal special-case the above keys, and send
the xterm modifyOtherKeys sequences just for those scenarios.
- This would _not_ work for <kbd>shift</kbd> all by itself.
- In my _opinion_, "just making the above work" is a subset of "full
INPUT_RECORD", and inevitably we're going to want "full INPUT_RECORD"
The goal we're trying to achieve is communicating `INPUT_RECORD`s from the
terminal to the client app via conpty. This isn't supposed to be a \*nix
terminal compatible communication, it's supposed to be fundamentally Win32-like.
Keys that we definitely need to support, that don't have unique VT sequences:
* <kbd>Ctrl+Space</kbd> ([#879], [#2865])
* <kbd>Shift+Enter</kbd> ([#530])
* <kbd>Ctrl+Break</kbd> ([#1119])
* <kbd>Ctrl+Alt+?</kbd> ([#3079])
* <kbd>Ctrl</kbd>, <kbd>Alt</kbd>, <kbd>Shift</kbd>, (without another keydown/up) ([#3608], [#4334], [#4446])
> 👉 NOTE: There are actually 5 types of events that can all be encoded as an
> `INPUT_RECORD`. This spec primarily focuses on the encoding of
> `KEY_EVENT_RECORD`s. It is left as a Future Consideration to add support for
> the other types of `INPUT_RECORD` as other sequences, which could be done
> trivially similarly to the following proposal.
## Solution Design
### Inspiration
The design we've settled upon is one that's highly inspired by a few precedents:
* `Application Cursor Keys (DECCKM)` is a long-supported VT sequence which a
client application can use to request a different input format from the
Terminal. This is the DECSET sequence `^[[?1h`/`^[[?1l` (for enable/disable,
respectively). This changes the sequences sent by keys like the Arrow keys
from a sequence like `^[[A` to `^[OA` instead.
* The `kitty` terminal emulator uses a similar DECSET sequence for enabling
their own input format, which they call ["full mode"]. Similar to DECCKM, this
changes the format of the sequences that the terminal should send for keyboard
input. Their "full mode" contains much more information when keys are pressed
or released (though, less than a full `INPUT_RECORD` worth of data). Instead
of input being sent to the client as a CSI or SS3 sequence, this `kitty` mode
uses "Application Program-Command" (or "APC") sequences , prefixed with `^[_`.
* [iTerm2](https://www.iterm2.com/documentation-escape-codes.html) has a region
of OSC's that they've carved for themselves all starting with the same initial
parameter, `1337`. They then have a number of commands that all use the second
parameter to indicate what command specific to iTerm2 they're actually
implementing.
### Requesting `win32-input-mode`
An application can request `win32-input-mode` with the following private mode sequence:
```
^[ [ ? 9001 h/l
l: Disable win32-input-mode
h: Enable win32-input-mode
```
Private mode `9001` seems unused according to the [xterm
documentation](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html). This is
stylistically similar to how `DECKPM`, `DECCKM`, and `kitty`'s ["full mode"] are
enabled.
> 👉 NOTE: an earlier draft of this spec used an OSC sequence for enabling these
> sequences. This was abandoned in favor of the more stylistically consistent
> private mode params proposed above. Additionally, if implemented as a private
> mode, then a client app could query if this setting was set with `DECRQM`
When a terminal receives a `^[[?9001h` sequence, they should switch into
`win32-input-mode`. In `win32-input-mode`, the terminal will send keyboard input
to the connected client application in the following format:
### `win32-input-mode` sequences
The `KEY_EVENT_RECORD` portion of an input record (the part that's important for
us to encode in this feature) is defined as the following:
```c++
typedef struct _KEY_EVENT_RECORD {
BOOL bKeyDown;
WORD wRepeatCount;
WORD wVirtualKeyCode;
WORD wVirtualScanCode;
union {
WCHAR UnicodeChar;
CHAR AsciiChar;
} uChar;
DWORD dwControlKeyState;
} KEY_EVENT_RECORD;
```
To encode all of this information, I propose the following sequence. This is a
CSI sequence with a final terminator character of `_`. This character appears to
only be used as a terminator for the [SCO input
sequence](https://vt100.net/docs/vt510-rm/chapter6.html) for
<kbd>Ctrl+Shift+F10</kbd>. This conflict isn't a real concern for us
compatibility wise. For more details, see [SCO
Compatibility](#SCO-compatibility) below.
```
^[ [ Vk ; Sc ; Uc ; Kd ; Cs ; Rc _
Vk: the value of wVirtualKeyCode - any number. If omitted, defaults to '0'.
Sc: the value of wVirtualScanCode - any number. If omitted, defaults to '0'.
Uc: the decimal value of UnicodeChar - for example, NUL is "0", LF is
"10", the character 'A' is "65". If omitted, defaults to '0'.
Kd: the value of bKeyDown - either a '0' or '1'. If omitted, defaults to '0'.
Cs: the value of dwControlKeyState - any number. If omitted, defaults to '0'.
Rc: the value of wRepeatCount - any number. If omitted, defaults to '1'.
```
> 👉 NOTE: an earlier draft of this spec used an APC sequence for encoding the
> input sequences. This was changed to a CSI for stylistic reasons. There's not
> a great body of reference anywhere that lists APC sequences in use, so there's
> no way to know if the sequence would collide with another terminal emulator's
> usage. Furthermore, using an APC seems to give a distinct impression that
> this is some "Windows Terminal" specific sequence, which is not intended. This
> is a Windows-specific sequence, but one that any Terminal/application could
> use.
In this way, a terminal can communicate input to a connected client application
as `INPUT_RECORD`s, without any loss of fidelity.
#### Example
When the user presses <kbd>Ctrl+F1</kbd> in the console, the console actually
send 4 input records to the client application:
* A <kbd>Ctrl</kbd> down event
* A <kbd>F1</kbd> down event
* A <kbd>F1</kbd> up event
* A <kbd>Ctrl</kbd> up event
Encoded in `win32-input-mode`, this would look like the following:
```
^[[17;29;0;1;8;1_
^[[112;59;0;1;8;1_
^[[112;59;0;0;8;1_
^[[17;29;0;0;0;1_
Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
Down: 1 Repeat: 1 KeyCode: 0x70 ScanCode: 0x3b Char: \0 (0x0) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x70 ScanCode: 0x3b Char: \0 (0x0) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20
```
Similarly, for a keypress like <kbd>Ctrl+Alt+A</kbd>, which is 6 key events:
```
^[[17;29;0;1;8;1_
^[[18;56;0;1;10;1_
^[[65;30;0;1;10;1_
^[[65;30;0;0;10;1_
^[[18;56;0;0;8;1_
^[[17;29;0;0;0;1_
Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
Down: 1 Repeat: 1 KeyCode: 0x12 ScanCode: 0x38 Char: \0 (0x0) KeyState: 0x2a
Down: 1 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: \0 (0x0) KeyState: 0x2a
Down: 0 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: \0 (0x0) KeyState: 0x2a
Down: 0 Repeat: 1 KeyCode: 0x12 ScanCode: 0x38 Char: \0 (0x0) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20
```
Or, for something simple like <kbd>A</kbd> (which is 4 key events):
```
^[[16;42;0;1;16;1_
^[[65;30;65;1;16;1_
^[[16;42;0;0;0;1_
^[[65;30;97;0;0;1_
Down: 1 Repeat: 1 KeyCode: 0x10 ScanCode: 0x2a Char: \0 (0x0) KeyState: 0x30
Down: 1 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: A (0x41) KeyState: 0x30
Down: 0 Repeat: 1 KeyCode: 0x10 ScanCode: 0x2a Char: \0 (0x0) KeyState: 0x20
Down: 0 Repeat: 1 KeyCode: 0x41 ScanCode: 0x1e Char: a (0x61) KeyState: 0x20
```
> 👉 NOTE: In all the above examples, I had my NumLock key off. If I had the
> NumLock key instead pressed, all the KeyState parameters would have bits 0x20
> set. To get these keys with a NumLock, add 32 to the value.
These parameters are ordered based on how likely they are to be used. Most of
the time, the repeat count is not needed (it's almost always `1`), so it can be
left off when not required. Similarly, the control key state is probably going
to be 0 a lot of the time too, so that is second last. Even keydown will be 0 at
least half the time, so that can be omitted some of the time.
Furthermore, considering omitted values in CSI parameters default to the values
specified above, the above sequences could each be shortened to the following.
* <kbd>Ctrl+F1</kbd>
```
^[[17;29;;1;8_
^[[112;59;;1;8_
^[[112;59;;;8_
^[[17;29_
```
* <kbd>Ctrl+Alt+A</kbd>
```
^[[17;29;;1;8_
^[[18;56;;1;10_
^[[65;30;;1;10_
^[[65;30;;;10_
^[[18;56;;;8_
^[[17;29;;_
```
* <kbd>A</kbd> (which is <kbd>shift+a</kbd>)
```
^[[16;42;;1;16_
^[[65;30;65;1;16_
^[[16;42_
^[[65;30;97_
```
* Or even easier, just <kbd>a</kbd>
```
^[[65;30;97;1_
^[[65;30;97_
```
### Scenarios
#### User is typing into WSL from the Windows Terminal
`WT -> conpty[1] -> wsl`
* Conpty[1] will ask for `win32-input-mode` from the Windows Terminal when
conpty[1] first boots up. Conpty will _always_ ask for win32-input-mode -
Terminals that _don't_ support this mode will ignore this sequence on startup.
* When the user types keys in Windows Terminal, WT will translate them into
win32 sequences and send them to conpty[1]
* Conpty[1] will translate those win32 sequences into `INPUT_RECORD`s.
- When those `INPUT_RECORD`s are written to the input buffer, they'll be
converted into VT sequences corresponding to whatever input mode the linux
app is in.
* When WSL reads the input, it'll read (using `ReadConsoleInput`) a stream of
`INPUT_RECORD`s that contain only character information, which it will then
pass to the linux application.
- This is how `wsl.exe` behaves today, before this change.
#### User is typing into `cmd.exe` running in WSL interop
`WT -> conpty[1] -> wsl -> conpty[2] -> cmd.exe`
(presuming you start from the previous scenario, and launch `cmd.exe` inside wsl)
* Conpty[2] will ask for `win32-input-mode` from conpty[1] when conpty[2] first
boots up.
- As conpty[1] is just a conhost that knows how to handle
`win32-input-mode`, it will switch its own VT input handling into
`win32-input-mode`
* When the user types keys in Windows Terminal, WT will translate them into
win32 sequences and send them to conpty[1]
* Conpty[1] will translate those win32 sequences into `INPUT_RECORD`s. When
conpty[1] writes these to its buffer, it will translate the `INPUT_RECORD`s
into VT sequences for the `win32-input-mode`. This is because it believes the
client (in this case, the conpty[2] running attached to `wsl`) wants
`win32-input-mode`.
* When WSL reads the input, it'll read (using `ReadConsoleInput`) a stream of
`INPUT_RECORD`s that contain only character information, which it will then
use to pass a stream of characters to conpty[2].
* Conpty[2] will get those sequences, and will translate those win32 sequences
into `INPUT_RECORD`s
* When `cmd.exe` reads the input, they'll receive the full `INPUT_RECORD`s
they're expecting
## UI/UX Design
This is not a user-facing feature.
## Capabilities
### Accessibility
_(no change expected)_
### Security
_(no change expected)_
### Reliability
_(no change expected)_
### Compatibility
This isn't expected to break any existing scenarios. The information that we're
passing to conpty from the Terminal should strictly have _more_ information in
them than they used to. Conhost was already capable of translating
`INPUT_RECORD`s back into VT sequences, so this should work the same as before.
There's some hypothetical future where the Terminal isn't connected to conpty.
In that future, the Terminal will still be able to work correctly, even with
this ConPTY change. The Terminal will only switch into sending
`win32-input-mode` sequences when _conpty asks for them_. Otherwise, the
Terminal will still behave like a normal terminal emulator.
#### Terminals that don't support `?9001h`
Traditionally, whenever a terminal emulator doesn't understand a particular VT
sequence, they simply ignore the unknown sequence. This assumption is being
relied upon heavily, as ConPTY will _always_ emit a `^[[?9001h` on
initialization, to request `win32-input-mode`.
#### SCO Compatibility
As mentioned above, the `_` character is used as a terminator for the [SCO input
sequence](https://vt100.net/docs/vt510-rm/chapter6.html) for
<kbd>Ctrl+Shift+F10</kbd>. This conflict would be a problem if a hypothetical
terminal was connected to conpty that sent input to conpty in SCO format.
However, if that terminal was only sending input to conpty in SCO mode, it would
have much worse problems than just <kbd>Ctrl+Shift+F10</kbd> not working. If we
did want to support SCO mode in the future, I'd even go so far as to say we
could maybe treat a `win32-input-mode` sequence with no params as
<kbd>Ctrl+Shift+F10</kbd>, considering that `KEY_EVENT_RECORD{0}` isn't really
valid anyways.
#### Remoting `INPUT_RECORD`s
A potential area of concern is the fact that VT sequences are often used to
remote input from one machine to another. For example, a terminal might be
running on machine A, and the conpty at the end of the pipe (which is running
the client application) might be running on another machine B.
If these two machines have different keyboard layouts, then it's possible that
the `INPUT_RECORD`s synthesized by the terminal on machine A won't really be
valid on machine B. It's possible that machine B has a different mapping of scan
codes \<-> characters. A client that's running on machine B that uses win32 APIs
to try and infer the vkey, scancode, or character from the other information in
the `INPUT_RECORD` might end up synthesizing the wrong values.
At the time of writing, we're not really sure what a good solution to this
problem would be. Client applications that use `win32-input-mode` should be
aware of this, and be written with the understanding that these values are
coming from the terminal's machine, which might not necessarily be the local
machine.
### Performance, Power, and Efficiency
_(no change expected)_
## Potential Issues
_(no change expected)_
## Future considerations
* We could also hypothetically use this same mechanism to send Win32-like mouse
events to conpty, since similar to VT keyboard events, VT mouse events don't
have the same fidelity that Win32 mouse events do.
- We could enable this with a different terminating character, to identify
which type of `INPUT_RECORD` event we're encoding.
* Client applications that want to be able to read full Win32 keyboard input
from `conhost` _using VT_ will also be able to use `^[[?9001h` to do this. If
they emit `^[[?9001h`, then conhost will switch itself into
`win32-input-mode`, and the client will read `win32-input-mode` encoded
sequences as input. This could enable other cross-platform applications to
also use win32-like input in the future.
## Options Considered
_disclaimer: these notes are verbatim from my research notes in [#4999]_.
### Create our own format for `INPUT_RECORD`s
* If we wanted to do this, then we'd probably want to have the Terminal only
send input as this format, and not use the existing translator to synthesize
VT sequences
- Consider sending a ctrl down, '^A', ctrl up. We wouldn't want to send this
as three sequences, because conpty will take the '^A' and synthesize
_another_ ctrl down, ctrl up pair.
* With conpty passthrough mode, we'd still need the `InputStateMachineEngine`
to convert these sequences into INPUT_RECORDs to translate back to VT
* Wouldn't really expect client apps to ever _need_ this format, but it could
always be possible for them to need it in the future.
#### Pros:
* Definitely gets us all the information that we need.
* Can handle solo modifiers
* Can handle keydown and keyup separately
* We can make the sequence however we want to parse it.
#### Cons:
* No reference implementation, so we'd be flying blind
* We'd be defining our own VT sequences for these, which we've never done
before. This was _inevitable_, however, this is still the first time we'd be
doing this.
* By having the Terminal send all input as _this protocol_, VT Input passthrough
to apps that want VT input won't work anymore for the Terminal. That's _okay_
### kitty extension
[Reference](https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling)
#### Pros:
* Not terribly difficult to decode
* Unique from anything else we'd be processing, as it's an APC sequence
(`\x1b_`)
* From their docs:
> All printable key presses without modifier keys are sent
just as in the normal mode. ... For non printable keys and key combinations
including one or more modifiers, an escape sequence encoding the key event is
sent
- I think I like this. ASCII and other keyboard layout chars (things that would
hit `SendChar`) would still just come through as the normal char.
#### Cons:
* Their encoding table is _odd_. [Look at
this](https://sw.kovidgoyal.net/kitty/key-encoding.html). What order is that
in? Obviously the first column is sorted alphabetically, but the mapping of
key->char is in a certainly hard to decipher order.
* I can't get it working locally, so hard to test 😐
* They do declare the `fullkbd` terminfo capability to identify that they
support this mode, but I'm not sure anyone else uses it.
- I'm also not sure that any _client_ apps are reading this currently.
* This isn't designed to be full `KEY_EVENT`s - where would we put the scancode
(for apps that think that's important)?
- We'd have to extend this protocol _anyways_
### `xterm` "Set key modifier options"
Notably looking at
[`modifyOtherKeys`](https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:modifyOtherKeys).
#### Pros:
* `xterm` implements this so there's a reference implementation
* relatively easy to parse these sequences. `CSI 27 ; <modifiers> ; <key> ~`
#### Cons:
* Only sends the sequence on key-up
* Doesn't send modifiers all on their own
### `DECPCTERM`
[VT100.net doc](https://vt100.net/docs/vt510-rm/DECPCTERM.html)
#### Pros:
* Enables us to send key-down and key-up keys independently
* Enables us to send modifiers on their own
* Part of the VT 510 standard
#### Cons:
* neither `xterm` nor `gnome-terminal` (VTE) seem to implement this. I'm not
sure if anyone's got a reference implementation for us to work with.
* Unsure how this would work with other keyboard layouts
- [this doc](https://vt100.net/docs/vt510-rm/chapter8.html#S8.13) seems to
list the key-down/up codes for all the en-us keyboard keys, but the
scancodes for these are different for up and down. That would seem to
imply we couldn't just shove the Win32 scancode in those bits
### `DECKPM`, `DECSMKR`
[DECKPM](https://vt100.net/docs/vt510-rm/DECKPM.html)
[DECSMKR](https://vt100.net/docs/vt510-rm/DECSMKR.html)
[DECEKBD](https://vt100.net/docs/vt510-rm/DECEKBD.html)
#### Pros:
* Enables us to send key-down and key-up keys independently
* Enables us to send modifiers on their own
* Part of the VT 510 standard
#### Cons:
* neither `xterm` nor `gnome-terminal` (VTE) seem to implement this. I'm not
sure if anyone's got a reference implementation for us to work with.
* not sure that "a three-character ISO key position name, for example C01" is
super compatible with our Win32 VKEYs.
### `libtickit` encoding
[Source](http://www.leonerd.org.uk/hacks/fixterms)
#### Pros:
* Simple encoding scheme
#### Cons:
* Doesn't differentiate between keydowns and keyups
* Unsure who implements this - not extensively investigated
## Resources
* The initial discussion for this topic was done in [#879], and much of the
research of available options is also available as a discussion in [#4999].
* [Why Is It so Hard to Detect Keyup Event on Linux?](https://blog.robertelder.org/detect-keyup-event-linux-terminal/)
- and the [HackerNews discussion](https://news.ycombinator.com/item?id=19012132)
* [ConEmu specific OSCs](https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC)
* [iterm2 specific sequences](https://www.iterm2.com/documentation-escape-codes.html)
* [terminal-wg draft list of OSCs](https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/10)
<!-- Footnotes -->
[#530]: https://github.com/microsoft/terminal/issues/530
[#879]: https://github.com/microsoft/terminal/issues/879
[#1119]: https://github.com/microsoft/terminal/issues/1119
[#1694]: https://github.com/microsoft/terminal/issues/1694
[#2865]: https://github.com/microsoft/terminal/issues/2865
[#3079]: https://github.com/microsoft/terminal/issues/3079
[#3483]: https://github.com/microsoft/terminal/issues/3483
[#3608]: https://github.com/microsoft/terminal/issues/3608
[#4334]: https://github.com/microsoft/terminal/issues/4334
[#4446]: https://github.com/microsoft/terminal/issues/4446
[#4999]: https://github.com/microsoft/terminal/issues/4999
[`INPUT_RECORD`]: https://docs.microsoft.com/en-us/windows/console/input-record-str
["full mode"]: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling

View File

@@ -0,0 +1,319 @@
---
author: Michael Niksa @miniksa/miniksa@microsoft.com
created on: 2019-07-24
last updated: 2019-07-24
issue id: #1256
---
# Tab Tearoff/Merge & Default App IPC
## Abstract
This spec describes the sort of interprocess communications that will be required to support features like tab tearoff and merge. It goes through some of the considerations that became apparent when I tried to prototype passing connections between `conhost` and `wt`.
## Inspiration
Two main drivers:
1. We want the ability to tear off a tab from one Windows Terminal instance and send it to another Windows Terminal instance
2. We want the ability for a launch of a command-line application to trigger a hosting environment that isn't the stock in-box `conhost.exe`.
Both of these concerns will require there to exist some sort of interprocess communication manager that can send/receive the system handles representing connections between client applications and the hosting environment.
I spent some time during the Microsoft Hackathon in July 2019 investigating these avenues with a branch I pushed and linked at the bottom. The work resulted in me finding more questions than answers and ultimately deciding that a Hackathon is good enough for exploration of the mechanisms and ideas behind this, but not a good time for a full implementation.
## Solution Design
### Common Pieces
There are several common pieces needed for both the tab tear-off scenario and the default application scenario.
#### Manager
We need some sort of server/manager code that sits there waiting for connections from `wt.exe` processes and potentially `conhost.exe` processes such that it can broker a connection between the processes. It either needs to run in its own process or it needs to run in one of the existing `wt.exe`s that is chosen as the primary manager at the time. It should create communication channels and a global mutex at the time of creation.
All other `wt.exe` processes starting after the primary should detect the existence of the server manager process and wait on the mutex handle. When the primary disappears, the OS scheduler should choose one of the others to wake up first on the mutex. It can take the lock and then set up the primary management channel.
Alternatively, if the manager process is completely isolated and we expect all `wt.exe`s to have to remain connected at all times, we can make it such that when the connections are broken between the individual processes and the manager that they all shut down. I would prefer that it is resilient (the previous option) over this one, but browsers must have a good reason for preferring this way.
I attempted one particular way in a prototype of communicating between processes by setting up a Multithreaded Pipe Server using a Message-type configuration. This is visible in the branch I linked at the bottom. However, ultimately I think we would want to formalize around something more structured, tested, and inherently secured like a COM server interface.
#### Connection details
There are several parameters to a connection and several different modes. In short, they summarize to the ability to pass kernel handles between two processes and/or the ability to pass arbitrary length structured information about paths and settings. Both tab tear off and default application will likely need both functionalities.
##### Fresh Start
For an application that is being freshly started, the information required to begin the session is one of three things:
1. A server (and maybe reference) handle that describes the driver connection between the console server and the command-line client process. A `conhost.exe` can wrap this and turn it into a PTY. This may also contain LNK file (shortcut file) preferences for the running session.
1. A command-line string and working directory that describes which command-line client process we want to start. A `conhost.exe` can start this up and create the server and reference handles along the way and then turn it into a PTY.
1. A PTY session with its read, write, and signal handles.
When transiting a connection, we need to be aware of all three of these modes and relay them to the destination `wt.exe`.
For system handles, we can use the manager to broker a request to the destination process to find its `PID` and tell the source process. We can then use the `PID` with the `OpenProcess` method and the `PROCESS_DUP_HANDLE` right to get a handle to `DuplicateHandle` any of the above handle types into the destination process. The act of opening and duplicating the handles already requires the OS to check our access tokens and rights to interfere with another process, so that should automatically handle some level of the security checking for us.
For command-line string and working directory, we can pass all of this information along to the destination `wt.exe` and let it attempt to start a new ConPTY normally as if someone had chosen to start an option from the dropdown menu. A minor trick here is that we may need to attempt to match the command-line string with one of the user profiles to line up the icon and user-preferences for how the session should launch.
Lastly, for things started from an LNK, a user might expect that a window launched inside `wt.exe` from an old shortcut that they had would still apply even if that shortcut's properties technically apply to `conhost.exe` preferences and not to `wt.exe` preferences. The behavior here would likely to be to transit the LNK file information along to the `wt.exe` process by the same mechanism as a command-line string or working directory and let `wt.exe` use the shortcut parsing shared libraries to extract this information and migrate it into a `Settings` preference. Whether we would store that `Settings` preference or not for future use in the drop down might be an option or a prompt.
##### Already Running
For an application that is already running, we will need to send several pieces of information to successfully migrate to a new tab location:
1. The ConPTY handles for read, write, and signal
1. The scroll-back history that is stored inside `wt.exe` but isn't actually a part of what the underlying PTY-mode `conhost.exe` re-renders at any given time
1. The user preferences and session information related to `Settings`.
We would send all of this over to the destination by whatever IPC mechanism and then let it stand up a new tab with all of the same parameters as the tab on the other end.
**ALTERNATIVELY**
If we move everything to an isolated process model where the individual tabs/panes have a process and their UI is hosted in another frame/shell process and then there's a manager process, we will presumably already have to architect a solution that allows the UIs to be remoted onto other interfaces (Component UI?). If this is true, then all we need to relay for an active session is the information required to redirect the drawing/input targets for a given tab/pane to a different shell. This may ultimately be easier and more reliable than moving and rebuilding all the pieces of what fundamentally makes a session to the other side.
### Separate Pieces
#### For Tab Tear-off
We add a handler to the on-drag for the tab bar. We also likely need to implement a drag and drop handler. Drag and drop handlers use OLE (COM) so this might be another reason why we should implement the entire manager as COM. Note, I have never used this before so this is a theoretical low-knowledge design that would have to be explored...
Presumably the tab control from WinUI will update to support reordering the tabs through its own drag/drop. But we would likely want to create some sort of drag source with the session GUID when a drag operation starts.
Then we can let the OS handle the drop operation with the session GUID information. If the drop handler drops onto another wt.exe, it can use the session GUID in the drop payload in order to convey connection information between the processes. If it drops somewhere else, presumably we can be made aware of that in the source of the drag/drop operation and instead spawn a new `wt.exe` with arguments that specify that it should start up doing the "drop" portion of the operation to the session GUID with the manager instead of launching the default tab.
#### For Default Application
For default application launches, `conhost.exe` will have to attempt to transfer the incoming connection to the registered terminal handler instead of launching its own UI window.
If the registered handler fails to start the connection, there is no registered handler, or any part of this mechanism fails. The `conhost.exe` needs to fall back to doing whatever it would have done prior to this development (launching a window if necessary, being hidden, etc.)
##### Interactive vs. Not
We would have to be able to detect the difference between an interactive and non-interactive mode here.
- Interactive is defined as the end-user is attempting to launch a command-line application with a visible window to see the output and enter input.
- Non-interactive is defined as tools, utilities, and services attempting to launch a command-line application with no visible window (and possibly some redirected handles).
We do not want to capture non-interactive sessions as compilers, scripts, and utilities run command-line tools all the time. These should not trigger the overhead of being transitioned into the terminal as they will not need output or display.
Additionally, we may need to identify ConPTYs being started and ensure that they don't accidentally attempt to hand off in an infinite loop.
The biggest trick here is that we don't know whether it is going to be interactive or not until we begin to accept the connection from the server handle. We have two choices here:
##### Inbox conhost handles it
The inbox `conhost.exe` can just accept the connection from the server handle, assure itself that a `wt.exe` could take over the UI hosting of the session, and then switch itself into `ConPTY` mode and give those handles over to `wt.exe` and remain invisible in the background in PTY mode (much the same as if `wt.exe` had started the connection itself).
The upside here is that most of the startup connection flow happens normally, the `conhost.exe` that was given the server handle is the one that will continue to service it for the lifetime of the command-line application session. I can then discard any concerns about how the driver reacts and how the applications grovel for the relationship between processes as it will be normal.
The downside here is that launching command-line applications from shortcuts, the shell, or the run box (as is what triggers the default application scenario) will be using an old version of the PTY. It is possible and even probable that we will make improvements to the PTY that we would want to leverage if they're on the system already inside the app package. However, if we try to transit the server connection to the PTY in the package, we will have to deal with:
1. Potentially leaving the original conhost.exe open until the other one exits in case someone is waiting on the process
1. Coming up with some sort of dance to have the delegated PTY conhost inside the package determine the interactivity on starting the connection **OR** having the outside conhost start the connection and passing the connection off part way through if it's interactive **OR** something of that ilk.
##### Conhost in the Terminal package handles it
We could just send the server connection from the `conhost.exe` in System32 into the one inside the package and let it deal with it. We can connect to the broker and pass along the server handle and let `wt.exe` create a `conhost.exe` in PTY mode with that specific server handle.
The upsides/downsides here are exactly opposite of those above, so I won't restate.
##### Making default app work on current and downlevel OS
There's a few areas to study here.
1. Replacing conhost.exe in system32 at install time
- The OS (via the code for `ConsoleInitialize` inside `kernelbase.dll`) will launch `C:\windows\system32\conhost.exe` to start a default application session with the server handle. We can technically replace this binary in `system32` with an `OpenConsole.exe` named `conhost.exe` to make newer code run on older OS (presuming that we have the CRTs installed, build against the in-OS-CRT, and otherwise have conditional feature detection properly performed for all APIs/references not accessible downlevel). This is how we test/develop locally inside Windows without a full nightly build, so we know it works to some degree. Replacing a binary in `system32` is a bit of a problem, though, because the OS actively works to defend against this through ACLs (Windows File Protection which detected and restored changes here is gone, I believe). Additionally, it works for us because we're using internal builds and signing our binaries with test certificates for which our machines have the root certificate installed. Not going to cut it outside. We probably also can't sign it officially with the app signing mechanism and have it work because I'm not sure the root certificates for app signing will be trusted the same way as the certificates for OS signing. Also, we can't build outside of Windows against the in-box CRT. So we'd have to have the MSVCRT redist, which is also gross.
2. Updating kernelbase.dll to look up the launch preference and/or to launch a console host via a protocol handler
- To make this work anywhere but the most recent OS build, we'd have to service downlevel. Given `kernelbase.dll` is fundamental to literally everything, there's virtually no chance that we would be allowed to service it backwards in time for the sake of adding a feature. It's too risky by any stretch of the imagination. It's even risky to change `kernelbase.dll` for an upcoming release edition given how fundamental it is. End of thought experiment.
3. Updating conhost.exe to look up the launch preference and/or to launch another console host via a protocol handler
- This would allow the `C:\windows\system32\conhost.exe` to effectively delegate the session to another `conhost.exe` that is hopefully newer than the inbox one. Given that the driver protocol in the box doesn't change and hasn't changed and we don't intend to change it, the forward/backward compatibility story is great here. Additionally, if for whatever reason the delegated `conhost.exe` fails to launch, we can just fall back and launch the old one like we would have prior to the change. It is significantly more likely, but still challenging, to argue for servicing `conhost.exe` back several versions in Windows to make this light up better for all folks. It might be especially more possible if it is a very targeted code snippet that can drop in to all the old versions of the `conhost.exe` code. We would still have the argument about spending resources developing for OS versions that are supposed to be dropped in favor of latest, but it's still a lesser argument than upending all of `kernelbase.dll`.
- A protocol handler is also well understood and relatively well handled/tested in Windows. Old apps can handle protocols. New apps can handle protocols. Protocol handlers can take arguments. We don't have to lean on any other team to get them to help change the way the rest of the OS works.
#### Communicating the launch
For the parameters passing, I see a few options:
1. `conhost.exe` can look up the package registration for `wt.exe` and call an entrypoint with arguments. This could be adapted to instead look up which package is registered as the default one instead of `wt.exe` for third party hosts. We would have to build provisions into the OS to select this, or use some sort of publically documented registry key mechanism. Somewhat gross.
1. `conhost.exe` can call the execution alias with parameters. WSL distro launchers use this.
1. We can define a protocol handler for these sorts of connections and let `wt.exe` register for it. Protocol handlers are already well supported and understood both by classic applications and by packaged/modern applications on Windows. They must have provisions to communicate at least some semblance of argument data as well. This is the route I'd probably prefer. `ms-term://incoming/<session-id>` or something like that. The receiving `wt.exe` can contact the manager process (or set one up if it is the first) and negotiate receiving the session that was specified into a new tab.
## UI/UX Design
### For Tab Tear-off
#### Ideal World
The UX would be just as one might expect from a browser application.
- Mouse down and drag on a tab should provide some visual indication that it is being dragged.
- Dragging left/right should provide a visual indicator of the tabs reordering on the bar and otherwise not involve the IPC manager service.
- Dragging up/down to break free from the tab bar should launch a new instance of `wt.exe` passing in the state of the dragging tab as the initial launch point (ignoring other default launch aspects). The drag/mouse-down would be passed to that new instance which would chase the mouse.
- Continuing to drag the loose tab onto the tab bar of another running instance of `wt.exe` would merge the tab with that copy of the application. The interim new/loose frame instance of `wt.exe` would close when it transferred out the last tab to the drop location.
#### Simplified V1
To simplify this for a first iteration, we could just make it so the transfer does not happen live.
- Mouse down and drag on a tab should provide a visual indication that it is being dragged by changing the cursor (or something of that ilk)
- Nothing would actually happen in terms of transitioning the tab until it is released
- If released onto the same `wt.exe` instance in a different spot on the tab bar, we reorder the tabs in the tab control
- If released onto a different `wt.exe` instance, we relay the communications channel and details through the IPC manager to the other instance. It opens the tab on the destination instance; we close the tab on the source instance.
- If released onto anything that isn't a `wt.exe` instance, we create a new `wt.exe` instance and send in the connection as the default startup parameter.
#### Component UI
It is also theoretically possible that if we could find a Component UI style solution (where the tab/panes live in their own process and just remote the UI/input into the shell) that it would be easy and even trivial to change out which shell/frame host is holding that element at any given time.
### For Default Application
The UX would make it look exactly like the user had started `wt.exe` from a shortcut or launch tile, but would launch the first tab differently than the defaults.
#### No WT already started
If no `wt.exe` is already started, the `conhost.exe` triggered by the system to host the client application would find the installed `wt.exe` package and launch it with parameters to use as its first connection (in lieu of launching the default tab). `conhost.exe` wouldn't show a window, it would drop into ConPTY mode and only the new `wt.exe` and its tab would be visible.
#### WT already started
If a `wt.exe` is already started, `conhost.exe` would find the running instance and just add a new tab at the end of the tab bar by the same mechanism.
#### Multiple WTs already started
If multiple `wt.exe`s are already started, `conhost.exe` would have to find the foreground one, the active one, or the primary/manager one and send the tab there. I'm not sure how other tabbing things to do this. We could research/study.
## Capabilities
### Accessibility
I don't believe it changes anything for accessibility. The only concern I'd have to call out is the knowledge I have that the UIA framework makes its connections and some of its logic/reasoning based on PIDs, HWNDs, and the hierarchy thereof. Playing with these might impact the ability of screen reading applications to get the UIA tree when tabs have been shuffled around.
### Security
This particular feature will have to go through a security review/audit. It is unclear what level of control we will need over the IPC communication channels. A few things come to mind:
1. We need to ensure that the mutexes/pipes/communications are restricted inside of one particular session to one particular user. If another user is also running WT in their session, it should involve a completely different manager process and system objects.
1. We MAY have to enforce a scenario where we inhibit cross-integrity-level connections from being passed around. Generally speaking, processes at a higher integrity level have the authority to perform actions on those with a lower integrity level. This means that an elevated `wt.exe` could theoretically send a tab to a standard level `wt.exe`. We may be required to inhibit/prohibit this. We may also need to have one manager per integrity level.
1. I'm not sure what sorts of ACL/DACL/SACLs we would need to apply to all the kernel objects involved.
1. My initial prototype here used message-passing type pipes with a custom rolled protocol. If I make my own protocol, it needs to be fuzzed. And I'm probably missing something. Many/most of these concerns for security are probably eliminated if we use a well-known mechanism for this sort of IPC. My thoughts go to a COM server. More complicated to implement than message pipes, but probably brings a lot of security benefits and eliminates the need to fuzz the protocol (probably).
### Reliability
In the simple implementation, it will decrease reliability. We'll be shuffling connections back and forth between application instances. By default, that's more risky than leaving things alone. The only reason it is worth it is the user experience.
We might be able to mitigate some of the reliability concerns here or even improve reliability by going a step further with the process/containerization model like browsers do and standing up each individual tab as its own process host.
```
wt.exe - Manager Mode
|- wt.exe - Frame Host Mode
| |- wt.exe - Tab Host Mode
| | |- conhost.exe - ConPTY mode
| | |- pwsh.exe - Client application
| |- wt.exe - Tab Host Mode
| |- conhost.exe - ConPTY mode
| |- cmd.exe - Client application
|- wt.exe - Frame Host Mode
|- wt.exe - Tab Host Mode
|- conhost.exe - ConPTY mode
|- pwsh.exe - Client application
```
The current structure of `wt.exe` has everything hosted within the one process. To improve reliability, we would likely have to make `wt.exe` run in three modes.
1. Manager Mode - no UI, just sits there as a broker to hold the kernel objects for a given window station/session and integrity level, accepts protocol handler routines, helps relay connections between various frame hosts when tabs move and determines where to instantiate new default-app tabs
1. Frame Host Mode - The complete outer shell of the application outside of an individual tab. Hosts the tab bar, settings drop downs, title bar, etc.
1. Tab Host Mode - The inner shell of an individual tab including the rendering area, scroll bar, inputs, etc.
1. Pane Host Mode - Now that panes are a thing, we might need to go even one level deeper. Or maybe it's just a recursion on Tab Host mode.
How these connect to each other is unexplored at this time.
### Compatibility
There are a few compatibility concerns here, primarily related to how client applications or outside utilities detect the relationship between a command-line client application and its console hosting environment.
We're well aware that the process tree/hierarchy is one of the major methods used for understanding the relationship between the client and server application. However, in order to accomplish our goals here, it is inevitable that the original hosting `conhost.exe` (either started in ConPTY mode by a `wt.exe` or started by the operating system in response to an otherwise unhosted command-line application) will become orphaned or otherwise disassociated with the UI that is actually presenting it.
It is possible (but would need to be explored) that the APIs available to us to reorder the parenting of the processes to put the `conhost.exe` as the parent of the `cmd.exe` (despite the fact that `cmd.exe` usually starts first as the default application and the `ConsoleInitialize` routines inside `kernelbase.dll` create the `conhost.exe`) could be reused here to shuffle around the parent/child relationships. However, it could also introduce new problems. One prior example was that the UIA trees for accessibility do **NOT** tolerate the shuffling of the parent child relationship because their communication channel sessions are often tied to the relationships of HWNDs and PIDs.
#### Hierarchy Example between two Terminals (tab tearoff/merge)
In the one instance, we have this process hierarchy. Two instances of Windows Terminal exist. In Terminal A, the user has started a `cmd.exe` and a `pwsh.exe` tab. In the second instance, the user has started just one `cmd.exe` tab.
```
- wt.exe (Terminal Instance A)
|- conhost.exe (in PTY mode) - Hosted to A
| |- cmd.exe
|- conhost.exe (in PTY mode) - Hosted to A
|- pwsh.exe <-- I will be dragged out
- wt.exe (Terminal Instance B)
|- conhost.exe (in PTY mode) - Hosted to B
|- cmd.exe
```
When the `pwsh.exe` tab is torn off from Instance A and is dropped onto Instance B, the process hierarchy doesn't actually change. The connection details, preferences, and session metadata are passed via the IPC management channels, but to an outside observer, nothing has actually changed.
```
- wt.exe (Terminal Instance A)
|- conhost.exe (in PTY mode) - Hosted to A
| |- cmd.exe
|- conhost.exe (in PTY mode) - Hosted to B
|- pwsh.exe <-- I am hosted in B but I'm parented to A
- wt.exe (Terminal Instance B)
|- conhost.exe (in PTY mode) - Hosted to B
|- cmd.exe
```
I don't believe there are provisions in the Windows OS to reparent applications to a different process.
Additionally, this becomes more interesting when Terminal Instance A dies and B is still running:
```
- conhost.exe (in PTY mode) - Hosted to B
|- pwsh.exe <-- I am hosted in B but I'm parented to A
- wt.exe (Terminal Instance B)
|- conhost.exe (in PTY mode) - Hosted to B
|- cmd.exe
```
When instance A dies, the `conhost.exe` that was reparented keeps running and now just appears orphaned within the process hierarchy, reporting to the top level under utilities like Process Explorer.
I believe the action plan here would be to implement what we can, observe the state of the world, and correct going forward. We don't have a solid understanding of how many client applications might be impacted by this apparent change. It also might be perfectly OK because the client applications will always remain parented to the same `conhost.exe` even if those `conhost.exe`s don't report up to the correct `wt.exe`.
It is also unclear whether someone might want to write a utility from the outside to discover this hierarchy. I would be inclined to not provide a way to do this without a strong case otherwise because attempting to understand the local machine process hierarchy is a great way to box yourself in when attempting to expand later to encompass remote connections.
#### Hierarchy Example between Conhost and a Terminal (default application)
This looks very much like the previous section where Terminal Instance B died.
```
- conhost.exe (in PTY mode) - Hosted to A
|- pwsh.exe
- wt.exe (Terminal Instance A)
```
The `conhost.exe` was started in response to a `pwsh.exe` being started with no host. It then put itself into PTY mode and launched into a connection of `wt.exe` instance A.
**ALTERNATIVELY**
```
- conhost.exe - idling
- wt.exe (Terminal Instance A)
|- conhost.exe (in PTY mode)
|- pwsh.exe
```
The `conhost.exe` at the top was launched in response to `pwsh.exe` being started with no host. It identified that `wt.exe` was running and instead shuttled the incoming connection into that `wt.exe`. `wt.exe` stood up the `conhost.exe` in PTY mode beneath itself and the client `pwsh.exe` call below that. The PTY mode `conhost.exe` uses its reparenting commands on startup to make the tree look like the above. The orphaned (originally started) `conhost.exe` waits until the connection exits before exiting itself in case someone was waiting on it.
### Performance, Power, and Efficiency
This is obviously less efficient than not doing it as we have to stand up servers and protocols and handlers for shuffling things about.
But as long as we're creating threads and services that sleep most of the time and are only awakened on some kernel/system event, we shouldn't be wasting too much in terms of power and background resources.
Additionally, `wt.exe` is worse than `conhost.exe` alone in all efficiency categories simply because it not only requires more resources to display in a "pretty" manner, but it also requires a `conhost.exe` under it in PTY mode to adapt the API calls. This is generally acceptable for end users who care more about the experience than the total performance.
It is, however, not likely to be much if any worse than just choosing to use `wt.exe` anyway over `conhost.exe`.
## Potential Issues
I've listed most of the issues above in their individual sections. The primary highlights are:
1. Process tree layout - The processes in hierarchy may not make sense to someone inspecting them either visually with a tool or programmatically
1. Process and kernel object lifetime - Applications may be counting on a specific process or object lifetime in regards to their hosting window and we might be tampering with that in how we apply job objects or shuffle around ownership to make tabs happen
1. Default launch expectations - It is possible that test utilities or automation are counting on `conhost.exe` being the host application or that they're not ready to tolerate the potential for other applications to start. I think the interactive/non-interactive check mitigates this, but we'd have to remain concerned here.
1. `AttachConsole` and `DetachConsole` and `AllocConsole` - I don't have the slightest idea what happens for these APIs. We would have to explore. `AttachConsole` has restrictions based on the process hierarchy. It would likely behave in interesting ways with the strange parenting order and might be a driver to why we would have to adjust the parenting of the processes (or change the API under the hood). `DetachConsole` might create an issue where a tab disappears out of the terminal and the job object causes everything to die. `AttachConsole` wouldn't necessarily be guaranteed to go back into the same `wt.exe` or a `wt.exe` at all.
## Future considerations
This might unlock some sort of isolation for extensions as well. Extensions of some sort our on our own long term roadmap, but they're inherently risky to the stability and integrity of the application. If we have to go through a lot of gyrations to enable process containerization and an interprocess communication model for tab tear off and default application work, we might also be able to contain extensions the same way. This derives further from the idea of what browsers do.
## Resources
- [Manager Prototype](https://github.com/microsoft/terminal/blob/dev/miniksa/manager/src/types/Manager.cpp)
- [Pipe Server documentation](https://docs.microsoft.com/en-us/windows/win32/ipc/multithreaded-pipe-server)
- [OLE Drag and Drop](https://docs.microsoft.com/en-us/windows/win32/api/ole2/nf-ole2-registerdragdrop)
- [OpenProcess](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-openprocess)
- [DuplicateHandle](https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-duplicatehandle)

View File

@@ -1,427 +0,0 @@
---
author: Mike Griese @zadjii-msft
created on: 2019-08-01
last updated: 2020-04-13
issue id: 2046
---
_This is a draft spec. It should be considered a work-in-progress._
# Command Palette
## Abstract
This spec covers the addition of a "command palette" to the Windows Terminal.
The Command Palette is a GUI that the user can activate to search for and
execute commands. Beneficially, the command palette allows the user to execute
commands _even if they aren't bound to a keybinding_.
## Inspiration
This feature is largely inspired by the "Command Palette" in text editors like
VsCode, Sublime Text and others.
This spec was initially drafted in [a
comment](https://github.com/microsoft/terminal/issues/2046#issuecomment-514219791)
in [#2046]. That was authored during the annual Microsoft Hackathon, where I
proceeded to prototype the solution. This spec is influenced by things I learned
prototyping.
## Solution Design
First off, for the sake of clarity, we'll rename the `command` of a keybinding
to `action`. This will help keep the mental model between commands and actions
clearer. When deserializing keybindings, we'll include a check for the old
`command` key to migrate it.
We'll introduce a new top-level array to the user settings, under the key
`commands`. `commands` will contain an array of commands, each with the
following schema:
```js
{
"name": string,
"action": string,
"icon": string
"args": object?,
}
```
Command names should be human-friendly names of actions, though they don't need
to necessarily be related to the action that it fires. For example, a command
with `newTab` as the action could have `"Open New Tab"` as the name.
The command will be parsed into a new class, `Command`:
```c++
class Command
{
winrt::hstring Name();
winrt::TerminalApp::ActionAndArgs ActionAndArgs();
winrt::hstring IconSource();
}
```
We'll add another structure in GlobalAppSettings to hold all these actions. It
will just be a `std::vector<Command>` in `GlobalAppSettings`.
We'll need app to be able to turn this vector into a `ListView`, or similar, so
that we can display this list of actions. Each element in the view will be
intrinsically associated with the `Command` object it's associated with. In
order to support this, we'll make `Command` a winrt type that implements
`Windows.UI.Xaml.Data.INotifyPropertyChanged`. This will let us bind the XAML
element to the winrt type.
When an element is clicked on in the list of commands, we'll raise the event
corresponding to that `ShortcutAction`. `AppKeyBindings` already does a great
job of dispatching `ShortcutActions` (and their associated arguments), so we'll
re-use that. We'll pull the basic parts of dispatching `ActionAndArgs`
callbacks into another class, `ShortcutActionDispatch`, with a single
`PerformAction(ActionAndArgs)` method (and events for each action).
`AppKeyBindings` will be initialized with a reference to the
`ShortcutActionDispatch` object, so that it can call `PerformAction` on it.
Additionally, by having a singular `ShortcutActionDispatch` instance, we won't
need to re-hook up the ShortcutAction keybindings each time we re-load the
settings.
In `App`, when someone clicks on an item in the list, we'll get the
`ActionAndArgs` associated with that list element, and call PerformAction on
the app's `ShortcutActionDispatch`. This will trigger the event handler just the
same as pressing the keybinding.
### Commands for each profile?
[#3879] Is a request for being able to launch a profile directly, via the
command palette. Essentially, the user will type the name of a profile, and hit
enter to launch that profile. I quite like this idea, but with the current spec,
this won't work great. We'd need to manually have one entry in the command
palette for each profile, and every time the user adds a profile, they'd need to
update the list of commands to add a new entry for that profile as well.
This is a fairly complicated addition to this feature, so I'd hold it for
"Command Palette v2", though I believe it's solution deserves special
consideration from the outset.
I suggest that we need a mechanism by which the user can specify a single
command that would be expanded to one command for every profile in the list of
profiles. Consider the following sample:
```json
"commands": [
{
"expandOn": "profiles",
"icon": "${profile.icon}",
"name": "New Tab with ${profile.name}",
"command": { "action": "newTab", "profile": "${profile.name}" }
},
{
"expandOn": "profiles",
"icon": "${profile.icon}",
"name": "New Vertical Split with ${profile.name}",
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
}
],
```
In this example:
* The `"expandOn": "profiles"` property indicates that each command should be
repeated for each individual profile.
* The `${profile.name}` value is treated as "when expanded, use the given
profile's name". This allows each command to use the `name` and `icon`
properties of a `Profile` to customize the text of the command.
To ensure that this works correctly, we'll need to make sure to expand these
commands after all the other settings have been parsed, presumably in the
`Validate` phase. If we do it earlier, it's possible that not all the profiles
from various sources will have been added yet, which would lead to an incomplete
command list.
We'll need to have a placeholder property to indicate that a command should be
expanded for each `Profile`. When the command is first parsed, we'll leave the
format strings `${...}` unexpanded at this time. Then, in the validate phase,
when we encounter a `"expandOn": "profiles"` command, we'll remove it from the
list, and use it as a prototype to generate commands for every `Profile` in our
profiles list. We'll do a string find-and-replace on the format strings to
replace them with the values from the profile, before adding the completed
command to the list of commands.
Of course, how does this work with localization? Considering the [section
below](#localization), we'd update the built-in commands to the following:
```json
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "NewTabWithProfileCommandName" },
"command": { "action": "newTab", "profile": "${profile.name}" }
},
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": { "key": "NewVerticalSplitWithProfileCommandName" },
"command": { "action": "splitPane", "split":"vertical", "profile": "${profile.name}" }
}
],
```
In this example, we'll look up the `NewTabWithProfileCommandName` resource when
we're first parsing the command, to find a string similar to `"New Tab with
${profile.name}"`. When we then later expand the command, we'll see the
`${profile.name}` bit from the resource, and expand that like we normally would.
Trickily, we'll need to make sure to have a helper for replacing strings like
this that can be used for general purpose arg parsing. As you can see, the
`profile` property of the `newTab` command also needs the name of the profile.
Either the command validation will need to go through and update these strings
manually, or we'll need another of enabling these `IActionArgs` classes to fill
those parameters in based on the profile being used. Perhaps the command
pre-expansion could just stash the json for the action, then expand it later?
This implementation detail is why this particular feature is not slated for
inclusion in an initial Command Palette implementation.
## UI/UX Design
We'll add another action that can be used to toggle the visibility of the
command palette. Pressing that keybinding will bring up the command palette.
When the command palette appears, we'll want it to appear as a single overlay
over all of the panes of the Terminal. The drop-down will be centered
horizontally, dropping down from the top (from the tab row). When commands are
entered, it will be implied that they are delivered to the focused terminal
pane. This will help avoid two problematic scenarios that could arise from
having the command palette attache to a single pane:
* When attached to a single pane, it might be very easy for the UI to quickly
become cluttered, especially at smaller pane sizes.
* This avoids the "find the overlay problem" which is common in editors like
VS where the dialog appears attached to the active editor pane.
The palette will consist of two main UI elements: a text box for searching for
commands, and a list of commands.
The list of commands will be populated with all the commands by default. Each
command will appear like a `MenuFlyoutItem`, with an icon at the left (if it has
one) and the name visible. When opened, the palette will automatically highlight
the first entry in the list.
The user can navigate the list of entries with the arrow keys. Hitting enter
will close the palette and execute the action that's highlighted. Hitting escape
will dismiss the palette, returning control to the terminal. When the palette is
closed for any reason (executing a command, dismissing with either escape or the
`toggleCommandPalette` keybinding), we'll clear out any search text from the
palette, so the user can start fresh again.
We'll also want to enable the command palette to be filterable, so that the user
can type the name of a command, and the command palette will automatically
filter the list of commands. This should be more powerful then just a simple
string compare - the user should be able to type a search string, and get all
the commands that match a "fuzzy search" for that string. This will allow users
to find the command they're looking for without needing to type the entire
command.
For example, consider the following list of commands:
```json
"commands": [
{ "icon": null, "name": "New Tab", "action": "newTab" },
{ "icon": null, "name": "Close Tab", "action": "closeTab" },
{ "icon": null, "name": "Close Pane", "action": "closePane" },
{ "icon": null, "name": "[-] Split Horizontal", "action": "splitHorizontal" },
{ "icon": null, "name": "[ | ] Split Vertical", "action": "splitVertical" },
{ "icon": null, "name": "Next Tab", "action": "nextTab" },
{ "icon": null, "name": "Prev Tab", "action": "prevTab" },
{ "icon": null, "name": "Open Settings", "action": "openSettings" },
{ "icon": null, "name": "Open Media Controls", "action": "openTestPane" }
],
```
* "open" should return both "**Open** Settings" and "**Open** Media Controls".
* "Tab" would return "New **Tab**", "Close **Tab**", "Next **Tab**" and "Prev
**Tab**".
* "P" would return "Close **P**ane", "[-] S**p**lit Horizontal", "[ | ]
S**p**lit Vertical", "**P**rev Tab", "O**p**en Settings" and "O**p**en Media
Controls".
* Even more powerfully, "sv" would return "[ | ] Split Vertical" (by matching
the **S** in "Split", then the **V** in "Vertical"). This is a great example
of how a user could execute a command with very few keystrokes.
As the user types, we should **bold** each matching character in the command
name, to show how their input correlates to the results on screen.
## Capabilities
### Accessibility
As the entire command palette will be a native XAML element, it'll automatically
be hooked up to the UIA tree, allowing for screen readers to naturally find it.
* When the palette is opened, it will automatically receive focus.
* The terminal panes will not be able to be interacted with while the palette
is open, which will help keep the UIA tree simple while the palette is open.
### Security
This should not introduce any _new_ security concerns. We're relying on the
security of jsoncpp for parsing json. Adding new keys to the settings file
will rely on jsoncpp's ability to securely parse those json values.
### Reliability
We'll need to make sure that invalid commands are ignored. A command could be
invalid because:
* it has a null `name`, or a name with the empty string for a value.
* it has a null `action`, or an action specified that's not an actual
`ShortcutAction`.
We'll ignore invalid commands from the user's settings, instead of hard
crashing. I don't believe this is a scenario that warrants an error dialog to
indicate to the user that there's a problem with the json.
### Compatibility
We will need to define default _commands_ for all the existing keybinding
commands. With #754, we could add all the actions (that make sense) as commands
to the commands list, so that everyone wouldn't need to define them manually.
### Performance, Power, and Efficiency
We'll be adding a few extra XAML elements to our tree which will certainly
increase our runtime memory footprint while the palette is open.
We'll additionally be introducing a few extra json values to parse, so that could
increase our load times (though this will likely be negligible).
## Potential Issues
This will first require the work in [#1205] to work properly. Right now we
heavily lean on the "focused" element to determine which terminal is "active".
However, when the command palette is opened, focus will move out of the terminal
control into the command palette, which leads to some hard to debug crashes.
Additionally, we'll need to ensure that the "fuzzy search" algorithm proposed
above will work for non-english languages, where a single character might be
multiple `char`s long. As we'll be using a standard XAML text box for input, we
won't need to worry about handling the input ourselves.
### Localization
Because we'll be shipping a set of default commands with the terminal, we should
make sure that list of commands can be localizable. Each of the names we'll give
to the commands should be locale-specific.
To facilitate this, we'll use a special type of object in JSON that will let us
specify a resource name in JSON. We'll use a syntax like the following to
suggest that we should load a string from our resources, as opposed to using the
value from the file:
```json
"commands": [
{ "icon": null, "name": { "key": "NewTabCommandName" }, "action": "newTab" },
{ "icon": null, "name": { "key": "CloseTabCommandKey" }, "action": "closeTab" },
{ "icon": null, "name": { "key": "ClosePaneCommandKey" }, "action": "closePane" },
{ "icon": null, "name": { "key": "SplitHorizontalCommandKey" }, "action": "splitHorizontal" },
{ "icon": null, "name": { "key": "SplitVerticalCommandKey" }, "action": "splitVertical" },
{ "icon": null, "name": { "key": "NextTabCommandKey" }, "action": "nextTab" },
{ "icon": null, "name": { "key": "PrevTabCommandKey" }, "action": "prevTab" },
{ "icon": null, "name": { "key": "OpenSettingsCommandKey" }, "action": "openSettings" },
],
```
We'll check at parse time if the `name` property is a string or an object. If
it's a string, we'll treat that string as the literal text. Otherwise, if it's
an object, we'll attempt to use the `key` property of that object to look up a
string from our `ResourceDictionary`. This way, we'll be able to ship localized
strings for all the built-in commands, while also allowing the user to easily
add their own commands.
During the spec review process, we considered other options for localization as
well. The original proposal included options such as having one `defaults.json`
file per-locale, and building the Terminal independently for each locale. Those
were not really feasible options, so we instead settled on this solution, as it
allowed us to leverage the existing localization support provided to us by the
platform.
The `{ "key": "resourceName" }` solution proposed here was also touched on in
[#5280].
## Future considerations
* Commands will provide an easy point for allowing an extension to add its
actions to the UI, without forcing the user to bind the extension's actions to
a keybinding
* Also discussed in [#2046] was the potential for adding a command that inputs a
certain commandline to be run by the shell. I felt that was out of scope for
this spec, so I'm not including it in detail. I believe that would be
accomplished by adding a `inputCommand` action, with two args: `commandline`,
a string, and `suppressNewline`, an optional bool, defaulted to false. The
`inputCommand` action would deliver the given `commandline` as input to the
connection, followed by a newline (as to execute the command).
`suppressNewline` would prevent the newline from being added. This would work
relatively well, so long as you're sitting at a shell prompt. If you were in
an application like `vim`, this might be handy for executing a sequence of
vim-specific keybindings. Otherwise, you're just going to end up writing a
commandline to the buffer of vim. It would be weird, but not unexpected.
* Additionally mentioned in [#2046] was the potential for profile-scoped
commands. While that's a great idea, I believe it's out of scope for this
spec.
* Once [#754] lands, we'll need to make sure to include commands for each action
manually in the default settings. This will add some overhead that the
developer will need to do whenever they add an action. That's unfortunate, but
will be largely beneficial to the end user.
* We could theoretically also display the keybinding for a certain command in
the `ListViewItem` for the command. We'd need some way to correlate a
command's action to a keybinding's action. This could be done in a follow-up
task.
* We might want to alter the fuzzy-search algorithm, to give higher precedence
in the results list to commands with more consecutive matching characters.
Alternatively we could give more weight to commands where the search matched
the initial character of words in the command.
- For example: `ot` would give more weight to "**O**pen **T**ab" than
"**O**pen Se**t**tings").
* Another idea for a future spec is the concept of "nested commands", where a
single command has many sub-commands. This would hide the children commands
from the entire list of commands, allowing for much more succinct top-level
list of commands, and allowing related commands to be grouped together.
- For example, I have a text editor plugin that enables rendering markdown to
a number of different styles. To use that command in my text editor, first I
hit enter on the "Render Markdown..." command, then I select which style I
want to render to, in another list of options. This way, I don't need to
have three options for "Render Markdown to github", "Render Markdown to
gitlab", all in the top-level list.
- We probably also want to allow a nested command set to be evaluated at
runtime somehow. Like if we had a "Open New Tab..." command that then had a
nested menu with the list of profiles.
* We may want to add a button to the New Tab Button's dropdown to "Show Command
Palette". I'm hesitant to keep adding new buttons to that UI, but the command
palette is otherwise not highly discoverable.
- We could add another button to the UI to toggle the visibility of the
command palette. This was the idea initially proposed in [#2046].
- For both these options, we may want a global setting to hide that button, to
keep the UI as minimal as possible.
* [#1571] is a request for customizing the "new tab dropdown" menu. When we get
to discussing that design, we should consider also enabling users to add
commands from their list of commands to that menu as well.
## Resources
Initial post that inspired this spec: #[2046](https://github.com/microsoft/terminal/issues/2046)
Keybindings args: #[1349](https://github.com/microsoft/terminal/pull/1349)
Cascading User & Default Settings: #[754](https://github.com/microsoft/terminal/issues/754)
Untie "active control" from "currently XAML-focused control" #[1205](https://github.com/microsoft/terminal/issues/1205)
Allow dropdown menu customization in profiles.json [#1571](https://github.com/microsoft/terminal/issues/1571)
Search or run a command in Dropdown menu [#3879]
Spec: Introduce a mini-specification for localized resource use from JSON [#5280]
<!-- Footnotes -->
[#754]: https://github.com/microsoft/terminal/issues/754
[#1205]: https://github.com/microsoft/terminal/issues/1205
[#1142]: https://github.com/microsoft/terminal/pull/1349
[#2046]: https://github.com/microsoft/terminal/issues/2046
[#1571]: https://github.com/microsoft/terminal/issues/1571
[#3879]: https://github.com/microsoft/terminal/issues/3879
[#5280]: https://github.com/microsoft/terminal/pull/5280

View File

@@ -0,0 +1,115 @@
---
author: Mike Griese @zadjii-msft
created on: 2019-05-31
last updated: 2019-05-31
issue id: #997
---
# Non-Terminal Panes
## Abstract
This spec hopes to cover the work necessary to enable panes to host non-terminal
content. It'll describe changes to the `Pane` class to support hosting arbitrary
controls in addition to terminals.
## Inspiration
The primary driver for this change is to enable testing of the pane code. If a
`Pane` can host an arbitrary class, then a use case for that would be the
hosting of a non-xaml test class that acts like a control. This test class could
be have its state queried, to make sure that the panes are properly delivering
focus to the correct pane content.
Additionally, non-terminal panes could be used to host a variety of other
content, such as browser panes, sticky notes, text editor scratch-pads, etc.
Some discussion of these ideas are in #644.
## Solution Design
We'll change the TermControl class to derive from the
`Windows.UI.Xaml.Controls.Control` runtime class.
* We may need to override its `FocusState` and `Focus` methods, and implement
them by plumbing them straight through to the fake Control the `TermControl`
hosts.
* Otherwise, it might be possible that we could just remove that fake control
entirely.
* We'll remove the `GetControl` method from the `TermControl`, as the
`TermControl` itself will now be used as the control.
We'll change the Pane class to accept a `Windows.UI.Xaml.Controls.Control`
instead of a `TermControl`.
We'll additionally change the `Pane` constructor to accept an `optional<GUID>`
as opposed to needing a GUID. For constructing panes with Terminals, we should
pass a GUID corresponding to that settings profile. For panes that aren't
hosting terminals however, we should pass `nullopt` as the GUID. For panes that
are leaf nodes (panes which are hosting a control, not another pair of panes),
if the pane has a GUID, we can assume that the control is a TermControl.
When we want to host other types of content, we'll simply pass any other control
to the Pane, and it'll render it just as it would the `TermControl`.
## UI/UX Design
Instead of a pane hosting a terminal, it could host _any arbitrary control_. The
control would still be subject to the sizing provided to it by the `Pane`, but
it could host any arbitrary content.
## Capabilities
### Security
I don't forsee this implementation by itself raising security concerns. This
feature is mostly concerned with adding support for arbitrary controls, not
actually implementing some arbitrary controls.
### Reliability
With more possible controls in a pane than just a terminal, it's possible that
crashes in those controls could impact the entire Terminal app's reliability.
This would largely be out of our control, as we only author the TermControl.
We may want to consider hosting each pane in it's own process, similar to how
moder browsers will host each tab in its own process, to help isolate tabs. This
is a bigger discussion than the feature at hand, however.
### Performance, Power, and Efficiency
decide to host a WebView in a pane, then it surely could impact these measures.
I don't believe this will have a noticable impact _on its own_. Should the user
However, I leave that discussion to the implementation of the actual alternative
pane content itself.
### Accessibility
When implementing the accessibility tree for Panes, we'll need to make sure that
for panes with arbitrary content, we properly activate their accessibility,
should the control provide some sort of accessibility pattern.
## Potential Issues
* [ ] It's entirely possible that panes with non-terminal content will not be
able to activate keybindings from the terminal application. For example, what
if the hosted control wants to use Ctrl+T for its own shortcut? The current
keybindings model has the `TermControl` call into the App layer to see if a
keystroke should be handled by the app first. We may want to make sure that
for non-terminal controls, we add a event handler to try and have the
`AppKeyBindings` handle the keypress if the control doesn't. This won't solve
the case where the control wants to use a keybinding that is mapped by the
Terminal App. In that case, non-terminal controls will actually behave
differently from the `TermControl`. The `TermControl` will give the app the
first chance to handle a keybinding, while for other controls, the app will
give the control the first chance to handle the keypress. This may be mildly
confusing to end users.
## Future considerations
I expect this to be a major part of our (eventual) extensibility model. By
allowing arbitrary controls to be hosted in a Tab/Pane, this will allow
extension authors to embed their own UI experiences alongside the terminal.
See #555 for more discussion on the extensibility/plugin subject.
## Resources
N/A

110
doc/terminal-v2-roadmap.md Normal file
View File

@@ -0,0 +1,110 @@
# Terminal 2.0 Roadmap
## Overview
This document outlines the roadmap towards delivering Windows Terminal 2.0 by Spring 2021.
## Milestones
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 |
| --- | --- | --- |
| 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
Below is the schedule for when milestones will be included in release builds of Windows Terminal and Windows Terminal Preview. The dates are rough estimates and are subject to change.
| Milestone End Date | Milestone Name | Preview Release Blog Post |
| ------------------ | -------------- | ------------------------- |
| 2020-06-18 | [1.1] in Windows Terminal Preview | [Windows Terminal Preview 1.1 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-1-release/) |
| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | |
| 2020-08-31 | 1.3 in Windows Terminal Preview<br>[1.2] in Windows Terminal | |
| 2020-09-30 | 1.4 in Windows Terminal Preview<br>1.3 in Windows Terminal | |
| 2020-10-31 | 1.5 in Windows Terminal Preview<br>1.4 in Windows Terminal | |
| 2020-11-30 | 1.6 in Windows Terminal Preview<br>1.5 in Windows Terminal | |
| 2020-12-31 | 1.7 in Windows Terminal Preview<br>1.6 in Windows Terminal | |
| 2021-01-31 | 1.8 in Windows Terminal Preview<br>1.7 in Windows Terminal | |
| 2021-02-28 | 1.9 in Windows Terminal Preview<br>1.8 in Windows Terminal | |
| 2021-03-31 | 1.10 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
Incoming issues/asks/etc. are triaged several times a week, labeled appropriately, and assigned to a milestone in priority order:
* P0 (serious crashes, data loss, etc.) issues are scheduled to be dealt with ASAP
* P1/2 issues/features/asks assigned to the current or future milestone, or to the [Terminal 2.0 milestone](https://github.com/microsoft/terminal/milestone/22) for future assignment, if required to deliver a 2.0 feature
* Issues/features/asks not on our list of 2.0 features are assigned to the [Terminal Backlog](https://github.com/microsoft/terminal/milestone/7) for subsequent triage, prioritization & scheduling.
## 2.0 Scenarios
The following are a list of the key scenarios we're aiming to deliver for Terminal 2.0.
> 👉 Note: There are many other features that don't fit within 2.0, but will be re-assessed and prioritized for 3.0, the plan for which will be published in 2021.
| 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] |
| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193] |
| 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] |
| 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] |
| 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 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] |
| 2 | Theme marketplace | Marketplace for creation and distribution of themes.<br>Dependent on overall theming |
| 2 | Jump list | Show profiles from task bar (on right click)/start menu.<br><br>Issue: [#576] |
| 2 | Open with multiple tabs | A setting that allows Windows Terminal to launch with a specific tab configuration (not using only command line arguments).<br><br>Issue: [#756] |
| 3 | Open in Windows Terminal | Functionality to right click on a file or folder and select Open in Windows Terminal.<br><br>Issue: [#1060]<br>Implementation: [#6100] |
| 3 | Session restoration | Launch Windows Terminal and the previous session is restored with the proper tab and pane configuration and starting directories.<br><br>Issues: [#961], [#960], [#766] |
| 3 | Quake mode | Provide a quick launch terminal that appears and disappears when a hotkey is pressed.<br><br>Issue: [#653] |
| 3 | Settings migration infrastructure | Migrate people's settings without breaking them. Hand-in-hand with settings UI. |
| 3 | Pointer bindings | Provide settings that can be bound to the mouse.<br><br>Issue: [#1553] |
Feature Notes:
\* Feature Priorities:
0. Mandatory <br/>
1. Optimal <br/>
2. Optional / Stretch-goal <br/>
[1.1]: https://github.com/microsoft/terminal/milestone/24
[1.2]: https://github.com/microsoft/terminal/milestone/25
[2.0]: https://github.com/microsoft/terminal/milestone/22
[#1564]: https://github.com/microsoft/terminal/issues/1564
[#5400]: https://github.com/microsoft/terminal/issues/5400
[#2046]: https://github.com/microsoft/terminal/issues/2046
[#2193]: https://github.com/microsoft/terminal/pull/2193
[#1256]: https://github.com/microsoft/terminal/issues/1256
[#2080]: https://github.com/microsoft/terminal/pull/2080
[#574]: https://github.com/microsoft/terminal/issues/574
[#492]: https://github.com/microsoft/terminal/issues/492
[#2080]: https://github.com/microsoft/terminal/pull/2080
[#3327]: https://github.com/microsoft/terminal/issues/3327
[#5772]: https://github.com/microsoft/terminal/pull/5772
[#5000]: https://github.com/microsoft/terminal/issues/5000
[#603]: https://github.com/microsoft/terminal/issues/603
[#980]: https://github.com/microsoft/terminal/issues/980
[#2529]: https://github.com/microsoft/terminal/pull/2529
[#6062]: https://github.com/microsoft/terminal/pull/6062
[#1410]: https://github.com/microsoft/terminal/issues/1410
[#1000]: https://github.com/microsoft/terminal/issues/1000
[#576]: https://github.com/microsoft/terminal/issues/576
[#756]: https://github.com/microsoft/terminal/issues/756
[#1060]: https://github.com/microsoft/terminal/issues/1060
[#6100]: https://github.com/microsoft/terminal/pull/6100
[#961]: https://github.com/microsoft/terminal/issues/961
[#960]: https://github.com/microsoft/terminal/issues/960
[#766]: https://github.com/microsoft/terminal/issues/766
[#653]: https://github.com/microsoft/terminal/issues/653
[#1553]: https://github.com/microsoft/terminal/issues/1553

View File

@@ -321,7 +321,7 @@ COORD CharRow::GetStorageKey(const size_t column) const noexcept
// - Updates the pointer to the parent row (which might change if we shuffle the rows around)
// Arguments:
// - pParent - Pointer to the parent row
void CharRow::UpdateParent(ROW* const pParent) noexcept
void CharRow::UpdateParent(ROW* const pParent)
{
_pParent = FAIL_FAST_IF_NULL(pParent);
}

View File

@@ -88,7 +88,7 @@ public:
const UnicodeStorage& GetUnicodeStorage() const noexcept;
COORD GetStorageKey(const size_t column) const noexcept;
void UpdateParent(ROW* const pParent) noexcept;
void UpdateParent(ROW* const pParent);
friend CharRowCellReference;
friend constexpr bool operator==(const CharRow& a, const CharRow& b) noexcept;

View File

@@ -5,6 +5,21 @@
#include "TextAttribute.hpp"
#include "../../inc/conattrs.hpp"
// Routine Description:
// - Returns a WORD with legacy-style attributes for this textattribute.
// Parameters:
// - defaultAttributes: the attribute values to be used for default colors.
// Return value:
// - a WORD with legacy-style attributes for this textattribute.
WORD TextAttribute::GetLegacyAttributes(const WORD defaultAttributes) const noexcept
{
const BYTE fgIndex = _foreground.GetLegacyIndex(defaultAttributes & FG_ATTRS);
const BYTE bgIndex = _background.GetLegacyIndex((defaultAttributes & BG_ATTRS) >> 4);
const WORD metaAttrs = _wAttrLegacy & META_ATTRS;
const bool brighten = _foreground.IsIndex16() && IsBold();
return fgIndex | (bgIndex << 4) | metaAttrs | (brighten ? FOREGROUND_INTENSITY : 0);
}
bool TextAttribute::IsLegacy() const noexcept
{
return _foreground.IsLegacy() && _background.IsLegacy();
@@ -72,12 +87,22 @@ void TextAttribute::SetBackground(const COLORREF rgbBackground) noexcept
void TextAttribute::SetIndexedForeground(const BYTE fgIndex) noexcept
{
_foreground = TextColor(fgIndex);
_foreground = TextColor(fgIndex, false);
}
void TextAttribute::SetIndexedBackground(const BYTE bgIndex) noexcept
{
_background = TextColor(bgIndex);
_background = TextColor(bgIndex, false);
}
void TextAttribute::SetIndexedForeground256(const BYTE fgIndex) noexcept
{
_foreground = TextColor(fgIndex, true);
}
void TextAttribute::SetIndexedBackground256(const BYTE bgIndex) noexcept
{
_background = TextColor(bgIndex, true);
}
void TextAttribute::SetColor(const COLORREF rgbColor, const bool fIsForeground) noexcept
@@ -226,21 +251,6 @@ void TextAttribute::SetDefaultBackground() noexcept
_background = TextColor();
}
// Method Description:
// - Returns true if this attribute indicates its foreground is the "default"
// foreground. Its _rgbForeground will contain the actual value of the
// default foreground. If the default colors are ever changed, this method
// should be used to identify attributes with the default fg value, and
// update them accordingly.
// Arguments:
// - <none>
// Return Value:
// - true iff this attribute indicates it's the "default" foreground color.
bool TextAttribute::ForegroundIsDefault() const noexcept
{
return _foreground.IsDefault();
}
// Method Description:
// - Returns true if this attribute indicates its background is the "default"
// background. Its _rgbBackground will contain the actual value of the

View File

@@ -40,10 +40,10 @@ public:
{
}
constexpr TextAttribute(const WORD wLegacyAttr) noexcept :
explicit constexpr TextAttribute(const WORD wLegacyAttr) noexcept :
_wAttrLegacy{ gsl::narrow_cast<WORD>(wLegacyAttr & META_ATTRS) },
_foreground{ gsl::narrow_cast<BYTE>(wLegacyAttr & FG_ATTRS) },
_background{ gsl::narrow_cast<BYTE>((wLegacyAttr & BG_ATTRS) >> 4) },
_foreground{ gsl::narrow_cast<BYTE>(wLegacyAttr & FG_ATTRS), true },
_background{ gsl::narrow_cast<BYTE>((wLegacyAttr & BG_ATTRS) >> 4), true },
_extendedAttrs{ ExtendedAttributes::Normal }
{
// If we're given lead/trailing byte information with the legacy color, strip it.
@@ -59,36 +59,7 @@ public:
{
}
constexpr WORD GetLegacyAttributes() const noexcept
{
const BYTE fg = (_foreground.GetIndex() & FG_ATTRS);
const BYTE bg = (_background.GetIndex() << 4) & BG_ATTRS;
const WORD meta = (_wAttrLegacy & META_ATTRS);
return (fg | bg | meta) | (IsBold() ? FOREGROUND_INTENSITY : 0);
}
// Method Description:
// - Returns a WORD with legacy-style attributes for this textattribute.
// If either the foreground or background of this textattribute is not
// a legacy attribute, then instead use the provided default index as
// the value for that component.
// Arguments:
// - defaultFgIndex: the BYTE to use as the index for the foreground, should
// the foreground not be a legacy style attribute.
// - defaultBgIndex: the BYTE to use as the index for the background, should
// the background not be a legacy style attribute.
// Return Value:
// - a WORD with legacy-style attributes for this textattribute.
constexpr WORD GetLegacyAttributes(const BYTE defaultFgIndex,
const BYTE defaultBgIndex) const noexcept
{
const BYTE fgIndex = _foreground.IsLegacy() ? _foreground.GetIndex() : defaultFgIndex;
const BYTE bgIndex = _background.IsLegacy() ? _background.GetIndex() : defaultBgIndex;
const BYTE fg = (fgIndex & FG_ATTRS);
const BYTE bg = (bgIndex << 4) & BG_ATTRS;
const WORD meta = (_wAttrLegacy & META_ATTRS);
return (fg | bg | meta) | (IsBold() ? FOREGROUND_INTENSITY : 0);
}
WORD GetLegacyAttributes(const WORD defaultAttributes = 0x07) const noexcept;
COLORREF CalculateRgbForeground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultFgColor,
@@ -139,21 +110,17 @@ public:
void SetBackground(const COLORREF rgbBackground) noexcept;
void SetIndexedForeground(const BYTE fgIndex) noexcept;
void SetIndexedBackground(const BYTE bgIndex) noexcept;
void SetIndexedForeground256(const BYTE fgIndex) noexcept;
void SetIndexedBackground256(const BYTE bgIndex) noexcept;
void SetColor(const COLORREF rgbColor, const bool fIsForeground) noexcept;
void SetDefaultForeground() noexcept;
void SetDefaultBackground() noexcept;
bool ForegroundIsDefault() const noexcept;
bool BackgroundIsDefault() const noexcept;
void SetStandardErase() noexcept;
constexpr bool IsRgb() const noexcept
{
return _foreground.IsRgb() || _background.IsRgb();
}
// This returns whether this attribute, if printed directly next to another attribute, for the space
// character, would look identical to the other one.
bool HasIdenticalVisualRepresentationForBlankSpace(const TextAttribute& other, const bool inverted = false) const noexcept
@@ -224,26 +191,6 @@ constexpr bool operator!=(const TextAttribute& a, const TextAttribute& b) noexce
return !(a == b);
}
constexpr bool operator==(const TextAttribute& attr, const WORD& legacyAttr) noexcept
{
return attr.GetLegacyAttributes() == legacyAttr;
}
constexpr bool operator!=(const TextAttribute& attr, const WORD& legacyAttr) noexcept
{
return !(attr == legacyAttr);
}
constexpr bool operator==(const WORD& legacyAttr, const TextAttribute& attr) noexcept
{
return attr == legacyAttr;
}
constexpr bool operator!=(const WORD& legacyAttr, const TextAttribute& attr) noexcept
{
return !(attr == legacyAttr);
}
#ifdef UNIT_TESTING
#define LOG_ATTR(attr) (Log::Comment(NoThrowString().Format( \

View File

@@ -4,6 +4,77 @@
#include "precomp.h"
#include "TextColor.h"
// clang-format off
// A table mapping 8-bit RGB colors, in the form RRRGGGBB,
// down to one of the 16 colors in the legacy palette.
constexpr std::array<BYTE, 256> CompressedRgbToIndex16 = {
0, 1, 1, 9, 0, 0, 1, 1, 2, 1, 1, 1, 2, 8, 1, 9,
2, 2, 3, 3, 2, 2, 11, 3, 10, 10, 11, 11, 10, 10, 10, 11,
0, 5, 1, 1, 0, 0, 1, 1, 8, 1, 1, 1, 2, 8, 1, 9,
2, 2, 3, 3, 2, 2, 11, 3, 10, 10, 10, 11, 10, 10, 10, 11,
5, 5, 5, 1, 4, 5, 1, 1, 8, 8, 1, 9, 2, 8, 9, 9,
2, 2, 3, 3, 2, 2, 11, 3, 10, 10, 11, 11, 10, 10, 10, 11,
4, 5, 5, 1, 4, 5, 5, 1, 8, 5, 5, 1, 8, 8, 9, 9,
2, 2, 8, 9, 10, 2, 11, 3, 10, 10, 11, 11, 10, 10, 10, 11,
4, 13, 5, 5, 4, 13, 5, 5, 4, 13, 13, 13, 6, 8, 13, 9,
6, 8, 8, 9, 10, 10, 11, 3, 10, 10, 11, 11, 10, 10, 10, 11,
4, 13, 13, 13, 4, 13, 13, 13, 4, 12, 13, 13, 6, 12, 13, 13,
6, 6, 8, 9, 6, 6, 7, 7, 10, 14, 14, 7, 10, 10, 14, 11,
4, 12, 13, 13, 4, 12, 13, 13, 4, 12, 13, 13, 6, 12, 12, 13,
6, 6, 12, 7, 6, 6, 7, 7, 6, 14, 14, 7, 14, 14, 14, 15,
12, 12, 13, 13, 12, 12, 13, 13, 12, 12, 12, 13, 12, 12, 12, 13,
6, 12, 12, 7, 6, 6, 7, 7, 6, 14, 14, 7, 14, 14, 14, 15
};
// A table mapping indexed colors from the 256-color palette,
// down to one of the 16 colors in the legacy palette.
constexpr std::array<BYTE, 256> Index256ToIndex16 = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 1, 1, 9, 9, 2, 1, 1, 1, 1, 1, 2, 2, 3, 3,
3, 3, 2, 2, 11, 11, 3, 3, 10, 10, 11, 11, 11, 11, 10, 10,
10, 10, 11, 11, 5, 5, 5, 5, 1, 1, 8, 8, 1, 1, 9, 9,
2, 2, 3, 3, 3, 3, 2, 2, 11, 11, 3, 3, 10, 10, 11, 11,
11, 11, 10, 10, 10, 10, 11, 11, 4, 13, 5, 5, 5, 5, 4, 13,
13, 13, 13, 13, 6, 8, 8, 8, 9, 9, 10, 10, 11, 11, 3, 3,
10, 10, 11, 11, 11, 11, 10, 10, 10, 10, 11, 11, 4, 13, 13, 13,
13, 13, 4, 12, 13, 13, 13, 13, 6, 6, 8, 8, 9, 9, 6, 6,
7, 7, 7, 7, 10, 14, 14, 14, 7, 7, 10, 10, 14, 14, 11, 11,
4, 12, 13, 13, 13, 13, 4, 12, 13, 13, 13, 13, 6, 6, 12, 12,
7, 7, 6, 6, 7, 7, 7, 7, 6, 14, 14, 14, 7, 7, 14, 14,
14, 14, 15, 15, 12, 12, 13, 13, 13, 13, 12, 12, 12, 12, 13, 13,
6, 12, 12, 12, 7, 7, 6, 6, 7, 7, 7, 7, 6, 14, 14, 14,
7, 7, 14, 14, 14, 14, 15, 15, 0, 0, 0, 0, 0, 0, 8, 8,
8, 8, 8, 8, 8, 8, 8, 8, 7, 7, 7, 7, 7, 7, 15, 15
};
// clang-format on
bool TextColor::IsLegacy() const noexcept
{
return IsIndex16() || (IsIndex256() && _index < 16);
}
bool TextColor::IsIndex16() const noexcept
{
return _meta == ColorType::IsIndex16;
}
bool TextColor::IsIndex256() const noexcept
{
return _meta == ColorType::IsIndex256;
}
bool TextColor::IsDefault() const noexcept
{
return _meta == ColorType::IsDefault;
}
bool TextColor::IsRgb() const noexcept
{
return _meta == ColorType::IsRgb;
}
// Method Description:
// - Sets the color value of this attribute, and sets this color to be an RGB
// attribute.
@@ -23,11 +94,12 @@ void TextColor::SetColor(const COLORREF rgbColor) noexcept
// - Sets this TextColor to be a legacy-style index into the color table.
// Arguments:
// - index: the index of the colortable we should use for this TextColor.
// - isIndex256: is this a 256 color index (true) or a 16 color index (false).
// Return Value:
// - <none>
void TextColor::SetIndex(const BYTE index) noexcept
void TextColor::SetIndex(const BYTE index, const bool isIndex256) noexcept
{
_meta = ColorType::IsIndex;
_meta = isIndex256 ? ColorType::IsIndex256 : ColorType::IsIndex16;
_index = index;
}
@@ -48,15 +120,15 @@ void TextColor::SetDefault() noexcept
// * If we're an RGB color, we'll use that value.
// * If we're an indexed color table value, we'll use that index to look up
// our value in the provided color table.
// - If brighten is true, and the index is in the "dark" portion of the
// color table (indices [0,7]), then we'll look up the bright version of
// this color (from indices [8,15]). This should be true for
// TextAttributes that are "Bold" and we're treating bold as bright
// (which is the default behavior of most terminals.)
// - If brighten is true, and we've got a 16 color index in the "dark"
// portion of the color table (indices [0,7]), then we'll look up the
// bright version of this color (from indices [8,15]). This should be
// true for TextAttributes that are "Bold" and we're treating bold as
// bright (which is the default behavior of most terminals.)
// * If we're a default color, we'll return the default color provided.
// Arguments:
// - colorTable: The table of colors we should use to look up the value of a
// legacy attribute from
// - colorTable: The table of colors we should use to look up the value of
// an indexed attribute from.
// - defaultColor: The color value to use if we're a default attribute.
// - brighten: if true, we'll brighten a dark color table index.
// Return Value:
@@ -94,21 +166,44 @@ COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
{
return _GetRGB();
}
else if (IsIndex16() && brighten)
{
return colorTable.at(_index | 8);
}
else
{
FAIL_FAST_IF(colorTable.size() < _index);
// If the color is already bright (it's in index [8,15] or it's a
// 256color value [16,255], then boldness does nothing.
if (brighten && _index < 8)
{
FAIL_FAST_IF(colorTable.size() < 16);
FAIL_FAST_IF(gsl::narrow_cast<size_t>(_index) + 8 > colorTable.size());
return colorTable.at(gsl::narrow_cast<size_t>(_index) + 8);
}
else
{
return colorTable.at(_index);
}
return colorTable.at(_index);
}
}
// Method Description:
// - Return a legacy index value that best approximates this color.
// Arguments:
// - defaultIndex: The index to use for a default color.
// Return Value:
// - an index into the 16-color table
BYTE TextColor::GetLegacyIndex(const BYTE defaultIndex) const noexcept
{
if (IsDefault())
{
return defaultIndex;
}
else if (IsIndex16())
{
return GetIndex();
}
else if (IsIndex256())
{
return Index256ToIndex16.at(GetIndex());
}
else
{
// We compress the RGB down to an 8-bit value and use that to
// lookup a representative 16-color index from a hard-coded table.
const BYTE compressedRgb = (_red & 0b11100000) +
((_green >> 3) & 0b00011100) +
((_blue >> 6) & 0b00000011);
return CompressedRgbToIndex16.at(compressedRgb);
}
}

View File

@@ -41,9 +41,10 @@ Revision History:
enum class ColorType : BYTE
{
IsIndex = 0x0,
IsDefault = 0x1,
IsRgb = 0x2
IsIndex256 = 0x0,
IsIndex16 = 0x1,
IsDefault = 0x2,
IsRgb = 0x3
};
struct TextColor
@@ -57,9 +58,9 @@ public:
{
}
constexpr TextColor(const BYTE wLegacyAttr) noexcept :
_meta{ ColorType::IsIndex },
_index{ wLegacyAttr },
constexpr TextColor(const BYTE index, const bool isIndex256) noexcept :
_meta{ isIndex256 ? ColorType::IsIndex256 : ColorType::IsIndex16 },
_index{ index },
_green{ 0 },
_blue{ 0 }
{
@@ -76,29 +77,22 @@ public:
friend constexpr bool operator==(const TextColor& a, const TextColor& b) noexcept;
friend constexpr bool operator!=(const TextColor& a, const TextColor& b) noexcept;
constexpr bool IsLegacy() const noexcept
{
return !(IsDefault() || IsRgb());
}
constexpr bool IsDefault() const noexcept
{
return _meta == ColorType::IsDefault;
}
constexpr bool IsRgb() const noexcept
{
return _meta == ColorType::IsRgb;
}
bool IsLegacy() const noexcept;
bool IsIndex16() const noexcept;
bool IsIndex256() const noexcept;
bool IsDefault() const noexcept;
bool IsRgb() const noexcept;
void SetColor(const COLORREF rgbColor) noexcept;
void SetIndex(const BYTE index) noexcept;
void SetIndex(const BYTE index, const bool isIndex256) noexcept;
void SetDefault() noexcept;
COLORREF GetColor(std::basic_string_view<COLORREF> colorTable,
const COLORREF defaultColor,
const bool brighten) const noexcept;
BYTE GetLegacyIndex(const BYTE defaultIndex) const noexcept;
constexpr BYTE GetIndex() const noexcept
{
return _index;

View File

@@ -81,7 +81,7 @@ void TextColorTests::TestDefaultColor()
void TextColorTests::TestDarkIndexColor()
{
TextColor indexColor((BYTE)(7));
TextColor indexColor((BYTE)(7), false);
VERIFY_IS_FALSE(indexColor.IsDefault());
VERIFY_IS_TRUE(indexColor.IsLegacy());
@@ -104,7 +104,7 @@ void TextColorTests::TestDarkIndexColor()
void TextColorTests::TestBrightIndexColor()
{
TextColor indexColor((BYTE)(15));
TextColor indexColor((BYTE)(15), false);
VERIFY_IS_FALSE(indexColor.IsDefault());
VERIFY_IS_TRUE(indexColor.IsLegacy());
@@ -186,7 +186,7 @@ void TextColorTests::TestChangeColor()
color = rgbColor.GetColor(view, _defaultBg, true);
VERIFY_ARE_EQUAL(_defaultBg, color);
rgbColor.SetIndex(7);
rgbColor.SetIndex(7, false);
color = rgbColor.GetColor(view, _defaultFg, false);
VERIFY_ARE_EQUAL(_colorTable[7], color);
@@ -199,7 +199,7 @@ void TextColorTests::TestChangeColor()
color = rgbColor.GetColor(view, _defaultBg, true);
VERIFY_ARE_EQUAL(_colorTable[15], color);
rgbColor.SetIndex(15);
rgbColor.SetIndex(15, false);
color = rgbColor.GetColor(view, _defaultFg, false);
VERIFY_ARE_EQUAL(_colorTable[15], color);

View File

@@ -46,8 +46,9 @@
<!-- Resources -->
<!-- This resw only defines things that are used in this package's AppxManifest,
so it's not in the common resource items. -->
<PRIResource Include="Resources\*\Resources.resw" />
<PRIResource Include="Resources\en-US\Resources.resw" />
<PRIResource Include="Resources\Resources.resw" />
<OCResourceDirectory Include="Resources" />
</ItemGroup>
<!-- This is picked up by CascadiaResources.build.items. -->
@@ -64,7 +65,9 @@
<ProjectReference Include="..\WindowsTerminal\WindowsTerminal.vcxproj" />
<ProjectReference Include="..\..\host\exe\Host.EXE.vcxproj" />
<ProjectReference Include="..\TerminalAzBridge\TerminalAzBridge.vcxproj" />
<ProjectReference Include="..\ShellExtension\WindowsTerminalShellExt.vcxproj" />
</ItemGroup>
<Target Name="OpenConsoleStompSourceProjectForWapProject" BeforeTargets="_ConvertItems">
<ItemGroup>
<!-- Stomp all "SourceProject" values for all incoming dependencies to flatten the package. -->
@@ -139,11 +142,13 @@
<!-- **END VC LIBS HACK** -->
<!-- This is required to get the package dependency in the AppXManifest. -->
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets')" />
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets'))" />
<Error Condition="!Exists('..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets'))" />
</Target>
<Import Project="$(SolutionDir)build\rules\CollectWildcardResources.targets" />
</Project>

View File

@@ -3,10 +3,15 @@
<Package
xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
xmlns:com="http://schemas.microsoft.com/appx/manifest/com/windows10"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
IgnorableNamespaces="uap mp rescap">
<Identity
@@ -15,7 +20,7 @@
Version="0.0.1.0" />
<Properties>
<DisplayName>ms-resource:AppNameDev</DisplayName>
<DisplayName>Windows Terminal Dev</DisplayName>
<PublisherDisplayName>A Lone Developer</PublisherDisplayName>
<Logo>Images\StoreLogo.png</Logo>
</Properties>
@@ -39,7 +44,7 @@
Square150x150Logo="Images\Square150x150Logo.png"
Square44x44Logo="Images\Square44x44Logo.png">
<uap:DefaultTile
Wide310x150Logo="Images\Wide310x150Logo.png"
Wide310x150Logo="Images\Wide310x150Logo.png"
Square71x71Logo="Images\SmallTile.png"
Square310x310Logo="Images\LargeTile.png"
ShortName="ms-resource:AppShortNameDev">
@@ -58,6 +63,36 @@
<desktop:ExecutionAlias Alias="wtd.exe" />
</uap3:AppExecutionAlias>
</uap3:Extension>
<uap5:Extension Category="windows.startupTask">
<uap5:StartupTask
TaskId="StartTerminalOnLoginTask"
Enabled="false"
DisplayName="ms-resource:AppNameDev" />
</uap5:Extension>
<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="WindowsTerminalShellExt">
<com:Class Id="9f156763-7844-4dc4-b2b1-901f640f5155" Path="WindowsTerminalShellExt.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop5:ItemType Type="Directory">
<desktop5:Verb Id="Command1" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
<!-- Due to a bug in the OS, this doesn't actually work right -
we'll get a nullptr in our implementation. So this is disabled
temporarily. See MSFT:24623699 for more details.
<desktop5:ItemType Type="Directory\Background">
<desktop5:Verb Id="Command2" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
-->
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>
</Extensions>
</Application>

View File

@@ -3,11 +3,15 @@
<Package
xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
xmlns:com="http://schemas.microsoft.com/appx/manifest/com/windows10"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp rescap">
@@ -17,7 +21,7 @@
Version="0.5.0.0" />
<Properties>
<DisplayName>Windows Terminal (Preview)</DisplayName>
<DisplayName>Windows Terminal Preview</DisplayName>
<PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
<Logo>Images\StoreLogo.png</Logo>
</Properties>
@@ -41,13 +45,13 @@
Square150x150Logo="Images\Square150x150Logo.png"
Square44x44Logo="Images\Square44x44Logo.png">
<uap:DefaultTile
Wide310x150Logo="Images\Wide310x150Logo.png"
Wide310x150Logo="Images\Wide310x150Logo.png"
Square71x71Logo="Images\SmallTile.png"
Square310x310Logo="Images\LargeTile.png"
ShortName="ms-resource:AppShortNamePre">
<uap:ShowNameOnTiles>
<uap:ShowOn Tile="square150x150Logo"/>
<uap:ShowOn Tile="wide310x150Logo"/>
<uap:ShowOn Tile="wide310x150Logo"/>
<uap:ShowOn Tile="square310x310Logo"/>
</uap:ShowNameOnTiles>
</uap:DefaultTile>
@@ -60,6 +64,36 @@
<desktop:ExecutionAlias Alias="wt.exe" />
</uap3:AppExecutionAlias>
</uap3:Extension>
<uap5:Extension Category="windows.startupTask">
<uap5:StartupTask
TaskId="StartTerminalOnLoginTask"
Enabled="false"
DisplayName="ms-resource:AppNamePre" />
</uap5:Extension>
<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="WindowsTerminalShellExt">
<com:Class Id="9f156763-7844-4dc4-b2b1-901f640f5155" Path="WindowsTerminalShellExt.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop5:ItemType Type="Directory">
<desktop5:Verb Id="Command1" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
<!-- Due to a bug in the OS, this doesn't actually work right -
we'll get a nullptr in our implementation. So this is disabled
temporarily. See MSFT:24623699 for more details.
<desktop5:ItemType Type="Directory\Background">
<desktop5:Verb Id="Command2" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
-->
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>
</Extensions>
</Application>

View File

@@ -3,11 +3,15 @@
<Package
xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
xmlns:com="http://schemas.microsoft.com/appx/manifest/com/windows10"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp rescap">
@@ -41,7 +45,7 @@
Square150x150Logo="Images\Square150x150Logo.png"
Square44x44Logo="Images\Square44x44Logo.png">
<uap:DefaultTile
Wide310x150Logo="Images\Wide310x150Logo.png"
Wide310x150Logo="Images\Wide310x150Logo.png"
Square71x71Logo="Images\SmallTile.png"
Square310x310Logo="Images\LargeTile.png"
ShortName="ms-resource:AppShortName">
@@ -60,6 +64,36 @@
<desktop:ExecutionAlias Alias="wt.exe" />
</uap3:AppExecutionAlias>
</uap3:Extension>
<uap5:Extension Category="windows.startupTask">
<uap5:StartupTask
TaskId="StartTerminalOnLoginTask"
Enabled="false"
DisplayName="ms-resource:AppName" />
</uap5:Extension>
<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="WindowsTerminalShellExt">
<com:Class Id="9f156763-7844-4dc4-b2b1-901f640f5155" Path="WindowsTerminalShellExt.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop5:ItemType Type="Directory">
<desktop5:Verb Id="Command1" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
<!-- Due to a bug in the OS, this doesn't actually work right -
we'll get a nullptr in our implementation. So this is disabled
temporarily. See MSFT:24623699 for more details.
<desktop5:ItemType Type="Directory\Background">
<desktop5:Verb Id="Command2" Clsid="9f156763-7844-4dc4-b2b1-901f640f5155" />
</desktop5:ItemType>
-->
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>
</Extensions>
</Application>

View File

@@ -121,18 +121,18 @@
<value>Windows Terminal</value>
</data>
<data name="AppNameDev" xml:space="preserve">
<value>Windows Terminal (Dev Build)</value>
<value>Windows Terminal Dev</value>
</data>
<data name="AppNamePre" xml:space="preserve">
<value>Windows Terminal (Preview)</value>
<value>Windows Terminal Preview</value>
</data>
<data name="AppShortName" xml:space="preserve">
<value>Terminal</value>
</data>
<data name="AppShortNameDev" xml:space="preserve">
<value>Terminal (Dev)</value>
<value>Terminal Dev</value>
</data>
<data name="AppShortNamePre" xml:space="preserve">
<value>Terminal (Preview)</value>
<value>Terminal Preview</value>
</data>
</root>

View File

@@ -0,0 +1,208 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "../TerminalApp/CascadiaSettings.h"
#include "JsonTestClass.h"
#include "TestUtils.h"
using namespace Microsoft::Console;
using namespace TerminalApp;
using namespace winrt::TerminalApp;
using namespace winrt::Microsoft::Terminal::Settings;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
using namespace WEX::Common;
namespace TerminalAppLocalTests
{
// TODO:microsoft/terminal#3838:
// Unfortunately, these tests _WILL NOT_ work in our CI. We're waiting for
// an updated TAEF that will let us install framework packages when the test
// package is deployed. Until then, these tests won't deploy in CI.
class CommandTests : public JsonTestClass
{
// Use a custom AppxManifest to ensure that we can activate winrt types
// from our test. This property will tell taef to manually use this as
// the AppxManifest for this test class.
// This does not yet work for anything XAML-y. See TabTests.cpp for more
// details on that.
BEGIN_TEST_CLASS(CommandTests)
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TestHostAppXManifest.xml")
END_TEST_CLASS()
TEST_METHOD(ManyCommandsSameAction);
TEST_METHOD(LayerCommand);
TEST_METHOD(TestSplitPaneArgs);
TEST_METHOD(TestResourceKeyName);
TEST_CLASS_SETUP(ClassSetup)
{
InitializeJsonReader();
return true;
}
};
void CommandTests::ManyCommandsSameAction()
{
const std::string commands0String{ R"([ { "name":"action0", "action": "copy" } ])" };
const std::string commands1String{ R"([ { "name":"action1", "action": { "action": "copy", "singleLine": false } } ])" };
const std::string commands2String{ R"([
{ "name":"action2", "action": "paste" },
{ "name":"action3", "action": "paste" }
])" };
const auto commands0Json = VerifyParseSucceeded(commands0String);
const auto commands1Json = VerifyParseSucceeded(commands1String);
const auto commands2Json = VerifyParseSucceeded(commands2String);
std::map<winrt::hstring, Command> commands;
VERIFY_ARE_EQUAL(0u, commands.size());
{
auto warnings = implementation::Command::LayerJson(commands, commands0Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
}
VERIFY_ARE_EQUAL(1u, commands.size());
{
auto warnings = implementation::Command::LayerJson(commands, commands1Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
}
VERIFY_ARE_EQUAL(2u, commands.size());
{
auto warnings = implementation::Command::LayerJson(commands, commands2Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
}
VERIFY_ARE_EQUAL(4u, commands.size());
}
void CommandTests::LayerCommand()
{
// Each one of the commands in this test should layer upon the previous, overriding the action.
const std::string commands0String{ R"([ { "name":"action0", "action": "copy" } ])" };
const std::string commands1String{ R"([ { "name":"action0", "action": "paste" } ])" };
const std::string commands2String{ R"([ { "name":"action0", "action": "newTab" } ])" };
const std::string commands3String{ R"([ { "name":"action0", "action": null } ])" };
const auto commands0Json = VerifyParseSucceeded(commands0String);
const auto commands1Json = VerifyParseSucceeded(commands1String);
const auto commands2Json = VerifyParseSucceeded(commands2String);
const auto commands3Json = VerifyParseSucceeded(commands3String);
std::map<winrt::hstring, Command> commands;
VERIFY_ARE_EQUAL(0u, commands.size());
{
auto warnings = implementation::Command::LayerJson(commands, commands0Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(1u, commands.size());
auto command = commands.at(L"action0");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::CopyText, command.Action().Action());
const auto& realArgs = command.Action().Args().try_as<CopyTextArgs>();
VERIFY_IS_NOT_NULL(realArgs);
}
{
auto warnings = implementation::Command::LayerJson(commands, commands1Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(1u, commands.size());
auto command = commands.at(L"action0");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::PasteText, command.Action().Action());
VERIFY_IS_NULL(command.Action().Args());
}
{
auto warnings = implementation::Command::LayerJson(commands, commands2Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(1u, commands.size());
auto command = commands.at(L"action0");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::NewTab, command.Action().Action());
const auto& realArgs = command.Action().Args().try_as<NewTabArgs>();
VERIFY_IS_NOT_NULL(realArgs);
}
{
// This last command should "unbind" the action.
auto warnings = implementation::Command::LayerJson(commands, commands3Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(0u, commands.size());
}
}
void CommandTests::TestSplitPaneArgs()
{
// This is the same as KeyBindingsTests::TestSplitPaneArgs, but with
// looking up the action and it's args from a map of commands, instead
// of from keybindings.
const std::string commands0String{ R"([
{ "name": "command0", "action": { "action": "splitPane", "split": null } },
{ "name": "command1", "action": { "action": "splitPane", "split": "vertical" } },
{ "name": "command2", "action": { "action": "splitPane", "split": "horizontal" } },
{ "name": "command3", "action": { "action": "splitPane", "split": "none" } },
{ "name": "command4", "action": { "action": "splitPane" } },
{ "name": "command5", "action": { "action": "splitPane", "split": "auto" } },
{ "name": "command6", "action": { "action": "splitPane", "split": "foo" } }
])" };
const auto commands0Json = VerifyParseSucceeded(commands0String);
std::map<winrt::hstring, Command> commands;
VERIFY_ARE_EQUAL(0u, commands.size());
auto warnings = implementation::Command::LayerJson(commands, commands0Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(7u, commands.size());
{
auto command = commands.at(L"command0");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, command.Action().Action());
const auto& realArgs = command.Action().Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_ARE_EQUAL(winrt::TerminalApp::SplitState::Automatic, realArgs.SplitStyle());
}
{
auto command = commands.at(L"command1");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::SplitPane, command.Action().Action());
const auto& realArgs = command.Action().Args().try_as<SplitPaneArgs>();
VERIFY_IS_NOT_NULL(realArgs);
// Verify the args have the expected value
VERIFY_ARE_EQUAL(winrt::TerminalApp::SplitState::Vertical, realArgs.SplitStyle());
}
}
void CommandTests::TestResourceKeyName()
{
// Each one of the commands in this test should layer upon the previous, overriding the action.
const std::string commands0String{ R"([ { "name": { "key": "DuplicateTabCommandKey"}, "action": "copy" } ])" };
const auto commands0Json = VerifyParseSucceeded(commands0String);
std::map<winrt::hstring, Command> commands;
VERIFY_ARE_EQUAL(0u, commands.size());
{
auto warnings = implementation::Command::LayerJson(commands, commands0Json);
VERIFY_ARE_EQUAL(0u, warnings.size());
VERIFY_ARE_EQUAL(1u, commands.size());
// NOTE: We're relying on DuplicateTabCommandKey being defined as
// "Duplicate Tab" here. If that string changes in our resources,
// this test will break.
auto command = commands.at(L"Duplicate Tab");
VERIFY_IS_NOT_NULL(command);
VERIFY_IS_NOT_NULL(command.Action());
VERIFY_ARE_EQUAL(ShortcutAction::CopyText, command.Action().Action());
const auto& realArgs = command.Action().Args().try_as<CopyTextArgs>();
VERIFY_IS_NOT_NULL(realArgs);
}
}
}

View File

@@ -78,6 +78,8 @@ namespace TerminalAppLocalTests
TEST_METHOD(ValidateLegacyGlobalsWarning);
TEST_METHOD(TestTrailingCommas);
TEST_CLASS_SETUP(ClassSetup)
{
InitializeJsonReader();
@@ -203,16 +205,32 @@ namespace TerminalAppLocalTests
]
})" };
const std::string goodProfilesSpecifiedByName{ R"(
{
"defaultProfile": "profile1",
"profiles": [
{
"name" : "profile0",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
},
{
"name" : "profile1",
"guid": "{6239a42c-2222-49a3-80bd-e8fdd045185c}"
}
]
})" };
{
// Case 1: Good settings
Log::Comment(NoThrowString().Format(
L"Testing a pair of profiles with unique guids, and the defaultProfile is one of those guids"));
const auto settingsObject = VerifyParseSucceeded(goodProfiles);
auto settings = CascadiaSettings::FromJson(settingsObject);
settings->_ResolveDefaultProfile();
settings->_ValidateDefaultProfileExists();
VERIFY_ARE_EQUAL(static_cast<size_t>(0), settings->_warnings.size());
VERIFY_ARE_EQUAL(static_cast<size_t>(2), settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.GetDefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(0).GetGuid());
}
{
// Case 2: Bad settings
@@ -220,12 +238,13 @@ namespace TerminalAppLocalTests
L"Testing a pair of profiles with unique guids, but the defaultProfile is NOT one of those guids"));
const auto settingsObject = VerifyParseSucceeded(badProfiles);
auto settings = CascadiaSettings::FromJson(settingsObject);
settings->_ResolveDefaultProfile();
settings->_ValidateDefaultProfileExists();
VERIFY_ARE_EQUAL(static_cast<size_t>(1), settings->_warnings.size());
VERIFY_ARE_EQUAL(::TerminalApp::SettingsLoadWarnings::MissingDefaultProfile, settings->_warnings.at(0));
VERIFY_ARE_EQUAL(static_cast<size_t>(2), settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.GetDefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(0).GetGuid());
}
{
// Case 2: Bad settings
@@ -233,12 +252,25 @@ namespace TerminalAppLocalTests
L"Testing a pair of profiles with unique guids, and no defaultProfile at all"));
const auto settingsObject = VerifyParseSucceeded(badProfiles);
auto settings = CascadiaSettings::FromJson(settingsObject);
settings->_ResolveDefaultProfile();
settings->_ValidateDefaultProfileExists();
VERIFY_ARE_EQUAL(static_cast<size_t>(1), settings->_warnings.size());
VERIFY_ARE_EQUAL(::TerminalApp::SettingsLoadWarnings::MissingDefaultProfile, settings->_warnings.at(0));
VERIFY_ARE_EQUAL(static_cast<size_t>(2), settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.GetDefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(0).GetGuid());
}
{
// Case 4: Good settings, default profile is a string
Log::Comment(NoThrowString().Format(
L"Testing a pair of profiles with unique guids, and the defaultProfile is one of the profile names"));
const auto settingsObject = VerifyParseSucceeded(goodProfilesSpecifiedByName);
auto settings = CascadiaSettings::FromJson(settingsObject);
settings->_ResolveDefaultProfile();
settings->_ValidateDefaultProfileExists();
VERIFY_ARE_EQUAL(static_cast<size_t>(0), settings->_warnings.size());
VERIFY_ARE_EQUAL(static_cast<size_t>(2), settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(1).GetGuid());
}
}
@@ -420,7 +452,7 @@ namespace TerminalAppLocalTests
VERIFY_ARE_EQUAL(::TerminalApp::SettingsLoadWarnings::UnknownColorScheme, settings->_warnings.at(2));
VERIFY_ARE_EQUAL(3u, settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.GetDefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_IS_TRUE(settings->_profiles.at(0)._guid.has_value());
VERIFY_IS_TRUE(settings->_profiles.at(1)._guid.has_value());
VERIFY_IS_TRUE(settings->_profiles.at(2)._guid.has_value());
@@ -448,18 +480,18 @@ namespace TerminalAppLocalTests
CascadiaSettings settings;
settings.LayerJson(settings0Json);
VERIFY_ARE_EQUAL(true, settings._globals._alwaysShowTabs);
VERIFY_ARE_EQUAL(120, settings._globals._initialCols);
VERIFY_ARE_EQUAL(30, settings._globals._initialRows);
VERIFY_ARE_EQUAL(4, settings._globals._rowsToScroll);
VERIFY_ARE_EQUAL(true, settings._globals._showTabsInTitlebar);
VERIFY_ARE_EQUAL(true, settings._globals._AlwaysShowTabs);
VERIFY_ARE_EQUAL(120, settings._globals._InitialCols);
VERIFY_ARE_EQUAL(30, settings._globals._InitialRows);
VERIFY_ARE_EQUAL(4, settings._globals._RowsToScroll);
VERIFY_ARE_EQUAL(true, settings._globals._ShowTabsInTitlebar);
settings.LayerJson(settings1Json);
VERIFY_ARE_EQUAL(true, settings._globals._alwaysShowTabs);
VERIFY_ARE_EQUAL(240, settings._globals._initialCols);
VERIFY_ARE_EQUAL(60, settings._globals._initialRows);
VERIFY_ARE_EQUAL(8, settings._globals._rowsToScroll);
VERIFY_ARE_EQUAL(false, settings._globals._showTabsInTitlebar);
VERIFY_ARE_EQUAL(true, settings._globals._AlwaysShowTabs);
VERIFY_ARE_EQUAL(240, settings._globals._InitialCols);
VERIFY_ARE_EQUAL(60, settings._globals._InitialRows);
VERIFY_ARE_EQUAL(8, settings._globals._RowsToScroll);
VERIFY_ARE_EQUAL(false, settings._globals._ShowTabsInTitlebar);
}
void SettingsTests::ValidateProfileOrdering()
@@ -867,7 +899,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_TRUE(settings._profiles.at(0)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(1)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
settings._ParseJsonString(settings0String, false);
settings.LayerJson(settings._userSettings);
@@ -968,7 +1000,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_TRUE(settings._profiles.at(0)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(1)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
settings._ParseJsonString(settings0String, false);
settings.LayerJson(settings._userSettings);
@@ -979,7 +1011,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_FALSE(settings._profiles.at(2)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(3)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotCrash", settings._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"Ubuntu", settings._profiles.at(3)._name);
@@ -990,7 +1022,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_TRUE(settings._profiles.at(1)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(2)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(3)._guid.has_value());
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotCrash", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Ubuntu", settings._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(3)._name);
@@ -1029,7 +1061,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_TRUE(settings._profiles.at(0)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(1)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
Log::Comment(NoThrowString().Format(
L"Parse the user settings"));
@@ -1043,7 +1075,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_FALSE(settings._profiles.at(3)._guid.has_value());
VERIFY_IS_FALSE(settings._profiles.at(4)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"ThisProfileIsGood", settings._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotLayer", settings._profiles.at(3)._name);
VERIFY_ARE_EQUAL(L"NeitherShouldThisOne", settings._profiles.at(4)._name);
@@ -1082,7 +1114,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_TRUE(settings._profiles.at(0)._guid.has_value());
VERIFY_IS_TRUE(settings._profiles.at(1)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
Log::Comment(NoThrowString().Format(
L"Parse the user settings"));
@@ -1096,7 +1128,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_FALSE(settings._profiles.at(3)._guid.has_value());
VERIFY_IS_FALSE(settings._profiles.at(4)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"ThisProfileIsGood", settings._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotDuplicate", settings._profiles.at(3)._name);
VERIFY_ARE_EQUAL(L"NeitherShouldThisOne", settings._profiles.at(4)._name);
@@ -1129,7 +1161,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_FALSE(settings2._profiles.at(3)._guid.has_value());
VERIFY_IS_FALSE(settings2._profiles.at(4)._guid.has_value());
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings2._profiles.at(0)._name);
VERIFY_ARE_EQUAL(L"cmd", settings2._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings2._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"ThisProfileIsGood", settings2._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotDuplicate", settings2._profiles.at(3)._name);
VERIFY_ARE_EQUAL(L"NeitherShouldThisOne", settings2._profiles.at(4)._name);
@@ -1149,7 +1181,7 @@ namespace TerminalAppLocalTests
VERIFY_ARE_EQUAL(L"ThisProfileShouldNotDuplicate", settings._profiles.at(1)._name);
VERIFY_ARE_EQUAL(L"NeitherShouldThisOne", settings._profiles.at(2)._name);
VERIFY_ARE_EQUAL(L"Windows PowerShell", settings._profiles.at(3)._name);
VERIFY_ARE_EQUAL(L"cmd", settings._profiles.at(4)._name);
VERIFY_ARE_EQUAL(L"Command Prompt", settings._profiles.at(4)._name);
}
void SettingsTests::TestHideAllProfiles()
@@ -1318,11 +1350,11 @@ namespace TerminalAppLocalTests
settings._ParseJsonString(settings0String, false);
settings.LayerJson(settings._userSettings);
VERIFY_ARE_EQUAL(guid0, settings.FindGuid(name0));
VERIFY_ARE_EQUAL(guid1, settings.FindGuid(name1));
VERIFY_ARE_EQUAL(guid2, settings.FindGuid(name2));
VERIFY_ARE_EQUAL(badGuid, settings.FindGuid(name3));
VERIFY_ARE_EQUAL(badGuid, settings.FindGuid(badName));
VERIFY_ARE_EQUAL(guid0, settings._GetProfileGuidByName(name0));
VERIFY_ARE_EQUAL(guid1, settings._GetProfileGuidByName(name1));
VERIFY_ARE_EQUAL(guid2, settings._GetProfileGuidByName(name2));
VERIFY_ARE_EQUAL(badGuid, settings._GetProfileGuidByName(name3));
VERIFY_ARE_EQUAL(badGuid, settings._GetProfileGuidByName(badName));
auto prof0{ settings.FindProfile(guid0) };
auto prof1{ settings.FindProfile(guid1) };
@@ -1475,8 +1507,7 @@ namespace TerminalAppLocalTests
})" };
VerifyParseSucceeded(settings0String);
const auto guid1 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}");
const auto guid2 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-2222-49a3-80bd-e8fdd045185c}");
const auto guid1String = L"{6239a42c-1111-49a3-80bd-e8fdd045185c}";
{
CascadiaSettings settings{ false };
@@ -1486,7 +1517,7 @@ namespace TerminalAppLocalTests
VERIFY_IS_FALSE(settings._userDefaultProfileSettings == Json::Value::null);
settings.LayerJson(settings._userSettings);
VERIFY_ARE_EQUAL(guid1, settings._globals._defaultProfile);
VERIFY_ARE_EQUAL(guid1String, settings._globals._unparsedDefaultProfile);
VERIFY_ARE_EQUAL(2u, settings._profiles.size());
VERIFY_ARE_EQUAL(2345, settings._profiles.at(0)._historySize);
@@ -1522,7 +1553,8 @@ namespace TerminalAppLocalTests
})" };
VerifyParseSucceeded(settings0String);
const auto guid1 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}");
const auto guid1String = L"{6239a42c-1111-49a3-80bd-e8fdd045185c}";
const auto guid1 = Microsoft::Console::Utils::GuidFromString(guid1String);
const auto guid2 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-2222-49a3-80bd-e8fdd045185c}");
{
@@ -1543,7 +1575,7 @@ namespace TerminalAppLocalTests
settings.LayerJson(settings._userSettings);
VERIFY_ARE_EQUAL(guid1, settings._globals._defaultProfile);
VERIFY_ARE_EQUAL(guid1String, settings._globals._unparsedDefaultProfile);
VERIFY_ARE_EQUAL(4u, settings._profiles.size());
VERIFY_ARE_EQUAL(guid1, settings._profiles.at(2)._guid);
@@ -2036,6 +2068,7 @@ namespace TerminalAppLocalTests
})" };
const auto settingsJsonObj = VerifyParseSucceeded(settingsString);
auto settings = CascadiaSettings::FromJson(settingsJsonObj);
settings->_ResolveDefaultProfile();
const auto guid1 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-1111-49a3-80bd-e8fdd045185c}");
const auto guid2 = Microsoft::Console::Utils::GuidFromString(L"{6239a42c-2222-49a3-80bd-e8fdd045185c}");
@@ -2105,7 +2138,7 @@ namespace TerminalAppLocalTests
VERIFY_ARE_EQUAL(2u, settings->_warnings.size());
VERIFY_ARE_EQUAL(2u, settings->_profiles.size());
VERIFY_ARE_EQUAL(settings->_globals.GetDefaultProfile(), settings->_profiles.at(0).GetGuid());
VERIFY_ARE_EQUAL(settings->_globals.DefaultProfile(), settings->_profiles.at(0).GetGuid());
try
{
const auto [guid, termSettings] = settings->BuildSettings(nullptr);
@@ -2263,4 +2296,39 @@ namespace TerminalAppLocalTests
VERIFY_ARE_EQUAL(1u, settings._warnings.size());
VERIFY_ARE_EQUAL(::TerminalApp::SettingsLoadWarnings::LegacyGlobalsProperty, settings._warnings.at(0));
}
void SettingsTests::TestTrailingCommas()
{
const std::string badSettings{ R"(
{
"defaultProfile": "{6239a42c-2222-49a3-80bd-e8fdd045185c}",
"profiles": [
{
"name" : "profile0",
"guid": "{6239a42c-2222-49a3-80bd-e8fdd045185c}"
},
{
"name" : "profile1",
"guid": "{6239a42c-3333-49a3-80bd-e8fdd045185c}"
},
],
"keybindings": [],
})" };
// Create the default settings
CascadiaSettings settings;
settings._ParseJsonString(DefaultJson, true);
settings.LayerJson(settings._defaultSettings);
// Now layer on the user's settings
try
{
settings._ParseJsonString(badSettings, false);
settings.LayerJson(settings._userSettings);
}
catch (...)
{
VERIFY_IS_TRUE(false, L"This call to LayerJson should succeed, even with the trailing comma");
}
}
}

View File

@@ -60,6 +60,7 @@
<ClCompile Include="ProfileTests.cpp" />
<ClCompile Include="ColorSchemeTests.cpp" />
<ClCompile Include="KeyBindingsTests.cpp" />
<ClCompile Include="CommandTests.cpp" />
<ClCompile Include="TabTests.cpp" />
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
@@ -114,11 +115,11 @@
<!-- From Microsoft.UI.Xaml.targets -->
<Native-Platform Condition="'$(Platform)' == 'Win32'">x86</Native-Platform>
<Native-Platform Condition="'$(Platform)' != 'Win32'">$(Platform)</Native-Platform>
<_MUXBinRoot>&quot;$(OpenConsoleDir)packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\runtimes\win10-$(Native-Platform)\native\&quot;</_MUXBinRoot>
<_MUXBinRoot>&quot;$(OpenConsoleDir)packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\runtimes\win10-$(Native-Platform)\native\&quot;</_MUXBinRoot>
</PropertyGroup>
<!-- We actually can just straight up reference MUX here, it's fine -->
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets')" />
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets')" />
<Import Project="..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.0.0\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets" Condition="Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.0.0\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" />
</Project>

View File

@@ -121,29 +121,29 @@
</Reference>
</ItemGroup>
<Import Project="$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.3.191217003-prerelease\build\native\Microsoft.UI.Xaml.targets')" />
<!-- Use this to auto-find all the dll's that TerminalConnection produces. We
don't roll these up automatically, so we'll need to copy them manually
(below)
The dependencies from TerminalConnection get rolled up in the
GetPackagingOutputs step, when it produces the "appx recipe". This means
they only show up when the build produces an AppX\ folder for either running
or packaging.
It is literally impossible to produce an AppX\ folder using MSBuild without
packaging an appx, and we don't want to do that anyway, so we use these copy
rules instead.
-->
<ItemGroup>
<TerminalConnectionDlls Include="$(_CppWinrtBinRoot)\TerminalConnection\*.dll"/>
</ItemGroup>
<Import Project="$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.4.2-prerelease.200604001\build\native\Microsoft.UI.Xaml.targets')" />
<Import Project="$(OpenConsoleDir)\src\common.build.post.props" />
<Target Name="AfterBuild">
<!-- Use this to auto-find all the dll's that TerminalConnection produces. We
don't roll these up automatically, so we'll need to copy them manually
(below)
The dependencies from TerminalConnection get rolled up in the
GetPackagingOutputs step, when it produces the "appx recipe". This means
they only show up when the build produces an AppX\ folder for either running
or packaging.
It is literally impossible to produce an AppX\ folder using MSBuild without
packaging an appx, and we don't want to do that anyway, so we use these copy
rules instead.
-->
<ItemGroup>
<TerminalConnectionDlls Include="$(_CppWinrtBinRoot)\TerminalConnection\*.dll"/>
</ItemGroup>
<!-- Copy the AppxManifest.xml to another file, because when TAEF is
deploying the app, it'll delete the AppxManifest.xml file from this
directory when it tries to clean up after itself. -->

View File

@@ -29,6 +29,7 @@ LRESULT CALLBACK HwndTerminal::HwndTerminalWndProc(
UINT uMsg,
WPARAM wParam,
LPARAM lParam) noexcept
try
{
#pragma warning(suppress : 26490) // Win32 APIs can only store void*, have to use reinterpret_cast
HwndTerminal* terminal = reinterpret_cast<HwndTerminal*>(GetWindowLongPtr(hwnd, GWLP_USERDATA));
@@ -84,6 +85,11 @@ LRESULT CALLBACK HwndTerminal::HwndTerminalWndProc(
}
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
catch (...)
{
LOG_CAUGHT_EXCEPTION();
return 0;
}
static bool RegisterTermClass(HINSTANCE hInstance) noexcept
{
@@ -555,11 +561,11 @@ catch (...)
return false;
}
void HwndTerminal::_SendKeyEvent(WORD vkey, WORD scanCode) noexcept
void HwndTerminal::_SendKeyEvent(WORD vkey, WORD scanCode, bool keyDown) noexcept
try
{
const auto flags = getControlKeyState();
_terminal->SendKeyEvent(vkey, scanCode, flags);
_terminal->SendKeyEvent(vkey, scanCode, flags, keyDown);
}
CATCH_LOG();
@@ -588,10 +594,10 @@ try
}
CATCH_LOG();
void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode)
void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode, bool keyDown)
{
const auto publicTerminal = static_cast<HwndTerminal*>(terminal);
publicTerminal->_SendKeyEvent(vkey, scanCode);
publicTerminal->_SendKeyEvent(vkey, scanCode, keyDown);
}
void _stdcall TerminalSendCharEvent(void* terminal, wchar_t ch, WORD scanCode)
@@ -686,6 +692,7 @@ void __stdcall TerminalKillFocus(void* terminal)
// - rows - Rows of text data to copy
// - fAlsoCopyFormatting - true if the color and formatting should also be copied, false otherwise
HRESULT HwndTerminal::_CopyTextToSystemClipboard(const TextBuffer::TextAndColor& rows, bool const fAlsoCopyFormatting)
try
{
std::wstring finalString;
@@ -714,7 +721,7 @@ HRESULT HwndTerminal::_CopyTextToSystemClipboard(const TextBuffer::TextAndColor&
RETURN_LAST_ERROR_IF(!OpenClipboard(_hwnd.get()));
{ // Clipboard Scope
auto clipboardCloser = wil::scope_exit([]() noexcept {
auto clipboardCloser = wil::scope_exit([]() {
LOG_LAST_ERROR_IF(!CloseClipboard());
});
@@ -742,6 +749,7 @@ HRESULT HwndTerminal::_CopyTextToSystemClipboard(const TextBuffer::TextAndColor&
return S_OK;
}
CATCH_RETURN()
// Routine Description:
// - Copies the given string onto the global system clipboard in the specified format

View File

@@ -34,7 +34,7 @@ __declspec(dllexport) bool _stdcall TerminalIsSelectionActive(void* terminal);
__declspec(dllexport) void _stdcall DestroyTerminal(void* terminal);
__declspec(dllexport) void _stdcall TerminalSetTheme(void* terminal, TerminalTheme theme, LPCWSTR fontFamily, short fontSize, int newDpi);
__declspec(dllexport) void _stdcall TerminalRegisterWriteCallback(void* terminal, const void __stdcall callback(wchar_t*));
__declspec(dllexport) void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode);
__declspec(dllexport) void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode, bool keyDown);
__declspec(dllexport) void _stdcall TerminalSendCharEvent(void* terminal, wchar_t ch, WORD scanCode);
__declspec(dllexport) void _stdcall TerminalBlinkCursor(void* terminal);
__declspec(dllexport) void _stdcall TerminalSetCursorVisible(void* terminal, const bool visible);
@@ -92,7 +92,7 @@ private:
friend void _stdcall TerminalClearSelection(void* terminal);
friend const wchar_t* _stdcall TerminalGetSelection(void* terminal);
friend bool _stdcall TerminalIsSelectionActive(void* terminal);
friend void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode);
friend void _stdcall TerminalSendKeyEvent(void* terminal, WORD vkey, WORD scanCode, bool keyDown);
friend void _stdcall TerminalSendCharEvent(void* terminal, wchar_t ch, WORD scanCode);
friend void _stdcall TerminalSetTheme(void* terminal, TerminalTheme theme, LPCWSTR fontFamily, short fontSize, int newDpi);
friend void _stdcall TerminalBlinkCursor(void* terminal);
@@ -115,7 +115,7 @@ private:
bool _CanSendVTMouseInput() const noexcept;
bool _SendMouseEvent(UINT uMsg, WPARAM wParam, LPARAM lParam) noexcept;
void _SendKeyEvent(WORD vkey, WORD scanCode) noexcept;
void _SendKeyEvent(WORD vkey, WORD scanCode, bool keyDown) noexcept;
void _SendCharEvent(wchar_t ch, WORD scanCode) noexcept;
// Inherited via IControlAccessibilityInfo

View File

@@ -0,0 +1,211 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "OpenTerminalHere.h"
// TODO GH#6112: Localize these strings
static constexpr std::wstring_view VerbDisplayName{ L"Open in Windows Terminal" };
static constexpr std::wstring_view VerbDevBuildDisplayName{ L"Open in Windows Terminal (Dev Build)" };
static constexpr std::wstring_view VerbName{ L"WindowsTerminalOpenHere" };
static constexpr std::wstring_view WtExe{ L"wt.exe" };
static constexpr std::wstring_view WtdExe{ L"wtd.exe" };
static constexpr std::wstring_view WindowsTerminalExe{ L"WindowsTerminal.exe" };
static constexpr std::wstring_view LocalAppDataAppsPath{ L"%LOCALAPPDATA%\\Microsoft\\WindowsApps\\" };
// This code is aggressively copied from
// https://github.com/microsoft/Windows-classic-samples/blob/master/Samples/
// Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb/ExplorerCommandVerb.cpp
// Function Description:
// - This is a helper to determine if we're running as a part of the Dev Build
// Package or the release package. We'll need to return different text, icons,
// and use different commandlines depending on which one the user requested.
// - Uses a C++11 "magic static" to make sure this is only computed once.
// - If we can't determine if it's the dev build or not, we'll default to true
// Arguments:
// - <none>
// Return Value:
// - true if we believe this extension is being run in the dev build package.
static bool IsDevBuild()
{
// use C++11 magic statics to make sure we only do this once.
static bool isDevBuild = []() -> bool {
try
{
const auto package{ winrt::Windows::ApplicationModel::Package::Current() };
const auto id = package.Id();
const std::wstring name{ id.FullName() };
// Does our PFN start with WindowsTerminalDev?
return name.rfind(L"WindowsTerminalDev", 0) == 0;
}
CATCH_LOG();
return true;
}();
return isDevBuild;
}
// Function Description:
// - Helper function for getting the path to the appropriate executable to use
// for this instance of the shell extension. If we're running the dev build,
// it should be a `wtd.exe`, but if we're preview or release, we want to make
// sure to get the correct `wt.exe` that corresponds to _us_.
// - If we're unpackaged, this needs to get us `WindowsTerminal.exe`, because
// the `wt*exe` alias won't have been installed for this install.
// Arguments:
// - <none>
// Return Value:
// - the full path to the exe, one of `wt.exe`, `wtd.exe`, or `WindowsTerminal.exe`.
static std::wstring _getExePath()
{
// use C++11 magic statics to make sure we only do this once.
static const std::wstring exePath = []() -> std::wstring {
// First, check a packaged location for the exe. If we've got a package
// family name, that means we're one of the packaged Dev build, packaged
// Release build, or packaged Preview build.
//
// If we're the preview or release build, there's no way of knowing if the
// `wt.exe` on the %PATH% is us or not. Fortunately, _our_ execution alias
// is located in "%LOCALAPPDATA%\Microsoft\WindowsApps\<our package family
// name>", _always_, so we can use that to look up the exe easier.
try
{
const auto package{ winrt::Windows::ApplicationModel::Package::Current() };
const auto id = package.Id();
const std::wstring pfn{ id.FamilyName() };
if (!pfn.empty())
{
const std::filesystem::path windowsAppsPath{ wil::ExpandEnvironmentStringsW<std::wstring>(LocalAppDataAppsPath.data()) };
const std::filesystem::path wtPath = windowsAppsPath / pfn / (IsDevBuild() ? WtdExe : WtExe);
return wtPath;
}
}
CATCH_LOG();
// If we're here, then we couldn't resolve our exe from the package. This
// means we're running unpackaged. We should just use the
// WindowsTerminal.exe that's sitting in the directory next to us.
try
{
HMODULE hModule = GetModuleHandle(nullptr);
THROW_LAST_ERROR_IF(hModule == nullptr);
std::wstring dllPathString;
THROW_IF_FAILED(wil::GetModuleFileNameW(hModule, dllPathString));
const std::filesystem::path dllPath{ dllPathString };
const std::filesystem::path rootDir = dllPath.parent_path();
std::filesystem::path wtPath = rootDir / WindowsTerminalExe;
return wtPath;
}
CATCH_LOG();
return L"wt.exe";
}();
return exePath;
}
// Method Description:
// - This method is called when the user activates the context menu item. We'll
// launch the Terminal using the current working directory.
// Arguments:
// - psiItemArray: a IShellItemArray which contains the item that's selected.
// Return Value:
// - S_OK if we successfully attempted to launch the Terminal, otherwise a
// failure from an earlier HRESULT.
HRESULT OpenTerminalHere::Invoke(IShellItemArray* psiItemArray,
IBindCtx* /*pBindContext*/)
{
DWORD count;
psiItemArray->GetCount(&count);
winrt::com_ptr<IShellItem> psi;
RETURN_IF_FAILED(psiItemArray->GetItemAt(0, psi.put()));
wil::unique_cotaskmem_string pszName;
RETURN_IF_FAILED(psi->GetDisplayName(SIGDN_FILESYSPATH, &pszName));
{
wil::unique_process_information _piClient;
STARTUPINFOEX siEx{ 0 };
siEx.StartupInfo.cb = sizeof(STARTUPINFOEX);
// Append a "\." to the given path, so that this will work in "C:\"
std::wstring cmdline = fmt::format(L"\"{}\" -d \"{}\\.\"", _getExePath(), pszName.get());
RETURN_IF_WIN32_BOOL_FALSE(CreateProcessW(
nullptr,
cmdline.data(),
nullptr, // lpProcessAttributes
nullptr, // lpThreadAttributes
false, // bInheritHandles
EXTENDED_STARTUPINFO_PRESENT | CREATE_UNICODE_ENVIRONMENT, // dwCreationFlags
nullptr, // lpEnvironment
nullptr,
&siEx.StartupInfo, // lpStartupInfo
&_piClient // lpProcessInformation
));
}
return S_OK;
}
HRESULT OpenTerminalHere::GetToolTip(IShellItemArray* /*psiItemArray*/,
LPWSTR* ppszInfoTip)
{
// tooltip provided here, in this case none is provided
*ppszInfoTip = nullptr;
return E_NOTIMPL;
}
HRESULT OpenTerminalHere::GetTitle(IShellItemArray* /*psiItemArray*/,
LPWSTR* ppszName)
{
// Change the string we return depending on if we're running from the dev
// build package or not.
const bool isDevBuild = IsDevBuild();
return SHStrDup(isDevBuild ? VerbDevBuildDisplayName.data() : VerbDisplayName.data(), ppszName);
}
HRESULT OpenTerminalHere::GetState(IShellItemArray* /*psiItemArray*/,
BOOL /*fOkToBeSlow*/,
EXPCMDSTATE* pCmdState)
{
// compute the visibility of the verb here, respect "fOkToBeSlow" if this is
// slow (does IO for example) when called with fOkToBeSlow == FALSE return
// E_PENDING and this object will be called back on a background thread with
// fOkToBeSlow == TRUE
// We however don't need to bother with any of that, so we'll just return
// ECS_ENABLED.
*pCmdState = ECS_ENABLED;
return S_OK;
}
HRESULT OpenTerminalHere::GetIcon(IShellItemArray* /*psiItemArray*/,
LPWSTR* ppszIcon)
{
// the icon ref ("dll,-<resid>") is provided here, in this case none is provided
*ppszIcon = nullptr;
// TODO GH#6111: Return the Terminal icon here
return E_NOTIMPL;
}
HRESULT OpenTerminalHere::GetFlags(EXPCMDFLAGS* pFlags)
{
*pFlags = ECF_DEFAULT;
return S_OK;
}
HRESULT OpenTerminalHere::GetCanonicalName(GUID* pguidCommandName)
{
*pguidCommandName = __uuidof(this);
return S_OK;
}
HRESULT OpenTerminalHere::EnumSubCommands(IEnumExplorerCommand** ppEnum)
{
*ppEnum = nullptr;
return E_NOTIMPL;
}

View File

@@ -0,0 +1,51 @@
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- OpenTerminalHere.h
Abstract:
- This is the class that implements our Explorer Context Menu item. By
implementing IExplorerCommand, we can provide an entry to the context menu to
allow the user to open the Terminal in the current working directory.
- Importantly, we need to make sure to declare the GUID of this implementation
class explicitly, so we can refer to it in our manifest, and use it to create
instances of this class when the shell asks for one.
- This is defined as a WRL type, so that we can use WRL's CoCreatableClass magic
to create the class factory and module management for us. See more details in
dllmain.cpp.
Author(s):
- Mike Griese - May 2020
--*/
#pragma once
#include <conattrs.hpp>
#include "../../cascadia/inc/cppwinrt_utils.h"
using namespace Microsoft::WRL;
struct __declspec(uuid("9f156763-7844-4dc4-b2b1-901f640f5155"))
OpenTerminalHere : public RuntimeClass<RuntimeClassFlags<ClassicCom | InhibitFtmBase>, IExplorerCommand>
{
#pragma region IExplorerCommand
STDMETHODIMP Invoke(IShellItemArray* psiItemArray,
IBindCtx* pBindContext);
STDMETHODIMP GetToolTip(IShellItemArray* psiItemArray,
LPWSTR* ppszInfoTip);
STDMETHODIMP GetTitle(IShellItemArray* psiItemArray,
LPWSTR* ppszName);
STDMETHODIMP GetState(IShellItemArray* psiItemArray,
BOOL fOkToBeSlow,
EXPCMDSTATE* pCmdState);
STDMETHODIMP GetIcon(IShellItemArray* psiItemArray,
LPWSTR* ppszIcon);
STDMETHODIMP GetFlags(EXPCMDFLAGS* pFlags);
STDMETHODIMP GetCanonicalName(GUID* pguidCommandName);
STDMETHODIMP EnumSubCommands(IEnumExplorerCommand** ppEnum);
#pragma endregion
};
CoCreatableClass(OpenTerminalHere);

View File

@@ -0,0 +1,10 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "PlaceholderType.h"
#include "PlaceholderType.g.cpp"
namespace winrt::Microsoft::Terminal::ShellExtension::implementation
{
}

View File

@@ -0,0 +1,37 @@
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- PlaceholderType.h
Abstract:
- This class is just here to make our .wapproj play nicely with this project. If
we don't define any winrt types, then we won't generate a .winmd, and the
.wapproj will become _very_ mad at this project. So we'll use this placeholder
class just to trick cppwinrt into generating a winmd for us. If we ever _do_
add a real winrt type to this project, this can be removed.
Author(s):
- Mike Griese - May 2020
--*/
#pragma once
#include <conattrs.hpp>
#include "PlaceholderType.g.h"
#include "../../cascadia/inc/cppwinrt_utils.h"
namespace winrt::Microsoft::Terminal::ShellExtension::implementation
{
struct PlaceholderType : PlaceholderTypeT<PlaceholderType>
{
PlaceholderType() = default;
GETSET_PROPERTY(int32_t, Placeholder, 42);
};
}
namespace winrt::Microsoft::Terminal::ShellExtension::factory_implementation
{
BASIC_FACTORY(PlaceholderType);
}

View File

@@ -0,0 +1,21 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
// This class is just here to make our .wapproj play nicely with this project.
// If we don't define any winrt types, then we won't generate a .winmd, and the
// .wapproj will become _very_ mad at this project. So we'll use this
// placeholder class just to trick cppwinrt into generating a winmd for us. If
// we ever _do_ add a real winrt type to this project, this can be removed.
namespace Microsoft.Terminal.ShellExtension
{
[default_interface] runtimeclass PlaceholderType {
PlaceholderType();
Int32 Placeholder
{
get;
set;
};
};
}

View File

@@ -1,3 +1,4 @@
EXPORTS
DllCanUnloadNow = WINRT_CanUnloadNow PRIVATE
DllGetActivationFactory = WINRT_GetActivationFactory PRIVATE
DllGetClassObject PRIVATE

View File

@@ -0,0 +1,68 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Globals">
<ProjectGuid>{f2ed628a-db22-446f-a081-4cc845b51a2b}</ProjectGuid>
<ProjectName>WindowsTerminalShellExt</ProjectName>
<RootNamespace>Microsoft.Terminal.ShellExtension</RootNamespace>
<!-- cppwinrt.build.pre.props depends on these settings: -->
<!-- build a dll, not exe (Application) -->
<ConfigurationType>DynamicLibrary</ConfigurationType>
<SubSystem>Console</SubSystem>
<!-- sets a bunch of Windows Universal properties -->
<OpenConsoleUniversalApp>true</OpenConsoleUniversalApp>
<!--
DON'T REDIRECT OUR OUTPUT.
Setting this will tell cppwinrt.build.post.props to copy our output from
the default OutDir up one level, so the wapproj will be able to find it.
-->
<NoOutputRedirection>true</NoOutputRedirection>
</PropertyGroup>
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
<ItemGroup>
<ClInclude Include="pch.h" />
<ClInclude Include="OpenTerminalHere.h" />
<ClInclude Include="PlaceholderType.h">
<DependentUpon>PlaceholderType.idl</DependentUpon>
</ClInclude>
</ItemGroup>
<ItemGroup>
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
<ClCompile Include="PlaceholderType.cpp">
<DependentUpon>PlaceholderType.idl</DependentUpon>
</ClCompile>
<ClCompile Include="OpenTerminalHere.cpp" />
<ClCompile Include="dllmain.cpp" />
<ClCompile Include="$(GeneratedFilesDir)module.g.cpp" />
</ItemGroup>
<ItemGroup>
<Midl Include="PlaceholderType.idl" />
</ItemGroup>
<ItemGroup>
<None Include="packages.config" />
<None Include="WindowsTerminalShellExt.def" />
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup>
<!--
the packaging project won't recurse through our dependencies, you have to
make sure that if you add a cppwinrt dependency to any of these projects,
you also update all the consumers
-->
<ProjectReference Include="$(OpenConsoleDir)src\types\lib\types.vcxproj">
<Project>{18D09A24-8240-42D6-8CB6-236EEE820263}</Project>
</ProjectReference>
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\WinRTUtils\WinRTUtils.vcxproj">
<Project>{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.post.props" />
</Project>

View File

@@ -0,0 +1,33 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "OpenTerminalHere.h"
// For reference, see:
// * https://docs.microsoft.com/en-us/cpp/cppcx/wrl/how-to-create-a-classic-com-component-using-wrl?view=vs-2019
// * https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/move-to-winrt-from-wrl#porting-a-wrl-module-microsoftwrlmodule
//
// We don't need to implement DllGetActivationFactory or DllCanUnloadNow
// manually, since the generated module.g.cpp will handle it for us, and will
// handle our WRL types appropriately.
//
// We DO need to implement DllGetClassObject, because that's what explorer.exe
// will call to attempt to create a class factory for our shell extension. The
// CoCreatableClass macro in OpenTerminalHere.h will create the factory for us,
// so that the GetClassObject call will work like magic.
STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, _COM_Outptr_ void** ppv)
{
return Microsoft::WRL::Module<Microsoft::WRL::InProc>::GetModule().GetClassObject(rclsid, riid, ppv);
}
STDAPI_(BOOL)
DllMain(_In_opt_ HINSTANCE hinst, DWORD reason, _In_opt_ void*)
{
if (reason == DLL_PROCESS_ATTACH)
{
DisableThreadLibraryCalls(hinst);
}
return TRUE;
}

View File

@@ -1,5 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Microsoft.UI.Xaml" version="2.3.191217003-prerelease" targetFramework="native" />
<package id="Microsoft.Windows.CppWinRT" version="2.0.200316.3" targetFramework="native" />
</packages>
</packages>

View File

@@ -0,0 +1,30 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
//
// pch.h
// Header for platform projection include files
//
#pragma once
#define WIN32_LEAN_AND_MEAN
#include <LibraryIncludes.h>
// This is inexplicable, but for whatever reason, cppwinrt conflicts with the
// SDK definition of this function, so the only fix is to undef it.
// from WinBase.h
// Windows::UI::Xaml::Media::Animation::IStoryboard::GetCurrentTime
#ifdef GetCurrentTime
#undef GetCurrentTime
#endif
#include <unknwn.h>
#include <wil/cppwinrt.h>
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.ApplicationModel.h>
#include <Shobjidl.h>
#include <shlwapi.h>
#include <wrl.h>
#include <wrl\module.h>

View File

@@ -1,11 +1,245 @@
#include "pch.h"
#include "ActionArgs.h"
#include "ActionAndArgs.h"
#include "ActionAndArgs.g.cpp"
// We define everything necessary for the ActionAndArgs class in the header, but
// we still need this file to compile the ActionAndArgs.g.cpp file, and we can't
// just include that file in the header.
static constexpr std::string_view ActionKey{ "action" };
// This key is reserved to remove a keybinding, instead of mapping it to an action.
static constexpr std::string_view UnboundKey{ "unbound" };
static constexpr std::string_view CopyTextKey{ "copy" };
static constexpr std::string_view PasteTextKey{ "paste" };
static constexpr std::string_view OpenNewTabDropdownKey{ "openNewTabDropdown" };
static constexpr std::string_view DuplicateTabKey{ "duplicateTab" };
static constexpr std::string_view NewTabKey{ "newTab" };
static constexpr std::string_view NewWindowKey{ "newWindow" };
static constexpr std::string_view CloseWindowKey{ "closeWindow" };
static constexpr std::string_view CloseTabKey{ "closeTab" };
static constexpr std::string_view ClosePaneKey{ "closePane" };
static constexpr std::string_view SwitchtoTabKey{ "switchToTab" };
static constexpr std::string_view NextTabKey{ "nextTab" };
static constexpr std::string_view PrevTabKey{ "prevTab" };
static constexpr std::string_view AdjustFontSizeKey{ "adjustFontSize" };
static constexpr std::string_view ResetFontSizeKey{ "resetFontSize" };
static constexpr std::string_view ScrollupKey{ "scrollUp" };
static constexpr std::string_view ScrolldownKey{ "scrollDown" };
static constexpr std::string_view ScrolluppageKey{ "scrollUpPage" };
static constexpr std::string_view ScrolldownpageKey{ "scrollDownPage" };
static constexpr std::string_view SwitchToTabKey{ "switchToTab" };
static constexpr std::string_view OpenSettingsKey{ "openSettings" }; // TODO GH#2557: Add args for OpenSettings
static constexpr std::string_view SplitPaneKey{ "splitPane" };
static constexpr std::string_view ResizePaneKey{ "resizePane" };
static constexpr std::string_view MoveFocusKey{ "moveFocus" };
static constexpr std::string_view FindKey{ "find" };
static constexpr std::string_view ToggleFullscreenKey{ "toggleFullscreen" };
static constexpr std::string_view ActionKey{ "action" };
// This key is reserved to remove a keybinding, instead of mapping it to an action.
static constexpr std::string_view UnboundKey{ "unbound" };
static constexpr std::string_view CopyTextKey{ "copy" };
static constexpr std::string_view PasteTextKey{ "paste" };
static constexpr std::string_view OpenNewTabDropdownKey{ "openNewTabDropdown" };
static constexpr std::string_view DuplicateTabKey{ "duplicateTab" };
static constexpr std::string_view NewTabKey{ "newTab" };
static constexpr std::string_view NewWindowKey{ "newWindow" };
static constexpr std::string_view CloseWindowKey{ "closeWindow" };
static constexpr std::string_view CloseTabKey{ "closeTab" };
static constexpr std::string_view ClosePaneKey{ "closePane" };
static constexpr std::string_view SwitchtoTabKey{ "switchToTab" };
static constexpr std::string_view NextTabKey{ "nextTab" };
static constexpr std::string_view PrevTabKey{ "prevTab" };
static constexpr std::string_view AdjustFontSizeKey{ "adjustFontSize" };
static constexpr std::string_view ResetFontSizeKey{ "resetFontSize" };
static constexpr std::string_view ScrollupKey{ "scrollUp" };
static constexpr std::string_view ScrolldownKey{ "scrollDown" };
static constexpr std::string_view ScrolluppageKey{ "scrollUpPage" };
static constexpr std::string_view ScrolldownpageKey{ "scrollDownPage" };
static constexpr std::string_view SwitchToTabKey{ "switchToTab" };
static constexpr std::string_view OpenSettingsKey{ "openSettings" }; // TODO GH#2557: Add args for OpenSettings
static constexpr std::string_view SplitPaneKey{ "splitPane" };
static constexpr std::string_view ResizePaneKey{ "resizePane" };
static constexpr std::string_view MoveFocusKey{ "moveFocus" };
static constexpr std::string_view FindKey{ "find" };
static constexpr std::string_view ToggleFullscreenKey{ "toggleFullscreen" };
static constexpr std::string_view ToggleCommandPaletteKey{ "toggleCommandPalette" };
namespace winrt::TerminalApp::implementation
{
// Specifically use a map here over an unordered_map. We want to be able to
// iterate over these entries in-order when we're serializing the keybindings.
// HERE BE DRAGONS:
// These are string_views that are being used as keys. These string_views are
// just pointers to other strings. This could be dangerous, if the map outlived
// the actual strings being pointed to. However, since both these strings and
// the map are all const for the lifetime of the app, we have nothing to worry
// about here.
const std::map<std::string_view, ShortcutAction, std::less<>> ActionAndArgs::ActionNamesMap{
{ CopyTextKey, ShortcutAction::CopyText },
{ PasteTextKey, ShortcutAction::PasteText },
{ OpenNewTabDropdownKey, ShortcutAction::OpenNewTabDropdown },
{ DuplicateTabKey, ShortcutAction::DuplicateTab },
{ NewTabKey, ShortcutAction::NewTab },
{ NewWindowKey, ShortcutAction::NewWindow },
{ CloseWindowKey, ShortcutAction::CloseWindow },
{ CloseTabKey, ShortcutAction::CloseTab },
{ ClosePaneKey, ShortcutAction::ClosePane },
{ NextTabKey, ShortcutAction::NextTab },
{ PrevTabKey, ShortcutAction::PrevTab },
{ AdjustFontSizeKey, ShortcutAction::AdjustFontSize },
{ ResetFontSizeKey, ShortcutAction::ResetFontSize },
{ ScrollupKey, ShortcutAction::ScrollUp },
{ ScrolldownKey, ShortcutAction::ScrollDown },
{ ScrolluppageKey, ShortcutAction::ScrollUpPage },
{ ScrolldownpageKey, ShortcutAction::ScrollDownPage },
{ SwitchToTabKey, ShortcutAction::SwitchToTab },
{ ResizePaneKey, ShortcutAction::ResizePane },
{ MoveFocusKey, ShortcutAction::MoveFocus },
{ OpenSettingsKey, ShortcutAction::OpenSettings },
{ ToggleFullscreenKey, ShortcutAction::ToggleFullscreen },
{ SplitPaneKey, ShortcutAction::SplitPane },
{ UnboundKey, ShortcutAction::Invalid },
{ FindKey, ShortcutAction::Find },
{ ToggleCommandPaletteKey, ShortcutAction::ToggleCommandPalette },
};
using ParseResult = std::tuple<IActionArgs, std::vector<::TerminalApp::SettingsLoadWarnings>>;
using ParseActionFunction = std::function<ParseResult(const Json::Value&)>;
// This is a map of ShortcutAction->function<IActionArgs(Json::Value)>. It holds
// a set of deserializer functions that can be used to deserialize a IActionArgs
// from json. Each type of IActionArgs that can accept arbitrary args should be
// placed into this map, with the corresponding deserializer function as the
// value.
static const std::map<ShortcutAction, ParseActionFunction, std::less<>> argParsers{
{ ShortcutAction::CopyText, winrt::TerminalApp::implementation::CopyTextArgs::FromJson },
{ ShortcutAction::NewTab, winrt::TerminalApp::implementation::NewTabArgs::FromJson },
{ ShortcutAction::SwitchToTab, winrt::TerminalApp::implementation::SwitchToTabArgs::FromJson },
{ ShortcutAction::ResizePane, winrt::TerminalApp::implementation::ResizePaneArgs::FromJson },
{ ShortcutAction::MoveFocus, winrt::TerminalApp::implementation::MoveFocusArgs::FromJson },
{ ShortcutAction::AdjustFontSize, winrt::TerminalApp::implementation::AdjustFontSizeArgs::FromJson },
{ ShortcutAction::SplitPane, winrt::TerminalApp::implementation::SplitPaneArgs::FromJson },
{ ShortcutAction::OpenSettings, winrt::TerminalApp::implementation::OpenSettingsArgs::FromJson },
{ ShortcutAction::Invalid, nullptr },
};
// Function Description:
// - Attempts to match a string to a ShortcutAction. If there's no match, then
// returns ShortcutAction::Invalid
// Arguments:
// - actionString: the string to match to a ShortcutAction
// Return Value:
// - The ShortcutAction corresponding to the given string, if a match exists.
static ShortcutAction GetActionFromString(const std::string_view actionString)
{
// Try matching the command to one we have. If we can't find the
// action name in our list of names, let's just unbind that key.
const auto found = ActionAndArgs::ActionNamesMap.find(actionString);
return found != ActionAndArgs::ActionNamesMap.end() ? found->second : ShortcutAction::Invalid;
}
// Method Description:
// - Deserialize an ActionAndArgs from the provided json object or string `json`.
// * If json is a string, we'll attempt to treat it as an action name,
// without arguments.
// * If json is an object, we'll attempt to retrieve the action name from
// its "action" property, and we'll use that name to fine a deserializer
// to precess the rest of the arguments in the json object.
// - If the action name is null or "unbound", or we don't understand the
// action name, or we failed to parse the arguments to this action, we'll
// return null. This should indicate to the caller that the action should
// be unbound.
// - If there were any warnings while parsing arguments for the action,
// they'll be appended to the warnings parameter.
// Arguments:
// - json: The Json::Value to attempt to parse as an ActionAndArgs
// - warnings: If there were any warnings during parsing, they'll be
// appended to this vector.
// Return Value:
// - a deserialized ActionAndArgs corresponding to the values in json, or
// null if we failed to deserialize an action.
winrt::com_ptr<ActionAndArgs> ActionAndArgs::FromJson(const Json::Value& json,
std::vector<::TerminalApp::SettingsLoadWarnings>& warnings)
{
// Invalid is our placeholder that the action was not parsed.
ShortcutAction action = ShortcutAction::Invalid;
// Actions can be serialized in two styles:
// "action": "switchToTab0",
// "action": { "action": "switchToTab", "index": 0 },
// NOTE: For keybindings, the "action" param is actually "command"
// 1. In the first case, the json is a string, that's the
// action name. There are no provided args, so we'll pass
// Json::Value::null to the parse function.
// 2. In the second case, the json is an object. We'll use the
// "action" in that object as the action name. We'll then pass
// the json object to the arg parser, for further parsing.
auto argsVal = Json::Value::null;
// Only try to parse the action if it's actually a string value.
// `null` will not pass this check.
if (json.isString())
{
auto commandString = json.asString();
action = GetActionFromString(commandString);
}
else if (json.isObject())
{
const auto actionVal = json[JsonKey(ActionKey)];
if (actionVal.isString())
{
auto actionString = actionVal.asString();
action = GetActionFromString(actionString);
argsVal = json;
}
}
// Some keybindings can accept other arbitrary arguments. If it
// does, we'll try to deserialize any "args" that were provided with
// the binding.
IActionArgs args{ nullptr };
std::vector<::TerminalApp::SettingsLoadWarnings> parseWarnings;
const auto deserializersIter = argParsers.find(action);
if (deserializersIter != argParsers.end())
{
auto pfn = deserializersIter->second;
if (pfn)
{
std::tie(args, parseWarnings) = pfn(argsVal);
}
warnings.insert(warnings.end(), parseWarnings.begin(), parseWarnings.end());
// if an arg parser was registered, but failed, bail
if (pfn && args == nullptr)
{
return nullptr;
}
}
if (action != ShortcutAction::Invalid)
{
auto actionAndArgs = winrt::make_self<ActionAndArgs>();
actionAndArgs->Action(action);
actionAndArgs->Args(args);
return actionAndArgs;
}
else
{
return nullptr;
}
}
}

View File

@@ -1,12 +1,18 @@
#pragma once
#include "ActionAndArgs.g.h"
#include "TerminalWarnings.h"
#include "..\inc\cppwinrt_utils.h"
namespace winrt::TerminalApp::implementation
{
struct ActionAndArgs : public ActionAndArgsT<ActionAndArgs>
{
static const std::map<std::string_view, ShortcutAction, std::less<>> ActionNamesMap;
static winrt::com_ptr<ActionAndArgs> FromJson(const Json::Value& json,
std::vector<::TerminalApp::SettingsLoadWarnings>& warnings);
ActionAndArgs() = default;
GETSET_PROPERTY(TerminalApp::ShortcutAction, Action, TerminalApp::ShortcutAction::Invalid);
GETSET_PROPERTY(IActionArgs, Args, nullptr);
};

View File

@@ -14,3 +14,4 @@
#include "MoveFocusArgs.g.cpp"
#include "AdjustFontSizeArgs.g.cpp"
#include "SplitPaneArgs.g.cpp"
#include "OpenSettingsArgs.g.cpp"

View File

@@ -14,6 +14,7 @@
#include "MoveFocusArgs.g.h"
#include "AdjustFontSizeArgs.g.h"
#include "SplitPaneArgs.g.h"
#include "OpenSettingsArgs.g.h"
#include "../../cascadia/inc/cppwinrt_utils.h"
#include "Utils.h"
@@ -360,7 +361,8 @@ namespace winrt::TerminalApp::implementation
if (otherAsUs)
{
return otherAsUs->_SplitStyle == _SplitStyle &&
otherAsUs->_TerminalArgs == _TerminalArgs &&
(otherAsUs->_TerminalArgs ? otherAsUs->_TerminalArgs.Equals(_TerminalArgs) :
otherAsUs->_TerminalArgs == _TerminalArgs) &&
otherAsUs->_SplitMode == _SplitMode;
}
return false;
@@ -381,6 +383,65 @@ namespace winrt::TerminalApp::implementation
return { *args, {} };
}
};
// Possible SettingsTarget values
// TODO:GH#2550/#3475 - move these to a centralized deserializing place
static constexpr std::string_view SettingsFileString{ "settingsFile" };
static constexpr std::string_view DefaultsFileString{ "defaultsFile" };
static constexpr std::string_view AllFilesString{ "allFiles" };
// Function Description:
// - Helper function for parsing a SettingsTarget from a string
// Arguments:
// - targetString: the string to attempt to parse
// Return Value:
// - The encoded SettingsTarget value, or SettingsTarget::SettingsFile if it was an invalid string
static TerminalApp::SettingsTarget ParseSettingsTarget(const std::string& targetString)
{
if (targetString == SettingsFileString)
{
return TerminalApp::SettingsTarget::SettingsFile;
}
else if (targetString == DefaultsFileString)
{
return TerminalApp::SettingsTarget::DefaultsFile;
}
else if (targetString == AllFilesString)
{
return TerminalApp::SettingsTarget::AllFiles;
}
// default behavior for invalid data
return TerminalApp::SettingsTarget::SettingsFile;
};
struct OpenSettingsArgs : public OpenSettingsArgsT<OpenSettingsArgs>
{
OpenSettingsArgs() = default;
GETSET_PROPERTY(TerminalApp::SettingsTarget, Target, TerminalApp::SettingsTarget::SettingsFile);
static constexpr std::string_view TargetKey{ "target" };
public:
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>();
if (auto targetString{ json[JsonKey(TargetKey)] })
{
args->_Target = ParseSettingsTarget(targetString.asString());
}
return { *args, {} };
}
};
}
namespace winrt::TerminalApp::factory_implementation

View File

@@ -37,6 +37,13 @@ namespace TerminalApp
Duplicate = 1
};
enum SettingsTarget
{
SettingsFile = 0,
DefaultsFile,
AllFiles
};
[default_interface] runtimeclass NewTerminalArgs {
NewTerminalArgs();
String Commandline;
@@ -90,4 +97,9 @@ namespace TerminalApp
NewTerminalArgs TerminalArgs { get; };
SplitType SplitMode { get; };
};
[default_interface] runtimeclass OpenSettingsArgs : IActionArgs
{
SettingsTarget Target { get; };
};
}

View File

@@ -6,7 +6,6 @@
#include "App.g.cpp"
using namespace winrt;
using namespace winrt::Windows::ApplicationModel;
using namespace winrt::Windows::ApplicationModel::Activation;
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::UI::Xaml;

View File

@@ -120,9 +120,11 @@ namespace winrt::TerminalApp::implementation
void TerminalPage::_HandleOpenSettings(const IInspectable& /*sender*/,
const TerminalApp::ActionEventArgs& args)
{
// TODO:GH#2557 Add an optional arg for opening the defaults here
_LaunchSettings(false);
args.Handled(true);
if (const auto& realArgs = args.ActionArgs().try_as<TerminalApp::OpenSettingsArgs>())
{
_LaunchSettings(realArgs.Target());
args.Handled(true);
}
}
void TerminalPage::_HandlePasteText(const IInspectable& /*sender*/,
@@ -232,7 +234,14 @@ namespace winrt::TerminalApp::implementation
void TerminalPage::_HandleToggleFullscreen(const IInspectable& /*sender*/,
const TerminalApp::ActionEventArgs& args)
{
_ToggleFullscreen();
ToggleFullscreen();
args.Handled(true);
}
void TerminalPage::_HandleToggleCommandPalette(const IInspectable& /*sender*/,
const TerminalApp::ActionEventArgs& args)
{
CommandPalette().ToggleVisibility();
args.Handled(true);
}
}

View File

@@ -157,6 +157,7 @@ int AppCommandlineArgs::_handleExit(const CLI::App& command, const CLI::Error& e
// - <none>
void AppCommandlineArgs::_buildParser()
{
// -v,--version: Displays version info
auto versionCallback = [this](int64_t /*count*/) {
if (const auto appLogic{ winrt::TerminalApp::implementation::AppLogic::Current() })
{
@@ -173,6 +174,20 @@ void AppCommandlineArgs::_buildParser()
};
_app.add_flag_function("-v,--version", versionCallback, RS_A(L"CmdVersionDesc"));
// Maximized and Fullscreen flags
// -M,--maximized: Maximizes the window on launch
// -F,--fullscreen: Fullscreens the window on launch
auto maximizedCallback = [this](int64_t /*count*/) {
_launchMode = winrt::TerminalApp::LaunchMode::MaximizedMode;
};
auto fullscreenCallback = [this](int64_t /*count*/) {
_launchMode = winrt::TerminalApp::LaunchMode::FullscreenMode;
};
auto maximized = _app.add_flag_function("-M,--maximized", maximizedCallback, RS_A(L"CmdMaximizedDesc"));
auto fullscreen = _app.add_flag_function("-F,--fullscreen", fullscreenCallback, RS_A(L"CmdFullscreenDesc"));
maximized->excludes(fullscreen);
// Subcommands
_buildNewTabParser();
_buildSplitPaneParser();
_buildFocusTabParser();
@@ -315,6 +330,9 @@ void AppCommandlineArgs::_addNewTerminalArgs(AppCommandlineArgs::NewTerminalSubc
subcommand.startingDirectoryOption = subcommand.subcommand->add_option("-d,--startingDirectory",
_startingDirectory,
RS_A(L"CmdStartingDirArgDesc"));
subcommand.titleOption = subcommand.subcommand->add_option("--title",
_startingTitle,
RS_A(L"CmdTitleArgDesc"));
// Using positionals_at_end allows us to support "wt new-tab -d wsl -d Ubuntu"
// without CLI11 thinking that we've specified -d twice.
@@ -372,6 +390,11 @@ NewTerminalArgs AppCommandlineArgs::_getNewTerminalArgs(AppCommandlineArgs::NewT
args->StartingDirectory(winrt::to_hstring(_startingDirectory));
}
if (*subcommand.titleOption)
{
args->TabTitle(winrt::to_hstring(_startingTitle));
}
return *args;
}
@@ -402,6 +425,7 @@ void AppCommandlineArgs::_resetStateToDefault()
{
_profileName.clear();
_startingDirectory.clear();
_startingTitle.clear();
_commandline.clear();
_splitVertical = false;
@@ -410,6 +434,10 @@ void AppCommandlineArgs::_resetStateToDefault()
_focusTabIndex = -1;
_focusNextTab = false;
_focusPrevTab = false;
// DON'T clear _launchMode here! This will get called once for every
// subcommand, so we don't want `wt -F new-tab ; split-pane` clearing out
// the "global" fullscreen flag (-F).
}
// Function Description:
@@ -604,3 +632,8 @@ void AppCommandlineArgs::ValidateStartupCommands()
_startupActions.push_front(*newTabAction);
}
}
std::optional<winrt::TerminalApp::LaunchMode> AppCommandlineArgs::GetLaunchMode() const noexcept
{
return _launchMode;
}

View File

@@ -38,6 +38,8 @@ public:
const std::string& GetExitMessage();
bool ShouldExitEarly() const noexcept;
std::optional<winrt::TerminalApp::LaunchMode> GetLaunchMode() const noexcept;
private:
static const std::wregex _commandDelimiterRegex;
@@ -51,6 +53,7 @@ private:
CLI::Option* commandlineOption;
CLI::Option* profileNameOption;
CLI::Option* startingDirectoryOption;
CLI::Option* titleOption;
};
// --- Subcommands ---
@@ -64,6 +67,7 @@ private:
std::string _profileName;
std::string _startingDirectory;
std::string _startingTitle;
// _commandline will contain the command line with which we'll be spawning a new terminal
std::vector<std::string> _commandline;
@@ -76,6 +80,8 @@ private:
int _focusTabIndex{ -1 };
bool _focusNextTab{ false };
bool _focusPrevTab{ false };
std::optional<winrt::TerminalApp::LaunchMode> _launchMode{ std::nullopt };
// Are you adding more args here? Make sure to reset them in _resetStateToDefault
std::deque<winrt::TerminalApp::ActionAndArgs> _startupActions;

View File

@@ -55,8 +55,12 @@ namespace winrt::TerminalApp::implementation
{
for (auto& kv : _keyShortcuts)
{
if (kv.second.Action() == actionAndArgs.Action() &&
kv.second.Args().Equals(actionAndArgs.Args()))
auto action = kv.second.Action();
auto args = kv.second.Args();
auto actionMatched = action == actionAndArgs.Action();
auto argsMatched = args ? args.Equals(actionAndArgs.Args()) : args == actionAndArgs.Args();
if (actionMatched &&
argsMatched)
{
return kv.first;
}

View File

@@ -21,97 +21,6 @@ static constexpr std::string_view KeysKey{ "keys" };
static constexpr std::string_view CommandKey{ "command" };
static constexpr std::string_view ActionKey{ "action" };
// This key is reserved to remove a keybinding, instead of mapping it to an action.
static constexpr std::string_view UnboundKey{ "unbound" };
static constexpr std::string_view CopyTextKey{ "copy" };
static constexpr std::string_view PasteTextKey{ "paste" };
static constexpr std::string_view OpenNewTabDropdownKey{ "openNewTabDropdown" };
static constexpr std::string_view DuplicateTabKey{ "duplicateTab" };
static constexpr std::string_view NewTabKey{ "newTab" };
static constexpr std::string_view NewWindowKey{ "newWindow" };
static constexpr std::string_view CloseWindowKey{ "closeWindow" };
static constexpr std::string_view CloseTabKey{ "closeTab" };
static constexpr std::string_view ClosePaneKey{ "closePane" };
static constexpr std::string_view SwitchtoTabKey{ "switchToTab" };
static constexpr std::string_view NextTabKey{ "nextTab" };
static constexpr std::string_view PrevTabKey{ "prevTab" };
static constexpr std::string_view AdjustFontSizeKey{ "adjustFontSize" };
static constexpr std::string_view ResetFontSizeKey{ "resetFontSize" };
static constexpr std::string_view ScrollupKey{ "scrollUp" };
static constexpr std::string_view ScrolldownKey{ "scrollDown" };
static constexpr std::string_view ScrolluppageKey{ "scrollUpPage" };
static constexpr std::string_view ScrolldownpageKey{ "scrollDownPage" };
static constexpr std::string_view SwitchToTabKey{ "switchToTab" };
static constexpr std::string_view OpenSettingsKey{ "openSettings" }; // TODO GH#2557: Add args for OpenSettings
static constexpr std::string_view SplitPaneKey{ "splitPane" };
static constexpr std::string_view ResizePaneKey{ "resizePane" };
static constexpr std::string_view MoveFocusKey{ "moveFocus" };
static constexpr std::string_view FindKey{ "find" };
static constexpr std::string_view ToggleFullscreenKey{ "toggleFullscreen" };
// Specifically use a map here over an unordered_map. We want to be able to
// iterate over these entries in-order when we're serializing the keybindings.
// HERE BE DRAGONS:
// These are string_views that are being used as keys. These string_views are
// just pointers to other strings. This could be dangerous, if the map outlived
// the actual strings being pointed to. However, since both these strings and
// the map are all const for the lifetime of the app, we have nothing to worry
// about here.
static const std::map<std::string_view, ShortcutAction, std::less<>> commandNames{
{ CopyTextKey, ShortcutAction::CopyText },
{ PasteTextKey, ShortcutAction::PasteText },
{ OpenNewTabDropdownKey, ShortcutAction::OpenNewTabDropdown },
{ DuplicateTabKey, ShortcutAction::DuplicateTab },
{ NewTabKey, ShortcutAction::NewTab },
{ NewWindowKey, ShortcutAction::NewWindow },
{ CloseWindowKey, ShortcutAction::CloseWindow },
{ CloseTabKey, ShortcutAction::CloseTab },
{ ClosePaneKey, ShortcutAction::ClosePane },
{ NextTabKey, ShortcutAction::NextTab },
{ PrevTabKey, ShortcutAction::PrevTab },
{ AdjustFontSizeKey, ShortcutAction::AdjustFontSize },
{ ResetFontSizeKey, ShortcutAction::ResetFontSize },
{ ScrollupKey, ShortcutAction::ScrollUp },
{ ScrolldownKey, ShortcutAction::ScrollDown },
{ ScrolluppageKey, ShortcutAction::ScrollUpPage },
{ ScrolldownpageKey, ShortcutAction::ScrollDownPage },
{ SwitchToTabKey, ShortcutAction::SwitchToTab },
{ ResizePaneKey, ShortcutAction::ResizePane },
{ MoveFocusKey, ShortcutAction::MoveFocus },
{ OpenSettingsKey, ShortcutAction::OpenSettings },
{ ToggleFullscreenKey, ShortcutAction::ToggleFullscreen },
{ SplitPaneKey, ShortcutAction::SplitPane },
{ UnboundKey, ShortcutAction::Invalid },
{ FindKey, ShortcutAction::Find },
};
using ParseResult = std::tuple<IActionArgs, std::vector<TerminalApp::SettingsLoadWarnings>>;
using ParseActionFunction = std::function<ParseResult(const Json::Value&)>;
// This is a map of ShortcutAction->function<IActionArgs(Json::Value)>. It holds
// a set of deserializer functions that can be used to deserialize a IActionArgs
// from json. Each type of IActionArgs that can accept arbitrary args should be
// placed into this map, with the corresponding deserializer function as the
// value.
static const std::map<ShortcutAction, ParseActionFunction, std::less<>> argParsers{
{ ShortcutAction::CopyText, winrt::TerminalApp::implementation::CopyTextArgs::FromJson },
{ ShortcutAction::NewTab, winrt::TerminalApp::implementation::NewTabArgs::FromJson },
{ ShortcutAction::SwitchToTab, winrt::TerminalApp::implementation::SwitchToTabArgs::FromJson },
{ ShortcutAction::ResizePane, winrt::TerminalApp::implementation::ResizePaneArgs::FromJson },
{ ShortcutAction::MoveFocus, winrt::TerminalApp::implementation::MoveFocusArgs::FromJson },
{ ShortcutAction::AdjustFontSize, winrt::TerminalApp::implementation::AdjustFontSizeArgs::FromJson },
{ ShortcutAction::SplitPane, winrt::TerminalApp::implementation::SplitPaneArgs::FromJson },
{ ShortcutAction::Invalid, nullptr },
};
// Function Description:
// - Small helper to create a json value serialization of a single
// KeyBinding->Action mapping.
@@ -155,7 +64,7 @@ Json::Value winrt::TerminalApp::implementation::AppKeyBindings::ToJson()
// Iterate over all the possible actions in the names list, and see if
// it has a binding.
for (auto& actionName : commandNames)
for (auto& actionName : ActionAndArgs::ActionNamesMap)
{
const auto searchedForName = actionName.first;
const auto searchedForAction = actionName.second;
@@ -172,34 +81,19 @@ Json::Value winrt::TerminalApp::implementation::AppKeyBindings::ToJson()
return bindingsArray;
}
// Function Description:
// - Attempts to match a string to a ShortcutAction. If there's no match, then
// returns ShortcutAction::Invalid
// Arguments:
// - actionString: the string to match to a ShortcutAction
// Return Value:
// - The ShortcutAction corresponding to the given string, if a match exists.
static ShortcutAction GetActionFromString(const std::string_view actionString)
{
// Try matching the command to one we have. If we can't find the
// action name in our list of names, let's just unbind that key.
const auto found = commandNames.find(actionString);
return found != commandNames.end() ? found->second : ShortcutAction::Invalid;
}
// Method Description:
// - Deserialize an AppKeyBindings from the key mappings that are in the array
// `json`. The json array should contain an array of objects with both a
// `command` string and a `keys` array, where `command` is one of the names
// listed in `commandNames`, and `keys` is an array of keypresses. Currently,
// the array should contain a single string, which can be deserialized into a
// KeyChord.
// listed in `ActionAndArgs::ActionNamesMap`, and `keys` is an array of
// keypresses. Currently, the array should contain a single string, which can
// be deserialized into a KeyChord.
// - Applies the deserialized keybindings to the provided `bindings` object. If
// a key chord in `json` is already bound to an action, that chord will be
// overwritten with the new action. If a chord is bound to `null` or
// `"unbound"`, then we'll clear the keybinding from the existing keybindings.
// Arguments:
// - json: and array of JsonObject's to deserialize into our _keyShortcuts mapping.
// - json: an array of Json::Value's to deserialize into our _keyShortcuts mapping.
std::vector<::TerminalApp::SettingsLoadWarnings> winrt::TerminalApp::implementation::AppKeyBindings::LayerJson(const Json::Value& json)
{
// It's possible that the user provided keybindings have some warnings in
@@ -236,61 +130,10 @@ std::vector<::TerminalApp::SettingsLoadWarnings> winrt::TerminalApp::implementat
continue;
}
const auto keyChordString = keys.isString() ? winrt::to_hstring(keys.asString()) : winrt::to_hstring(keys[0].asString());
// Invalid is our placeholder that the action was not parsed.
ShortcutAction action = ShortcutAction::Invalid;
// Keybindings can be serialized in two styles:
// { "command": "switchToTab0", "keys": ["ctrl+1"] },
// { "command": { "action": "switchToTab", "index": 0 }, "keys": ["ctrl+alt+1"] },
// 1. In the first case, the "command" is a string, that's the
// action name. There are no provided args, so we'll pass
// Json::Value::null to the parse function.
// 2. In the second case, the "command" is an object. We'll use the
// "action" in that object as the action name. We'll then pass
// the "command" object to the arg parser, for further parsing.
auto argsVal = Json::Value::null;
// Only try to parse the action if it's actually a string value.
// `null` will not pass this check.
if (commandVal.isString())
{
auto commandString = commandVal.asString();
action = GetActionFromString(commandString);
}
else if (commandVal.isObject())
{
const auto actionVal = commandVal[JsonKey(ActionKey)];
if (actionVal.isString())
{
auto actionString = actionVal.asString();
action = GetActionFromString(actionString);
argsVal = commandVal;
}
}
// Some keybindings can accept other arbitrary arguments. If it
// does, we'll try to deserialize any "args" that were provided with
// the binding.
IActionArgs args{ nullptr };
std::vector<::TerminalApp::SettingsLoadWarnings> parseWarnings;
const auto deserializersIter = argParsers.find(action);
if (deserializersIter != argParsers.end())
{
auto pfn = deserializersIter->second;
if (pfn)
{
std::tie(args, parseWarnings) = pfn(argsVal);
}
warnings.insert(warnings.end(), parseWarnings.begin(), parseWarnings.end());
// if an arg parser was registered, but failed, bail
if (pfn && args == nullptr)
{
continue;
}
}
// If the action was null, "unbound", or something we didn't
// understand, this will return nullptr.
auto actionAndArgs = ActionAndArgs::FromJson(commandVal, warnings);
// Try parsing the chord
try
@@ -301,11 +144,8 @@ std::vector<::TerminalApp::SettingsLoadWarnings> winrt::TerminalApp::implementat
// or the action was `null` or `"unbound"`, just clear out the
// keybinding. Otherwise, set the keybinding to the action we
// found.
if (action != ShortcutAction::Invalid)
if (actionAndArgs)
{
auto actionAndArgs = winrt::make_self<ActionAndArgs>();
actionAndArgs->Action(action);
actionAndArgs->Args(args);
SetKeyBinding(*actionAndArgs, chord);
}
else

View File

@@ -8,6 +8,7 @@
#include <LibraryResources.h>
using namespace winrt::Windows::ApplicationModel;
using namespace winrt::Windows::ApplicationModel::DataTransfer;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::UI::Core;
@@ -23,6 +24,7 @@ namespace winrt
using IInspectable = Windows::Foundation::IInspectable;
}
static const winrt::hstring StartupTaskName = L"StartTerminalOnLoginTask";
// clang-format off
// !!! IMPORTANT !!!
// Make sure that these keys are in the same order as the
@@ -235,20 +237,32 @@ namespace winrt::TerminalApp::implementation
// so this setting is overridden to false no matter what the preference is.
if (_isUwp)
{
_settings->GlobalSettings().SetShowTabsInTitlebar(false);
_settings->GlobalSettings().ShowTabsInTitlebar(false);
}
_root->SetSettings(_settings, false);
_root->Loaded({ this, &AppLogic::_OnLoaded });
_root->Initialized([this](auto&&, auto&&) {
// GH#288 - When we finish initialization, if the user wanted us
// launched _fullscreen_, toggle fullscreen mode. This will make sure
// that the window size is _first_ set up as something sensible, so
// leaving fullscreen returns to a reasonable size.
const auto launchMode = this->GetLaunchMode();
if (launchMode == LaunchMode::FullscreenMode)
{
_root->ToggleFullscreen();
}
});
_root->Create();
_ApplyTheme(_settings->GlobalSettings().GetTheme());
_ApplyTheme(_settings->GlobalSettings().Theme());
_ApplyStartupTaskStateChange();
TraceLoggingWrite(
g_hTerminalAppProvider,
"AppCreated",
TraceLoggingDescription("Event emitted when the application is started"),
TraceLoggingBool(_settings->GlobalSettings().GetShowTabsInTitlebar(), "TabsInTitlebar"),
TraceLoggingBool(_settings->GlobalSettings().ShowTabsInTitlebar(), "TabsInTitlebar"),
TraceLoggingKeyword(MICROSOFT_KEYWORD_MEASURES),
TelemetryPrivacyDataTag(PDT_ProductAndServicePerformance));
}
@@ -294,7 +308,7 @@ namespace winrt::TerminalApp::implementation
// details here, but it does have the desired effect.
// It's not enough to set the theme on the dialog alone.
auto themingLambda{ [this](const Windows::Foundation::IInspectable& sender, const RoutedEventArgs&) {
auto theme{ _settings->GlobalSettings().GetTheme() };
auto theme{ _settings->GlobalSettings().Theme() };
auto element{ sender.try_as<winrt::Windows::UI::Xaml::FrameworkElement>() };
while (element)
{
@@ -476,7 +490,7 @@ namespace winrt::TerminalApp::implementation
// GH#2061 - If the global setting "Always show tab bar" is
// set or if "Show tabs in title bar" is set, then we'll need to add
// the height of the tab bar here.
if (_settings->GlobalSettings().GetShowTabsInTitlebar())
if (_settings->GlobalSettings().ShowTabsInTitlebar())
{
// If we're showing the tabs in the titlebar, we need to use a
// TitlebarControl here to calculate how much space to reserve.
@@ -490,7 +504,7 @@ namespace winrt::TerminalApp::implementation
titlebar.Measure({ SHRT_MAX, SHRT_MAX });
proposedSize.Y += (titlebar.DesiredSize().Height) * scale;
}
else if (_settings->GlobalSettings().GetAlwaysShowTabs())
else if (_settings->GlobalSettings().AlwaysShowTabs())
{
// Otherwise, let's use a TabRowControl to calculate how much extra
// space we'll need.
@@ -526,7 +540,13 @@ namespace winrt::TerminalApp::implementation
LoadSettings();
}
return _settings->GlobalSettings().GetLaunchMode();
// GH#4620/#5801 - If the user passed --maximized or --fullscreen on the
// commandline, then use that to override the value from the settings.
const auto valueFromSettings = _settings->GlobalSettings().LaunchMode();
const auto valueFromCommandlineArgs = _appArgs.GetLaunchMode();
return valueFromCommandlineArgs.has_value() ?
valueFromCommandlineArgs.value() :
valueFromSettings;
}
// Method Description:
@@ -547,18 +567,11 @@ namespace winrt::TerminalApp::implementation
LoadSettings();
}
winrt::Windows::Foundation::Point point((float)defaultInitialX, (float)defaultInitialY);
auto initialX = _settings->GlobalSettings().GetInitialX();
auto initialY = _settings->GlobalSettings().GetInitialY();
if (initialX.has_value())
{
point.X = gsl::narrow_cast<float>(initialX.value());
}
if (initialY.has_value())
{
point.Y = gsl::narrow_cast<float>(initialY.value());
}
const auto initialPosition{ _settings->GlobalSettings().InitialPosition() };
winrt::Windows::Foundation::Point point{
/* X */ gsl::narrow_cast<float>(initialPosition.x.value_or(defaultInitialX)),
/* Y */ gsl::narrow_cast<float>(initialPosition.y.value_or(defaultInitialY))
};
return point;
}
@@ -571,7 +584,7 @@ namespace winrt::TerminalApp::implementation
LoadSettings();
}
return _settings->GlobalSettings().GetTheme();
return _settings->GlobalSettings().Theme();
}
bool AppLogic::GetShowTabsInTitlebar()
@@ -582,7 +595,7 @@ namespace winrt::TerminalApp::implementation
LoadSettings();
}
return _settings->GlobalSettings().GetShowTabsInTitlebar();
return _settings->GlobalSettings().ShowTabsInTitlebar();
}
// Method Description:
@@ -752,9 +765,57 @@ namespace winrt::TerminalApp::implementation
co_await winrt::resume_foreground(_root->Dispatcher());
// Refresh the UI theme
_ApplyTheme(_settings->GlobalSettings().GetTheme());
_ApplyTheme(_settings->GlobalSettings().Theme());
}
fire_and_forget AppLogic::_ApplyStartupTaskStateChange()
try
{
// First, make sure we're running in a packaged context. This method
// won't work, and will crash mysteriously if we're running unpackaged.
const auto package{ winrt::Windows::ApplicationModel::Package::Current() };
if (package == nullptr)
{
return;
}
auto weakThis{ get_weak() };
co_await winrt::resume_foreground(_root->Dispatcher(), CoreDispatcherPriority::Normal);
if (auto page{ weakThis.get() })
{
StartupTaskState state;
bool tryEnableStartupTask = _settings->GlobalSettings().StartOnUserLogin();
StartupTask task = co_await StartupTask::GetAsync(StartupTaskName);
state = task.State();
switch (state)
{
case StartupTaskState::Disabled:
{
if (tryEnableStartupTask)
{
co_await task.RequestEnableAsync();
}
break;
}
case StartupTaskState::DisabledByUser:
{
// TODO: GH#6254: define UX for other StartupTaskStates
break;
}
case StartupTaskState::Enabled:
{
if (!tryEnableStartupTask)
{
task.Disable();
}
break;
}
}
}
}
CATCH_LOG();
// Method Description:
// - Reloads the settings from the profile.json.
void AppLogic::_ReloadSettings()
@@ -783,6 +844,7 @@ namespace winrt::TerminalApp::implementation
_root->SetSettings(_settings, true);
_RefreshThemeRoutine();
_ApplyStartupTaskStateChange();
}
// Method Description:
@@ -844,20 +906,21 @@ namespace winrt::TerminalApp::implementation
// Method Description:
// - Implements the F7 handler (per GH#638)
// - Implements the Alt handler (per GH#6421)
// Return value:
// - whether F7 was handled
bool AppLogic::OnF7Pressed()
// - whether the key was handled
bool AppLogic::OnDirectKeyEvent(const uint32_t vkey, const bool down)
{
if (_root)
{
// Manually bubble the OnF7Pressed event up through the focus tree.
// Manually bubble the OnDirectKeyEvent event up through the focus tree.
auto xamlRoot{ _root->XamlRoot() };
auto focusedObject{ Windows::UI::Xaml::Input::FocusManager::GetFocusedElement(xamlRoot) };
do
{
if (auto f7Listener{ focusedObject.try_as<IF7Listener>() })
if (auto keyListener{ focusedObject.try_as<IDirectKeyListener>() })
{
if (f7Listener.OnF7Pressed())
if (keyListener.OnDirectKeyEvent(vkey, down))
{
return true;
}
@@ -893,31 +956,108 @@ namespace winrt::TerminalApp::implementation
}
}
int32_t AppLogic::SetStartupCommandline(array_view<const winrt::hstring> actions)
// Method Description:
// - Sets the initial commandline to process on startup, and attempts to
// parse it. Commands will be parsed into a list of ShortcutActions that
// will be processed on TerminalPage::Create().
// - This function will have no effective result after Create() is called.
// - This function returns 0, unless a there was a non-zero result from
// trying to parse one of the commands provided. In that case, no commands
// after the failing command will be parsed, and the non-zero code
// returned.
// Arguments:
// - args: an array of strings to process as a commandline. These args can contain spaces
// Return Value:
// - the result of the first command who's parsing returned a non-zero code,
// or 0. (see AppLogic::_ParseArgs)
int32_t AppLogic::SetStartupCommandline(array_view<const winrt::hstring> args)
{
if (_root)
const auto result = _ParseArgs(args);
if (result == 0)
{
return _root->SetStartupCommandline(actions);
_appArgs.ValidateStartupCommands();
_root->SetStartupActions(_appArgs.GetStartupActions());
}
return result;
}
// Method Description:
// - Attempts to parse an array of commandline args into a list of
// commands to execute, and then parses these commands. As commands are
// successfully parsed, they will generate ShortcutActions for us to be
// able to execute. If we fail to parse any commands, we'll return the
// error code from the failure to parse that command, and stop processing
// additional commands.
// Arguments:
// - args: an array of strings to process as a commandline. These args can contain spaces
// Return Value:
// - 0 if the commandline was successfully parsed
int AppLogic::_ParseArgs(winrt::array_view<const hstring>& args)
{
auto commands = ::TerminalApp::AppCommandlineArgs::BuildCommands(args);
for (auto& cmdBlob : commands)
{
// On one hand, it seems like we should be able to have one
// AppCommandlineArgs for parsing all of them, and collect the
// results one at a time.
//
// On the other hand, re-using a CLI::App seems to leave state from
// previous parsings around, so we could get mysterious behavior
// where one command affects the values of the next.
//
// From https://cliutils.github.io/CLI11/book/chapters/options.html:
// > If that option is not given, CLI11 will not touch the initial
// > value. This allows you to set up defaults by simply setting
// > your value beforehand.
//
// So we pretty much need the to either manually reset the state
// each command, or build new ones.
const auto result = _appArgs.ParseCommand(cmdBlob);
// If this succeeded, result will be 0. Otherwise, the caller should
// exit(result), to exit the program.
if (result != 0)
{
return result;
}
}
// If all the args were successfully parsed, we'll have some commands
// built in _appArgs, which we'll use when the application starts up.
return 0;
}
// Method Description:
// - If there were any errors parsing the commandline that was used to
// initialize the terminal, this will return a string containing that
// message. If there were no errors, this message will be blank.
// - If the user requested help on any command (using --help), this will
// contain the help message.
// - If the user requested the version number (using --version), this will
// contain the version string.
// Arguments:
// - <none>
// Return Value:
// - the help text or error message for the provided commandline, if one
// exists, otherwise the empty string.
winrt::hstring AppLogic::ParseCommandlineMessage()
{
if (_root)
{
return _root->ParseCommandlineMessage();
}
return { L"" };
return winrt::to_hstring(_appArgs.GetExitMessage());
}
// Method Description:
// - Returns true if we should exit the application before even starting the
// window. We might want to do this if we're displaying an error message or
// the version string, or if we want to open the settings file.
// Arguments:
// - <none>
// Return Value:
// - true iff we should exit the application before even starting the window
bool AppLogic::ShouldExitEarly()
{
if (_root)
{
return _root->ShouldExitEarly();
}
return false;
return _appArgs.ShouldExitEarly();
}
winrt::hstring AppLogic::ApplicationDisplayName() const

View File

@@ -45,7 +45,7 @@ namespace winrt::TerminalApp::implementation
hstring Title();
void TitlebarClicked();
bool OnF7Pressed();
bool OnDirectKeyEvent(const uint32_t vkey, const bool down);
void WindowCloseButtonClicked();
@@ -76,6 +76,9 @@ namespace winrt::TerminalApp::implementation
std::atomic<bool> _settingsReloadQueued{ false };
::TerminalApp::AppCommandlineArgs _appArgs;
int _ParseArgs(winrt::array_view<const hstring>& args);
fire_and_forget _ShowDialog(const winrt::Windows::Foundation::IInspectable& sender, winrt::Windows::UI::Xaml::Controls::ContentDialog dialog);
void _ShowLoadErrorsDialog(const winrt::hstring& titleKey, const winrt::hstring& contentKey, HRESULT settingsLoadedResult);
void _ShowLoadWarningsDialog();
@@ -83,6 +86,7 @@ namespace winrt::TerminalApp::implementation
fire_and_forget _LoadErrorsDialogRoutine();
fire_and_forget _ShowLoadWarningsDialogRoutine();
fire_and_forget _RefreshThemeRoutine();
fire_and_forget _ApplyStartupTaskStateChange();
void _OnLoaded(const IInspectable& sender, const Windows::UI::Xaml::RoutedEventArgs& eventArgs);

View File

@@ -3,7 +3,7 @@
import "../TerminalPage.idl";
import "../ShortcutActionDispatch.idl";
import "../IF7Listener.idl";
import "../IDirectKeyListener.idl";
namespace TerminalApp
{
@@ -11,9 +11,10 @@ namespace TerminalApp
{
DefaultMode,
MaximizedMode,
FullscreenMode,
};
[default_interface] runtimeclass AppLogic : IF7Listener
[default_interface] runtimeclass AppLogic : IDirectKeyListener
{
AppLogic();

View File

@@ -63,34 +63,6 @@ CascadiaSettings::CascadiaSettings(const bool addDynamicProfiles)
}
}
// Method Description:
// - Finds a GUID associated with the given profile name. If no profile matches
// the profile name, returns a std::nullopt.
// Arguments:
// - profileName: the name of the profile's GUID to return.
// Return Value:
// - the GUID associated with the profile name.
std::optional<GUID> CascadiaSettings::FindGuid(const std::wstring_view profileName) const noexcept
{
std::optional<GUID> profileGuid{};
for (const auto& profile : _profiles)
{
if (profileName == profile.GetName())
{
try
{
profileGuid = profile.GetGuid();
}
CATCH_LOG();
break;
}
}
return profileGuid;
}
// Method Description:
// - Finds a profile that matches the given GUID. If there is no profile in this
// settings object that matches, returns nullptr.
@@ -191,6 +163,9 @@ void CascadiaSettings::_ValidateSettings()
// Then do some validation on the profiles. The order of these does not
// terribly matter.
_ValidateNoDuplicateProfiles();
// Resolve the default profile before we validate that it exists.
_ResolveDefaultProfile();
_ValidateDefaultProfileExists();
// Ensure that all the profile's color scheme names are
@@ -245,6 +220,17 @@ void CascadiaSettings::_ValidateProfilesHaveGuid()
}
}
// Method Description:
// - Resolves the "defaultProfile", which can be a profile name, to a GUID
// and stores it back to the globals.
void CascadiaSettings::_ResolveDefaultProfile()
{
const auto unparsedDefaultProfile{ GlobalSettings().UnparsedDefaultProfile() };
auto maybeParsedDefaultProfile{ _GetProfileGuidByName(unparsedDefaultProfile) };
auto defaultProfileGuid{ Utils::CoalesceOptionals(maybeParsedDefaultProfile, GUID{}) };
GlobalSettings().DefaultProfile(defaultProfileGuid);
}
// Method Description:
// - Checks if the "defaultProfile" is set to one of the profiles we
// actually have. If the value is unset, or the value is set to something that
@@ -254,7 +240,7 @@ void CascadiaSettings::_ValidateProfilesHaveGuid()
// warnings if we failed to find the default.
void CascadiaSettings::_ValidateDefaultProfileExists()
{
const auto defaultProfileGuid = GlobalSettings().GetDefaultProfile();
const auto defaultProfileGuid = GlobalSettings().DefaultProfile();
const bool nullDefaultProfile = defaultProfileGuid == GUID{};
bool defaultProfileNotInProfiles = true;
for (const auto& profile : _profiles)
@@ -273,7 +259,7 @@ void CascadiaSettings::_ValidateDefaultProfileExists()
// _temporarily_ set the default profile to the first profile. Because
// we're adding a warning, this settings change won't be re-serialized.
GlobalSettings().SetDefaultProfile(_profiles[0].GetGuid());
GlobalSettings().DefaultProfile(_profiles[0].GetGuid());
}
}
@@ -569,58 +555,66 @@ TerminalSettings CascadiaSettings::BuildSettings(GUID profileGuid) const
// - the GUID of the profile corresponding to this combination of index and NewTerminalArgs
GUID CascadiaSettings::_GetProfileForArgs(const NewTerminalArgs& newTerminalArgs) const
{
std::optional<int> profileIndex{ std::nullopt };
if (newTerminalArgs &&
newTerminalArgs.ProfileIndex() != nullptr)
{
profileIndex = newTerminalArgs.ProfileIndex().Value();
}
GUID profileGuid = _GetProfileForIndex(profileIndex);
std::optional<GUID> profileByIndex, profileByName;
if (newTerminalArgs)
{
const auto profileString = newTerminalArgs.Profile();
// First, try and parse the "profile" argument as a GUID. If it's a
// GUID, and the GUID of one of our profiles, then use that as the
// profile GUID instead. If it's not, then try looking it up as a
// name of a profile. If it's still not that, then just ignore it.
if (!profileString.empty())
if (newTerminalArgs.ProfileIndex() != nullptr)
{
bool wasGuid = false;
profileByIndex = _GetProfileGuidByIndex(newTerminalArgs.ProfileIndex().Value());
}
// Do a quick heuristic check - is the profile 38 chars long (the
// length of a GUID string), and does it start with '{'? Because if
// it doesn't, it's _definitely_ not a GUID.
if (profileString.size() == 38 && profileString[0] == L'{')
{
try
{
const auto newGUID = Utils::GuidFromString(profileString.c_str());
if (FindProfile(newGUID))
{
profileGuid = newGUID;
wasGuid = true;
}
}
CATCH_LOG();
}
profileByName = _GetProfileGuidByName(newTerminalArgs.Profile());
}
// Here, we were unable to use the profile string as a GUID to
// lookup a profile. Instead, try using the string to look the
// Profile up by name.
if (!wasGuid)
return Utils::CoalesceOptionals(profileByName, profileByIndex, _globals.DefaultProfile());
}
// Method Description:
// - Helper to get the GUID of a profile given a name that could be a guid or an actual name.
// Arguments:
// - name: a guid string _or_ the name of a profile
// Return Value:
// - the GUID of the profile corresponding to this name
std::optional<GUID> CascadiaSettings::_GetProfileGuidByName(const std::wstring_view name) const
try
{
// First, try and parse the "name" as a GUID. If it's a
// GUID, and the GUID of one of our profiles, then use that as the
// profile GUID instead. If it's not, then try looking it up as a
// name of a profile. If it's still not that, then just ignore it.
if (!name.empty())
{
// Do a quick heuristic check - is the profile 38 chars long (the
// length of a GUID string), and does it start with '{'? Because if
// it doesn't, it's _definitely_ not a GUID.
if (name.size() == 38 && name[0] == L'{')
{
const auto newGUID{ Utils::GuidFromString(static_cast<std::wstring>(name)) };
if (FindProfile(newGUID))
{
const auto guidFromName = FindGuid(profileString.c_str());
if (guidFromName.has_value())
{
profileGuid = guidFromName.value();
}
return newGUID;
}
}
// Here, we were unable to use the profile string as a GUID to
// lookup a profile. Instead, try using the string to look the
// Profile up by name.
const auto profileIterator{ std::find_if(_profiles.cbegin(), _profiles.cend(), [&](auto&& profile) {
return profile.GetName().compare(name) == 0;
}) };
if (profileIterator != _profiles.cend())
{
return profileIterator->GetGuid();
}
}
return profileGuid;
return std::nullopt;
}
catch (...)
{
LOG_CAUGHT_EXCEPTION();
return std::nullopt;
}
// Method Description:
@@ -633,27 +627,20 @@ GUID CascadiaSettings::_GetProfileForArgs(const NewTerminalArgs& newTerminalArgs
// If omitted, instead return the default profile's GUID
// Return Value:
// - the Nth profile's GUID, or the default profile's GUID
GUID CascadiaSettings::_GetProfileForIndex(std::optional<int> index) const
std::optional<GUID> CascadiaSettings::_GetProfileGuidByIndex(std::optional<int> index) const
{
GUID profileGuid;
if (index)
{
const auto realIndex = index.value();
const auto realIndex{ index.value() };
// If we don't have that many profiles, then do nothing.
if (realIndex < 0 ||
realIndex >= gsl::narrow_cast<decltype(realIndex)>(_profiles.size()))
if (realIndex >= 0 &&
realIndex < gsl::narrow_cast<decltype(realIndex)>(_profiles.size()))
{
return _globals.GetDefaultProfile();
const auto& selectedProfile = _profiles.at(realIndex);
return selectedProfile.GetGuid();
}
const auto& selectedProfile = _profiles.at(realIndex);
profileGuid = selectedProfile.GetGuid();
}
else
{
// get Guid for the default profile
profileGuid = _globals.GetDefaultProfile();
}
return profileGuid;
return std::nullopt;
}
// Method Description:
@@ -715,7 +702,7 @@ std::string CascadiaSettings::_ApplyFirstRunChangesToSettingsTemplate(std::strin
} };
std::wstring defaultProfileGuid{ DEFAULT_WINDOWS_POWERSHELL_GUID };
if (const auto psCoreProfileGuid{ FindGuid(PowershellCoreProfileGenerator::GetPreferredPowershellProfileName()) })
if (const auto psCoreProfileGuid{ _GetProfileGuidByName(PowershellCoreProfileGenerator::GetPreferredPowershellProfileName()) })
{
defaultProfileGuid = Utils::GuidToString(*psCoreProfileGuid);
}

View File

@@ -69,7 +69,6 @@ public:
static std::filesystem::path GetSettingsPath();
static std::filesystem::path GetDefaultSettingsPath();
std::optional<GUID> FindGuid(const std::wstring_view profileName) const noexcept;
const Profile* FindProfile(GUID profileGuid) const noexcept;
std::vector<TerminalApp::SettingsLoadWarnings>& GetWarnings();
@@ -106,7 +105,8 @@ private:
static std::optional<std::string> _ReadUserSettings();
static std::optional<std::string> _ReadFile(HANDLE hFile);
GUID _GetProfileForIndex(std::optional<int> index) const;
std::optional<GUID> _GetProfileGuidByName(const std::wstring_view) const;
std::optional<GUID> _GetProfileGuidByIndex(std::optional<int> index) const;
GUID _GetProfileForArgs(const winrt::TerminalApp::NewTerminalArgs& newTerminalArgs) const;
void _ValidateSettings();
@@ -114,6 +114,7 @@ private:
void _ValidateProfilesHaveGuid();
void _ValidateDefaultProfileExists();
void _ValidateNoDuplicateProfiles();
void _ResolveDefaultProfile();
void _ReorderProfilesToMatchUserSettingsOrder();
void _RemoveHiddenProfiles();
void _ValidateAllSchemesExist();

View File

@@ -61,7 +61,7 @@ std::unique_ptr<CascadiaSettings> CascadiaSettings::LoadAll()
// GH 3588, we need this below to know if the user chose something that wasn't our default.
// Collect it up here in case it gets modified by any of the other layers between now and when
// the user's preferences are loaded and layered.
const auto hardcodedDefaultGuid = resultPtr->GlobalSettings().GetDefaultProfile();
const auto hardcodedDefaultGuid = resultPtr->GlobalSettings().UnparsedDefaultProfile();
std::optional<std::string> fileData = _ReadUserSettings();
const bool foundFile = fileData.has_value();
@@ -141,11 +141,12 @@ std::unique_ptr<CascadiaSettings> CascadiaSettings::LoadAll()
// is a lot of computation we can skip if no one cares.
if (TraceLoggingProviderEnabled(g_hTerminalAppProvider, 0, MICROSOFT_KEYWORD_MEASURES))
{
auto guid = resultPtr->GlobalSettings().GetDefaultProfile();
const auto hardcodedDefaultGuidAsGuid = Utils::GuidFromString(hardcodedDefaultGuid);
const auto guid = resultPtr->GlobalSettings().DefaultProfile();
// Compare to the defaults.json one that we set on install.
// If it's different, log what the user chose.
if (hardcodedDefaultGuid != guid)
if (hardcodedDefaultGuidAsGuid != guid)
{
TraceLoggingWrite(
g_hTerminalAppProvider, // handle to TerminalApp tracelogging provider

View File

@@ -0,0 +1,9 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "Command.h"
#include "Command.g.cpp"
namespace winrt::TerminalApp::implementation
{
}

View File

@@ -0,0 +1,31 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#pragma once
#include "Command.g.h"
#include "TerminalWarnings.h"
#include "..\inc\cppwinrt_utils.h"
namespace winrt::TerminalApp::implementation
{
struct Command : CommandT<Command>
{
Command() = default;
static winrt::com_ptr<Command> FromJson(const Json::Value& json, std::vector<::TerminalApp::SettingsLoadWarnings>& warnings);
static std::vector<::TerminalApp::SettingsLoadWarnings> LayerJson(std::map<winrt::hstring, winrt::TerminalApp::Command>& commands,
const Json::Value& json);
WINRT_CALLBACK(PropertyChanged, Windows::UI::Xaml::Data::PropertyChangedEventHandler);
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, Name, _PropertyChangedHandlers);
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, IconPath, _PropertyChangedHandlers);
OBSERVABLE_GETSET_PROPERTY(winrt::TerminalApp::ActionAndArgs, Action, _PropertyChangedHandlers);
OBSERVABLE_GETSET_PROPERTY(winrt::hstring, KeyChordText, _PropertyChangedHandlers);
};
}
namespace winrt::TerminalApp::factory_implementation
{
BASIC_FACTORY(Command);
}

View File

@@ -0,0 +1,17 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
import "../ShortcutActionDispatch.idl";
namespace TerminalApp
{
[default_interface] runtimeclass Command : Windows.UI.Xaml.Data.INotifyPropertyChanged
{
Command();
String Name;
String IconPath;
ActionAndArgs Action;
String KeyChordText;
}
}

View File

@@ -0,0 +1,338 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "CommandPalette.h"
#include "CommandPalette.g.cpp"
using namespace winrt;
using namespace winrt::TerminalApp;
using namespace winrt::Windows::UI::Xaml;
using namespace winrt::Windows::System;
using namespace winrt::Windows::Foundation;
namespace winrt::TerminalApp::implementation
{
CommandPalette::CommandPalette()
{
InitializeComponent();
_filteredActions = winrt::single_threaded_observable_vector<winrt::TerminalApp::Command>();
_allActions = winrt::single_threaded_vector<winrt::TerminalApp::Command>();
if (CommandPaletteShadow())
{
// Hook up the shadow on the command palette to the backdrop that
// will actually show it. This needs to be done at runtime, and only
// if the shadow actually exists. ThemeShadow isn't supported below
// version 18362.
CommandPaletteShadow().Receivers().Append(ShadowBackdrop());
// "raise" the command palette up by 16 units, so it will cast a shadow.
Backdrop().Translation({ 0, 0, 16 });
}
}
// Method Description:
// - Toggles the visibility of the command palette. This will auto-focus the
// input box within the palette.
// - TODO GH#TODO: When we add support for commandline mode, accept a parameter here
// for which mode we should enter in.
void CommandPalette::ToggleVisibility()
{
const bool isVisible = Visibility() == Visibility::Visible;
if (!isVisible)
{
// Become visible
Visibility(Visibility::Visible);
_SearchBox().Focus(FocusState::Programmatic);
_FilteredActionsView().SelectedIndex(0);
}
else
{
// Raise an event to return control to the Terminal.
_close();
}
}
// Method Description:
// - Moves the focus up or down the list of commands. If we're att the top,
// we'll loop around to the bottom, and vice-versa.
// Arguments:
// - moveDown: if true, we're attempting to move to the next item in the
// list. Otherwise, we're attempting to move to the previous.
// Return Value:
// - <none>
void CommandPalette::_selectNextItem(const bool moveDown)
{
const auto selected = _FilteredActionsView().SelectedIndex();
const int numItems = ::base::saturated_cast<int>(_FilteredActionsView().Items().Size());
// Wraparound math. By adding numItems and then calculating modulo numItems,
// we clamp the values to the range [0, numItems) while still supporting moving
// upward from 0 to numItems - 1.
const auto newIndex = ((numItems + selected + (moveDown ? 1 : -1)) % numItems);
_FilteredActionsView().SelectedIndex(newIndex);
_FilteredActionsView().ScrollIntoView(_FilteredActionsView().SelectedItem());
}
// Method Description:
// - Process keystrokes in the input box. This is used for moving focus up
// and down the list of commands in Action mode, and for executing
// commands in both Action mode and Commandline mode.
// Arguments:
// - e: the KeyRoutedEventArgs containing info about the keystroke.
// Return Value:
// - <none>
void CommandPalette::_keyDownHandler(IInspectable const& /*sender*/,
Windows::UI::Xaml::Input::KeyRoutedEventArgs const& e)
{
auto key = e.OriginalKey();
if (key == VirtualKey::Up)
{
// Action Mode: Move focus to the next item in the list.
_selectNextItem(false);
e.Handled(true);
}
else if (key == VirtualKey::Down)
{
// Action Mode: Move focus to the previous item in the list.
_selectNextItem(true);
e.Handled(true);
}
else if (key == VirtualKey::Enter)
{
// Action Mode: Dispatch the action of the selected command.
if (const auto selectedItem = _FilteredActionsView().SelectedItem())
{
if (const auto data = selectedItem.try_as<Command>())
{
const auto actionAndArgs = data.Action();
_dispatch.DoAction(actionAndArgs);
_close();
}
}
e.Handled(true);
}
else if (key == VirtualKey::Escape)
{
// Action Mode: Dismiss the palette.
_close();
}
}
// Method Description:
// - Event handler for when the text in the input box changes. In Action
// Mode, we'll update the list of displayed commands, and select the first one.
// Arguments:
// - <unused>
// Return Value:
// - <none>
void CommandPalette::_filterTextChanged(IInspectable const& /*sender*/,
Windows::UI::Xaml::RoutedEventArgs const& /*args*/)
{
_updateFilteredActions();
_FilteredActionsView().SelectedIndex(0);
}
Collections::IObservableVector<Command> CommandPalette::FilteredActions()
{
return _filteredActions;
}
void CommandPalette::SetActions(Collections::IVector<TerminalApp::Command> const& actions)
{
_allActions = actions;
_updateFilteredActions();
}
// Method Description:
// - Update our list of filtered actions to reflect the current contents of
// the input box. For more details on which commands will be displayed,
// see `_filterMatchesName`.
// Arguments:
// - <none>
// Return Value:
// - <none>
void CommandPalette::_updateFilteredActions()
{
_filteredActions.Clear();
auto searchText = _SearchBox().Text();
const bool addAll = searchText.empty();
// If there's no filter text, then just add all the commands in order to the list.
if (addAll)
{
for (auto action : _allActions)
{
_filteredActions.Append(action);
}
return;
}
// Here, there was some filter text.
// Show these actions in a weighted order.
// - Matching the first character of a word, then the first char of a
// subsequent word seems better than just "the order they appear in
// the list".
// - TODO GH#TODO:"Recently used commands" ordering also seems valuable.
auto compare = [searchText](const Command& left, const Command& right) {
const int leftWeight = _getWeight(left.Name(), searchText);
const int rightWeight = _getWeight(right.Name(), searchText);
return leftWeight < rightWeight;
};
// Use a priority queue to order commands so that "better" matches
// appear first in the list. The ordering will be determined by the
// match weight produced by _getWeight.
std::priority_queue<Command, std::vector<Command>, decltype(compare)> heap(compare);
for (auto action : _allActions)
{
if (CommandPalette::_filterMatchesName(searchText, action.Name()))
{
heap.push(action);
}
}
// Remove everything in-order from the queue, and add to the list of
// filtered actions.
while (!heap.empty())
{
_filteredActions.Append(heap.top());
heap.pop();
}
}
// Function Description:
// - Determine if a command with the given `name` should be shown if the
// input box contains the string `searchText`. If all the characters of
// search text appear in order in `name`, then this fuction will return
// true. There can be any number of characters separating consecutive
// characters in searchText.
// * For example:
// "name": "New Tab"
// "name": "Close Tab"
// "name": "Close Pane"
// "name": "[-] Split Horizontal"
// "name": "[ | ] Split Vertical"
// "name": "Next Tab"
// "name": "Prev Tab"
// "name": "Open Settings"
// "name": "Open Media Controls"
// * "open" should return both "**Open** Settings" and "**Open** Media Controls".
// * "Tab" would return "New **Tab**", "Close **Tab**", "Next **Tab**" and "Prev
// **Tab**".
// * "P" would return "Close **P**ane", "[-] S**p**lit Horizontal", "[ | ]
// S**p**lit Vertical", "**P**rev Tab", "O**p**en Settings" and "O**p**en Media
// Controls".
// * "sv" would return "[ | ] Split Vertical" (by matching the **S** in
// "Split", then the **V** in "Vertical").
// Arguments:
// - searchText: the string of text to search for in `name`
// - name: the name to check
// Return Value:
// - true if name contained all the characters of searchText
bool CommandPalette::_filterMatchesName(const winrt::hstring& searchText, const winrt::hstring& name)
{
std::wstring lowercaseSearchText{ searchText.c_str() };
std::wstring lowercaseName{ name.c_str() };
std::transform(lowercaseSearchText.begin(), lowercaseSearchText.end(), lowercaseSearchText.begin(), std::towlower);
std::transform(lowercaseName.begin(), lowercaseName.end(), lowercaseName.begin(), std::towlower);
const wchar_t* namePtr = lowercaseName.c_str();
const wchar_t* endOfName = lowercaseName.c_str() + lowercaseName.size();
for (const auto& wch : lowercaseSearchText)
{
while (wch != *namePtr)
{
// increment the character to look at in the name string
namePtr++;
if (namePtr >= endOfName)
{
// If we are at the end of the name string, we haven't found all the search chars
return false;
}
}
}
return true;
}
// Function Description:
// - Calculates a "weighting" by which should be used to order a command
// name relative to other names, given a specific search string.
// Currently, this is based off of two factors:
// * The weight is incremented once for each matched character of the
// search text.
// * If a matching character from the search text was found at the start
// of a word in the name, then we increment the weight again.
// * For example, for a search string "sp", we want "Split Pane" to
// appear in the list before "Close Pane"
// Arguments:
// - searchText: the string of text to search for in `name`
// - name: the name to check
// Return Value:
// - the relative weight of this match
int CommandPalette::_getWeight(const winrt::hstring& searchText,
const winrt::hstring& name)
{
std::wstring lowercaseSearchText{ searchText.c_str() };
std::wstring lowercaseName{ name.c_str() };
std::transform(lowercaseSearchText.begin(), lowercaseSearchText.end(), lowercaseSearchText.begin(), std::towlower);
std::transform(lowercaseName.begin(), lowercaseName.end(), lowercaseName.begin(), std::towlower);
int totalWeight = 0;
bool lastCharWasSpace = true;
const wchar_t* namePtr = lowercaseName.c_str();
const wchar_t* endOfName = lowercaseName.c_str() + lowercaseName.size();
for (const auto& wch : lowercaseSearchText)
{
while (wch != *namePtr)
{
// increment the character to look at in the name string
namePtr++;
if (namePtr >= endOfName)
{
// If we are at the end of the name string, we haven't found all the search chars
return totalWeight;
}
lastCharWasSpace = *namePtr == L' ';
}
// We found the char, increment weight
totalWeight++;
totalWeight += lastCharWasSpace ? 1 : 0;
}
return totalWeight;
}
void CommandPalette::SetDispatch(const winrt::TerminalApp::ShortcutActionDispatch& dispatch)
{
_dispatch = dispatch;
}
// Method Description:
// - Dismiss the command palette. This will:
// * select all the current text in the input box
// * set our visibility to Hidden
// * raise our Closed event, so the page can return focus to the active Terminal
// Arguments:
// - <none>
// Return Value:
// - <none>
void CommandPalette::_close()
{
Visibility(Visibility::Collapsed);
// TODO: Do we want to clear the text box each time we close the dialog? Or leave it?
// I think if we decide to leave it, we should auto-select all the text
// in it, so a user can start typing right away, or continue with the
// current selection.
// _SearchBox().Text(L"");
_closeHandlers(*this, RoutedEventArgs{});
}
DEFINE_EVENT_WITH_TYPED_EVENT_HANDLER(CommandPalette, Closed, _closeHandlers, TerminalApp::CommandPalette, winrt::Windows::UI::Xaml::RoutedEventArgs);
}

View File

@@ -0,0 +1,50 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#pragma once
#include "winrt/Microsoft.UI.Xaml.Controls.h"
#include "CommandPalette.g.h"
#include "../../cascadia/inc/cppwinrt_utils.h"
namespace winrt::TerminalApp::implementation
{
struct CommandPalette : CommandPaletteT<CommandPalette>
{
CommandPalette();
Windows::Foundation::Collections::IObservableVector<TerminalApp::Command> FilteredActions();
void SetActions(Windows::Foundation::Collections::IVector<TerminalApp::Command> const& actions);
void ToggleVisibility();
void SetDispatch(const winrt::TerminalApp::ShortcutActionDispatch& dispatch);
DECLARE_EVENT_WITH_TYPED_EVENT_HANDLER(Closed, _closeHandlers, TerminalApp::CommandPalette, winrt::Windows::UI::Xaml::RoutedEventArgs);
private:
friend struct CommandPaletteT<CommandPalette>; // for Xaml to bind events
Windows::Foundation::Collections::IObservableVector<TerminalApp::Command> _filteredActions{ nullptr };
Windows::Foundation::Collections::IVector<TerminalApp::Command> _allActions{ nullptr };
winrt::TerminalApp::ShortcutActionDispatch _dispatch;
void _filterTextChanged(Windows::Foundation::IInspectable const& sender,
Windows::UI::Xaml::RoutedEventArgs const& args);
void _keyDownHandler(Windows::Foundation::IInspectable const& sender,
Windows::UI::Xaml::Input::KeyRoutedEventArgs const& e);
void _selectNextItem(const bool moveDown);
void _updateFilteredActions();
static bool _filterMatchesName(const winrt::hstring& searchText, const winrt::hstring& name);
static int _getWeight(const winrt::hstring& searchText, const winrt::hstring& name);
void _close();
};
}
namespace winrt::TerminalApp::factory_implementation
{
struct CommandPalette : CommandPaletteT<CommandPalette, implementation::CommandPalette>
{
};
}

View File

@@ -0,0 +1,21 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
import "../Command.idl";
namespace TerminalApp
{
[default_interface] runtimeclass CommandPalette : Windows.UI.Xaml.Controls.Grid
{
CommandPalette();
Windows.Foundation.Collections.IObservableVector<Command> FilteredActions { get; };
void SetActions(Windows.Foundation.Collections.IVector<Command> actions);
void ToggleVisibility();
void SetDispatch(ShortcutActionDispatch dispatch);
event Windows.Foundation.TypedEventHandler<CommandPalette, Windows.UI.Xaml.RoutedEventArgs> Closed;
}
}

View File

@@ -0,0 +1,113 @@
<!-- Copyright (c) Microsoft Corporation. All rights reserved. Licensed under
the MIT License. See LICENSE in the project root for license information. -->
<Grid
x:Class="TerminalApp.CommandPalette"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:TerminalApp"
xmlns:mux="using:Microsoft.UI.Xaml.Controls"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:Windows10version1903="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsApiContractPresent(Windows.Foundation.UniversalApiContract, 8)"
mc:Ignorable="d">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="*" />
<ColumnDefinition Width="8*" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="9*"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
<!-- ThemeShadow is only on 18362. This "Windows10version1903" bit adds it
conditionally -->
<Grid.Resources>
<Windows10version1903:ThemeShadow x:Name="CommandPaletteShadow" />
</Grid.Resources>
<Grid
x:Name="ShadowBackdrop"
Background="Transparent"
Grid.Column="1"
Grid.Row="0"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch">
</Grid>
<Grid
x:Name="Backdrop"
Background="{ThemeResource SystemChromeMediumLowColor}"
CornerRadius="{ThemeResource ControlCornerRadius}"
Margin="8"
Grid.Column="1"
Grid.Row="0"
MaxWidth="400"
MaxHeight="400"
Windows10version1903:Shadow="{StaticResource CommandPaletteShadow}"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
<TextBox
Grid.Row="0"
x:Uid="CommandPalette_SearchBox"
x:Name="_SearchBox"
Margin="8"
TextChanged="_filterTextChanged"
KeyDown="_keyDownHandler"
Text="">
</TextBox>
<ListView
Grid.Row="1"
x:Name="_FilteredActionsView"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
SelectionMode="Single"
CanReorderItems="False"
AllowDrop="False"
ItemsSource="{x:Bind FilteredActions}">
<ItemsControl.ItemTemplate >
<DataTemplate x:DataType="local:Command">
<!-- This HorizontalContentAlignment="Stretch" is important
to make sure it takes the entire width of the line -->
<ListViewItem HorizontalContentAlignment="Stretch">
<Grid HorizontalAlignment="Stretch" >
<Grid.ColumnDefinitions>
<ColumnDefinition Width="16"/>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
<!-- TODO: Add Icon to command palette entries, in column 0 -->
<TextBlock Grid.Column="1"
HorizontalAlignment="Left"
Text="{x:Bind Name, Mode=OneWay}" />
<TextBlock Grid.Column="2"
Foreground="{ThemeResource SystemControlForegroundBaseMediumBrush}"
FontSize="12"
HorizontalAlignment="Right"
VerticalAlignment="Center"
Text="{x:Bind KeyChordText, Mode=OneWay}" />
</Grid>
</ListViewItem>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ListView>
</Grid>
</Grid>

View File

@@ -0,0 +1,165 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "pch.h"
#include "Command.h"
#include "Utils.h"
#include "ActionAndArgs.h"
#include <LibraryResources.h>
using namespace winrt::Microsoft::Terminal::Settings;
using namespace winrt::TerminalApp;
static constexpr std::string_view NameKey{ "name" };
static constexpr std::string_view IconPathKey{ "iconPath" };
static constexpr std::string_view ActionKey{ "action" };
static constexpr std::string_view ArgsKey{ "args" };
namespace winrt::TerminalApp::implementation
{
// Function Description:
// - attempt to get the name of this command from the provided json object.
// * If the "name" property is a string, return that value.
// * If the "name" property is an object, attempt to lookup the string
// resource specified by the "key" property, to support localizable
// command names.
// Arguments:
// - json: The Json::Value representing the command object we should get the name for.
// Return Value:
// - the empty string if we couldn't find a name, otherwise the command's name.
winrt::hstring _nameFromJson(const Json::Value& json)
{
if (const auto name{ json[JsonKey(NameKey)] })
{
if (name.isObject())
{
try
{
if (const auto keyJson{ name[JsonKey("key")] })
{
// Make sure the key is present before we try
// loading it. Otherwise we'll crash
const auto resourceKey = GetWstringFromJson(keyJson);
if (HasLibraryResourceWithName(resourceKey))
{
return GetLibraryResourceString(resourceKey);
}
}
}
CATCH_LOG();
}
else if (name.isString())
{
return winrt::to_hstring(name.asString());
}
}
return L"";
}
// Method Description:
// - Deserialize an Command from the `json` object. The json object should
// contain a "name" and "action", and optionally an "icon".
// * "name": string|object - the name of the command to display in the
// command palette. If this is an object, look for the "key" property,
// and try to load the string from our resources instead.
// * "action": string|object - A ShortcutAction, either as a name or as an
// ActionAndArgs serialization. See ActionAndArgs::FromJson for details.
// If this is null, we'll remove this command from the list of commands.
// * "iconPath": string? - the path to an icon to use with this command entry
// Arguments:
// - json: the Json::Value to deserialize into a Command
// - warnings: If there were any warnings during parsing, they'll be
// appended to this vector.
// Return Value:
// - the newly constructed Command object.
winrt::com_ptr<Command> Command::FromJson(const Json::Value& json,
std::vector<::TerminalApp::SettingsLoadWarnings>& warnings)
{
auto result = winrt::make_self<Command>();
result->_setName(_nameFromJson(json));
if (result->_Name.empty())
{
return nullptr;
}
// TODO GH#TODO: iconPath not implemented quite yet. Can't seem to get the binding quite right.
if (const auto iconPathJson{ json[JsonKey(IconPathKey)] })
{
result->_setIconPath(winrt::to_hstring(iconPathJson.asString()));
}
if (const auto actionJson{ json[JsonKey(ActionKey)] })
{
auto actionAndArgs = ActionAndArgs::FromJson(actionJson, warnings);
if (actionAndArgs)
{
result->_setAction(*actionAndArgs);
}
else
{
// Something like
// { name: "foo", action: "unbound" }
// will _remove_ the "foo" command, by returning null here.
return nullptr;
}
}
else
{
// { name: "foo", action: null } will land in this case, which
// should also be used for unbinding.
return nullptr;
}
return result;
}
// Function Description:
// - Attempt to parse all the json objects in `json` into new Command
// objects, and add them to the map of commands.
// - If any parsed command has
// the same Name as an existing command in commands, the new one will
// layer on top of the existing one.
// Arguments:
// - commands: a map of Name->Command which new commands should be layered upon.
// - json: A Json::Value containing an array of serialized commands
// Return Value:
// - A vector containing any warnings detected while parsing
std::vector<::TerminalApp::SettingsLoadWarnings> Command::LayerJson(std::map<winrt::hstring, winrt::TerminalApp::Command>& commands,
const Json::Value& json)
{
std::vector<::TerminalApp::SettingsLoadWarnings> warnings;
for (const auto& value : json)
{
if (value.isObject())
{
try
{
auto result = Command::FromJson(value, warnings);
if (result)
{
// Override commands with the same name
commands.insert_or_assign(result->Name(), *result);
}
else
{
// If there wasn't a parsed command, then try to get the
// name from the json blob. If that name currently
// exists in our list of commands, we should remove it.
const auto name = _nameFromJson(json);
if (!name.empty())
{
commands.erase(name);
}
}
}
CATCH_LOG();
}
}
return warnings;
}
}

View File

@@ -7,7 +7,6 @@
#include "../../inc/DefaultSettings.h"
#include "Utils.h"
#include "JsonUtils.h"
#include <sstream>
using namespace TerminalApp;
using namespace winrt::Microsoft::Terminal::Settings;
@@ -18,6 +17,7 @@ using namespace ::Microsoft::Console;
using namespace winrt::Microsoft::UI::Xaml::Controls;
static constexpr std::string_view KeybindingsKey{ "keybindings" };
static constexpr std::string_view CommandsKey{ "commands" };
static constexpr std::string_view DefaultProfileKey{ "defaultProfile" };
static constexpr std::string_view AlwaysShowTabsKey{ "alwaysShowTabs" };
static constexpr std::string_view InitialRowsKey{ "initialRows" };
@@ -27,8 +27,6 @@ static constexpr std::string_view InitialPositionKey{ "initialPosition" };
static constexpr std::string_view ShowTitleInTitlebarKey{ "showTerminalTitleInTitlebar" };
static constexpr std::string_view ThemeKey{ "theme" };
static constexpr std::string_view TabWidthModeKey{ "tabWidthMode" };
static constexpr std::wstring_view EqualTabWidthModeValue{ L"equal" };
static constexpr std::wstring_view TitleLengthTabWidthModeValue{ L"titleLength" };
static constexpr std::string_view ShowTabsInTitlebarKey{ "showTabsInTitlebar" };
static constexpr std::string_view WordDelimitersKey{ "wordDelimiters" };
static constexpr std::string_view CopyOnSelectKey{ "copyOnSelect" };
@@ -36,16 +34,28 @@ static constexpr std::string_view CopyFormattingKey{ "copyFormatting" };
static constexpr std::string_view LaunchModeKey{ "launchMode" };
static constexpr std::string_view ConfirmCloseAllKey{ "confirmCloseAllTabs" };
static constexpr std::string_view SnapToGridOnResizeKey{ "snapToGridOnResize" };
static constexpr std::wstring_view DefaultLaunchModeValue{ L"default" };
static constexpr std::wstring_view MaximizedLaunchModeValue{ L"maximized" };
static constexpr std::wstring_view LightThemeValue{ L"light" };
static constexpr std::wstring_view DarkThemeValue{ L"dark" };
static constexpr std::wstring_view SystemThemeValue{ L"system" };
static constexpr std::string_view EnableStartupTaskKey{ "startOnUserLogin" };
static constexpr std::string_view DebugFeaturesKey{ "debugFeatures" };
static constexpr std::string_view ForceFullRepaintRenderingKey{ "experimental.rendering.forceFullRepaint" };
static constexpr std::string_view SoftwareRenderingKey{ "experimental.rendering.software" };
static constexpr std::string_view ForceVTInputKey{ "experimental.input.forceVT" };
static constexpr std::string_view DebugFeaturesKey{ "debugFeatures" };
// Launch mode values
static constexpr std::wstring_view DefaultLaunchModeValue{ L"default" };
static constexpr std::wstring_view MaximizedLaunchModeValue{ L"maximized" };
static constexpr std::wstring_view FullscreenLaunchModeValue{ L"fullscreen" };
// Tab Width Mode values
static constexpr std::wstring_view EqualTabWidthModeValue{ L"equal" };
static constexpr std::wstring_view TitleLengthTabWidthModeValue{ L"titleLength" };
static constexpr std::wstring_view TitleLengthCompactModeValue{ L"compact" };
// Theme values
static constexpr std::wstring_view LightThemeValue{ L"light" };
static constexpr std::wstring_view DarkThemeValue{ L"dark" };
static constexpr std::wstring_view SystemThemeValue{ L"system" };
#ifdef _DEBUG
static constexpr bool debugFeaturesDefault{ true };
@@ -57,25 +67,13 @@ GlobalAppSettings::GlobalAppSettings() :
_keybindings{ winrt::make_self<winrt::TerminalApp::implementation::AppKeyBindings>() },
_keybindingsWarnings{},
_colorSchemes{},
_unparsedDefaultProfile{ std::nullopt },
_defaultProfile{},
_alwaysShowTabs{ true },
_confirmCloseAllTabs{ true },
_initialRows{ DEFAULT_ROWS },
_initialCols{ DEFAULT_COLS },
_rowsToScroll{ DEFAULT_ROWSTOSCROLL },
_initialX{},
_initialY{},
_showTitleInTitlebar{ true },
_showTabsInTitlebar{ true },
_theme{ ElementTheme::Default },
_tabWidthMode{ TabViewWidthMode::Equal },
_wordDelimiters{ DEFAULT_WORD_DELIMITERS },
_copyOnSelect{ false },
_copyFormatting{ false },
_launchMode{ LaunchMode::DefaultMode },
_forceFullRepaintRendering{ false },
_softwareRendering{ false },
_debugFeatures{ debugFeaturesDefault }
_InitialRows{ DEFAULT_ROWS },
_InitialCols{ DEFAULT_COLS },
_RowsToScroll{ DEFAULT_ROWSTOSCROLL },
_WordDelimiters{ DEFAULT_WORD_DELIMITERS },
_DebugFeaturesEnabled{ debugFeaturesDefault }
{
}
@@ -93,143 +91,29 @@ const std::unordered_map<std::wstring, ColorScheme>& GlobalAppSettings::GetColor
return _colorSchemes;
}
void GlobalAppSettings::SetDefaultProfile(const GUID defaultProfile) noexcept
void GlobalAppSettings::DefaultProfile(const GUID defaultProfile) noexcept
{
_unparsedDefaultProfile.reset();
_defaultProfile = defaultProfile;
}
GUID GlobalAppSettings::GetDefaultProfile() const noexcept
GUID GlobalAppSettings::DefaultProfile() const
{
// If we have an unresolved default profile, we should likely explode.
THROW_HR_IF(E_INVALIDARG, _unparsedDefaultProfile.has_value());
return _defaultProfile;
}
std::wstring GlobalAppSettings::UnparsedDefaultProfile() const
{
return _unparsedDefaultProfile.value();
}
AppKeyBindings GlobalAppSettings::GetKeybindings() const noexcept
{
return *_keybindings;
}
bool GlobalAppSettings::GetAlwaysShowTabs() const noexcept
{
return _alwaysShowTabs;
}
void GlobalAppSettings::SetAlwaysShowTabs(const bool showTabs) noexcept
{
_alwaysShowTabs = showTabs;
}
bool GlobalAppSettings::GetShowTitleInTitlebar() const noexcept
{
return _showTitleInTitlebar;
}
void GlobalAppSettings::SetShowTitleInTitlebar(const bool showTitleInTitlebar) noexcept
{
_showTitleInTitlebar = showTitleInTitlebar;
}
ElementTheme GlobalAppSettings::GetTheme() const noexcept
{
return _theme;
}
void GlobalAppSettings::SetTheme(const ElementTheme theme) noexcept
{
_theme = theme;
}
TabViewWidthMode GlobalAppSettings::GetTabWidthMode() const noexcept
{
return _tabWidthMode;
}
void GlobalAppSettings::SetTabWidthMode(const TabViewWidthMode tabWidthMode)
{
_tabWidthMode = tabWidthMode;
}
std::wstring GlobalAppSettings::GetWordDelimiters() const noexcept
{
return _wordDelimiters;
}
void GlobalAppSettings::SetWordDelimiters(const std::wstring wordDelimiters) noexcept
{
_wordDelimiters = wordDelimiters;
}
bool GlobalAppSettings::GetCopyOnSelect() const noexcept
{
return _copyOnSelect;
}
void GlobalAppSettings::SetCopyOnSelect(const bool copyOnSelect) noexcept
{
_copyOnSelect = copyOnSelect;
}
bool GlobalAppSettings::GetCopyFormatting() const noexcept
{
return _copyFormatting;
}
LaunchMode GlobalAppSettings::GetLaunchMode() const noexcept
{
return _launchMode;
}
void GlobalAppSettings::SetLaunchMode(const LaunchMode launchMode)
{
_launchMode = launchMode;
}
bool GlobalAppSettings::GetConfirmCloseAllTabs() const noexcept
{
return _confirmCloseAllTabs;
}
void GlobalAppSettings::SetConfirmCloseAllTabs(const bool confirmCloseAllTabs) noexcept
{
_confirmCloseAllTabs = confirmCloseAllTabs;
}
bool GlobalAppSettings::GetForceFullRepaintRendering() noexcept
{
return _forceFullRepaintRendering;
}
bool GlobalAppSettings::GetSoftwareRendering() noexcept
{
return _softwareRendering;
}
bool GlobalAppSettings::DebugFeaturesEnabled() const noexcept
{
return _debugFeatures;
}
#pragma region ExperimentalSettings
bool GlobalAppSettings::GetShowTabsInTitlebar() const noexcept
{
return _showTabsInTitlebar;
}
void GlobalAppSettings::SetShowTabsInTitlebar(const bool showTabsInTitlebar) noexcept
{
_showTabsInTitlebar = showTabsInTitlebar;
}
std::optional<int32_t> GlobalAppSettings::GetInitialX() const noexcept
{
return _initialX;
}
std::optional<int32_t> GlobalAppSettings::GetInitialY() const noexcept
{
return _initialY;
}
#pragma endregion
// Method Description:
// - Applies appropriate settings from the globals into the given TerminalSettings.
// Arguments:
@@ -239,14 +123,15 @@ std::optional<int32_t> GlobalAppSettings::GetInitialY() const noexcept
void GlobalAppSettings::ApplyToSettings(TerminalSettings& settings) const noexcept
{
settings.KeyBindings(GetKeybindings());
settings.InitialRows(_initialRows);
settings.InitialCols(_initialCols);
settings.RowsToScroll(_rowsToScroll);
settings.InitialRows(_InitialRows);
settings.InitialCols(_InitialCols);
settings.RowsToScroll(_RowsToScroll);
settings.WordDelimiters(_wordDelimiters);
settings.CopyOnSelect(_copyOnSelect);
settings.ForceFullRepaintRendering(_forceFullRepaintRendering);
settings.SoftwareRendering(_softwareRendering);
settings.WordDelimiters(_WordDelimiters);
settings.CopyOnSelect(_CopyOnSelect);
settings.ForceFullRepaintRendering(_ForceFullRepaintRendering);
settings.SoftwareRendering(_SoftwareRendering);
settings.ForceVTInput(_ForceVTInput);
}
// Method Description:
@@ -266,59 +151,58 @@ void GlobalAppSettings::LayerJson(const Json::Value& json)
{
if (auto defaultProfile{ json[JsonKey(DefaultProfileKey)] })
{
auto guid = Utils::GuidFromString(GetWstringFromJson(defaultProfile));
_defaultProfile = guid;
_unparsedDefaultProfile.emplace(GetWstringFromJson(defaultProfile));
}
JsonUtils::GetBool(json, AlwaysShowTabsKey, _alwaysShowTabs);
JsonUtils::GetBool(json, AlwaysShowTabsKey, _AlwaysShowTabs);
JsonUtils::GetBool(json, ConfirmCloseAllKey, _confirmCloseAllTabs);
JsonUtils::GetBool(json, ConfirmCloseAllKey, _ConfirmCloseAllTabs);
JsonUtils::GetInt(json, InitialRowsKey, _initialRows);
JsonUtils::GetInt(json, InitialRowsKey, _InitialRows);
JsonUtils::GetInt(json, InitialColsKey, _initialCols);
JsonUtils::GetInt(json, InitialColsKey, _InitialCols);
if (auto rowsToScroll{ json[JsonKey(RowsToScrollKey)] })
{
//if it's not an int we fall back to setting it to 0, which implies using the system setting. This will be the case if it's set to "system"
if (rowsToScroll.isInt())
{
_rowsToScroll = rowsToScroll.asInt();
_RowsToScroll = rowsToScroll.asInt();
}
else
{
_rowsToScroll = 0;
_RowsToScroll = 0;
}
}
if (auto initialPosition{ json[JsonKey(InitialPositionKey)] })
{
_ParseInitialPosition(GetWstringFromJson(initialPosition), _initialX, _initialY);
_ParseInitialPosition(initialPosition.asString(), _InitialPosition);
}
JsonUtils::GetBool(json, ShowTitleInTitlebarKey, _showTitleInTitlebar);
JsonUtils::GetBool(json, ShowTitleInTitlebarKey, _ShowTitleInTitlebar);
JsonUtils::GetBool(json, ShowTabsInTitlebarKey, _showTabsInTitlebar);
JsonUtils::GetBool(json, ShowTabsInTitlebarKey, _ShowTabsInTitlebar);
JsonUtils::GetWstring(json, WordDelimitersKey, _wordDelimiters);
JsonUtils::GetWstring(json, WordDelimitersKey, _WordDelimiters);
JsonUtils::GetBool(json, CopyOnSelectKey, _copyOnSelect);
JsonUtils::GetBool(json, CopyOnSelectKey, _CopyOnSelect);
JsonUtils::GetBool(json, CopyFormattingKey, _copyFormatting);
JsonUtils::GetBool(json, CopyFormattingKey, _CopyFormatting);
if (auto launchMode{ json[JsonKey(LaunchModeKey)] })
{
_launchMode = _ParseLaunchMode(GetWstringFromJson(launchMode));
_LaunchMode = _ParseLaunchMode(GetWstringFromJson(launchMode));
}
if (auto theme{ json[JsonKey(ThemeKey)] })
{
_theme = _ParseTheme(GetWstringFromJson(theme));
_Theme = _ParseTheme(GetWstringFromJson(theme));
}
if (auto tabWidthMode{ json[JsonKey(TabWidthModeKey)] })
{
_tabWidthMode = _ParseTabWidthMode(GetWstringFromJson(tabWidthMode));
_TabWidthMode = _ParseTabWidthMode(GetWstringFromJson(tabWidthMode));
}
if (auto keybindings{ json[JsonKey(KeybindingsKey)] })
@@ -335,12 +219,23 @@ void GlobalAppSettings::LayerJson(const Json::Value& json)
JsonUtils::GetBool(json, SnapToGridOnResizeKey, _SnapToGridOnResize);
JsonUtils::GetBool(json, ForceFullRepaintRenderingKey, _forceFullRepaintRendering);
JsonUtils::GetBool(json, ForceFullRepaintRenderingKey, _ForceFullRepaintRendering);
JsonUtils::GetBool(json, SoftwareRenderingKey, _softwareRendering);
JsonUtils::GetBool(json, SoftwareRenderingKey, _SoftwareRendering);
JsonUtils::GetBool(json, ForceVTInputKey, _ForceVTInput);
// GetBool will only override the current value if the key exists
JsonUtils::GetBool(json, DebugFeaturesKey, _debugFeatures);
JsonUtils::GetBool(json, DebugFeaturesKey, _DebugFeaturesEnabled);
JsonUtils::GetBool(json, EnableStartupTaskKey, _StartOnUserLogin);
if (auto commandsArray{ json[JsonKey(CommandsKey)] })
{
auto warnings = winrt::TerminalApp::implementation::Command::LayerJson(_commands, commandsArray);
// It's possible that the user provided commands have some warnings
// in them, similar to the keybindings.
_keybindingsWarnings.insert(_keybindingsWarnings.end(), warnings.begin(), warnings.end());
}
}
// Method Description:
@@ -364,26 +259,6 @@ ElementTheme GlobalAppSettings::_ParseTheme(const std::wstring& themeString) noe
return ElementTheme::Default;
}
// Method Description:
// - Helper function for converting a CursorStyle to its corresponding string
// value.
// Arguments:
// - theme: The enum value to convert to a string.
// Return Value:
// - The string value for the given CursorStyle
std::wstring_view GlobalAppSettings::_SerializeTheme(const ElementTheme theme) noexcept
{
switch (theme)
{
case ElementTheme::Light:
return LightThemeValue;
case ElementTheme::Dark:
return DarkThemeValue;
default:
return SystemThemeValue;
}
}
// Method Description:
// - Helper function for converting the initial position string into
// 2 coordinate values. We allow users to only provide one coordinate,
@@ -395,17 +270,15 @@ std::wstring_view GlobalAppSettings::_SerializeTheme(const ElementTheme theme) n
// (100, 100, 100): we only read the first two values, this is equivalent to (100, 100)
// Arguments:
// - initialPosition: the initial position string from json
// initialX: reference to the _initialX member
// initialY: reference to the _initialY member
// ret: reference to a struct whose optionals will be populated
// Return Value:
// - None
void GlobalAppSettings::_ParseInitialPosition(const std::wstring& initialPosition,
std::optional<int32_t>& initialX,
std::optional<int32_t>& initialY) noexcept
void GlobalAppSettings::_ParseInitialPosition(const std::string& initialPosition,
LaunchPosition& ret) noexcept
{
const wchar_t singleCharDelim = L',';
std::wstringstream tokenStream(initialPosition);
std::wstring token;
static constexpr char singleCharDelim = ',';
std::stringstream tokenStream(initialPosition);
std::string token;
uint8_t initialPosIndex = 0;
// Get initial position values till we run out of delimiter separated values in the stream
@@ -418,12 +291,12 @@ void GlobalAppSettings::_ParseInitialPosition(const std::wstring& initialPositio
int32_t position = std::stoi(token);
if (initialPosIndex == 0)
{
initialX.emplace(position);
ret.x.emplace(position);
}
if (initialPosIndex == 1)
{
initialY.emplace(position);
ret.y.emplace(position);
}
}
catch (...)
@@ -433,33 +306,6 @@ void GlobalAppSettings::_ParseInitialPosition(const std::wstring& initialPositio
}
}
// Method Description:
// - Helper function for converting X/Y initial positions to a string
// value.
// Arguments:
// - initialX: reference to the _initialX member
// initialY: reference to the _initialY member
// Return Value:
// - The concatenated string for the the current initialX and initialY
std::string GlobalAppSettings::_SerializeInitialPosition(const std::optional<int32_t>& initialX,
const std::optional<int32_t>& initialY) noexcept
{
std::string serializedInitialPos = "";
if (initialX.has_value())
{
serializedInitialPos += std::to_string(initialX.value());
}
serializedInitialPos += ", ";
if (initialY.has_value())
{
serializedInitialPos += std::to_string(initialY.value());
}
return serializedInitialPos;
}
// Method Description:
// - Helper function for converting the user-specified launch mode
// to a LaunchMode enum value
@@ -473,28 +319,14 @@ LaunchMode GlobalAppSettings::_ParseLaunchMode(const std::wstring& launchModeStr
{
return LaunchMode::MaximizedMode;
}
else if (launchModeString == FullscreenLaunchModeValue)
{
return LaunchMode::FullscreenMode;
}
return LaunchMode::DefaultMode;
}
// Method Description:
// - Helper function for converting a LaunchMode to its corresponding string
// value.
// Arguments:
// - launchMode: The enum value to convert to a string.
// Return Value:
// - The string value for the given LaunchMode
std::wstring_view GlobalAppSettings::_SerializeLaunchMode(const LaunchMode launchMode) noexcept
{
switch (launchMode)
{
case LaunchMode::MaximizedMode:
return MaximizedLaunchModeValue;
default:
return DefaultLaunchModeValue;
}
}
// Method Description:
// - Helper function for converting the user-specified tab width
// to a TabViewWidthMode enum value
@@ -508,28 +340,14 @@ TabViewWidthMode GlobalAppSettings::_ParseTabWidthMode(const std::wstring& tabWi
{
return TabViewWidthMode::SizeToContent;
}
else if (tabWidthModeString == TitleLengthCompactModeValue)
{
return TabViewWidthMode::Compact;
}
// default behavior for invalid data or EqualTabWidthValue
return TabViewWidthMode::Equal;
}
// Method Description:
// - Helper function for converting a TabViewWidthMode to its corresponding string
// value.
// Arguments:
// - tabWidthMode: The enum value to convert to a string.
// Return Value:
// - The string value for the given TabWidthMode
std::wstring_view GlobalAppSettings::_SerializeTabWidthMode(const TabViewWidthMode tabWidthMode) noexcept
{
switch (tabWidthMode)
{
case TabViewWidthMode::SizeToContent:
return TitleLengthTabWidthModeValue;
default:
return EqualTabWidthModeValue;
}
}
// Method Description:
// - Adds the given colorscheme to our map of schemes, using its name as the key.
// Arguments:
@@ -555,3 +373,8 @@ std::vector<TerminalApp::SettingsLoadWarnings> GlobalAppSettings::GetKeybindings
{
return _keybindingsWarnings;
}
const std::map<winrt::hstring, winrt::TerminalApp::Command>& GlobalAppSettings::GetCommands() const noexcept
{
return _commands;
}

View File

@@ -16,6 +16,7 @@ Author(s):
#pragma once
#include "AppKeyBindings.h"
#include "ColorScheme.h"
#include "Command.h"
// fwdecl unittest classes
namespace TerminalAppLocalTests
@@ -27,6 +28,12 @@ namespace TerminalAppLocalTests
namespace TerminalApp
{
class GlobalAppSettings;
struct LaunchPosition
{
std::optional<int> x;
std::optional<int> y;
};
};
class TerminalApp::GlobalAppSettings final
@@ -39,49 +46,8 @@ public:
const std::unordered_map<std::wstring, ColorScheme>& GetColorSchemes() const noexcept;
void AddColorScheme(ColorScheme scheme);
void SetDefaultProfile(const GUID defaultProfile) noexcept;
GUID GetDefaultProfile() const noexcept;
winrt::TerminalApp::AppKeyBindings GetKeybindings() const noexcept;
bool GetAlwaysShowTabs() const noexcept;
void SetAlwaysShowTabs(const bool showTabs) noexcept;
bool GetShowTitleInTitlebar() const noexcept;
void SetShowTitleInTitlebar(const bool showTitleInTitlebar) noexcept;
bool GetConfirmCloseAllTabs() const noexcept;
void SetConfirmCloseAllTabs(const bool confirmCloseAllTabs) noexcept;
winrt::Windows::UI::Xaml::ElementTheme GetTheme() const noexcept;
void SetTheme(const winrt::Windows::UI::Xaml::ElementTheme requestedTheme) noexcept;
winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode GetTabWidthMode() const noexcept;
void SetTabWidthMode(const winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode tabWidthMode);
bool GetShowTabsInTitlebar() const noexcept;
void SetShowTabsInTitlebar(const bool showTabsInTitlebar) noexcept;
std::wstring GetWordDelimiters() const noexcept;
void SetWordDelimiters(const std::wstring wordDelimiters) noexcept;
bool GetCopyOnSelect() const noexcept;
void SetCopyOnSelect(const bool copyOnSelect) noexcept;
bool GetCopyFormatting() const noexcept;
std::optional<int32_t> GetInitialX() const noexcept;
std::optional<int32_t> GetInitialY() const noexcept;
winrt::TerminalApp::LaunchMode GetLaunchMode() const noexcept;
void SetLaunchMode(const winrt::TerminalApp::LaunchMode launchMode);
bool GetForceFullRepaintRendering() noexcept;
bool GetSoftwareRendering() noexcept;
bool DebugFeaturesEnabled() const noexcept;
static GlobalAppSettings FromJson(const Json::Value& json);
void LayerJson(const Json::Value& json);
@@ -89,56 +55,52 @@ public:
std::vector<TerminalApp::SettingsLoadWarnings> GetKeybindingsWarnings() const;
const std::map<winrt::hstring, winrt::TerminalApp::Command>& GetCommands() const noexcept;
// These are implemented manually to handle the string/GUID exchange
// by higher layers in the app.
void DefaultProfile(const GUID defaultProfile) noexcept;
GUID DefaultProfile() const;
std::wstring UnparsedDefaultProfile() const;
GETSET_PROPERTY(int32_t, InitialRows); // default value set in constructor
GETSET_PROPERTY(int32_t, InitialCols); // default value set in constructor
GETSET_PROPERTY(bool, AlwaysShowTabs, true);
GETSET_PROPERTY(bool, ShowTitleInTitlebar, true);
GETSET_PROPERTY(bool, ConfirmCloseAllTabs, true);
GETSET_PROPERTY(winrt::Windows::UI::Xaml::ElementTheme, Theme, winrt::Windows::UI::Xaml::ElementTheme::Default);
GETSET_PROPERTY(winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode, TabWidthMode, winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode::Equal);
GETSET_PROPERTY(int, RowsToScroll); // default value set in constructor
GETSET_PROPERTY(bool, ShowTabsInTitlebar, true);
GETSET_PROPERTY(std::wstring, WordDelimiters); // default value set in constructor
GETSET_PROPERTY(bool, CopyOnSelect, false);
GETSET_PROPERTY(bool, CopyFormatting, false);
GETSET_PROPERTY(LaunchPosition, InitialPosition);
GETSET_PROPERTY(winrt::TerminalApp::LaunchMode, LaunchMode, winrt::TerminalApp::LaunchMode::DefaultMode);
GETSET_PROPERTY(bool, SnapToGridOnResize, true);
GETSET_PROPERTY(bool, ForceFullRepaintRendering, false);
GETSET_PROPERTY(bool, SoftwareRendering, false);
GETSET_PROPERTY(bool, ForceVTInput, false);
GETSET_PROPERTY(bool, DebugFeaturesEnabled); // default value set in constructor
GETSET_PROPERTY(bool, StartOnUserLogin, false);
private:
std::optional<std::wstring> _unparsedDefaultProfile;
GUID _defaultProfile;
winrt::com_ptr<winrt::TerminalApp::implementation::AppKeyBindings> _keybindings;
std::vector<::TerminalApp::SettingsLoadWarnings> _keybindingsWarnings;
std::unordered_map<std::wstring, ColorScheme> _colorSchemes;
int32_t _initialRows;
int32_t _initialCols;
int32_t _rowsToScroll;
std::optional<int32_t> _initialX;
std::optional<int32_t> _initialY;
bool _showStatusline;
bool _alwaysShowTabs;
bool _showTitleInTitlebar;
bool _confirmCloseAllTabs;
bool _showTabsInTitlebar;
std::wstring _wordDelimiters;
bool _copyOnSelect;
bool _copyFormatting;
winrt::Windows::UI::Xaml::ElementTheme _theme;
winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode _tabWidthMode;
winrt::TerminalApp::LaunchMode _launchMode;
bool _softwareRendering;
bool _forceFullRepaintRendering;
bool _debugFeatures;
std::map<winrt::hstring, winrt::TerminalApp::Command> _commands;
static winrt::Windows::UI::Xaml::ElementTheme _ParseTheme(const std::wstring& themeString) noexcept;
static std::wstring_view _SerializeTheme(const winrt::Windows::UI::Xaml::ElementTheme theme) noexcept;
static std::wstring_view _SerializeTabWidthMode(const winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode tabWidthMode) noexcept;
static winrt::Microsoft::UI::Xaml::Controls::TabViewWidthMode _ParseTabWidthMode(const std::wstring& tabWidthModeString) noexcept;
static void _ParseInitialPosition(const std::wstring& initialPosition,
std::optional<int32_t>& initialX,
std::optional<int32_t>& initialY) noexcept;
static void _ParseInitialPosition(const std::string& initialPosition,
LaunchPosition& ret) noexcept;
static std::string _SerializeInitialPosition(const std::optional<int32_t>& initialX,
const std::optional<int32_t>& initialY) noexcept;
static std::wstring_view _SerializeLaunchMode(const winrt::TerminalApp::LaunchMode launchMode) noexcept;
static winrt::TerminalApp::LaunchMode _ParseLaunchMode(const std::wstring& launchModeString) noexcept;
friend class TerminalAppLocalTests::SettingsTests;

View File

@@ -7,10 +7,8 @@ namespace TerminalApp
// Instead, we just pin the uuid and include it in both TermControl and App
// If you update this one, please update the one in TerminalControl\TermControl.idl
// If you change this interface, please update the guid.
// If you press F7 and get a runtime error, go make sure both copies are the same.
[uuid("339e1a87-5315-4da6-96f0-565549b6472b")]
interface IF7Listener
{
Boolean OnF7Pressed();
// If you press F7 or Alt and get a runtime error, go make sure both copies are the same.
[uuid("339e1a87-5315-4da6-96f0-565549b6472b")] interface IDirectKeyListener {
Boolean OnDirectKeyEvent(UInt32 vkey, Boolean down);
}
}

View File

@@ -0,0 +1,471 @@
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- JsonUtils.h
Abstract:
- Helpers for the TerminalApp project
Author(s):
- Mike Griese - August 2019
- Dustin Howett - January 2020
--*/
#pragma once
#include <json.h>
#include "../types/inc/utils.hpp"
namespace winrt
{
// If we don't use winrt, nobody will include the ConversionTrait for winrt::guid.
// If nobody includes it, this forward declaration will suffice.
struct guid;
}
namespace TerminalApp::JsonUtils
{
namespace Detail
{
// Function Description:
// - Returns a string_view to a Json::Value's internal string storage,
// hopefully without copying it.
__declspec(noinline) inline const std::string_view GetStringView(const Json::Value& json)
{
const char* begin{ nullptr };
const char* end{ nullptr };
json.getString(&begin, &end);
const std::string_view zeroCopyString{ begin, gsl::narrow_cast<size_t>(end - begin) };
return zeroCopyString;
}
template<typename T>
struct DeduceOptional
{
using Type = typename std::decay<T>::type;
};
template<typename TOpt>
struct DeduceOptional<std::optional<TOpt>>
{
using Type = typename std::decay<TOpt>::type;
};
}
// These exceptions cannot use localized messages, as we do not have
// guaranteed access to the resource loader.
class TypeMismatchException : public std::runtime_error
{
public:
TypeMismatchException() :
runtime_error("unexpected data type") {}
};
class KeyedException : public std::runtime_error
{
public:
KeyedException(const std::string_view key, std::exception_ptr exception) :
runtime_error(fmt::format("error parsing \"{0}\"", key).c_str()),
_key{ key },
_innerException{ std::move(exception) } {}
std::string GetKey() const
{
return _key;
}
[[noreturn]] void RethrowInner() const
{
std::rethrow_exception(_innerException);
}
private:
std::string _key;
std::exception_ptr _innerException;
};
class UnexpectedValueException : public std::runtime_error
{
public:
UnexpectedValueException(const std::string_view value) :
runtime_error(fmt::format("unexpected value \"{0}\"", value).c_str()),
_value{ value } {}
std::string GetValue() const
{
return _value;
}
private:
std::string _value;
};
template<typename T>
struct ConversionTrait
{
// FromJson, CanConvert are not defined so as to cause a compile error (which forces a specialization)
};
template<>
struct ConversionTrait<std::string>
{
std::string FromJson(const Json::Value& json)
{
return json.asString();
}
bool CanConvert(const Json::Value& json)
{
return json.isString();
}
};
template<>
struct ConversionTrait<std::wstring>
{
std::wstring FromJson(const Json::Value& json)
{
return til::u8u16(Detail::GetStringView(json));
}
bool CanConvert(const Json::Value& json)
{
return json.isString();
}
};
template<>
struct ConversionTrait<bool>
{
bool FromJson(const Json::Value& json)
{
return json.asBool();
}
bool CanConvert(const Json::Value& json)
{
return json.isBool();
}
};
template<>
struct ConversionTrait<int>
{
int FromJson(const Json::Value& json)
{
return json.asInt();
}
bool CanConvert(const Json::Value& json)
{
return json.isInt();
}
};
template<>
struct ConversionTrait<unsigned int>
{
unsigned int FromJson(const Json::Value& json)
{
return json.asUInt();
}
bool CanConvert(const Json::Value& json)
{
return json.isUInt();
}
};
template<>
struct ConversionTrait<float>
{
float FromJson(const Json::Value& json)
{
return json.asFloat();
}
bool CanConvert(const Json::Value& json)
{
return json.isNumeric();
}
};
template<>
struct ConversionTrait<double>
{
double FromJson(const Json::Value& json)
{
return json.asDouble();
}
bool CanConvert(const Json::Value& json)
{
return json.isNumeric();
}
};
template<>
struct ConversionTrait<GUID>
{
GUID FromJson(const Json::Value& json)
{
return ::Microsoft::Console::Utils::GuidFromString(til::u8u16(Detail::GetStringView(json)));
}
bool CanConvert(const Json::Value& json)
{
if (!json.isString())
{
return false;
}
const auto string{ Detail::GetStringView(json) };
return string.length() == 38 && string.front() == '{' && string.back() == '}';
}
};
// (GUID and winrt::guid are mutually convertible!)
template<>
struct ConversionTrait<winrt::guid> : public ConversionTrait<GUID>
{
};
template<>
struct ConversionTrait<til::color>
{
til::color FromJson(const Json::Value& json)
{
return ::Microsoft::Console::Utils::ColorFromHexString(Detail::GetStringView(json));
}
bool CanConvert(const Json::Value& json)
{
if (!json.isString())
{
return false;
}
const auto string{ Detail::GetStringView(json) };
return (string.length() == 7 || string.length() == 3) && string.front() == '#';
}
};
template<typename T, typename TBase>
struct EnumMapper
{
using pair_type = std::pair<std::string_view, T>;
T FromJson(const Json::Value& json)
{
const auto name{ Detail::GetStringView(json) };
for (const auto& pair : TBase::mappings)
{
if (pair.first == name)
{
return pair.second;
}
}
throw UnexpectedValueException{ name };
}
bool CanConvert(const Json::Value& json)
{
return json.isString();
}
};
// FlagMapper is EnumMapper, but it works for bitfields.
// It supports a string (single flag) or an array of strings.
// Does an O(n*m) search; meant for small search spaces!
//
// Cleverly leverage EnumMapper to do the heavy lifting.
template<typename T, typename TBase>
struct FlagMapper : public EnumMapper<T, TBase>
{
static constexpr T AllSet{ static_cast<T>(~0u) };
static constexpr T AllClear{ static_cast<T>(0u) };
T FromJson(const Json::Value& json)
{
if (json.isString())
{
return EnumMapper::FromJson(json);
}
else if (json.isArray())
{
unsigned int seen{ 0 };
T value{};
for (const auto& element : json)
{
const auto newFlag{ EnumMapper::FromJson(element) };
if (++seen > 1 &&
((newFlag == AllClear && value != AllClear) ||
(value == AllClear && newFlag != AllClear)))
{
// attempt to combine AllClear (explicitly) with anything else
throw UnexpectedValueException{ element.asString() };
}
value |= newFlag;
}
return value;
}
// We'll only get here if CanConvert has failed us.
return AllClear;
}
bool CanConvert(const Json::Value& json)
{
return EnumMapper::CanConvert(json) || json.isArray();
}
};
// Method Description:
// - Helper that will populate a reference with a value converted from a json object.
// Arguments:
// - json: the json object to convert
// - target: the value to populate with the converted result
// Return Value:
// - a boolean indicating whether the value existed (in this case, was non-null)
//
// GetValue, type-deduced, manual converter
template<typename T, typename Converter>
bool GetValue(const Json::Value& json, T& target, Converter&& conv)
{
if (json)
{
if (!conv.CanConvert(json))
{
throw TypeMismatchException{};
}
target = conv.FromJson(json);
return true;
}
return false;
}
// Method Description:
// - Overload on GetValue that will populate a std::optional with a value converted from json
// - If the json value doesn't exist we'll leave the target object unmodified.
// - If the json object is set to `null`, then
// we'll instead set the target back to nullopt.
// Arguments:
// - json: the json object to convert
// - target: the value to populate with the converted result
// Return Value:
// - a boolean indicating whether the optional was changed
//
// GetValue, type-deduced for optional, manual converter
template<typename TOpt, typename Converter>
bool GetValue(const Json::Value& json, std::optional<TOpt>& target, Converter&& conv)
{
if (json.isNull())
{
target = std::nullopt;
return true; // null is valid for optionals
}
std::decay_t<TOpt> local{};
if (GetValue(json, local, std::forward<Converter>(conv)))
{
target = std::move(local);
return true;
}
return false;
}
// GetValue, forced return type, manual converter
template<typename T, typename Converter>
std::decay_t<T> GetValue(const Json::Value& json, Converter&& conv)
{
std::decay_t<T> local{};
GetValue(json, local, std::forward<Converter>(conv));
return local; // returns zero-initialized or value
}
// GetValueForKey, type-deduced, manual converter
template<typename T, typename Converter>
bool GetValueForKey(const Json::Value& json, std::string_view key, T& target, Converter&& conv)
{
if (auto found{ json.find(&*key.cbegin(), (&*key.cbegin()) + key.size()) })
{
try
{
return GetValue(*found, target, std::forward<Converter>(conv));
}
catch (...)
{
// Wrap any caught exceptions in one that preserves context.
throw KeyedException(key, std::current_exception());
}
}
return false;
}
// GetValueForKey, forced return type, manual converter
template<typename T, typename Converter>
std::decay_t<T> GetValueForKey(const Json::Value& json, std::string_view key, Converter&& conv)
{
std::decay_t<T> local{};
GetValueForKey(json, key, local, std::forward<Converter>(conv));
return local; // returns zero-initialized?
}
// GetValue, type-deduced, with automatic converter
template<typename T>
bool GetValue(const Json::Value& json, T& target)
{
return GetValue(json, target, ConversionTrait<typename Detail::DeduceOptional<T>::Type>{});
}
// GetValue, forced return type, with automatic converter
template<typename T>
std::decay_t<T> GetValue(const Json::Value& json)
{
std::decay_t<T> local{};
GetValue(json, local, ConversionTrait<typename Detail::DeduceOptional<T>::Type>{});
return local; // returns zero-initialized or value
}
// GetValueForKey, type-deduced, with automatic converter
template<typename T>
bool GetValueForKey(const Json::Value& json, std::string_view key, T& target)
{
return GetValueForKey(json, key, target, ConversionTrait<typename Detail::DeduceOptional<T>::Type>{});
}
// GetValueForKey, forced return type, with automatic converter
template<typename T>
std::decay_t<T> GetValueForKey(const Json::Value& json, std::string_view key)
{
return GetValueForKey<T>(json, key, ConversionTrait<typename Detail::DeduceOptional<T>::Type>{});
}
// Get multiple values for keys (json, k, &v, k, &v, k, &v, ...).
// Uses the default converter for each v.
// Careful: this can cause a template explosion.
constexpr void GetValuesForKeys(const Json::Value& /*json*/) {}
template<typename T, typename... Args>
void GetValuesForKeys(const Json::Value& json, std::string_view key1, T&& val1, Args&&... args)
{
GetValueForKey(json, key1, val1);
GetValuesForKeys(json, std::forward<Args>(args)...);
}
};
#define JSON_ENUM_MAPPER(...) \
template<> \
struct ::TerminalApp::JsonUtils::ConversionTrait<__VA_ARGS__> : \
public ::TerminalApp::JsonUtils::EnumMapper<__VA_ARGS__, ::TerminalApp::JsonUtils::ConversionTrait<__VA_ARGS__>>
#define JSON_FLAG_MAPPER(...) \
template<> \
struct ::TerminalApp::JsonUtils::ConversionTrait<__VA_ARGS__> : \
public ::TerminalApp::JsonUtils::FlagMapper<__VA_ARGS__, ::TerminalApp::JsonUtils::ConversionTrait<__VA_ARGS__>>
#define JSON_MAPPINGS(Count) \
static constexpr std::array<pair_type, Count> mappings

View File

@@ -4,7 +4,6 @@ the MIT License. See LICENSE in the project root for license information. -->
x:Class="TerminalApp.MinMaxCloseControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:TerminalApp"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
@@ -93,7 +92,21 @@ the MIT License. See LICENSE in the project root for license information. -->
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="CommonStates">
<VisualState x:Name="Normal" />
<VisualStateGroup.Transitions>
<VisualTransition From="PointerOver" To="Normal">
<Storyboard>
<ColorAnimation Storyboard.TargetName="ButtonBaseElement" Storyboard.TargetProperty="(UIElement.Background).(SolidColorBrush.Color)" To="{Binding Color, Source={ThemeResource CaptionButtonBackground}}" Duration="0:0:0.2"/>
<ColorAnimation Storyboard.TargetName="Path" Storyboard.TargetProperty="(UIElement.Stroke).(SolidColorBrush.Color)" To="{Binding Color, Source={ThemeResource CaptionButtonStroke}}" Duration="0:0:0.1"/>
</Storyboard>
</VisualTransition>
</VisualStateGroup.Transitions>
<VisualState x:Name="Normal">
<VisualState.Setters>
<Setter Target="ButtonBaseElement.Background" Value="{ThemeResource CaptionButtonBackground}" />
<Setter Target="Path.Stroke" Value="{ThemeResource CaptionButtonStroke}" />
</VisualState.Setters>
</VisualState>
<VisualState x:Name="PointerOver">
<VisualState.Setters>

View File

@@ -28,6 +28,7 @@ static constexpr std::string_view TabTitleKey{ "tabTitle" };
static constexpr std::string_view SuppressApplicationTitleKey{ "suppressApplicationTitle" };
static constexpr std::string_view HistorySizeKey{ "historySize" };
static constexpr std::string_view SnapOnInputKey{ "snapOnInput" };
static constexpr std::string_view AltGrAliasingKey{ "altGrAliasing" };
static constexpr std::string_view CursorColorKey{ "cursorColor" };
static constexpr std::string_view CursorShapeKey{ "cursorShape" };
static constexpr std::string_view CursorHeightKey{ "cursorHeight" };
@@ -121,6 +122,7 @@ Profile::Profile(const std::optional<GUID>& guid) :
_suppressApplicationTitle{},
_historySize{ DEFAULT_HISTORY_SIZE },
_snapOnInput{ true },
_altGrAliasing{ true },
_cursorShape{ CursorStyle::Bar },
_cursorHeight{ DEFAULT_CURSOR_HEIGHT },
@@ -188,6 +190,7 @@ TerminalSettings Profile::CreateTerminalSettings(const std::unordered_map<std::w
// Fill in the Terminal Setting's CoreSettings from the profile
terminalSettings.HistorySize(_historySize);
terminalSettings.SnapOnInput(_snapOnInput);
terminalSettings.AltGrAliasing(_altGrAliasing);
terminalSettings.CursorHeight(_cursorHeight);
terminalSettings.CursorShape(_cursorShape);
@@ -475,6 +478,8 @@ void Profile::LayerJson(const Json::Value& json)
JsonUtils::GetBool(json, SnapOnInputKey, _snapOnInput);
JsonUtils::GetBool(json, AltGrAliasingKey, _altGrAliasing);
JsonUtils::GetUInt(json, CursorHeightKey, _cursorHeight);
if (json.isMember(JsonKey(CursorShapeKey)))
@@ -870,27 +875,6 @@ CloseOnExitMode Profile::ParseCloseOnExitMode(const Json::Value& json)
return CloseOnExitMode::Graceful;
}
// Method Description:
// - Helper function for converting a CloseOnExitMode to its corresponding string
// value.
// Arguments:
// - closeOnExitMode: The enum value to convert to a string.
// Return Value:
// - The string value for the given CloseOnExitMode
std::string_view Profile::_SerializeCloseOnExitMode(const CloseOnExitMode closeOnExitMode)
{
switch (closeOnExitMode)
{
case CloseOnExitMode::Always:
return CloseOnExitAlways;
case CloseOnExitMode::Never:
return CloseOnExitNever;
case CloseOnExitMode::Graceful:
default:
return CloseOnExitGraceful;
}
}
// Method Description:
// - Helper function for converting a user-specified scrollbar state to its corresponding enum
// Arguments:
@@ -940,29 +924,6 @@ Media::Stretch Profile::ParseImageStretchMode(const std::string_view imageStretc
}
}
// Method Description:
// - Helper function for converting an ImageStretchMode to the
// correct string value.
// Arguments:
// - imageStretchMode: The enum value to convert to a string.
// Return Value:
// - The string value for the given ImageStretchMode
std::string_view Profile::SerializeImageStretchMode(const Media::Stretch imageStretchMode)
{
switch (imageStretchMode)
{
case Media::Stretch::None:
return ImageStretchModeNone;
case Media::Stretch::Fill:
return ImageStretchModeFill;
case Media::Stretch::Uniform:
return ImageStretchModeUniform;
default:
case Media::Stretch::UniformToFill:
return ImageStretchModeUniformTofill;
}
}
// Method Description:
// - Helper function for converting a user-specified image horizontal and vertical
// alignment to the appropriate enum values tuple
@@ -1019,58 +980,6 @@ std::tuple<HorizontalAlignment, VerticalAlignment> Profile::ParseImageAlignment(
}
}
// Method Description:
// - Helper function for converting the HorizontalAlignment+VerticalAlignment tuple
// to the correct string value.
// Arguments:
// - imageAlignment: The enum values tuple to convert to a string.
// Return Value:
// - The string value for the given ImageAlignment
std::string_view Profile::SerializeImageAlignment(const std::tuple<HorizontalAlignment, VerticalAlignment> imageAlignment)
{
const auto imageHorizontalAlignment = std::get<HorizontalAlignment>(imageAlignment);
const auto imageVerticalAlignment = std::get<VerticalAlignment>(imageAlignment);
switch (imageHorizontalAlignment)
{
case HorizontalAlignment::Left:
switch (imageVerticalAlignment)
{
case VerticalAlignment::Top:
return ImageAlignmentTopLeft;
case VerticalAlignment::Bottom:
return ImageAlignmentBottomLeft;
default:
case VerticalAlignment::Center:
return ImageAlignmentLeft;
}
case HorizontalAlignment::Right:
switch (imageVerticalAlignment)
{
case VerticalAlignment::Top:
return ImageAlignmentTopRight;
case VerticalAlignment::Bottom:
return ImageAlignmentBottomRight;
default:
case VerticalAlignment::Center:
return ImageAlignmentRight;
}
default:
case HorizontalAlignment::Center:
switch (imageVerticalAlignment)
{
case VerticalAlignment::Top:
return ImageAlignmentTop;
case VerticalAlignment::Bottom:
return ImageAlignmentBottom;
default:
case VerticalAlignment::Center:
return ImageAlignmentCenter;
}
}
}
// Method Description:
// - Helper function for converting a user-specified cursor style corresponding
// CursorStyle enum value
@@ -1104,31 +1013,6 @@ CursorStyle Profile::_ParseCursorShape(const std::wstring& cursorShapeString)
return CursorStyle::Bar;
}
// Method Description:
// - Helper function for converting a CursorStyle to its corresponding string
// value.
// Arguments:
// - cursorShape: The enum value to convert to a string.
// Return Value:
// - The string value for the given CursorStyle
std::wstring_view Profile::_SerializeCursorStyle(const CursorStyle cursorShape)
{
switch (cursorShape)
{
case CursorStyle::Underscore:
return CursorShapeUnderscore;
case CursorStyle::FilledBox:
return CursorShapeFilledbox;
case CursorStyle::EmptyBox:
return CursorShapeEmptybox;
case CursorStyle::Vintage:
return CursorShapeVintage;
default:
case CursorStyle::Bar:
return CursorShapeBar;
}
}
// Method Description:
// - If this profile never had a GUID set for it, generate a runtime GUID for
// the profile. If a profile had their guid manually set to {0}, this method
@@ -1238,24 +1122,3 @@ TextAntialiasingMode Profile::ParseTextAntialiasingMode(const std::wstring& anti
// default behavior for invalid data
return TextAntialiasingMode::Grayscale;
}
// Method Description:
// - Helper function for converting a TextAntialiasingMode to its corresponding
// string value.
// Arguments:
// - antialiasingMode: The enum value to convert to a string.
// Return Value:
// - The string value for the given TextAntialiasingMode
std::wstring_view Profile::SerializeTextAntialiasingMode(const TextAntialiasingMode antialiasingMode)
{
switch (antialiasingMode)
{
case TextAntialiasingMode::Cleartype:
return AntialiasingModeCleartype;
case TextAntialiasingMode::Aliased:
return AntialiasingModeAliased;
default:
case TextAntialiasingMode::Grayscale:
return AntialiasingModeGrayscale;
}
}

View File

@@ -110,21 +110,16 @@ private:
static winrt::Microsoft::Terminal::Settings::ScrollbarState ParseScrollbarState(const std::wstring& scrollbarState);
static winrt::Windows::UI::Xaml::Media::Stretch ParseImageStretchMode(const std::string_view imageStretchMode);
static winrt::Windows::UI::Xaml::Media::Stretch _ConvertJsonToStretchMode(const Json::Value& json);
static std::string_view SerializeImageStretchMode(const winrt::Windows::UI::Xaml::Media::Stretch imageStretchMode);
static std::tuple<winrt::Windows::UI::Xaml::HorizontalAlignment, winrt::Windows::UI::Xaml::VerticalAlignment> ParseImageAlignment(const std::string_view imageAlignment);
static std::tuple<winrt::Windows::UI::Xaml::HorizontalAlignment, winrt::Windows::UI::Xaml::VerticalAlignment> _ConvertJsonToAlignment(const Json::Value& json);
static winrt::Windows::UI::Text::FontWeight _ParseFontWeight(const Json::Value& json);
static CloseOnExitMode ParseCloseOnExitMode(const Json::Value& json);
static std::string_view _SerializeCloseOnExitMode(const CloseOnExitMode closeOnExitMode);
static std::string_view SerializeImageAlignment(const std::tuple<winrt::Windows::UI::Xaml::HorizontalAlignment, winrt::Windows::UI::Xaml::VerticalAlignment> imageAlignment);
static winrt::Microsoft::Terminal::Settings::CursorStyle _ParseCursorShape(const std::wstring& cursorShapeString);
static std::wstring_view _SerializeCursorStyle(const winrt::Microsoft::Terminal::Settings::CursorStyle cursorShape);
static winrt::Microsoft::Terminal::Settings::TextAntialiasingMode ParseTextAntialiasingMode(const std::wstring& antialiasingMode);
static std::wstring_view SerializeTextAntialiasingMode(const winrt::Microsoft::Terminal::Settings::TextAntialiasingMode antialiasingMode);
static GUID _GenerateGuidForProfile(const std::wstring& name, const std::optional<std::wstring>& source) noexcept;
@@ -147,6 +142,7 @@ private:
bool _suppressApplicationTitle;
int32_t _historySize;
bool _snapOnInput;
bool _altGrAliasing;
uint32_t _cursorHeight;
winrt::Microsoft::Terminal::Settings::CursorStyle _cursorShape;

View File

@@ -189,6 +189,9 @@
<data name="TabColorClearButton.Content" xml:space="preserve">
<value>Reset</value>
</data>
<data name="RenameTabText" xml:space="preserve">
<value>Rename Tab</value>
</data>
<data name="InvalidBackgroundImage" xml:space="preserve">
<value>Found a profile with an invalid "backgroundImage". Defaulting that profile to have no background image. Make sure that when setting a "backgroundImage", the value is a valid file path to an image.</value>
<comment>{Locked="\"backgroundImage\""}</comment>
@@ -253,9 +256,19 @@
<value>Open in the given directory instead of the profile's set "startingDirectory"</value>
<comment>{Locked="\"startingDirectory\""}</comment>
</data>
<data name="CmdTitleArgDesc" xml:space="preserve">
<value>Open the terminal with the provided title instead of the profile's set "title"</value>
<comment>{Locked="\"title\""}</comment>
</data>
<data name="CmdVersionDesc" xml:space="preserve">
<value>Display the application version</value>
</data>
<data name="CmdMaximizedDesc" xml:space="preserve">
<value>Launch the window maximized</value>
</data>
<data name="CmdFullscreenDesc" xml:space="preserve">
<value>Launch the window in fullscreen mode</value>
</data>
<data name="NewTabSplitButton.[using:Windows.UI.Xaml.Automation]AutomationProperties.HelpText" xml:space="preserve">
<value>Press the button to open a new terminal tab with your default profile. Open the flyout to select which profile you want to open.</value>
</data>
@@ -334,4 +347,74 @@
<value>Command Prompt</value>
<comment>This is the name of "Command Prompt", as localized in Windows. The localization here should match the one in the Windows product for "Command Prompt"</comment>
</data>
<data name="CommandPalette_SearchBox.PlaceholderText" xml:space="preserve">
<value>Type a command name...</value>
</data>
<data name="CloseWindowCommandKey" xml:space="preserve">
<value>Close Window</value>
</data>
<data name="ToggleFullscreenCommandKey" xml:space="preserve">
<value>Toggle Fullscreen</value>
</data>
<data name="OpenNewTabDropdownCommandKey" xml:space="preserve">
<value>Open New Tab Dropdown</value>
</data>
<data name="OpenSettingsCommandKey" xml:space="preserve">
<value>Open Settings</value>
</data>
<data name="FindCommandKey" xml:space="preserve">
<value>Find</value>
</data>
<data name="NewTabCommandKey" xml:space="preserve">
<value>New Tab</value>
</data>
<data name="DuplicateTabCommandKey" xml:space="preserve">
<value>Duplicate Tab</value>
</data>
<data name="DuplicatePaneCommandKey" xml:space="preserve">
<value>Duplicate Pane</value>
</data>
<data name="NextTabCommandKey" xml:space="preserve">
<value>Next Tab</value>
</data>
<data name="PrevTabCommandKey" xml:space="preserve">
<value>Prev Tab</value>
</data>
<data name="ClosePaneCommandKey" xml:space="preserve">
<value>Close Pane</value>
</data>
<data name="SplitHorizontalCommandKey" xml:space="preserve">
<value>Split Pane Horizontally</value>
</data>
<data name="SplitVerticalCommandKey" xml:space="preserve">
<value>Split Pane Vertically</value>
</data>
<data name="CopyTextCommandKey" xml:space="preserve">
<value>Copy Text</value>
</data>
<data name="PasteCommandKey" xml:space="preserve">
<value>Paste</value>
</data>
<data name="ScrollDownCommandKey" xml:space="preserve">
<value>Scroll Down One Line</value>
</data>
<data name="ScrollDownPageCommandKey" xml:space="preserve">
<value>Scroll Down One Page</value>
</data>
<data name="ScrollUpCommandKey" xml:space="preserve">
<value>Scroll Up One Line</value>
</data>
<data name="ScrollUpPageCommandKey" xml:space="preserve">
<value>Scroll Up One Page</value>
</data>
<data name="IncreaseFontSizeCommandKey" xml:space="preserve">
<value>Increase Font Size</value>
</data>
<data name="DecreaseFontSizeCommandKey" xml:space="preserve">
<value>Decrease Font Size</value>
</data>
<data name="ResetFontSizeCommandKey" xml:space="preserve">
<value>Reset Font Size</value>
</data>
</root>

View File

@@ -159,6 +159,11 @@ namespace winrt::TerminalApp::implementation
_ToggleFullscreenHandlers(*this, *eventArgs);
break;
}
case ShortcutAction::ToggleCommandPalette:
{
_ToggleCommandPaletteHandlers(*this, *eventArgs);
break;
}
default:
return false;
}

View File

@@ -23,30 +23,31 @@ namespace winrt::TerminalApp::implementation
bool DoAction(const ActionAndArgs& actionAndArgs);
// clang-format off
TYPED_EVENT(CopyText, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(PasteText, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(OpenNewTabDropdown,TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(DuplicateTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NewTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NewWindow, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(CloseWindow, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(CloseTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ClosePane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(SwitchToTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NextTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(PrevTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(SplitPane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(AdjustFontSize, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ResetFontSize, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollUp, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollDown, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollUpPage, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollDownPage, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(OpenSettings, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ResizePane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(Find, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(MoveFocus, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ToggleFullscreen, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(CopyText, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(PasteText, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(OpenNewTabDropdown, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(DuplicateTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NewTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NewWindow, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(CloseWindow, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(CloseTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ClosePane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(SwitchToTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(NextTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(PrevTab, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(SplitPane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(AdjustFontSize, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ResetFontSize, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollUp, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollDown, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollUpPage, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ScrollDownPage, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(OpenSettings, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ResizePane, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(Find, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(MoveFocus, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ToggleFullscreen, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
TYPED_EVENT(ToggleCommandPalette, TerminalApp::ShortcutActionDispatch, TerminalApp::ActionEventArgs);
// clang-format on
private:

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