Compare commits

...

289 Commits

Author SHA1 Message Date
paul cheung
7faf3342e0 minor typo fix (#2863) 2019-09-24 15:34:26 -07:00
Jonas Lomholdt
9ed9e7c8aa doc: fix broken releases link in README.md (#2877) 2019-09-24 13:51:33 -07:00
Michael Niksa
60c6a9fb8f Improve debugging experience of key events (#2872)
... by adding natvis rules for display and by typifying the flags field so the debugger presents it as flags naturally.
2019-09-24 13:50:53 -07:00
Carlos Zamora
a862f3196f Bugfix: EraseInLine off-by-one error (#2879) 2019-09-24 13:05:39 -07:00
Rich Turner
f5071439a3 Writeup Terminal milestones & timeline doc (#2821)
First version, including all addressed feedback.
2019-09-24 06:49:34 -07:00
paul cheung
a9d57ef9ea doc: minor typo fix (#2860) 2019-09-23 19:58:02 -07:00
Dustin L. Howett (MSFT)
a1bd7967e2 conhost: if we start with invalid terminal colors, reset them to sanity (#2855)
* conhost: if we start with invalid terminal colors, reset them to sanity

We've seen a number of cases where the user's settings can get corrupted
and their default foreground/background and cursor color get set to all
black (black on black). This results in a fairly unhappy user and
probably a great number of support incidents.

Let's declare that an invalid state.

* Add some comments to the comments
2019-09-23 18:35:53 -07:00
Dustin L. Howett (MSFT)
90a3d99512 defaults: bind alt+f4 to closeWindow (#2858) 2019-09-23 17:12:00 -07:00
James Holderness
0c8a4df963 Remove unwanted DECSTBM clipping (#2764)
The `DECSTBM` margins are meant to define the range of lines within which
certain vertical scrolling operations take place. However, we were applying
these margin restrictions in the `ScrollRegion` function, which is also used in
a number of places that shouldn't be affected by `DECSTBM`.

This includes the `ICH` and `DCH` escape sequences (which are only affected by
the horizontal margins, which we don't yet support), the
`ScrollConsoleScreenBuffer` API (which is public Console API, not meant to be
affected by the VT terminal emulation), and the `CSI 3 J` erase scrollback
extension (which isn't really scrolling as such, but uses the `ScrollRegion`
function to manipulate the scrollback buffer).

This commit moves the margin clipping out of the `ScrollRegion` function, so it
can be applied exclusively in the places that need it.

With the margin clipping removed from the `ScrollRegion` function, it now had
to be applied manually in the places it was actually required. This included:

* The `DoSrvPrivateReverseLineFeed` function (for the `RI` control): This was
* just a matter of updating the bottom of the scroll rect to the bottom margin
* (at least when the margins were actually set), since the top of the scroll
* rect would always be the top of the viewport.  The
* `DoSrvPrivateModifyLinesImpl` function (for the `IL` and `DL` commands):
* Again this was just a matter of updating the bottom of the scroll rect, since
* the cursor position would always determine the top of the scroll rect.  The
* `AdaptDispatch::_ScrollMovement` method (for the `SU` and `SD` commands):
* This required updating both the top and bottom coordinates of the scroll
* rect, and also a simpler destination Y coordinate (the way the `ScrollRegion`
* function worked before, the caller was expected to take the margins into
* account when determining the destination).

On the plus side, there was now no longer a need to override the margins when
calling `ScrollRegion` in the `AdjustCursorPosition` function. In the first
case, the margins had needed to be cleared (_stream.cpp 143-145), but that is
now the default behaviour. In the second case, there had been a more
complicated adjustment of the margins (_stream.cpp 196-209), but that code was
never actually used so could be removed completely (to get to that point either
_fScrollUp_ was true, so _scrollDownAtTop_ couldn't also be true, or
_fScrollDown_ was true, but in that case there is a check to make sure
_scrollDownAtTop_ is false).

While testing, I also noticed that one of the `ScrollRegion` calls in the
`AdjustCursorPosition` function was not setting the horizontal range correctly
- the scrolling should always affect the full buffer width rather than just the
  viewport width - so I've fixed that now as well.

## Validation Steps Performed

For commands like `RI`, `IL`, `DL`, etc. where we've changed the implementation
but not the behaviour, there were already unit tests that could confirm that
the new implementation was still producing the correct results.

Where there has been a change in behaviour - namely for the `ICH` and `DCH`
commands, and the `ScrollConsoleScreenBuffer` API - I've extended the existing
unit tests to check that they still function correctly even when the `DECSTBM`
margins are set (which would previously have caused them to fail).

I've also tested manually with the test cases in issues #2543 and #2659, and
confirmed that they now work as expected.

Closes #2543
Closes #2659
2019-09-23 16:16:54 -07:00
Mike Griese
1c412d42b3 Enable VT processing by default for ConPTY (#2824)
This change enables VT processing by default for _all_ conpty clients. See #1965 for a discussion on why we believe this is a righteous change.

Also mentioned in the issue was the idea of only checking the `VirtualTerminalLevel` reg key in the conpty startup. I don't think this would be a more difficult change, looks like all we'd need is a simple `reg.LoadGlobalsFromRegistry();` call instead of this change.

# Validation Steps Performed
Manually launched a scratch app in both the terminal and the console. The console launch's output mode was 0x3, and the terminal's was 0x7. 0x4 is the ` ENABLE_VIRTUAL_TERMINAL_PROCESSING` flag, which the client now had by default in the Terminal.

Closes #1965
2019-09-23 15:07:47 -07:00
Dustin L. Howett (MSFT)
277acc3383 Add some retry support to Renderer::PaintFrame (#2830)
If _PaintFrameForEngine returns E_PENDING, we'll give it another two
tries to get itself straight. If it continues to fail, we'll take down
the application.

We observed that the DX renderer was failing to present the swap chain
and failfast'ing when it did so; however, there are some errors from
which DXGI guidance suggests we try to recover. We'll now return
E_PENDING (and destroy our device resources) when we hit those errors.

Fixes #2265.
2019-09-23 15:06:47 -07:00
Carlos Zamora
8afc5b2f59 Bugfix: TextBuffer Line Wrapping from VTRenderer (#2797)
* Bugfix: line selection copy

* Revert clipboard change
Change VT renderer to do erase line instead of a ton of erase chars

* revert TerminalApi change
2019-09-23 09:39:24 -07:00
Gage Ames
b096a57387 Update path to profiles.json in documentation (#2843)
The profiles.json file was moved from RoamingState to LocalState in
PR #2298. Update the documentation to reflect this change.
2019-09-23 09:15:47 -07:00
Carlos Zamora
6b415126fd Improve Accessibility Reliability (#2609)
* Remove WindowUiaProvider entry points
Make TerminalAutomationPeer not crash the app if creation failed.

* code format

* prefer universal initialization

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-09-23 08:59:03 -07:00
Alexander Sklar
bfb1484708 Remember last-used string in the Find dialog in conhost (#2845) 2019-09-23 10:16:40 -04:00
Michael Niksa
56c35945b9 Rework locking and eventing during startup and shutdown to alleviate some VT issues (#2525)
Adjusts the startup and shutdown behavior of most threads in the console host to alleviate race conditions that are either exacerbated or introduced by the VT PTY threads.
2019-09-20 15:43:11 -07:00
James Holderness
9102c5d030 Fix display of the "low ASCII" glyphs in PC code pages (#1964)
In the legacy console, it used to be possible to write out characters
from the C0 range of a PC code page (e.g. CP437), and get the actual
glyphs defined for those code points (at least those that weren't
processed as control codes). In the v2 console this stopped working so
you'd get an FFFD replacement glyph (�) for those characters instead.
This PR fixes the issue so the correct glyphs are displayed again.

There was already code in place to achieve this in the
`WriteCharsLegacy` method. It used the `GetStringTypeW` method to
determine the character type of the value being output, and if it was a
`C1_CNTRL` character it performed the appropriate mapping. The problem
was that the test of the character type flag was done as a direct
comparision, when it should have been a bit test, so the condition was
never met.

With this condition fixed, the code also needed to be reordered slightly
to handle the null character. That had a special-case mapping to space,
which was previously performed after the control test, but since a null
character now successfully matches `C1_CNTRL`, it no longer falls
through to that special case. To address that, I've had to move the null
check above the control test.

I've tested this manually, by trying to output all the characters in the
affected range (ASCII values 0 to 31, and 127, excluding the actual
control codes 8,9,10 and 13). In all cases they now match the output
that the legacy console produced.

Note that this only applies to PC code pages that have glyphs defined
for the C0 range, so it won't work with the UTF-8 code page, but that
was to be expected - the legacy console behaved the same way.

Also, note that this only works when the `ENABLE_PROCESSED_OUTPUT`
console mode is set. That seems wrong to me (I'd expect the glyphs to
work in both cases), but that's the way the legacy console behaved as
well, so if that's a bug it's a separate issue.

I haven't added any unit tests, because I expect the behaviour of some
of these characters to change over time (as support is added for more
control codes), which could then cause the tests to fail. But if that's
not a concern, I could probably add something to the ScreenBufferTests
(perhaps with a comment warning that the tests might be expected to fail
in the future).

Closes #166.
2019-09-20 13:42:36 -07:00
Dustin L. Howett (MSFT)
b84a073464 Package Cascadia Code with the Terminal (release builds) (#2806)
TTF from microsoft/cascadia-code@5f91b87
2019-09-19 16:35:33 -07:00
Dustin L. Howett (MSFT)
b37d6c03ac Update CascadiaPackage to v0.5 2019-09-19 15:51:53 -07:00
Mike Griese
dfaaa44789 Initialize the VT tab stops when a buffer is created in VT mode (#2816)
* fixes #411

* update this comment to actually match

* run this test in isolation so it doesn't break other tests, @dhowett-msft

* This fixes the test that's broken?

  Kinda raises more questions tbh
2019-09-19 15:23:07 -05:00
Mike Griese
7128e873a4 Add validation for hiding all the profiles (#2800)
fixes #2794
2019-09-19 16:54:36 +00:00
Michael Niksa
a62c6cd22b Update SignConfig to use SHA2 variant per governance request. (#2802) 2019-09-19 09:27:42 -07:00
David Madrigal-Hernandez
5705347640 Updated startingDirectory setting description (#2813)
This change add the note about the path for `startingDirectory` needing to be a Windows path.
2019-09-19 11:24:24 -05:00
Dustin L. Howett (MSFT)
5a57c5a6c9 Add a schema reference to the userDefaults and patch one into user data (#2803)
* Add a schema reference to the userDefaults and patch one into existing files
* Only add the , if there's another object in there.
2019-09-18 18:37:23 -07:00
Mike Griese
4b439cf290 Add hidden to the defaults, the userDefaults, and the autogenerated stubs (#2801)
Fixes #2795
2019-09-18 13:37:34 -07:00
mcpiroman
95580b5f11 Bugfix: Escape HTML entities (#2777) 2019-09-17 15:43:24 -07:00
Dustin L. Howett (MSFT)
7edbbd1ccb Don't let one bad Dynamic Profile Generator spoil the bunch (#2798)
Fixes #2796
2019-09-17 15:34:28 -07:00
Carlos Zamora
4217bed9c8 Selection Code Cleanup + Double Click Delimiter Runs (#2511)
* Test: out of bounds selection
* Clean up Selection code:
- selectionVerticalOffset
- proper return values (const)
- Break up GetSelectionRects()

* Fix Delimiter Text Runs (#2552)

* Added helper method and some log comments throughout tests

Closes #1327.
Closes #2261.
Closes #2206.
2019-09-17 10:39:39 -07:00
Michael Niksa
7b47f4601d remove null check from glyph run drawing as it's truly optional (#2791)
Fixes #2724.
2019-09-17 10:25:22 -07:00
Mike Griese
c30ef6d30b Don't explode name-only profiles (#2789)
* Add a test for #2782

* Attempt to do something weird with _GenerateStub

  I was thinking maybe we have the stubs have a GUID included. I like that less though I think. That would mean that DPGs would always have the GUID generated for them, even if the DPG doesn't specify a GUID. I guess that's fine though. No DPG's _aren't_ generating names now so this shouldn't change anything.

* Add some more notes on why this was a bad idea

* Actually fix the issue at hand

  If the profile doesn't have a guid, it's a name-only profile.
  During validation, we'll generate a GUID for the profile, but
  validation occurs after this. We should ignore these types of
  profiles.
  If a dynamic profile was generated _without_ a GUID, we also
  don't want it serialized here. The first check in
  Profile::ShouldBeLayered checks that the profile hasa guid. For a
  dynamic profile without a GUID, that'll _never_ be true, so it
  would be impossible to be layered.

* Revert "Add some more notes on why this was a bad idea"

This reverts commit 85b8b8a53c.

* Revert "Attempt to do something weird with _GenerateStub"

This reverts commit f204b98177.

* Little test fixes

* Update src/cascadia/TerminalApp/CascadiaSettingsSerialization.cpp

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-09-17 10:20:52 -07:00
Martin Lopes
fe6fa04f15 Edits doc section Installing Windows Terminal (#2728)
* Edits doc section `Installing Windows Terminal`

* Adds some light edits throughout.
* Adds link to `winver` documentation.

* Adds link to Microsoft Store listing

Updates procedure to link to https://aka.ms/install-terminal
2019-09-17 08:47:17 -07:00
Kaiyu Wang
5806cdab52 Enable Terminal closing with ALT + F4 and warning of multiple open tabs (#2526)
* ALT+F4 to close the terminal app window and warn user of multiple tabs

* Fix indent issue

* Indentation issue fix 2

* add some comments

* move close window warning texts to resources

* CR feedback changes - 8/28

* fix resource file space issue

* Fix resource file space issue 2

* Fix resource file space issue

* minor CR changes

* update comments

* Sync to the latest master branch

* CR changes round 2

* Format fix

* fix type conversion warning

* CR changes on 9-12

* CR feedback changes on 9-12

* add comments why we remove tabs in reverse order

* Fix warnings
2019-09-16 22:43:27 -07:00
Dustin L. Howett (MSFT)
2d0608d8c0 utils: prevent the corruption of GUID strings (#2765) 2019-09-16 15:01:47 -07:00
Mike Griese
0df02343f1 Add Dynamic Profile Generators (#2603)
_**This PR targets the #2515 PR**_. It does that for the sake of diffing. When this PR and #2515 are both ready, I'll merge #2515 first, then change the target of this branch, and merge this one.

<!-- 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 support for "dynamic profiles", in accordance with the [Cascading Settings Spec](https://github.com/microsoft/terminal/blob/master/doc/cascadia/Cascading-Default-Settings.md#dynamic-profiles). Currently, we have three types of default profiles that fit the category of dynamic profile generators. These are profiles that we want to create on behalf of the user, but require runtime information to be able to create correctly. Because they require runtime information, we can't ship a static version of these profiles as a part of `defaults.json`. These three profile generators are:
* The Powershell Core generator
* The WSL Distro generator
* The Azure Cloud Shell generator

<!-- 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 #754
* [x] I work here
* [x] look at all these **Tests**
* [x] Requires documentation to be updated - This is done as part of the parent PR

<!-- 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

We want to be able to enable the user to edit dynamic profiles that are generated from DPGs. When dynamic profiles are added, we'll add entries for them to the user's `profiles.json`. We do this _without re-serializing_ the settings. Instead, we insert a partial serialization for the profile into the user's settings. 

### Remaining TODOs:
* Make sure that dynamic profiles appear in the right place in the order of profiles -> #2722
* [x] don't serialize the `colorTable` key for dynamic profiles.
* [x] re-parse the user settings string if we've changed it.
*  Handle changing the default profile to pwsh if it exists on first launch, or file a follow-up issue -> #2721

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


<hr>

* Create profiles by layering them

* Update test to layer multiple times on the same profile

* Add support for layering an array of profiles, but break a couple tests

* Add a defaults.json to the package

* Layer colorschemes

  * Moves tests into individual classes
  * adds support for layering a colorscheme on top of another

* Layer an array of color schemes

* oh no, this was missed with #2481

  must have committed without staging this change, uh oh. Not like those tests actually work so nbd

* Layer keybindings

* Read settings from defaults.json + profiles.json, layer appropriately

  This is like 80% of #754. Needs tests.

* Add tests for keybindings

  * add support to unbind a key with `null` or `"unbound"` or `"garbage"`

* Layer or clear optional properties

* Add a helper to get an optional variable for a bunch of different types

  In the end, I think we need to ask _was this worth it_

* Do this with the stretch mode too

* Add back in the GUID check for profiles

* Add some tests for global settings layering

* M A D  W I T H  P O W E R

  Add a MsBuild target to auto-generate a header with the defaults.json as a
  string in the file. That way, we can _always_ load the defaults. Literally impossible to not.

* When the user's profile.json doesn't exist, create it from a template

* Re-order profiles to match the order set in the user's profiles.json

* Add tests for re-ordering profiles to match user ordering

* Add support for hiding profiles using `"hidden": true`

* Use the hardcoded defaults.json for the exception->"use defaults" case

* Somehow I messed up the git submodules?

* woo documentation

* Fix a Terminal.App.Unit.Tests failure

* signed/unsigned is hard

* Use Alt+Settings button to open the default settings

* Missed a signed/unsigned

* Start dynamically creating profiles

* Give the inbox generators a namespace

  and generally hack this a lot less

* Some very preliminary PR feedback

* More PR feedback

  Use the wil helper for the exe path
  Move jsonutils into their own file
  kill some dead code

* Add templates to these bois

* remove some code for generating defaults, reorder defaults.json a tad

* Make guid a std::optional

* Large block of PR feedback

  * Remove some dead code
  * add some comments
  * tag some todos

* stl is love, stl is life

* Serialize the source key

* Make the Azure cloud shell a dynamic profile

* Make the built-in namespaces public

* Add a mechanism for quick-diffing a profile

  This will be used to generate the json snippets for dynamically generated profiles.

* Generate partial serializations of dynamic profiles _not_ in the user settings

* Start writing tests for generating dyn profiles

  * dyn profiles generate GUIDs based on _source
  * we won't run DPGs when they'd disabled?

* Add more DPG tests - TestDontRunDisabledGenerators

* Don't layer profiles with a source that's also different

* Add another test, DoLayerUserProfilesOnDynamicsWhenSourceMatches

* Actually insert new dynamic profiles into the file

* Minor cleanup of `Profile::ShouldBeLayered`

* Migrate legacy profiles gracefully

* using namespace winrt::Windows::UI::Xaml;

* _Only_ layer dynamic profiles from user settings, never create

* Write a test for migrating dynamic profiles

* Comments for dayssssss

* add `-noprofile`

* Fix the crash that dustin found

* -Encoding ASCII

* Set a profile's default scheme to Campbell

* Fix the tests I regressed

* Update UsingJsonSetting.md to reflect that changes from these PRs

* Change how GenerateGuidForProfile works

* Make AppKeyBindings do its own serialization

* Remove leftover dead code from the previous commit

* Fix up an enormous number of PR nits

* Don't layer a profile if the json doesn't have a GUID

* Fix a test I unfixed

* get rid of extraneous bois{};

* Piles of PR feedback

* Collection of PR nits

* PR nits

* Fix a typo; Update the defaults to match #2378

* Tiny nits

* In-den-taition!

* Some typos, PR nits

* Fix this broken defaults case

* Apply suggestions from code review

Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>

* PR nits
2019-09-16 13:34:27 -07:00
Mike Griese
8ba8f35dc5 Add Cascading User + Default Settings (#2515)
This PR represents the start of the work on Cascading User + default settings, #754.

Cascading settings will be done in two parts: 
* [ ] Layered Default+User settings (this PR)
* [ ] Dynamic Profile Generation (#2603).

Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master.

This PR covers adding one primary feature: the settings are now in two separate files:
* a static `defaults.json` that ships with the package (the "default settings")
* a `profiles.json` with the user's customizations (the "user settings)

User settings are _layered_ upon the settings in the defaults settings.

## References

Other things that might be related here:
* #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state 
* #1398 - This might have honestly been solved by #2475 

## PR Checklist
* [x] Closes #754
* [x] Closes #1378 
* [x] Closes #2566
* [x] I work here
* [x] Tests added/passed
* [x] Requires documentation to be updated - it **ABSOLUTELY DOES**


## Detailed Description of the Pull Request / Additional comments

1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 
2. Next, we add tests for layering properties like that.
3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings.
4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk.
5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values.
6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is.
7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything.
8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles.

## TODO:
* [x] Still need to make Alt+Click work on the settings button
* [x] Need to write some user documentation on how the new settings model works
* [x] Fix the pair of tests I broke (re: Duplicate profiles)


<hr>

* Create profiles by layering them

* Update test to layer multiple times on the same profile

* Add support for layering an array of profiles, but break a couple tests

* Add a defaults.json to the package

* Layer colorschemes

  * Moves tests into individual classes
  * adds support for layering a colorscheme on top of another

* Layer an array of color schemes

* oh no, this was missed with #2481

  must have committed without staging this change, uh oh. Not like those tests actually work so nbd

* Layer keybindings

* Read settings from defaults.json + profiles.json, layer appropriately

  This is like 80% of #754. Needs tests.

* Add tests for keybindings

  * add support to unbind a key with `null` or `"unbound"` or `"garbage"`

* Layer or clear optional properties

* Add a helper to get an optional variable for a bunch of different types

  In the end, I think we need to ask _was this worth it_

* Do this with the stretch mode too

* Add back in the GUID check for profiles

* Add some tests for global settings layering

* M A D  W I T H  P O W E R

  Add a MsBuild target to auto-generate a header with the defaults.json as a
  string in the file. That way, we can _always_ load the defaults. Literally impossible to not.

* When the user's profile.json doesn't exist, create it from a template

* Re-order profiles to match the order set in the user's profiles.json

* Add tests for re-ordering profiles to match user ordering

* Add support for hiding profiles using `"hidden": true`

* Use the hardcoded defaults.json for the exception->"use defaults" case

* Somehow I messed up the git submodules?

* woo documentation

* Fix a Terminal.App.Unit.Tests failure

* signed/unsigned is hard

* Use Alt+Settings button to open the default settings

* Missed a signed/unsigned

* Some very preliminary PR feedback

* More PR feedback

  Use the wil helper for the exe path
  Move jsonutils into their own file
  kill some dead code

* Add templates to these bois

* remove some code for generating defaults, reorder defaults.json a tad

* Make guid a std::optional

* Large block of PR feedback

  * Remove some dead code
  * add some comments
  * tag some todos

* stl is love, stl is life

* add `-noprofile`

* Fix the crash that dustin found

* -Encoding ASCII

* Set a profile's default scheme to Campbell

* Fix the tests I regressed

* Update UsingJsonSetting.md to reflect that changes from these PRs

* Change how GenerateGuidForProfile works

* Make AppKeyBindings do its own serialization

* Remove leftover dead code from the previous commit

* Fix up an enormous number of PR nits

* Fix a typo; Update the defaults to match #2378

* Tiny nits

* Some typos, PR nits

* Fix this broken defaults case
2019-09-16 12:57:10 -07:00
mcpiroman
ed87689c04 Set Proper Background Color in HTML Copy (#2762)
* Set actual background color in HTML copy

* const

Co-Authored-By: Mike Griese <migrie@microsoft.com>

* format
2019-09-16 10:32:04 -07:00
Carlos Zamora
3d35e396b2 Bugfix: CLS should clear current active buffer (#2729)
CLS calls two functions: 
- `SetConsoleCursorPositionImpl()`
- `ScrollConsoleScreenBufferWImpl()`
Both of these were not checking which buffer to apply to (main vs active buffer).

Now we get the active buffer and apply the changes to that one.

Also, we forgot to switch out of the alt buffer in the previous test. Added that in.

Closes #1189.
2019-09-13 14:36:01 -07:00
Dustin L. Howett (MSFT)
b693fd484a wap: add some workaround to ensure that our package builds on 16.3 (#2730)
Fixes #2625.
2019-09-13 14:34:41 -07:00
James Holderness
1fccbc5304 Move cursor to left margin for IL and DL controls (#2731)
* Move cursor position to the left margin after execution of the IL and DL escape sequences.
* Update IL and DL screen buffer tests to account for the cursor moving to the left margin.
2019-09-12 10:46:38 -07:00
Martin Lopes
537258a60f Edits doc section Configuring Windows Terminal (#2719)
* Edits doc section `Configuring Windows Terminal`

* Converts into a procedure.
* Uses `⌵` character to replace the `down` UI element.

* Additional minor edit

Updates formatting, edits for brevity.

* Fixed json path

Added `8wekyb3d8bbwe` to file path.
2019-09-11 09:24:20 -07:00
kynapse
b5fe4ffd54 Update link to Background Images and Icons section (#2725) 2019-09-11 09:21:15 -07:00
James Holderness
12d2e170dd Correct the boundaries of the scrolling commands (#2505)
There are a number of VT escape sequences that rely on the `ScrollRegion`
function to scroll the viewport (RI, DL, IL, SU, SD, ICH, and DCH) , and all of
them have got the clipping rect or scroll boundaries wrong in some way,
resulting in content being scrolled off the screen that should have been
clipped, revealed areas not being correctly filled, or parts of the screen not
being moved that should have been. This PR attempts to fix all of those issues.

The `ScrollRegion` function is what ultimately handles the scrolling, but it's
typically called via the `ApiRoutines::ScrollConsoleScreenBufferWImpl` method,
and it's the callers of that method that have needed correcting.

One "mistake" that many of these operations made, was in setting a clipping
rect that was different from the scrolling rect. This should never have been
necessary, since the area being scrolled is also the boundary into which the
content needs to be clipped, so the easiest thing to do is just use the same
rect for both parameters.

Another common mistake was in clipping the horizontal boundaries to the width
of the viewport. But it's really the buffer width that represents the active
width of the screen - the viewport width and offset are merely a window on that
active area. As such, the viewport should only be used to clip vertically - the
horizontal extent should typically be the full buffer width.

On that note, there is really no need to actually calculate the buffer width
when we want to set any of the scrolling parameters to that width. The
`ScrollRegion` function already takes care of clipping everything within the
buffer boundary, so we can simply set the `Left` of the rect to `0` and the
`Right` to `SHORT_MAX`.

More details on individual commands:

* RI (the `DoSrvPrivateReverseLineFeed` function)
  This now uses a single rect for both the scroll region and clipping boundary,
  and the width is set to `SHORT_MAX` to cover the full buffer width. Also the
  bottom of the scrolling region is now the bottom of the viewport (rather than
  bottom-1), otherwise it would be off by one.

* DL and IL (the `DoSrvPrivateModifyLinesImpl` function)
  Again this uses a single rect for both the scroll region and clipping
  boundary, and the width is set to `SHORT_MAX` to cover the full width. The
  most significant change, though, is that the bottom boundary is now the
  viewport bottom rather than the buffer bottom. Using the buffer bottom
  prevented it clipping the content that scrolled off screen when inserting,
  and failed to fill the revealed area when deleting.

* SU and SD (the `AdaptDispatch::_ScrollMovement` method)
  This was already using a single rect for both the scroll region and clipping
  boundary, but it was previously constrained to the width of the viewport
  rather than the buffer width, so some areas of the screen weren't correctly
  scrolled. Also, the bottom boundary was off by 1, because it was using an
  exclusive rect while the `ScrollRegion` function expects inclusive rects.

* ICH and DCH (the `AdaptDispatch::_InsertDeleteHelper` method)
  This method has been considerably simplified, because it was reimplementing a
  lot of functionality that was already provided by the `ScrollRegion`
  function. And like many of the other cases, it has been updated to use a
  single rect for both the scroll region and clipping boundary, and clip to the
  full buffer width rather than the viewport width.

I should add that if we were following the specs exactly, then the SU and SD
commands should technically be panning the viewport over the buffer instead of
moving the buffer contents within the viewport boundary. So SU would be the
equivalent of a newline at the bottom of the viewport (assuming no margins).
And SD would assumedly do the opposite, scrolling the back buffer back into
view (an RI at the top of the viewport should do the same).

This doesn't seem to be something that is consistently implemented, though.
Some terminals do implement SU as a viewport pan, but I haven't seen anyone
implement SD or RI as a pan. If we do want to do something about this, I think
it's best addressed as a separate issue.

## Validation Steps Performed

There were already existing tests for the SU, SD, ICH, and DCH commands, but
they were implemented as adapter tests, which weren't effectively testing
anything - the `ScrollConsoleScreenBufferW` method used in those tests was just
a mock (an incomplete reimplementation of the `ScrollRegion` function), so
confirming that the mock produced the correct result told you nothing about the
validity of the real code.

To address that, I've now reimplemented those adapter tests as screen buffer
tests. For the most part I've tried to duplicate the functionality of the
original tests, but there are significant differences to account for the fact
that scrolling region now covers the full width of the buffer rather than just
the viewport width.

I've also extended those tests with additional coverage for the RI, DL, and IL
commands, which are really just a variation of the SU and SD functionality.

Closes #2174
2019-09-10 18:20:46 -07:00
Fredi Machado
2da3b49c9e Fix json settings documentation (#2699)
* Fix json settings documentation

The ctrl+c issue was fixed in [#2446](https://github.com/microsoft/terminal/pull/2446)

* Update UsingJsonSettings.md
2019-09-10 16:08:15 -07:00
Michael Niksa
2063197605 Add SECURITY.md to repo (#2720)
Open Source program office guidelines encourage us to add this information to our repository. So I'm doing it.

Sourced from https://github.com/microsoft/microsoft.github.io/blob/master/SECURITY.MD
2019-09-10 15:56:50 -07:00
Carlos Zamora
2ac24979da Stylus Selection Support (#2586) 2019-09-10 10:29:31 -06:00
Michael Niksa
429af0e6fa Merge pull request #2607 from microsoft/dev/miniksa/audit-a
Crank up static analysis audit
2019-09-09 17:12:09 -07:00
Michael Niksa
18bacfe973 A few PR comments. A constexpr here, a misleading comment there, and an extraneous local. 2019-09-09 16:01:28 -07:00
Mike Griese
bac69f7cab When inserting/deleting lines, preserve RGB/256 attributes (#2668)
* This fixes #832 by not mucking with roundtripping attributes. Still needs a test

* Add a test

* Lets just make this test test everything

  @miniksa https://media0.giphy.com/media/d7mMzaGDYkz4ZBziP6/giphy.gif

* Remove dead code
2019-09-09 15:06:50 +00:00
Mike Griese
ce34c7320c Prevent "Options" propsheet from reverting cursor shape settings (#2663)
* this actually fixes #1219

* the terminal page should check the checkbox on the options page

* Discard these changes from #2651

* Add comments, pull function out to helper
2019-09-09 14:45:05 +00:00
Martin Lopes
badbbc43a4 doc: amend docs procedure for Running a Different Shell (#2605)
* Amends user-docs procedure

Amends docs procedure for `Running a Different Shell`:
* Adds an overview sentence.
* Adds some light rephrasing.
* Proposes using the countersink arrow `⌵` to depict the `down` GUI element.

* Adds link to WSL installation guide
2019-09-08 19:20:17 -07:00
Michael Niksa
fecddafad5 Changed feedback hub request rule (#2680)
We were using a tag to trigger the bot for the verbose feedback hub response.

But...
1. We have run into several instances of the bot aggressively replying multiple times before the tag is removed.
2. We asked for a "comment contains" function in the bot and the Fabric Bot team obliged.

So I've changed it to `/duplicate` from the tag trigger and will remove the tag.
2019-09-06 08:55:13 -05:00
Michael Niksa
d8ff47a0d3 Some of the PR feedback. 2019-09-05 17:21:54 -07:00
Mike Griese
125e1771ae Add some logging around startup, connection start timing (#2544)
Adds a number of TL events we can use to track startup time better. Adds events for:
* Initial exe start
* Time the window is created
* time we start loading settings
* time we finish loading setings
* time when a connection recieves its first byte

Also updates our `ConnectionCreated` event to include the session GUID, so that we can correlate that with the connection's `RecievedFirstByte` event.
2019-09-05 15:38:42 -05:00
Mike Griese
c58033cda2 Don't crash when restore-down'ing the alt buffer (#2666)
## Summary of the Pull Request

When a user had "Disable Scroll Forward" enabled and switched to the alt buffer and maximized the console, then restored down, we'd crash. Now we don't.

## References

## PR Checklist
* [x] Closes #1206 
* [x] I work here
* [x] Tests added/passed

## Detailed Description of the Pull Request / Additional comments

The problem is that we'd previously try to "anchor" the viewport to the virtual bottom when resizing like this. This would also cause us to move the top of the viewport down, into the buffer. However, if the alt buffer is getting smaller, we don't want to do this - if we anchor to the old _virtualBottom, the bottom of the viewport will actually be outside the current buffer.

This could theoretically happen with the main buffer too, but it's much easier to repro with the alt buffer.
2019-09-05 15:37:27 -05:00
Michael Niksa
fc81adf32f use the array size for the read bounds. using extent on the newly-converted-to-array type doesn't give the correct value. 2019-09-05 13:09:36 -07:00
Michael Niksa
689c21e802 PR feedback. 2019-09-05 11:17:13 -07:00
Michael Niksa
96cc7727bc Add GH issue IDs to all the suppress/disables that I left behind as they were a bit too challenging to solve with this giant PR 2019-09-05 11:14:43 -07:00
Michael Niksa
886d018bb4 warnings as errors for cppwinrt projects, then fix the warnings (#2660)
Fixes #1155.
2019-09-04 16:43:45 -07:00
Michael Niksa
d0c207bc9c fix remaining issues that appeared on merge. 2019-09-04 15:45:22 -07:00
Kaiyu Wang
ce3028e12f Clean up boundary between terminal app and terminal page (#2208)
* change 1: add settings pointer and some member variables to page

* clean up the boundary between Page and App - First working version

* First CR review change

* Sync and remove declaration of TraceLogger provider

* Code review round 2 - apply missed new changes

* remove useless comment

* CR change round 3

* CR minor changes

* apply changes from Aug 6th to Aug 14th

* Code review changes round 4

* Apply changes on Aug 16

* Cr changes on 8/20

* CR changes on 8-26

* correct syncing mistakes and fix formatting issues

* CR changes on 8-29

* CR changes 9-4

* apply new changes of App

* Format fix
2019-09-04 14:34:06 -07:00
Michael Niksa
b7c1e05060 code formatter, you're killing me. 2019-09-04 13:40:10 -07:00
Michael Niksa
3bff2a3eb0 fix merge conflict with master 2019-09-04 13:35:31 -07:00
Michael Niksa
7c66e66ca1 Fix redefinition of class name for constexpr method I moved from CPP to HPP. 2019-09-04 12:49:15 -07:00
Dustin L. Howett (MSFT)
e0762f6bb3 Open-source the PseudoConsole family of functions in a new DLL (#2611)
This pull request introduces a copy of the code from kernel32.dll that
implements CreatePseudoConsole, ClosePseudoConsole and
ResizePseudoConsole. Apart from some light modifications to fit into the
infrastructure in this project and support launching OpenConsole.exe, it
is intended to be 1:1 with the code that ships in Windows.

Any guideline violations in this code are likely intentional. Since this
was built into kernel32, it uses the STL only _very sparingly._

Consumers of this library must make sure that conpty.lib lives earlier
in the link line than onecoreuap_apiset, onecoreuap, onecore_apiset,
onecore or kernel32.

Refs #1130.
2019-09-04 12:03:44 -07:00
Konstantin Yakushev
51f53535d1 Add support for short hex color codes like #CCC (#2658)
This adds a few lines to support shorthand color hex codes like #ABC. They are treated as equivalent of #AABBCC.

Fixes #2639.
2019-09-04 11:45:35 -07:00
Rich Turner
21067a7629 Fixes #1918 - Added docs for image/icon settings & paths (#2545)
* Fixes #1918 - Added docs for image/icon settings & paths

* Described URI Schemes & their use
* Added guidance re. background images
* Added notes re. icons (inc. sizing)
* Added example JSON & screenshot of background & icon
2019-09-04 11:21:39 -07:00
Michael Niksa
7d9534bfa8 constexprs have to go into the headers or other usages can't find them. Imagine that. 2019-09-04 10:59:18 -07:00
Michael Niksa
6735311fc9 Suppress last two errors (C26455 default constructor throw in DxEngine because it's due for refactoring soon anyway & C26444 custom construction/destruction on OutputCellIterator because I can't see what's going on and it needs more investigation and shouldn't hold this up). Also run codeformat. 2019-09-03 16:18:19 -07:00
Michael Niksa
4204733c34 C26481, don't use pointer arithmetic. Convert to measuring string within known limit and using view. 2019-09-03 15:48:02 -07:00
Michael Niksa
23b4a466f5 C26429, C26481, don't use pointer arithmetic, test for nullness. Also eliminated completely unused GetTextRaw. Left todo behind for pointers as iterator boundaries in CharRowCellReference to fix later. 2019-09-03 15:41:37 -07:00
Michael Niksa
01bd77003c C26429, mark as not_null if not testing for nullness. 2019-09-03 15:23:44 -07:00
Michael Niksa
ae25a32913 C26497, you can mark this thing as constexpr. 2019-09-03 15:18:01 -07:00
Michael Niksa
93aa9455e2 C26429, test for nullness or mark as not_null (and a few cascading warnings. 2019-09-03 15:14:44 -07:00
Michael Niksa
41f209f6d3 C26440, default constructors should be noexcept. 2019-09-03 15:10:33 -07:00
Michael Niksa
244fb72fee C26490, no reinterpret_cast. Just use the actual struct and copy instead of relying on the wink/nudge fact they're defined the same way. 2019-09-03 15:09:30 -07:00
Michael Niksa
3a0da64276 C26490, no reinterpret_cast. Suppress on OutputCellIterator because fixing it will make trouble in the Windows build if we're not careful thanks to non-differentiation of wchar_t and DWORD. 2019-09-03 15:08:48 -07:00
Michael Niksa
b2c093fa2f C26455, default constructor may not throw, mark as nothrow (another trivial one) 2019-09-03 15:04:42 -07:00
Michael Niksa
87f5852a72 Define actual constructor for CodepointWidthDetector as default isn't cutting it. 2019-09-03 15:03:54 -07:00
Michael Niksa
e14a59a1b6 C26455, default constructor may not throw. Mark noexcept. (Trivial cases.) 2019-09-03 14:57:14 -07:00
Michael Niksa
cd144e98c6 C26436, destructor definition required for class with virtual methods. 2019-09-03 14:52:00 -07:00
Michael Niksa
c7f0a3439d C26490, don't reinterpret_cast. It looks like the buffer can easily be char. Also use brace initialization per feedback. 2019-09-03 14:39:23 -07:00
Michael Niksa
5d60d69e86 C26426, global initializer calls non-constexpr. This is an easy move to wstring_view. 2019-09-03 14:33:00 -07:00
Michael Niksa
072bbfd09d C26426, global initializer calls non-constexpr. This needs further consideration. I brifely tried to turn GlyphWidth into a singleton class but it cascaded into interesting far corners of the code because IsGlyphFullWidth was liberally used everywhere for a long time. I'm punting here to a future work item. 2019-09-03 14:32:44 -07:00
Michael Niksa
b87f8f9070 C26426, global initializers calling non-constexpr. Suppress for default settings as changing to wstring_view cascades through the entire codebase (non-trivial, string_views aren't guaranteed as Z terminated.) 2019-09-03 14:30:40 -07:00
Michael Niksa
b78d9176ae C26434, do not hide base class methods. Overriding this one because it's going to require design changes that need a future todo. 2019-09-03 14:22:02 -07:00
Michael Niksa
3bbd8f4c97 C26443, overriding destructors shouldn't declare virtual nor override. 2019-09-03 14:14:07 -07:00
Michael Niksa
2d3f285894 C26432, rule-of-five (if you define one of destruct/copy/move, then define them all) 2019-09-03 13:45:16 -07:00
Michael Niksa
49ff36bfc3 Reflect inbox changes in 8c63dff
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/190820-1847 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 73e964d4046c37df3030970cae1ae32e83103fb5

(cherry picked from commit 8c63dff982093db1af7e2bb46b49af884dfec0c5)
2019-09-03 13:32:31 -07:00
Michael Niksa
d8bc94f13c forgot all return paths to _FillRectangle. 2019-09-03 13:30:03 -07:00
Michael Niksa
dd49c3ed51 C26460, use const on params that are unchanged (and remove some unnecessary span refs). 2019-09-03 13:02:09 -07:00
Michael Niksa
9678dd894c C26414, don't use smart pointers for locals 2019-09-03 11:27:43 -07:00
Michael Niksa
45e599368f C26430, not tested for nullness on all paths. I will just always check for null as a defense against a bad QI implementation. 2019-09-03 11:20:27 -07:00
Michael Niksa
594dca993b C26429, mark gsl::not_null on places where we don't test for null (shouldn't need to, internal methods only. 2019-09-03 11:18:28 -07:00
Michael Niksa
c956913a28 C26497, use constexpr for functions that could be evaluated at compile time. 2019-09-03 10:30:06 -07:00
Michael Niksa
b180406b07 C26445, wstring_view byref may indicate a lifetime issue 2019-09-03 10:19:59 -07:00
Michael Niksa
bbdfdf91eb C26462, const local variables that are unchanged. 2019-09-03 10:04:30 -07:00
Michael Niksa
d5d7cf420d C26494, uninitalized local variables 2019-09-03 10:02:18 -07:00
Michael Niksa
81ab5803aa C26473, do not cast pointer back to the same type. 2019-09-03 09:44:19 -07:00
Michael Niksa
7d4096bbbf C26485, refactor to avoid array-to-pointer decay. 2019-09-03 09:40:31 -07:00
Michael Niksa
230e7f43e0 C26466, disable dynamic_cast rule because we're not RTTI due to OS policy. Also reinstitute C6001 and C6011 because they're not actually a part of the 'core checks' and they're goodness we had before I turned them off at the beginning of this series. 2019-09-03 09:15:49 -07:00
Michael Niksa
cdfbf8f106 C26474, don't use static_cast when an implicit cast is acceptable. 2019-09-03 08:53:54 -07:00
Michael Niksa
30e8e7f3a3 C26429, symbols not tested for nullness. 2019-09-03 08:46:24 -07:00
Dustin L. Howett (MSFT)
feb5b18296 doc: move cascadia specs and rename them to spec format (#2593) 2019-08-29 17:32:27 -07:00
Carlos Zamora
7ec6bfc01c catch failure to open clipboard (#2590) 2019-08-29 17:31:53 -07:00
Michael Niksa
4f1157c044 C26447,C26440 - is noexcept but can throw or doesn't throw but not noexcept 2019-08-29 15:23:07 -07:00
Michael Niksa
8c3a629b52 C26481, don't use pointer arithemetic. use span. 2019-08-29 14:08:47 -07:00
Michael Niksa
8579d8905a C26451, promote before arithmetic if storing in larger result size (or use safe math) 2019-08-29 13:41:51 -07:00
Michael Niksa
50e2d0c433 C26433, overrides should be explicit. 2019-08-29 13:23:32 -07:00
Michael Niksa
8ea7401dc9 C26472, no static_cast for arithmetic conversions. narrow or narrow_cast 2019-08-29 13:19:01 -07:00
Michael Niksa
a381f6a042 C26435, choose one of virtual, override, or final 2019-08-29 13:07:08 -07:00
Michael Niksa
c63289b114 C26493, no C-style casts. 2019-08-29 12:45:16 -07:00
Michael Niksa
b33a59816e C26496, mark const if it's never written after creation 2019-08-29 11:27:39 -07:00
Michael Niksa
bd2d5ddb4b C26477, don't use 0 or NULL, use nullptr. 2019-08-29 11:12:55 -07:00
Michael Niksa
23897b1bd4 [Complex] C26446, Use .at instead of array indices - Reword UTF8OutPipeReader to use std::array so we can use .at and move some pointers to iterators. 2019-08-29 11:09:44 -07:00
Michael Niksa
65dec36cb1 C26446, Use .at instead of array indices 2019-08-29 11:05:32 -07:00
Michael Niksa
1989eb9d00 Make warnings errors for static analysis. 2019-08-29 10:27:29 -07:00
Kayla Cinnamon
cb02ca7534 Changed default padding to 8,8,8,8 and default font size to 11 (#2378)
* changed default padding to 5,5,5,5 and default font size to 11

* updated documentation

* changed padding to 8
2019-08-29 09:47:01 -07:00
brightbluejay
5de63096ac Update building.md (#2501)
minor spelling corrections
2019-08-29 09:46:32 -07:00
Michael Niksa
f93adb9540 Added more bot rules (#2502)
* Added more bot rules

* Update bot.md
2019-08-29 09:45:02 -07:00
drebelsky
0d12a25b2d Fix typo (#2538)
changed "an file" to "a file"
2019-08-29 09:41:10 -07:00
Martin Lopes
5e38bcd754 Fixed typo in user-docs (#2592)
Fixed typo "the the".
2019-08-28 17:43:29 -07:00
Richard Szalay
f4294b17d7 Clean up Pane (#2494)
* Merge pane splitting methods

Having separate Horizontal/Vertical versions made it hard to manage, and App.cpp already made use of Pane::SplitState so it made sense to have that be the descriminator

* Rename Tab::(Can)AddSplit to (Can)SplitPane to align with Pane methods

Split was used as a noun in Tab but a verb in Pane, which felt odd

* Remove unused local variable in Pane::_CanSplit

* Remove redundant 'else' branches in Pane

Improves readibility for all 'low hanging fruit' cases where the 'if' was returning.
2019-08-28 07:40:16 -07:00
James Holderness
974e95ebf7 Make the RIS command clear the display and scrollback correctly (#2367)
When the scrollback buffer is empty, the RIS escape sequence (Reset to Initial
State) will fail to clear the screen, or reset any of the state. And when there
is something in the scrollback, it doesn't get cleared completely, and the
screen may get filled with the wrong background color (it should use the
default color, but it actually uses the previously active background color).
This commit attempts to fix those issues.

The initial failure is caused by the `SCREEN_INFORMATION::WriteRect` method
throwing an exception when passed an empty viewport. And the reason it's passed
an empty viewport is because that's what the `Viewport::Subtract` method
returns when the result of the subtraction is nothing.  The PR fixes the
problem by making the `Viewport::Subtract` method actually return nothing in
that situation. 

This is a change in the defined behavior that also required the associated
viewport tests to be updated. However, it does seem a sensible change, since
the `Subtract` method never returns empty viewports under any other
circumstances. And the only place the method seems to be used is in the
`ScrollRegion` implementation, where the previous behavior is guaranteed to
throw an exception.

The other issues are fixed simply by changing the order in which things are
reset in the `AdaptDispatch::HardReset` method. The call to `SoftReset` needed
to be made first, so that the SGR attributes would be reset before the screen
was cleared, thus making sure that the default background color would be used.
And the screen needed to be cleared before the scrollback was erased, otherwise
the last view of the screen would be retained in the scrollback buffer.

These changes also required existing adapter tests to be updated, but not
because of a change in the expected behaviour. It's just that certain tests
relied on the `SoftReset` happening later in the order, so weren't expecting it
to be called if say the scrollback erase had failed. It doesn't seem like the
tests were deliberately trying to verify that the SoftReset _hadn't_ been
called.

In addition to the updates to existing tests, this PR also add a new screen
buffer test which verifies the display and scrollback are correctly cleared
under the conditions that were previously failing.

Fixes #2307.
2019-08-27 18:45:38 -07:00
Mike Griese
cffa033116 When we reload a profile, always use the same GUID for it (#2542)
This ensures that settings reload works for profiles w/o GUIDs
2019-08-26 10:21:30 -07:00
Dustin L. Howett (MSFT)
ebcf8126dc connection: start up the output thread _only after_ all the pipes are up (#2528)
Fixes #2527
2019-08-26 10:21:10 -07:00
Marcel Freiberg
02d8df8431 Don't treat the Windows keys as input (#2514)
Fixes #2506.
2019-08-23 10:56:26 -07:00
brightbluejay
949839fdd8 doc: Update Keybindings-Arguments.md (#2498)
Minor grammar and spelling changes
2019-08-23 10:55:28 -07:00
Dustin L. Howett (MSFT)
e7c78c8d28 Update package version to 0.4 2019-08-22 15:38:30 -07:00
Dustin L. Howett (MSFT)
1006e98780 az: Don't fail when a tenant doesn't have a knowable name (#2508)
On occasion, in certain delegated access scenarios, we'll fail to read
the name of one or more of the user's Azure tenants. We would summarily
explode (because we're being strict about our incoming JSON, and we
didn't know that this was possible.)

Now we'll substitute in an alternate name and present the ID.

Fixes #2249.

* Update src/cascadia/TerminalConnection/AzureConnection.cpp
2019-08-22 12:05:18 -07:00
Dustin L. Howett (MSFT)
9ff90ba174 az: Introduce a "credential version" to force old credentials to be deleted (#2492)
When we change the client ID, we're going to need to force people to log
in again.

We can do that either by:

1. Trying to log in and refresh the user's token and failing (displaying
   a cryptic message like "you aren't on the internet, please get on the
   internet"), **OR** by...
2. Getting out ahead of it, detecting when we would have failed for client
   ID (and other) reasons, and _not trying at all._

This is option 2.
2019-08-21 14:55:28 -07:00
brightbluejay
5694606aea doc: Update submitting_code.md (#2499)
Minor spelling corrections
2019-08-21 10:38:51 -07:00
brightbluejay
84d19f5348 doc: Update bot.md (#2500)
minor spelling correction
2019-08-21 10:38:27 -07:00
Paul-00910
6d50fb4d31 doc: More clear path instructions (#2497) 2019-08-21 09:14:55 -07:00
Nathan Metzger
d1a3e6d2b8 doc: startingDirectory formatting note (#2415) 2019-08-20 19:16:16 -07:00
Carlos Zamora
be52880620 Accessibility: Add BoundingRects to UiaTextRanges (#2423) 2019-08-20 17:50:34 -07:00
MikeTheGreat
e92efa5bc0 doc: svg currently doesn't work; using .jpg instead (#2443)
Since the JPG won't stretch nicely we're also going to put it in the top-right corner without any scaling
2019-08-20 16:35:16 -07:00
Carlos Zamora
667c0286c1 Accessibility: Refactor Providers (#2414)
Refactors the accessibility providers (ScreenInfoUiaProvider and UiaTextRange) into a better separated model between ConHost and Windows Terminal.

ScreenInfoUiaProviderBase and UiaTextRangeBase are introduced. ConHost and Windows Terminal implement their own versions of ScreenInfoUiaProvider and UiaTextRange that inherit from their respective base classes.

WindowsTerminal's ScreenInfoUiaProvider --> TermControlUiaProvider
2019-08-20 16:32:44 -07:00
Dustin L. Howett (MSFT)
28b767d00b dx: Render all gridlines (and, bonus: the box cursor) properly (#2491)
Since we're rendering with antialiasing enabled, we need to make sure
we're stroking actual pixels; to do that, we need to adjust all of our
coordinates by the StrokeWidth / 2. We're always using a stroke width of
1, so that means 0.5.

While I was here, I took the opportunity to fix the color of the grid
lines. Fixes #543.
2019-08-20 16:14:26 -07:00
Mike Griese
8096d7cf2f Don't overwrite the settings file (#2475)
This is more trouble than it's worth. We had code before to re-serialize
  settings when they changed, to try and gracefully migrate settings from old
  schemas to new ones. This is good in theory, but with #754 coming soon, this
  is going to become a minefield. In the future we'll just always be providing a
  base schema that's reasonable, so this won't matter so much. Keys that users
  have that aren't understood will just be ignored, and that's _fine_.
2019-08-20 15:46:42 -07:00
Carlos Zamora
f9752148d0 Bugfix: Copy data should persist after Windows Terminal Closes (#2486) 2019-08-20 15:39:28 -07:00
Richard Szalay
09d79cb422 Prevent splitting panes into 0 width/height #2401 (#2450)
Fixes a crash that can occur when splitting pane that was so small that the target panes would have a width/height of 0, causing DxRenderer to fail when creating the device resources.

This PR prevents both the call to `App::AddHorizontal/VerticalSplit` and the creation of the `TermControl` if the split would fail.

Closes #2401

## Details

`App::_SplitPane` calls `focusedTab->CanAddHorizontalSplit/CanAddHorizontalSplit` before it initializes the `TermControl` to avoid having to deal with the cleanup. If a split cannot occur, it will simply return. 

**Question: Should we beep or something here?**

It then follows the same naming/flow style as the split operation, so: `Tab::CanAddHorizontalSplit -> Pane::CanSplitHorizontal ->Pane::_CanSplit`. The public pane methods will handle leaf/child the same as the current Split methods.

`_CanSplit` reuses existing logic like `_root.GetActualWidth/Height`, `Pane::_GetMinSize`, and the `Half` constant.

## Validation Steps Performed

1. Open a new tab
2. Attempt to split horizontally/vertically more than 6-8 times

Success: Pane will will eventually stop splitting rather than crashing the process.
2019-08-20 15:38:45 -07:00
Mike Griese
0c454f53e9 TURNS OUT CASE SENSITIVITY IS IMPORTANT (#2481)
* TURNS OUT CASE SENSITIVITY IS IMPORTANT

* Add a note that this is important
2019-08-20 11:16:06 -07:00
Carlos Zamora
ff87190823 Added CopyOnSelect as a Global Setting (#2152)
* Added CopyOnSelect as a ControlSetting

* Updated doc

* Updated doc

* CopyOnSelect feature changes (like, overall)

* Made CopyOnSelect a CoreSetting
CopyOnSelect value accessible through Terminal's IsCopyOnSelectActive

* Refactor a bit.

* CopyOnSelect Tests

* PR nits
2019-08-20 16:42:17 +00:00
Mike Griese
98f77818ff Draft Spec for Cascading Default + User Settings (#1258)
* Start working on drafting this spec

* Really add a LOT of notes

* More spec updates.

  * Remove `hiddenProfiles` in favor of `profile.hidden`
  * Add info on how layering will work
  * add more powershell core info

* Finish remaining TODO sections

* Apply suggestions from code review

Fix simple typos

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>

* Lots of feedback from PR

  * Try and make dynamic settings a bit clearer
  * more clearly call out serializing only what's different from a default-
    constructed `Profile`
  * Add more goals
  * add a blurb for user-default profile objects

* Add updates concerning dynamic profile generation (#1321)

* Add updates concerning dynamic profile generation

  This is based on discussion with @dhowett-msft we had o*line. We're trying to
  work through a way to prevent dynamic profiles from roaming to machines the
  dynamic profiles might not exist on.

  After writing this up, I'm not totally sure that it's a better design.

* Add some initial updates from discussion

* Pushing some updates here. I haven't given it a once over to ensure it's all consistent but it's worth reviewing @dhowett-msft

* Some minor updates from Dustin

* Fix a bunch of slightly more minor points in the spec

* Move "Profile Ordering" to "Future considerations"

* Add some notes on migrating profiles, GUID generation, de-duping profiles, and O R A N G E

* Fix the indenting here

* Update powershell core to be a dynamic profile, don't even mention other options.

* Remaining PR feedback

* Apply suggestions from code review

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* remove a dead comment
2019-08-20 08:53:30 -05:00
Carlos Zamora
71eaf621bc Add support for HTML copy (#1224)
* Move Clipboard::GenHTML to TextBuffer (add params)
Refactor RetrieveSelectedTextFromBuffer
Modify CopyToClipboardEventArgs to include HTML data

* minor code format fix

* PR Changes
NOTE: refactoring text buffer code is a separate task. New issue to be created.

* Refactor TextBuffer::GenHTML (#2038)

Fixes #1846.

* nit change

* x86 build fix

* nit changes
2019-08-19 22:59:01 +00:00
inventivejon
38156311e8 sample: Fix static "cmd.exe" in miniterm (#2461) 2019-08-19 11:20:06 -07:00
Carlos Zamora
bd47dcc898 Accessibility: Refactor IRenderData with IUiaData (#2296)
* Refactor IRenderData with IUiaData
* remove duplicate tracking of active selection
2019-08-19 11:03:45 -07:00
Mike Griese
734fc1dcc6 Don't copy text if there's no selection (#2446)
This commit also transitions our keybinding events and event handlers to a
TypedEventHandler model with an "event args" class, as specified in the
keybinding arguments specification (#1349). In short, every event can be marked
Handled independently, and a Handled event will stop bubbling out to the
terminal. An unhandled event will be passed off to the terminal as a standard
keypress.

This unifies our keybinding event model and provides a convenient place for
binding arguments to live.

Fixes #2285.
Related to #1349, #1142.
2019-08-16 15:43:51 -07:00
Mike Griese
c70fb49ab5 Add a spec draft for Keybindings Arguments (#1349)
* Add a spec draft for Keybindings Arguments.

  Specs #1142.

  Just read the spec :)

* Apply suggestions from code review

Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>

* Include notes on reliability, security, and `Handle`ing Keybinding Args

* Add some extra details from review

  * Split up ActionArgs and ActionEventArgs
  * Clarify _not_ handling an action
  * Add some notes on parsing args
  * Add some future considerations on extensions

* Updating spec to remove the bulk of the `IActionArgs` and `IActionEventArgs` implementations, as they're redundant.
2019-08-16 16:33:45 -05:00
Kayla Cinnamon
d55ecae199 Add default keybinding for opening dropdown (#2365)
* added keybinding for opening dropdown

* fixed spacing issues

* tabs spaces sadness fix

* code formatting

* renamed references to openNewTabDropdown and updated documentation

* removed newline
2019-08-16 21:29:12 +00:00
Mike Griese
d7d96f723a Add Warnings during settings load (#2422)
* Warn the user when their settings are bad

  The start of work on #1348

* Display an error dialog for errors during validation

* Polish for PR

  * Add a ton of tests
  * Polish the _GetMessageText bits
  * Add code to check for duplicate profiles
  * Verify that many warnings work at the same time
  * comments y'all

* Apply fixes for dustin's thoughts from PR

* Add a proper exception type, use an array instead of a map

* PR Fixes

  * Fix x86 build break
  * Add a bit on "using the defaults" when we encountering an exception
  * remove a redundant variable

* guid->GUID

* Address Michael's PR comments

* Clean up this error text, and catch exceptions better

* Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
2019-08-16 21:21:43 +00:00
Mike Griese
24ea0866d3 When the titlebar is clicked, dismiss the new tab flyout (#2438)
* When the titlebar is clicked, dismiss the new tab flyout

  Fixes #2028.

* Fix this for the base IslandWindow as well
2019-08-16 21:18:29 +00:00
Michael Niksa
fca0cd9879 Reduce scope of audit mode build to just the projects that are currently ready to be audited to alleviate disk space problem. (#2457) 2019-08-16 13:31:21 -07:00
Dustin L. Howett (MSFT)
16e1e29a12 Replace CodepointWidthDetector's runtime table with a static one (#2368)
This commit replaces CodepointWidthDetector's
dynamically-generated map with a static constexpr one that's compiled
into the binary.

It also almost totally removes the notion of an `Invalid` width. We
definitely had gaps in our character coverage where we'd report a
character as invalid, but we'd then flatten that down to `Narrow` when
asked. By combining the not-present state and the narrow state, we get
to save a significant chunk of data.

I've tested this by feeding it all 0x10FFFF codepoints (and then some)
and making sure they 100% match the old code's outputs.

|------------------------------|---------------|----------------|
| Metric                       | Then          | Now            |
|------------------------------|---------------|----------------|
| disk space                   | 56k (`.text`) | 3k (`.rdata`)  |
| runtime memory (allocations) | 1088          | 0              |
| runtime memory (bytes)       | 51k           | ~0             |
| memory behavior              | not shared    | fully shared   |
| lookup time                  | ~31ns         | ~9ns           |
| first hit penalty            | ~170000ns     | 0ns            |
| lines of code                | 1088          | 285            |
| clarity                      | extreme       | slightly worse |
|------------------------------|---------------|----------------|

I also took a moment and cleaned up a stray boolean that we didn't need.
2019-08-16 10:54:17 -07:00
Mike Griese
becdd16008 Add Dustin's comment from #632 to Niksa's Doc (#2346)
This seemed like it fit the style & depth of the other Niksa posts, so I'm proposing we add it here. We could always make a `Howett.md` if that seems more reasonable
2019-08-15 14:01:46 -07:00
Carlos Zamora
1f41fd35cf Chunk Selection Expansion for Double/Triple Click Selection (#2184)
Double/Triple click create a selection expanding beyond one cell. This PR makes it so that when you're dragging your mouse to expand the selection, you expand to the next delimiter defined by double/triple click.

So, double click expands by doubleClickDelimiter ranges. Triple click expands by line.

When you double/triple click, a word/line is selected. When you drag, that word/line will remain selected after the expansion occurs.

Closes #1933 

## Details
Rather than resizing the selection when the mouse event occurs, I figured I'd do what I did with wide glyph selection: expand at render time.

We needed an enum `multiClickSelectionMode` to keep track of which expansion mode we're in.

Minor modifications to `_ExpandDoubleClickSelection*(COORD)` had to be made so that we can re-use them. 

Actual expansion occurs in `_GetSelectionRects()`

## Validation Steps Performed
- generic double click test
  - `dir` or `ls`
  - double click a word
  - drag up
  - Works! ✔
- double click on delimiter test
  - `dir` or `ls`
  - double click a word delimiter (i.e.: space between words)
  - drag up
  - Works! ✔
- generic triple click test
  - `dir` or `ls`
  - triple click a line
  - drag up
  - Works! ✔
- ALT + double click test
  - `dir` or `ls`
  - hold ALT
  - double click a word
  - drag up
  - Works! ✔

repeat above tests in following scenarios:
- when at top of scrollback
- drag down instead of up
2019-08-14 16:41:43 -07:00
Mike Griese
82de43bce9 A better fix for #tab-titles-are-too-long (#2373)
### User Stories:

1. A user wants to be able to use the executable path as their starting title
    - Does anyone want this?
2. A user wants to be able to set a custom starting title, but have that title be overridable
3. A user wants to be able to set an overridable starting title, different from the profile name
    - Presumably someone will want this
4. A user totally wants to ignore the VT title and use something else
    - This will make more sense in the post [#1320] "Support runtime variables in the custom user title" settings

### Solutions:

1. `name`, `startingTitle`, `tabTitle`
    * a. `name` is only ever used as the profile name.
    * b. If `startingTitle` isn't set, then the executable path is used
    * c. If `startingTitle` is set, it's used as the initial title
    * d. If `tabTitle` is set, it overrides the title from the terminal
    * e. Current users of `tabTitle` need to manually update to the new behavior.
2. `name` as starting title, `tabTitle` as a different starting title
    * a. `name` is used as the starting title and the profile name in the dropdown
    * b. If `tabTitle` is set, we'll use that as the overridable starting title instead.
    * c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
    * d. Current users of `tabTitle` automatically get the new (different!) behavior.
    * e. User Story 1 is impossible
        - Does anyone want the behavior _ever_? Perhaps making that scenario impossible is good?
3. `name` unchanged, `tabTitle` as the starting title
    * a. `name` is only ever used as the profile name.
    * b. If `tabTitle` is set, we'll use that as the overridable starting title.
    * c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
    * d. Current users of `tabTitle` automatically get the new (different!) behavior.
4. `name` as starting title, `tabTitle` as different starting title, `suppressApplicationTitle` Boolean to force it to override
    * a. `name`, `tabTitle` work as in Solution 2.
    * b. When someone wants to be able to statically totally override that title (story 4), they can use `suppressApplicationTitle`
    * c. `suppressApplicationTitle` name is WIP
    * d.  We'll add `suppressApplicationTitle` when someone complains
    * e. If you really want story 1, use `tabTitle: c:\path\to\foo.exe` and `suppressApplicationTitle`.

[#1320]: https://github.com/microsoft/terminal/issues/1320

We've decided to pursue path 4.
2019-08-14 16:16:38 -07:00
Mike Griese
8999c661b2 Only update the icon of a tab it the icon actually _changed_ (#2376)
Fixes #1333.
Fixes #2329.
2019-08-14 16:12:14 -07:00
Mike Griese
13d66c9948 Add info about adding copy/paste keybindings (#2290)
* Add info about adding copy/paste keybindings

* Update doc/user-docs/UsingJsonSettings.md

* Apply suggestions from code review

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-08-13 08:28:04 -05:00
Mike Griese
ac97e5d082 Add a Local Test binary, to enable local TerminalApp testing (#2294)
In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest.

Since that was all insane, I created a new Terminal App unittesting project without those problems.
1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally.
2. The project will auto-generate its SxS manifest, using the work from #1987. 
3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests.


* This is the start of me trying to enable local unittesting again

  * We've got a new unittests project that isn't named *unit*test*

  * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file

  * the runas:UAP thing still doesn't work. We'll investigate.

* This shockingly works

but I'm still stuck with:
```
Summary of Errors Outside of Tests:
Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for
out of process test execution. (The
IApplicationActivationManager::ActivateApplication call failed while using a
default host. TAEF's ETW logs which are gathered with the /enableEtwLogging
switch should contain events from relevant providers that may help to diagnose
the failure.)
```

* Cleaning this all up for review.

  Frankly just pushing to see if it'll work in CI

* Couple things I noticed in the diff from master

* Apply @dhowett-msft's suggestions from code review
2019-08-13 08:23:28 -05:00
Mike MacCana
138d3b81c8 template: add Powershell command to get OS version (#2403)
As `ver` doesn't work.
2019-08-12 11:03:04 -07:00
Pawel Zubrycki
0843f3cced doc: fix typo reaons -> reasons (#2383) 2019-08-10 20:55:17 -07:00
Mike Griese
646d8f91b9 Fix the ut_app build for VS 16.2, 16.3 (#2347)
Move the hack from TerminalApp.vcxproj to a .targets file to be used by the ut_app project too.

Fixes #2143
2019-08-09 13:21:45 -07:00
toby
eac29d2c67 Add list of keybindings to SettingsSchema.md (#2335)
* Add list of keybindings to

* Add missed copy bindings
2019-08-09 09:33:01 -07:00
Mike Griese
1e4e12507d Stop Roaming settings (#2298)
* Stop Roaming settings

  Also migrate existing settings from RoamingState to LocalState.

  Fixes #1770.

* * de-dupe these functions
* const a pair of things

* This should be in the previous commit

* use `unique_hfile`'s

* Make some of these wil things cleaner
2019-08-08 17:02:34 -05:00
Dustin L. Howett (MSFT)
6c747c565b Update a number of our dependencies (#2301)
Microsoft.VCRTForwarders.140 1.0.0-rc -> 1.0.1-rc
Microsoft.Toolkit.Win32.UI.XamlApplication 6.0.0-preview6.* -> 6.0.0-preview7
Microsoft.Windows.CppWinRT 2.0.190605.7 -> 2.0.190730.2

wil fbcd1d2a -> e8c599bc
gsl b74b286d -> 1212beae

We're skipping the following update:
Microsoft.UI.Xaml 2.2.190611001-prerelease -> 2.2.190731001-prerelease
2019-08-07 16:43:49 -07:00
Dustin L. Howett (MSFT)
89925ebe44 inbox: reflect changes from 20h1 branch (#2310) 2019-08-07 10:58:53 -07:00
Mike Griese
8fa42e09df Add a note about the build required to the README (#2291) 2019-08-06 13:25:43 -07:00
Carlos Zamora
94e5d545aa skip a few failing tests for x86 (#2262) 2019-08-06 13:16:19 -07:00
Yves Dolce
dfb853644a use std::move() on a few more strings, other general code tidying (#1899)
* -  moving string parameter into data member instead of copying it.
-  removing noexcept from methods where an exception could be raised.
   If std::terminate() call is desired instead, I guess those should be
   left and std::move_if_noexcept() used to document the fact that it's
   on purpose.
- std::moving local variable into argument when possible.
- change maxversiontested XML element to maxVersionTested.
- used of gsl::narrow_cast where appropriate to prevent warnings.
- fixed bug in TerminalSettings::SetColorTableEntry()

Fixes #1844
2019-08-06 11:33:32 -07:00
James Holderness
ff7fdbeab4 Don't log an error message when _DoGetConsoleInput returns CONSOLE_STATUS_WAIT. (#2244) 2019-08-06 17:24:00 +00:00
Michael Niksa
a7877558f2 add exclusion directories to PR builds, not just rolling builds. (#2272) 2019-08-06 09:46:43 -07:00
Michael Niksa
aae938fc33 Attempt to clean up PCHs as we build to leave more Hosted Agent disk space (#2271)
* Cleanup PCHs as the build rolls along to leave enough space on CI agents.

* Attempt to restrict pch cleanup to only CI agents.

* Write message when objects are deleted.
2019-08-06 06:51:50 -05:00
Mike Griese
b495ad255f Create bx.cmd (#2168)
* Try createing a script to only build the current working directory

  Inspired by #2078.

  I wanted to use this for WindowsTerminal, but I can't generate the
  resources.pri from just building WindowsTerminal. Maybe @dhowett-msft has
  some ideas.

* Cleanup for PR

* fix some bugs with building outside a project directory.

* PR nits
2019-08-05 20:18:40 -05:00
Leonard Hecker
4529e46d3e Fixed Ctrl+Alt shortcuts conflicting with AltGr (#2235)
This moves the detection of AltGr keypresses in front of the shortcut
handling. This allows one to have Ctrl+Alt shortcuts, while
simultaneously being able to use the AltGr key for special characters.
2019-08-05 16:58:48 -05:00
Michael Niksa
3086671bc7 Update bot with new rules (#2259)
We added a few more rules. Update the bot doc description.
2019-08-05 11:28:05 -07:00
Michael Niksa
1b33d186f3 Update bug template with crash instructions (#2257)
It's a doc change and the x86 CI is cranky. We're looking into it.
2019-08-05 10:09:56 -07:00
PankajBhojwani
0d8f2998d6 Azure connector only shows up if available (#2195)
The default azure connector profile only shows up if a) its a release build and b) its non-ARM64

Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-08-02 14:41:46 -07:00
Michael Niksa
42c1e58966 Remove job object and startup suspended behavior because conhosts should clean themselves up. (#2198) 2019-08-02 13:27:34 -07:00
PankajBhojwani
0da13cdf2d Use ROW.Reset in EraseInDisplay instead of printing millions of spaces per line #2197 2019-08-01 13:19:22 -07:00
Tapasweni Pathak
f8f0798826 Added information on WxH character (#2104)
* Add information on WxH character

* Add line and separate footnote
2019-08-01 08:34:18 -05:00
James Holderness
6749ab03b8 First draft of a spec for VT52 escape sequences (#2017)
* First draft of a spec for splitting off the existing VT52 escape sequences, and extending the VT52 support.

* Make the issue ID visible on GitHub.

* Added suggested mappings for the Graphics Mode character set.

* Add escape sequences for all the commands and clarify the use of the ESC < sequence when switching back to ANSI mode.

* Add details about the differing boundary rules of the VT100 CUP command and the VT52 Direct Cursor Address command.

* Specify the identifying sequence that the Identify command should return.

* Add details of the print commands.

* Add a list of keyboard sequences that are different in the VT52 mode, and make the description of the Keypad Mode commands a little clearer.

* Add a section describing the testing needed to cover the new functionality.
2019-08-01 08:23:10 -05:00
Michael Niksa
66044ca605 Try to turn audit mode back on without building test/utilities (#2179)
* Attempt to remove all test and utility projects from audit mode (and turn it back on) to see if that keeps it within the disk space boundaries.
* drop x86 and arm configs for the test projects too.
2019-07-31 16:58:16 -07:00
Carlos Zamora
a08666b58e Accessibility: TermControl Automation Peer (#2083)
Builds on the work of #1691 and #1915 

Let's start with the easy change:
- `TermControl`'s `controlRoot` was removed. `TermControl` is a `UserControl`
  now.

Ok. Now we've got a story to tell here....

### TermControlAP - the Automation Peer
Here's an in-depth guide on custom automation peers:
https://docs.microsoft.com/en-us/windows/uwp/design/accessibility/custom-automation-peers

We have a custom XAML element (TermControl). So XAML can't really hold our
hands and determine an accessible behavior for us. So this automation peer is
responsible for enabling that interaction.

We made it a FrameworkElementAutomationPeer to get as much accessibility as
possible from it just being a XAML element (i.e.: where are we on the screen?
what are my dimensions?). This is recommended. Any functions with "Core" at the
end, are overwritten here to tweak this automation peer into what we really
need.

But what kind of interactions can a user expect from this XAML element?
Introducing ControlPatterns! There's a ton of interfaces that just define "what
can I do". Thankfully, we already know that we're supposed to be
`ScreenInfoUiaProvider` and that was an `ITextProvider`, so let's just make the
TermControlAP an `ITextProvider` too.

So now we have a way to define what accessible actions can be performed on us,
but what should those actions do? Well let's just use the automation providers
from ConHost that are now in a shared space! (Note: this is a great place to
stop and get some coffee. We're about to hop into the .cpp file in the next
section)


### Wrapping our shared Automation Providers

Unfortunately, we can't just use the automation providers from ConHost. Or, at
least not just hook them up as easily as we wish. ConHost's UIA Providers were
written using UIAutomationCore and ITextRangeProiuder. XAML's interfaces
ITextProvider and ITextRangeProvider are lined up to be exactly the same.

So we need to wrap our ConHost UIA Providers (UIAutomationCore) with the XAML
ones. We had two providers, so that means we have two wrappers.

#### TermControlAP (XAML) <----> ScreenInfoUiaProvider (UIAutomationCore)
Each of the functions in the pragma region `ITextProvider` for
TermControlAP.cpp is just wrapping what we do in `ScreenInfoUiaProvider`, and
returning an acceptable version of it.

Most of `ScreenInfoUiaProvider`'s functions return `UiaTextRange`s. So we need
to wrap that too. That's this next section...

#### XamlUiaTextRange (XAML) <----> UiaTextRange (UIAutomationCore)
Same idea.  We're wrapping everything that we could do with `UiaTextRange` and
putting it inside of `XamlUiaTextRange`.


### Additional changes to `UiaTextRange` and `ScreenInfoUiaProvider`
If you don't know what I just said, please read this background:
- #1691: how accessibility works and the general responsibility of these two
  classes
- #1915: how we pulled these Accessibility Providers into a shared area

TL;DR: `ScreenInfoUiaProvider` lets you interact with the displayed text.
`UiaTextRange` is specific ranges of text in the display and navigate the text.

Thankfully, we didn't do many changes here. I feel like some of it is hacked
together but now that we have a somewhat working system, making changes
shouldn't be too hard...I hope.

#### UiaTextRange
We don't have access to the window handle. We really only need it to draw the
bounding rects using WinUser's `ScreenToClient()` and `ClientToScreen()`. I
need to figure out how to get around this.

In the meantime, I made the window handle optional. And if we don't have
one....well, we need to figure that out. But other than that, we have a
`UiaTextRange`.

#### ScreenInfoUiaProvider
At some point, we need to hook up this automation provider to the
WindowUiaProvider. This should help with navigation of the UIA Tree and make
everything just look waaaay better. For now, let's just do the same approach
and make the pUiaParent optional.

This one's the one I'm not that proud of, but it works. We need the parent to
get a bounding rect of the terminal. While we figure out how to attach the
WindowUiaProvider, we should at the very least be able to get a bunch of info
from our xaml automation peer. So, I've added a _getBoundingRect optional
function. This is what's called when we don't have a WindowUiaProvider as our
parent.


## Validation Steps Performed
I've been using inspect.exe to see the UIA tree.
I was able to interact with the terminal mostly fine. A few known issues below.

Unfortunately, I tried running Narrator on this and it didn't seem to like it
(by that I mean WT crashed). Then again, I don't really know how to use
narrator other than "click on object" --> "listen voice". I feel like there's a
way to get the other interactions with narrator, but I'll be looking into more
of that soon. I bet if I fix the two issues below, Narrator will be happy.

## Miscellaneous Known Issues
- `GetSelection()` and `GetVisibleRanges()` crashes. I need to debug through
  these. I want to include them in this PR.

Fixes #1353.
2019-07-30 16:43:10 -07:00
Dustin L. Howett (MSFT)
1afab788ab Update the package version to v0.3
Acked-by: Pankaj Bhojwani <t-pabhoj@microsoft.com>
Acked-by: Carlos Zamora <cazamor@microsoft.com>
2019-07-30 16:35:08 -07:00
PankajBhojwani
63df881f31 VT sequence support for EraseInLine, EraseInDisplay, DeleteCharacter and InsertCharacter (#2144)
* We now support EraseInLine, EraseInDisplay, DeleteCharacter and InsertCharacter
2019-07-30 16:28:28 -07:00
Mike Griese
2d3e271a4f Fix the terminal snapping across DPI boundaries strangely
When we snap across a DPI boundary, we'll get the DPI changed message _after_ the resize message. So when we try to calculate the new terminal position, we'll use the _old_ DPI to calculate the size. When snapping to a lower DPI, this means the terminal will be smaller, with "padding" all around the actual app. 

Instead, when we get a new DPI, force us to update out UI layout for the new DPI.

Closes #2057
2019-07-30 15:04:48 -07:00
Mike Griese
7abcc35fdf Fix a crash on restore down (#2149)
* Don't trigger a frame due to circling when in the middle of a resize operation

  This fixes #1795, and shined quite a bit of light on the whole conpty resize process.

* Move the Begin/End to ResizeScreenBuffer, to catch more cases.
2019-07-30 17:01:27 -05:00
Dustin L. Howett (MSFT)
c6c51fbb0e Change our manifest from depending on Windows.Universal to Windows.Desktop (#2155) 2019-07-30 14:36:15 -07:00
Michael Niksa
56589c0aac Fixes crash when specifying invalid font (#2153)
* Stop the crash with fonts by trying a few fallback/backup fonts if we can't find what was selected.
* Create fallback pattern for finding a font. Resolve and pass the locale name. Retrieve the font name while retrieving the font object. Use retrieved data in the _GetProposedFont methods instead of re-resolving it.
* Add details to schema about fallback. Finish comment explaining fallback pattern to doc comment on method.
2019-07-30 14:32:23 -07:00
Dustin L. Howett (MSFT)
3f62c8b470 Add some ETL around profile, control and connection creation (#2125)
This commit adds some tracelogging (and telemetry) to answer the following questions:
* Do people use padding? If so, what is the common range of values?
* Are people turning off showTabsInTitlebar?
* How many different profiles are in use, and how do they break down between custom and default?
* Are people manually launching specific profiles, or using "default" fairly often?
* Are people using the Azure Cloud Shell connection?
* Are people leveraging the feature added in #2108 (autogenerating GUIDs)?
2019-07-29 17:24:20 -07:00
Carlos Zamora
96496d8154 Accessibility: Set-up UIA Tree (#1691)
**The Basics of Accessibility**
- [What is a User Interaction Automation (UIA) Tree?](https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-tree-overview)
- Other projects (i.e.: Narrator) can take advantage of this UIA tree and are used to present information within it.
- Some things like XAML already have a UIA Tree. So some UIA tree navigation and features are already there. It's just a matter of getting them hooked up and looking right.

**Accessibility in our Project**
There's a few important classes...
regarding Accessibility...
- **WindowUiaProvider**: This sets up the UIA tree for a window. So this is the top-level for the UIA tree.
- **ScreenInfoUiaProvider**: This sets up the UIA tree for a terminal buffer.
- **UiaTextRange**: This is essential to interacting with the UIA tree for the terminal buffer. Actually gets portions of the buffer and presents them.

regarding the Windows Terminal window...
- **BaseWindow**: The foundation to a window. Deals with HWNDs and that kind of stuff.
- **IslandWindow**: This extends `BaseWindow` and is actually what holds our Windows Terminal
- **NonClientIslandWindow**: An extension of the `IslandWindow`

regarding ConHost...
- **IConsoleWindow**: This is an interface for the console window.
- **Window**: This is the actual window for ConHost. Extends `IConsoleWindow`

- `IConsoleWindow` changes:
  - move into `Microsoft::Console::Types` (a shared space)
  - Have `IslandWindow` extend it
- `WindowUiaProvider` changes:
  - move into `Microsoft::Console::Types` (a shared space)
- Hook up `WindowUiaProvider` to IslandWindow (yay! we now have a tree)

### Changes to the WindowUiaProvider
As mentioned earlier, the WindowUiaProvider is the top-level UIA provider for our projects. To reuse as much code as possible, I created `Microsoft::Console::Types::WindowUiaProviderBase`. Any existing functions that reference a `ScreenInfoUiaProvider` were virtual-ized.

In each project, a `WindowUiaProvider : WindowUiaProviderBase` was created to define those virtual functions. Note that that will be the main difference between ConHost and Windows Terminal moving forward: how many TextBuffers are on the screen.

So, ConHost should be the same as before, with only one `ScreenInfoUiaProvider`, whereas Windows Terminal needs to (1) update which one is on the screen and (2) may have multiple on the screen.

🚨 Windows Terminal doesn't have the `ScreenInfoUiaProvider` hooked up yet. We'll have all the XAML elements in the UIA tree. But, since `TermControl` is a custom XAML Control, I need to hook up the `ScreenInfoUiaProvider` to it. This work will be done in a new PR and resolve GitHub Issue #1352.


### Moved to `Microsoft::Console::Types`
These files got moved to a shared area so that they can be used by both ConHost and Windows Terminal.
This means that any references to the `ServiceLocator` had to be removed.

- `IConsoleWindow`
  - Windows Terminal: `IslandWindow : IConsoleWindow`
- `ScreenInfoUiaProvider`
  - all references to `ServiceLocator` and `SCREEN_INFORMATION` were removed. `IRenderData` was used to accomplish this. Refer to next section for more details.
- `UiaTextRange`
  - all references to `ServiceLocator` and `SCREEN_INFORMATION` were removed. `IRenderData` was used to accomplish this. Refer to next section for more details.
  - since most of the functions were `static`, that means that an `IRenderData` had to be added into most of them.


### Changes to IRenderData
Since `IRenderData` is now being used to abstract out `ServiceLocator` and `SCREEN_INFORMATION`, I had to add a few functions here:
- `bool IsAreaSelected()`
- `void ClearSelection()`
- `void SelectNewRegion(...)`
- `HRESULT SearchForText(...)`

`SearchForText()` is a problem here. The overall new design is great! But Windows Terminal doesn't have a way to search for text in the buffer yet, whereas ConHost does. So I'm punting on this issue for now. It looks nasty, but just look at all the other pretty things here. :)
2019-07-29 15:21:15 -07:00
Mike Griese
ed18c1e8c1 Fix the About Dialog II: This Time it's Optional (#2122)
* Get rid of this unused variable
* This is the actual fix to the about dialog crashing: an unchecked optional variable
2019-07-29 09:46:32 -07:00
Dustin L. Howett (MSFT)
10c599eb17 Update SettingsSchema.md to fix #2121 (#2123)
* Update SettingsSchema.md to fix #2121
Fixes #2121.
* Update doc/cascadia/SettingsSchema.md
2019-07-29 09:45:11 -07:00
Mike Griese
bd5cae1328 Change "Summary"->"Description" (#2115) 2019-07-26 11:16:53 -05:00
Mike Griese
dd1f8a8245 Prevent a crash on resizing too small caused by the Titlebar (#2118)
Only set the MaxWidth of the TitlebarControl's Content when the value is
  positive. Any smaller will crash the app.
2019-07-26 11:16:13 -05:00
Mike Griese
644ac56fdb If a profile did not have a GUID, generate one (#2117)
Fixes #2108
  Adds tests too!
2019-07-26 11:11:26 -05:00
mervynzhang
83a4c22919 Set Starting Directory for WSL profile (#2033) 2019-07-26 09:02:07 -07:00
Kayla Cinnamon
09e828fa49 shrunk + icon (#2109) 2019-07-26 07:06:28 -05:00
Mike Griese
c97cccb55c Initializes conhost's Campbell color scheme in conhost order instead of ANSI/VT order (#1237)
* Fix this

* Swap the elements instead of having two whole tables

* Add a unittest to make @miniksa happy
2019-07-25 22:03:00 +00:00
PankajBhojwani
63347f47fb The Azure cloud shell connector (#1808)
* We can now connect to the Azure cloud shell #1235
2019-07-25 13:31:41 -07:00
Mike Griese
a5746850f9 Make sure to apply the theme on load of the application (#2107)
Fixes #1913.

  _AplyTheme raises an event for the IslandWindow to handle and actually apply
  the theme, so we don't _really_ need to worry about it, but we do need to
  worry for ContentDialogs.
2019-07-25 13:25:38 -07:00
Mike Griese
a2744529e6 Fixes #2090 (#2094) 2019-07-25 11:01:03 -07:00
Maurice Kevenaar
577da7441e (GH-2044) Updated readme to include Chocolatey package (#2084)
* (GH-2044) Updated readme to include Chocolatey package
Co-Authored-By: Mike Griese <migrie@microsoft.com>
2019-07-25 10:50:57 -07:00
Michael Ratanapintha
66d46ed8ed Allow empty strings and env vars in profile "icon" settings - fixes #1468, #1867 (#2050)
First, I tried reusing the existing ExpandEnvironmentVariableStrings()
helper in TerminalApp/CascadiaSettings.cpp, but then I realized that
WIL already provides its own wrapper for ExpandEnvironmentStrings(),
so instead I deleted ExpandEnvironmentVariableStrings() and replaced
its usages with wil::ExpandEnvironmentStringsW().

I then used wil::ExpandEnvironmentStringsW() when resolving the
icon path as well. In addition, to allow empty strings,
I made changes to treat empty strings for "icon" the same
as JSON `null` or not setting the property at all.

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
2019-07-25 10:44:58 -07:00
Michael Niksa
8ae4f2fc1b The spice must flow. (#2096) 2019-07-25 10:44:12 -07:00
James Holderness
2febe1fa2b Fix a couple of the DEC Special Graphics characters (#2081)
* Map the code point 0x5F to a blank glyph in the Special Graphics character set.

* Map code point 0x60 in the Special Graphics character set to the Unicode "black diamond suite", rather than the "black diamond", since the latter is currently rendered as a double width glyph.

* Correct a couple of the comments on the Special Graphics translation table to match the DEC documentation.

* Make hex values consistently lowercase for the Unicode characters in the Special Graphics translation table.
2019-07-24 21:55:59 -07:00
Robert Jordan
89190c6e6c Add support for background image alignment (as one setting) (#1959)
* Implement base background image alignment settings

TerminalSettings now has two new properties:
* BackgroundImageHorizontalAlignment
* BackgroundImageVerticalAlignment

These properties are used in TermControl::_InitializeBackgroundBrush to specify the alignment for TermControl::_bgImageLayer.

This is a base commit that will split into two possible branches:
* Use one setting in profiles.json: "backgroundImageAlignment"
* Use two settings in profiles.json: "backgroundImageHorizontal/VerticalAlignment"

* Implement background image alignment profile setting

Implement background image alignment as one profile setting.
* This has the benefit of acting as a single setting when the user would likely want to change both horizontal and vertical alignment.
* HorizontalAlignment and VerticalAlignment are still stored as a tuple in Profile because they are an optional field. And thus, it would not make sense for one of the alignments to be left unused while the other is not.
* Cons are that the tuple signature is quite long, but it is only used in a small number of locations. The Serialize method is also a little mishapen with the nested switch statements. Empty lines have been added between base-level cases to improve readability.

* Fix capitalization typo for BackgroundImageStretchModeKey

In Profiles.cpp, the key for the image stretch mode json property had a lowercase 'i' in "Backgroundimage", not following proper UpperCamelCase.
The "i" has been capitalized and the two usages of the constant have been updated as well.

* Document Background Image settings

* Adds entries SettingsSchema.md for the original 3 backgroundImage settings in addition to the new backgroundImageAlignment setting.

* Fix setting capitalization error in UsingJsonSettings.md

* The background image example in UsingJsonSettings.md listing a backgroundImageStretchMode of "Fill" has been corrected to "fill".


Fixes #1949.
2019-07-24 21:47:06 -07:00
Michael Niksa
2c3e175f62 Doc of stuff I've explained. (#1942)
* Doc of stuff I've explained.

* add a few more

* archive fulltext of comments and link back to originals, attempt to make relative anchor links for jumping.
2019-07-24 14:10:33 -07:00
Force Charlie
9d36b08b82 Switch away from OS version detection for DirectWrite things (#2065)
* If IDWriteTextFormat1 does not exist, return directly
* We use DXGI_SCALING_NONE create SwapChain first, if failed switch to DXGI_SCALING_STRETCH

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2019-07-24 09:57:13 -07:00
mcpiroman
5da2ab1a86 Scroll from selection dragging out of window (#1247) (#1523)
* Scroll from selection dragging out of window
* Review changes, dynamic dt measurement, function separation
2019-07-24 09:37:17 -07:00
Scott Hanselman
e662277cb0 TAKE ME TO THE DOWNLOADS (#2070)
* TAKE ME TO THE DOWNLOADS
* Update README.md
Added store badge and reader and alternate release suggestion
2019-07-24 09:31:56 -07:00
Dustin L. Howett (MSFT)
2407828d03 Allow the mapping of OEM keys ({}|\<>/_-=+) in key bindings (#2067)
This commit introduces support for key bindings containing keys
traditionally classified as "OEM" keys. It uses VkKeyScanW and
MapVirtualKeyW, and translates the modifiers that come out of
VkKeyScanW to key chord modifiers.

The net result of this is that you can use bindings like "ctrl+|" in
your settings. That one in particular will be reserialized (and
displayed in any menus) as "ctrl+shift+\". Admittedly, this is not
clear, but it _is_ the truest representation of the key.

This commit also moves the Xaml key chord name override generator into
App as a static function, *AND* it forces its use for all modifier
names. This will present a localization issue, which will be helped in
part by #1972. This is required to work around
microsoft/microsoft-ui-xaml#708. I've kept the original code around
guarded by a puzzling ifdef, because it absolutely has value.

Fixes #1212.
2019-07-23 14:05:07 -07:00
Dustin L. Howett (MSFT)
69c67f8a8e Move TerminalApp's resources into the TerminalApp project (#1972)
* Move TerminalApp's resources into the TerminalApp project

This commit also introduces a scoped resource accessor, lightly taken
from microsoft-ui-xaml. It also moves all static UI strings out of
App.cpp and into localizable resources.

Fixes #792.
2019-07-23 11:29:38 -07:00
Mike Griese
260d095f94 Change some default keybindings (#2014)
Closes #1417.

  Changes New Tab to Ctrl+Shift+t (from Ctrl+t)
  Changes SwitchToTabN to Ctrl+Alt+<number> (from Alt+<number>)
2019-07-22 17:53:10 -07:00
Dustin L. Howett (MSFT)
a6ab075a62 Automatically generate an SxS manifest for WindowsTerminal's winmds (#2043)
Fixes #1987.
2019-07-22 17:51:37 -07:00
Force Charlie
3b96a84261 Fix conhost.exe detect os version (#2059)
* add openconsole.exe.manifest to fix detecting of os version
2019-07-22 17:49:35 -07:00
WSLUser
dca0ffe6dd Changes link to go to latest ColorTool release (#2027)
Since ColorTool shares the same Release page as Windows Terminal, it is more difficult to navigate to it. So whenever ColorTool is updated with a new release, we will update the link to the latest release. The link I changed to is the latest available from April 2019.
2019-07-19 12:11:58 -07:00
Mike Griese
5074335392 Add a keybinding for ClosePane (#2012)
Closes #993
  When the last pane in a tab is closed, the tab will close.
  Bound to Ctrl+Shift+W by default. See #1417 for discussion on the default
  keybindings. The Ctrl+W->CloseTab keybinding is being removed in favor of
  ClosePane.
2019-07-18 17:23:40 -07:00
Mike Griese
8ffff8ea37 Enable dragging with the entire titlebar (#1948)
* This definitely works for getting shadow, pointy corners back

  Don't do anything in NCPAINT. If you do, you have to do everything. But the
  whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in
  your normal paint. So just do that dummy.

  * This doesn't transition across monitors.
  * This has a window style change I think is wrong.
  * I'm not sure the margins change is important.

* The window style was _not_ important

* Still getting a black xaml islands area (the HRGN) when we switch to high DPI

* I don't know if this affects anything.

* heyo this works.

  I'm not entirely sure why. But if we only update the titlebar drag region when
  that actually changes, it's a _lot_ smoother. I'm not super happy with the
  duplicated work in _UpdateDragRegion and OnSize, but checking this in in case
  I can't figure that out.

* Add more comments and cleanup

* Try making the button RightCustomContent

* * Make the MinMaxClose's drag bar's min size the same as a caption button
* Make the new tab button transparent, to see how that looks
* Make sure the TabView doesn't push the MMC off the window

* Create a TitlebarControl

  * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar,
    and MMCControl.
  * The App instatntiates a TabRowControl at runtime, and either places it in
    the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW
    when the NCIW creates its UI.
  * When the NCIW is created, it creates a grid with two rows, one for the
    titlebar and one for the app content.
  * The MMCControl is only responsible for Min Max Close now, and is closer to
    the window implementation.
  * The drag bar takes up all the space from the right of the TabRow to the left
    of the MMC
  * Things that **DON'T** work:
    - When you add tabs, the drag bar doesn't update it's size. It only updates
      OnSize
    - The MMCControl's Min and Max buttons don't seem to work anymore.
      - They should probably just expose their OnMinimizeClick and
        OnMaximizeClick events for the Titlebar to handle minimizing and
        maximizing.
    - The drag bar is Magenta (#ff00ff) currently.
    - I'm not _sure_ we need a TabRowControl. We could probably get away with
      removing it from the UI tree, I was just being dumb before.

* Fix the MMC buttons not working

  I forgot to plumb the window handle through

* Make the titlebar less magenta

* Resize the drag region as we add/remove tabs

* Move the actual MMC handling to the TitlebarControl

* Some PR nits, fix the titlebar painting on maximize

* Put the TabRow in our XAML

* Remove dead code in preparation for review

* Horrifyingly try Gdi Plus as a solution, that is _wrong_ though

* Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though"

This reverts commit e038b5d921.

* This fixes the bottom border but breaks the titlebar painting

* Fix the NC bottom border

* A bunch of the more minor PR nits

* Add a MinimizeClick event to the MMCControl

  This works for Minimize. This is what I wanted to do originally.

* Add events for _all_ of the buttons, not just the Minimize btn

* Change hoe setting the titlebar content works

  Now the app triggers a callcack on the host to set the content, instead of the host querying the app.

* Move the tab row to the bottom of it's available space

* Fix the theme reloading

* PR nits from @miniksa

* Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* This needed to be fixed, was missed in other PR nits

* runformat

  wait _what_

* Does this fix the CI build?
2019-07-18 17:21:33 -05:00
Dustin L. Howett (MSFT)
57ad2d57fd Roll up dependencies through TerminalApp so the package is right (#2018)
This commit includes a script and build step to make sure the MSIX doesn't continue to regress
2019-07-18 11:23:34 -07:00
Michael Ratanapintha
f1441a589c Fix test runner commands (runut.cmd and friends; Invoke-OpenConsoleTests) (#2020)
In commit 0905140955 (PR #1164),
we updated the version of the Taef.Redist.Wlk NuGet package
for the TAEF test harness and framework. However, the helper commands
to run the various test cases hard-code the path to the TAEF executable,
which because of NuGet's design includes the TAEF NuGet package version.
These commands weren't updated to reflect the new TAEF version
and so have been broken since then.

This commit fixes the issue and makes running tests possible again.
2019-07-18 09:31:25 -07:00
Dustin L. Howett (MSFT)
988fe0ba60 Fix the static UTF8OutPipeReader & tests (#1998)
This commit addresses some lingering issues in UTF8OutPipeReader and cleans up its termination logic. It also fixes some issues exposed in the test.

Fixes #1997.
2019-07-17 16:27:09 -07:00
Dustin L. Howett (MSFT)
de1de4425e Roll up WindowsTerminal's subprojects into packaging outputs (#2007)
This commit introduces a GetPackagingOutputs override to WindowsTerminal that
rolls up its child projects' outputs.

It also introduces an atrocity that fixes a new regression in VS 16.2/16.3.
2019-07-17 14:02:20 -07:00
Mike Griese
8d52ba0990 Add support for moving focus between panes with the keyboard (#1910)
Enables the user to set keybindings to move focus between panes with the keyboard. 
This is highly based off the work done for resizing panes. Same logic applies - 
  moving focus will move up the panes tree until we find a pane to move the focus to.
2019-07-17 09:30:15 -05:00
Dustin L. Howett
a0782bfd6c Mark ESC as handled so that it doesn't come back in CharacterHandler (#1974) 2019-07-16 13:56:46 -07:00
Steffen
fa5b9b06bd Fix for UTF-8 partials in function ConhostConnection::_OutputThread. (#1850)
* Fix for UTF-8 partials in functions `ConhostConnection::_OutputThread` and `ApiRoutines::WriteConsoleOutputCharacterAImpl`

The implementation needs to check whether or not the buffer ends with a partial character. If so, only convert the code points which are complete, and save the partial code units in a cache that gets prepended to the next chunk of text.

* Utf8OutPipeReader class added
* Unit Test added
* use specific macros and WIL classes
* avoid possible deadlock caused by unclosed pipe handle
2019-07-16 11:14:07 -07:00
Leonard Hecker
7067910862 Add a ControlKeyStates wrapper class (#1718)
* Fixed a minor build warning
* Removed an unimplemented method declaration
* Added Microsoft::Terminal::Core::ControlKeyStates
// This class will act as a safe wrapper for the ControlKeyState enum,
// found in the NT console subsystem (<um/wincon.h>).
2019-07-16 11:09:29 -07:00
Mike Griese
0905140955 Refactor TerminalApp and Add Tests for Xaml Content (#1164)
* Refactors TerminalApp into two projects: 
  - TerminalAppLib, which builds a .lib, and includes all the code
  - TerminalApp, which builds a dll by linking the lib
* Adds a TerminalApp.Unit.Tests project
  - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation
  - includes the ability to test types with XAML content using an appxmanifest
* Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR.

-------------------------
These are some previous commit messages. They may be helpful to future readers.

* Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042

* VS automatically did this for me

* This is a dead end

  I tried including the idl-y things into the lib, but that way leads insanity

  If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets
  that ProjectReferences can have winmd's in them, so it won't be able to
  compile any types from the referenced projects. If you instead try to manually
  reference the types, you'll get duplicate types up the wazoo, which of course
  is insane, since we're referencing them the _one_ time

* Yea just follow #1042 on github for status

  So current state:

  1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and
     TerminalSettings, then mdmerge will complain about all   the types from
     TerminalSettings being defined twice. In this magic scenario, the
     dependencies of TerminalControl are used directly   for some reason:

```
  12>    Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd.
  12>    Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd.
  12>    Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd.
  12>    Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd.
  12>    Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd.
```

  2. If you don't add a `Reference` TerminalControl, then it'll complain about
     being unable to find the type TitleChangedEventArgs,   which is defined in
     TerminalControl.

  3. If you don't add a `Reference` TerminalSettings, then it'll complain about
     being unable to find the type KeyChord and other   types from
     TerminalSettings. In this scenario, it doesn't recurse on the other
     dependencies from TerminalControl for whatever   reason.

  4. If you instead try to add all 3 as a `ProjectReference`, then it'll
     complain about being unable to find TitleChangedEventArgs,   as in 2.
     Presumably, it;ll have troubles with the other types too, as none of the 3
     are actually included in the midlrt.rsp file.

  5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as
     a `Reference`, you'll get a `MIDL2011: [msg]  unresolved type declaration
     Microsoft.UI.Xaml.Markup.XamlApplication`

  6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND
     MUX.Markup as a `Reference`, you'll get the same   result as 3.

* what if we just don't idl

  This seems to compile

* This compiles but I broke the MUX resources

  look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that!

* lets do this

    If I leave the MUX nuget out of the project, I'll get a compile error in
    App.xaml:

    ```
    ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls'
    ```

    If I add it back to the project, it works

* Some cleanup from the previous commit

* This is busted again.

  Doing a clean build didn't work.

    A clean rebuild of the project, paired with some removal of dead code
    revealed a problem with what I have so far.

    TerminalAppLib depends on the generation of two headers,
    `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the
    winrt types. They're needed to be able to compile the implementations.
    Presumably that's not getting generated by the lib project, because the dll
    project is the one to generate that file.

    So we need to move the idl's to the lib project. This created maddness,
    because of course the Duplicate Type thing. The solution to that is to
    actually mark the winrt DLLs that we're chaining up through us as

    ```
        <Private>false</Private>
        <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
    ```

    This will prevent them from getting double-included.

    This still doesn't work however, since
    ```
    app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp'
    error C3861: 'XamlMetaDataProvider': identifier not found
    ```

    So we need to figure that out. The dll project is still generating the right
    header, so lets look there.

* Move the xaml stuff to the lib

  This compiles, but when we launch, we fail to load the tabviewcontrol
  resources again. So that's not what you want. Why is it not included?

* It works again!

  * Use the pri, xbf files from TerminalAppLib, not TerminalApp
  * Manually make TerminalApp include a reference to TerminalAppLib's
    TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to
    TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the
    TerminalApp project (it's expecting it to have a winmd)
  * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The
    dll doesn't do any codegen anymore.

* Agressively clean up these files

* Clean up unnecessary includes in the dll pch.h

* This does NOT work.

  The WindowsxamlManager call crashes. I'm thinking it has to do with activation
  of winrt types from a dll.

  Email out to @Austin-Lamb to see if he can assist

* This gets our cppwinrt types working, but xaml islands is still broken

* Split the tests apart, so they aren't insane

* These are the magic words to make xaml islands work

* All this witchcraft is necessary to make XAML+MUX work right

* Clean this up a bit and add comments

* Create an enormous doc explaining this madness

* Unsure how this got changed.

* Trying to get the CI build to work again.

  This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false.

  However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference.

* Update cppwinrt to the latest version - this fixes the MSBuild

  * I still need to re-add the KeyModifiers checks from TermControl. I think
    this update broke `operator&` for that enum.
  * There needs to be some cleanup obviously
  * The doc should be updated as well

* Clean up changes from cppwinrt update

* Try doing this, even though it seems wrong

* Lets try this (press x to doubt)

* Clean up vcxproj file, and remove appxmanifest change from previous commit

* Update to the latest TAEF release, maybe that'll work

* Let's try a prerelease version, shall we?

* Add notes about TAEF package, comment out tests

* Format the code

* Hopefully fix the arm64 and x86 builds

  also a typo

* Fix PR nits

* Fix some bad merge conflicts

* Some cleanup from the merge

* Well I was close to getting the merge right

* I believe this will fix CI

* Apply suggestions from code review

Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>

* These definitely need to be fixed

* Try version detecting in the test

  IDK if this will build, I'm letting the CI try while I clean rebuild locally

* Try blindly updating to the newest nuget version

* Revert "Try blindly updating to the newest nuget version"

This reverts commit b72bd9eb73.

* We're just going to see if these work in CI with this change

* Comment the tests back out. Windows Server 2019 is 10.0.17763.557

* Remove the nuget package

  We don't need this package anymore now that we're hosting it

* Okay this _was_ important
2019-07-15 14:27:56 -05:00
ksyx
fad7638bb3 user docs: Fix the capitalization on “Color Schemes” (#1953) 2019-07-13 11:17:11 -07:00
Michael Niksa
3377f06e52 Host our own NuGet feed for packages that we need that aren't elsewhere yet (#1951)
* Stop hosting packages inside of here. Put them on a blob storage account instead.
2019-07-12 15:22:03 -07:00
Dustin L. Howett (MSFT)
120e6157c3 Fix the WAP packaging project (#1900)
* Fix the WAP packaging project

This commits fixes the centennial package by:
* Forcing XBF (XAML binary format) files to be embedded in project
  PRI files.
* Moving package content generation to before PRI generation
* Collecting all of the package's PRI files to merge into resources.pri
* Fixing the hardcoded resource paths to reflect the new reality.

It also includes a magic value that fixes the bug where the project is
autodetected as a Mixed (CLR + Native) project.

Fixes #1816.
2019-07-12 15:21:45 -07:00
Dustin L. Howett (MSFT)
c1599248d7 Force the use of v2 (non-legacy) conhost when in ConPTY mode (#1935)
Fixes #1838.
2019-07-12 15:20:45 -07:00
Kayla Cinnamon
b706b60843 Style the button and tab view background to match the titlebar (#1934)
* styled title bar to be one color, shrunk + button
2019-07-12 15:07:03 -07:00
Mike Griese
f4e02d889c Don't NCPAINT our window, PAINT our window (#1898)
* This definitely works for getting shadow, pointy corners back

  Don't do anything in NCPAINT. If you do, you have to do everything. But the
  whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in
  your normal paint. So just do that dummy.

  * This doesn't transition across monitors.
  * This has a window style change I think is wrong.
  * I'm not sure the margins change is important.

* The window style was _not_ important

* Still getting a black xaml islands area (the HRGN) when we switch to high DPI

* I don't know if this affects anything.

* heyo this works.

  I'm not entirely sure why. But if we only update the titlebar drag region when
  that actually changes, it's a _lot_ smoother. I'm not super happy with the
  duplicated work in _UpdateDragRegion and OnSize, but checking this in in case
  I can't figure that out.

* Add more comments and cleanup

* Some PR nits, fix the titlebar painting on maximize
2019-07-12 14:46:27 -05:00
Force Charlie
02e8389518 Fix the conhost command line not being properly escaped (#1815)
This commit re-escapes the path to conhost's subprocess before it launches it.
2019-07-11 19:38:56 -07:00
Carlos Zamora
6d3001f3b8 Double and Triple Click Selection (#1197) 2019-07-11 16:06:18 -07:00
Dustin L. Howett (MSFT)
5b3a554da9 Update the README to clear out references to VS2017 (#1932) 2019-07-11 15:34:18 -07:00
Daniel Griffen
0219781753 Allow the DX rendering engine to run on Windows 7 (#1274)
Certain DirectX features are unavailable on windows 7. The important ones as they are used in the DX renderer are color font rendering and fallback font support. Color fonts did not exist at all on windows 7 so running basic glyphrun rendering should work just fine.

Fallback font support was not exposed to the user in windows 7, making dealing with them difficult. Rather than try to get some workarounds to properly enable it I have opted to just conditionally disable the support on windows 7.
2019-07-11 15:20:15 -07:00
Kayla Cinnamon
b9cc819afe Added links to user docs inside About popup (#1887)
* added links into about section

* added resources and aka.ms links

* moved links to resources

* Move the feedback URI into the resources too!
2019-07-11 21:01:46 +00:00
Michael Niksa
29522c472e Set utf-8 for the entire project (#1929)
* Set utf-8 for the entire project.
2019-07-11 13:13:10 -07:00
Brandon
7b8cf10fe0 Fix wrong maximized window offset on non primary monitors (#1921)
The overhang of a maximized window is currently calculated with this:
```cpp
auto offset = 0;
if (rcMaximum.left == 0)
{
    offset = windowPos->x;
}
else if (rcMaximum.top == 0)
{
    offset = windowPos->y;
}
```

This always works on the primary monitor but on a non primary monitor, it isn't always the case that `left` or `top` can be 0. Examples are when you offset a monitor. In those cases, `offset` will be 0 and the window will be cut off.

Instead I've changed the calculation to calculate the width of the windows frame which is how much it would overhang. Admittedly, the old calculation could be kept and take into consideration the current monitor.
2019-07-11 10:59:19 -07:00
Dustin L. Howett (MSFT)
60a444c630 Obstruct the user when they try to run WT under WOW (#1648)
* Obstruct the user when they try to run under WOW

* Move strings to resource file, add comments to methods, remove extraneous wil include.

* remove excess newline

* output of formatter.
2019-07-11 17:23:23 +00:00
James Holderness
594a7e4501 Fix interpretation of DECSTBM margin parameters (#1881)
* Fix DECSTBM parameter interpretation to ignore invalid ranges, and clear the margins on all full screen ranges.

* Add additional scroll margin adapter tests to verify the parameter configurations that were previously incorrect.

* Fix scroll margin adapter tests that weren't actually verifying the conditions that they claimed to be testing.
2019-07-10 15:41:16 -07:00
Summon528
3ce53adf56 Implement background image over acrylic or solid color (#1107) 2019-07-10 12:54:56 -07:00
Dustin L. Howett (MSFT)
3e5bb99478 inbox: reflect incoming changes up to uxp aa5182a2 (#1916) 2019-07-10 12:40:51 -07:00
Moshe Schorr
b970356600 Fixed DirectX RTL text issue where it'd be over other text / offscreen (#1873)
This is a partial fix of #538 . This does *not* change the Console RTL behavior, it does however fix an issue in the rendering. Basically, DirectX expects the origin to be on the right if it is going to draw RTL text. This PR is a simple fix for that. Rather than draw with the left point and then move the origin rightwards, we check if it's RTL, if so, we move the origin rightwards immediately, and then draw. LTR rendering is unchanged.
This doesn't fix underlying questions of RTL handling in the console. It's just a render bugfix. However, this render bugfix should still be a big help and solve the low-hanging issues.

## Validation Steps Performed
Behavior was tested. No changes were made to underlying console.
Three sample cases:
1. RTL text input
Before:
![image](https://user-images.githubusercontent.com/16987694/60816422-6737e100-a1a2-11e9-9e14-c62323fd5b02.png)
After:
![image](https://user-images.githubusercontent.com/16987694/60816395-5ab38880-a1a2-11e9-9f0a-17b03f8268ce.png)
2. Hebrew Output
Before (the Hebrew text is all being drawn to the left of the screen, hence the phantom text):
![image](https://user-images.githubusercontent.com/16987694/60816527-93ebf880-a1a2-11e9-9ba3-d3ebb46cc404.png)
After:
![image](https://user-images.githubusercontent.com/16987694/60816456-77e85700-a1a2-11e9-9783-9e69849f026d.png)
3. Mixed Output
So, this is where this is partial. Due to inherent stuff with RTL behavior, it doesn't look perfect. But the rendering itself is no longer at fault.
Before:
![image](https://user-images.githubusercontent.com/16987694/60816593-b5e57b00-a1a2-11e9-82be-0fcabb80f7d4.png)
After:
![image](https://user-images.githubusercontent.com/16987694/60816607-bb42c580-a1a2-11e9-849a-12846ec4d5c0.png)
2019-07-10 11:27:36 -07:00
James Holderness
0e6f290806 Fix margin boundary tests in the RI, DL, and IL escape sequences. (#1807)
* Fix margin boundary tests in the RI, DL, and IL sequences.
* Refactor the margin boundary tests into a reusable SCREEN_INFORMATION method.
* Add screen buffer unit tests for the RI, DL, and IL sequences.
2019-07-10 09:42:13 -07:00
Carlos Zamora
46d794b946 bugfix: crash on selection on wide glyphs in scrollback buffer (#1879) 2019-07-10 09:18:20 -07:00
Michael Ratanapintha
af1a4dd068 Added "Vintage" color scheme to defaults; fixes #1781 (#1901)
Testing done: All manual tests:
- Deleted profiles.json, started Terminal.
- Verified that the output "Vintage" color scheme existed.
- Verified that "Vintage" diffed equal to the "Classic" scheme
  in the issue, apart from the name and the addition of
  "background" and "foreground" colors, which I made equal
  to the "black" and "white" ones respectively.
- Verified that I could set a profile to use Vintage
  and that the colors changed accordingly.
2019-07-10 13:52:23 +00:00
Mike Griese
2de2f445c7 Enable resizing the panes with the keyboard. (#1207)
Adds the ability to resize panes with the keyboard. 

This is accomplished by making the Column/RowDefinitions for a Pane use `GridLengthHelper::FromPixels` to set their size. We store a pair of floats that represents the relative amount that each pane takes out of the parent pane. When the window is resized, we use that percentage to figure out the new size of each child in pixels, and manually size each column. 

Then, when the user presses the keybindings for resizePane{Left/Right/Up/Down}, we'll adjust those percentages, and resize the rows/cols as appropriate.

Currently, each pane adjusts the width/height by 5% of the total size at a time. I am not in love with this, but it works for now. I think when we get support for keybindings with arbitrary arg blobs, then we could do either a percent movement, or a number of characters at a time. The number of characters one would be trickier, because we'd have to get the focused control, and get the number of pixels per character, as adjacent panes might not have the same font sizes.
2019-07-10 08:27:12 -05:00
Dustin L. Howett (MSFT)
122f0de382 Move most of TerminalApp's runtime Xaml to a .xaml file and class (#1885) 2019-07-09 14:47:30 -07:00
Gautam Naik
cfbc9e8f9f Added fontSize and acrylicOpacity changing tip (#1889)
* Added fontSize and acrylicOpacity changing tip

Added Terminal tip about changing the font size and acrylic opacity using keyboard shortcuts.

* Update index.md
2019-07-09 12:19:06 -07:00
Michael Guntsche
bce8a79163 Make opening the settings file more robust (#1841)
* Make opening the settings file more robust

This fixes two issues.

 * Opens the assigned default application regardless of its configuration.
   Gvim for example only reacts to the "edit" verb so when selected as default application won't open.
   Using nullptr results in using the first specified application.
   This fixes #1789
 * If no application is assigned for json files fall back to notepad

 See https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea for more details
 especially why the result code checking is so horrific.

* Fix c-style cast
2019-07-09 07:29:44 -05:00
Alec Clews
c9d8e3ee2b The start of some User docs (#1577)
* Start User docs

* Fix typos

* Addded some more TODO

* Update doc/user-docs/index.md

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* Update doc/user-docs/index.md

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* Update doc/user-docs/index.md

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* Update doc/user-docs/index.md

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* Updated from suggestions in the PR

* Improve path to profiles.json

* Added some details about Json settings

* Example Json settings, and a #TODO

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/UsingJsonSettings.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* Update doc/user-docs/index.md

Co-Authored-By: Kayla Cinnamon <48369326+cinnamon-msft@users.noreply.github.com>

* After review and make colour US.

1. Merged in comments from PR
2. Made colour color :-(
3. Other tidy ups

* Added more detais about background images

* Remove some TODO comments and minot tidy up

* Get rid of TODO

1. Some notes abouet cut and paste -- needs more work
2. Get rid of TODO -- replace with links to issues
3. Add some extra notes about URI for background images
2019-07-08 11:17:19 -07:00
Martin Gill
7eae91ea3c Fixed #1186, incorrect path was calculted when module already installed locally. (#1839) 2019-07-05 18:58:14 -07:00
Kayla Cinnamon
eda6547ba3 added default values to global and profiles (#1784) 2019-07-05 10:04:14 -07:00
Summon528
c6ca298fdb Make padding applied as swap chain panel's margin (#1778) 2019-07-05 10:03:51 -07:00
Michael Niksa
eae920e5f9 Propose banner at top of templates (#1687)
* Propose banner at top of issue templates

Getting tired of obvious low quality issues and I want to provide the warning that we may start closing things without further explanation as our volume is too high to deal with junk issues.

* Add bot rule information too.
2019-07-03 11:44:37 -07:00
Michael Niksa
d8485079cd Stop crash on window snap by preventing torn device resources state (#1768)
* Stop crash on window snap by preventing torn device resources state when quick on-the-fly resizing operations happen. #1572
2019-07-02 12:51:28 -07:00
Antoine Cotten
078e6420fe Fix inaccurate Solarized palette (#1720) 2019-07-02 12:24:07 -07:00
Christopher Harrison
874324fad2 Updated link to docs (#1779)
The link to docs was pointing to issues. Set it to point to the root of the repo.
2019-07-02 14:08:17 -05:00
James Holderness
fe7fd332b0 Support VT100 DECOM Origin Mode (#1331)
* Add support for origin mode (DECOM).
* Added a state machine unit test for the origin mode.
* Prevent the cursor position moving below the bottom margin of the scrolling region if the origin mode is relative.
* Only adjust the relative cursor position for origin mode if the scrolling region is actually set.
* Add some screenbuffer unit tests for the origin mode.
* Enhance the soft reset screenbuffer tests to verify the origin mode is reset.
* Move the origin mode flag constructor assignments into the intializer list.
2019-07-02 11:17:04 -07:00
dnagl
5dbcd4c4f8 #1536 - Feature Request - Duplicate tab (#1685)
* Implemented method to duplicate a tab
* Added event definitions for duplicating a tab with keyboard shortcut(CTRL + SHIFT + D)
2019-07-02 10:45:51 -07:00
James Holderness
2e0e9628fc Enable DECCOLM support via a private mode escape sequence (#1709)
* Implement XTerm's private mode escape sequence for enabling DECCOLM support.
* Add output engine and screen buffer units test for the private mode 40 escape sequence.
2019-07-02 10:24:11 -07:00
Kayla Cinnamon
c791b7870d Add support for setting a profile's tab title (#1358)
tab renaming functionality
2019-07-02 10:09:22 -07:00
Mike Griese
47b1fe61fc Update the title of the bug report template (#1767) 2019-07-01 17:11:06 -07:00
Dustin L. Howett (MSFT)
171c37009e Replace caption buttons with ones that look close to correct (#1627) 2019-07-01 14:38:56 -07:00
Ryan Beesley
f63cada9ed Change Campbell's default foreground color (#1629)
Changed the foreground color from #F2F2F2 to #CCCCCC so that ESC[1m _actually_ brightens it.
2019-06-28 18:19:41 -07:00
Peter Nelson
14d2484acf Revoke old event handlers correctly on pane close (#1279) 2019-06-28 18:17:31 -07:00
Dustin L. Howett (MSFT)
e1ce8a5ed7 Move to Microsoft.UI.Xaml 2.2.109211001-prerelease (#1707)
Fixes #1265.
2019-06-28 18:03:43 -07:00
PankajBhojwani
10ed3991fc Spec for #1235 Azure Cloud Shell connector (#1624)
* Azure connector spec
2019-06-28 15:48:19 -07:00
PankajBhojwani
b353ad8c16 App now initializes the connection instead of term control. (#1676)
* App now initializes the connection instead of term control.
2019-06-28 10:55:46 -07:00
Michael Niksa
688c96cba9 Update bot tag system enforcement
I added the new rule that `Resolution-Duplicate` doesn't require the other tags. This documents the change.
2019-06-28 09:40:28 -07:00
Leonard Hecker
6775325839 Fixed #521 - AltGr combinations not working (#1436)
This commit changes how TerminalControl/TerminalCore handle key events to give it better knowledge about modifier states at the lower levels.
2019-06-27 16:20:55 -07:00
Michael Niksa
c0720525c5 Update bot doc for In-PR label rule (#1678) 2019-06-27 12:47:11 -07:00
Dustin L. Howett (MSFT)
54457e550a Disable the AppContainer bit on our C++/WinRT binaries (#1653)
Having the AppContainer bit enabled makes us fail the Windows App
Certification Kit test required to submit to the store.
2019-06-26 16:54:13 -07:00
Oscar Calvo
45ad2d71bf Fix a bug where Terminal may crash or hang at shutdown (#1651)
* Fix a bug where Terminal may crash at shutdown
2019-06-26 15:15:01 -07:00
Michael Niksa
5dd1f8d38a move version to vs2019, the 1903 sdk, and the 14.2 build tools. (#1012)
* move version to vs2019, the 1903 sdk, and the 14.2 build tools.
2019-06-26 14:13:32 -07:00
David Jackman
04e808fd0a Add feature to ColorTool to write color scheme as JSON for Windows Terminal (issue #986) (#1052)
* Add a new console target that writes the color scheme to stdout in JSON format for copying into a Windows Terminal profiles.json file.

* Update src/tools/ColorTool/ColorTool/ConsoleTargets/TerminalSchemeConsoleTarget.cs

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>

* Create a base class for scheme parsers for common code and helpers.  Fix string formatting according to review comments.
2019-06-25 13:36:00 -07:00
Oscar Calvo
ab08320dde Apply a GDI region to the top level Island window to allow dragging with a single Island (#929)
* Use a region to cut off the dragable region
* Use proper measurements for the draggable area
* Working better, paint works most of the time
* Fix a bug where paint is incomplete when double clicking the dragbar
* Remove old fork on XamlApplication
* Upgrade to XamlApp preview6.2
* Add Microsoft.VCRTForwarders to make it easy to dogfood

Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
Co-Authored-By: Mike Griese <migrie@microsoft.com>
2019-06-25 13:06:11 -07:00
d-bingham
b115799810 Connect clipboard functionality to their keybindings (#1093)
* Connects clipboard functionality to their keybindings.

* Cleaning up comments and whitespace.

* Added "copyTextWithoutNewlines" keybinding.

* Fixing tabs in idl file

* Fixing merge conflicts

* Adding default keybindings for copy and paste to ctrl-shift-c and ctrl-shift-v, respectively.

* Complying with refactoring

* Fixing formatting issues
2019-06-25 12:17:02 -07:00
Daniel Griffen
b9e66fee6d Add a fallback to software rendering (#1263)
This commit enables a software rendering fallback for the DX renderer in the case that hardware acceleration fails. This is primarily useful for Hyper-V environments where hardware acceleration is not guaranteed to exist.

This will be useful for future work to enable the DX renderer to run on windows 7 since win7 virtual machines do not/cannot have hardware acceleration unlike windows 10 machines

This commit does two things:
- Fallback to `D3D_DRIVER_TYPE_WARP` if `D3D_DRIVER_TYPE_HARDWARE` fails.
- pass `NULL` as the adapter instead of creating the default adapter ourselves.
2019-06-24 17:02:26 -07:00
David Kean
bc236c7c59 Set the default startup project (#1314)
Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution.

The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 09:47:00 -07:00
Summon528
0fba910d75 Make the about dialog's contents selectable (#1452) 2019-06-24 09:13:11 -07:00
Balakrishna Prasad Ganne
198acadc05 doc: fix some punctuation in README.md (#1512)
Typo fixes
2019-06-24 09:12:10 -07:00
Oskar Oldorf
a5f31f77bc doc: Add ColorTool link to profiles.json documentation (#1396) 2019-06-22 18:18:14 -07:00
Kayla Cinnamon
ce4c6d6124 Update the to link to the public preview (#1374) 2019-06-21 19:02:48 -07:00
Dustin L. Howett (MSFT)
08464648f2 inbox: reflect incoming changes from Windows (#1359)
official/rs_onecore_dep_acioss 9638166d8c8374081a2aa8b8f9ecabf2bae0df0a
2019-06-20 17:51:04 -07:00
465 changed files with 32704 additions and 13686 deletions

View File

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

View File

@@ -7,7 +7,20 @@ assignees: ''
---
# Summary of the new feature/enhancement
<!--
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.
All good? Then proceed!
-->
# Description of the new feature/enhancement
<!--
A clear and concise description of what the problem is that the new feature would solve.

View File

@@ -25,10 +25,10 @@
"Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.Component.VC.Tools.ARM64",
"Microsoft.VisualStudio.Component.VC.v141.x86.x64",
"Microsoft.VisualStudio.Component.VC.v141.ARM64",
"Microsoft.VisualStudio.Component.VC.v142.x86.x64",
"Microsoft.VisualStudio.Component.VC.v142.ARM64",
"Microsoft.VisualStudio.ComponentGroup.UWP.VC",
"Microsoft.VisualStudio.ComponentGroup.UWP.VC.v141",
"Microsoft.VisualStudio.ComponentGroup.UWP.VC.v142",
"Microsoft.VisualStudio.Component.UWP.VC.ARM64"
]
}

View File

@@ -5,7 +5,10 @@
<!-- Add repositories here to the list of available repositories -->
<!-- Dependencies that we must carry because they're not on public nuget feeds right now. -->
<add key="Static Package Dependencies" value="dep\packages" />
<!--<add key="Static Package Dependencies" value="dep\packages" />-->
<!-- Use our own NuGet Feed -->
<add key="Windows Terminal NuGet Feed" value="https://terminalnuget.blob.core.windows.net/feed/index.json" />
<!-- Internal NuGet feeds that may not be accessible outside Microsoft corporate network -->
<!--<add key="TAEF - internal" value="https://microsoft.pkgs.visualstudio.com/DefaultCollection/_packaging/Taef/nuget/v3/index.json" />

View File

@@ -1,8 +1,12 @@
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.27004.2008
# Visual Studio Version 16
VisualStudioVersion = 16.0.29001.49
MinimumVisualStudioVersion = 10.0.40219.1
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Terminal", "Terminal", "{59840756-302F-44DF-AA47-441A9D673202}"
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "CascadiaPackage", "src\cascadia\CascadiaPackage\CascadiaPackage.wapproj", "{CA5CAD1A-224A-4171-B13A-F16E576FDD12}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.EXE", "src\host\exe\Host.EXE.vcxproj", "{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
@@ -163,8 +167,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "BufferOut", "src\buffer\out
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererDx", "src\renderer\dx\lib\dx.vcxproj", "{48D21369-3D7B-4431-9967-24E81292CF62}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Terminal", "Terminal", "{59840756-302F-44DF-AA47-441A9D673202}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalConnection", "src\cascadia\TerminalConnection\TerminalConnection.vcxproj", "{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalCore", "src\cascadia\TerminalCore\lib\TerminalCore-lib.vcxproj", "{CA5CAD1A-ABCD-429C-B551-8562EC954746}"
@@ -180,8 +182,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalControl", "src\casc
{1CF55140-EF6A-4736-A403-957E4F7430BB} = {1CF55140-EF6A-4736-A403-957E4F7430BB}
EndProjectSection
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "CascadiaPackage", "src\cascadia\CascadiaPackage\CascadiaPackage.wapproj", "{CA5CAD1A-224A-4171-B13A-F16E576FDD12}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminal", "src\cascadia\WindowsTerminal\WindowsTerminal.vcxproj", "{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
@@ -193,6 +193,7 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminal", "src\casc
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalApp", "src\cascadia\TerminalApp\TerminalApp.vcxproj", "{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
@@ -202,8 +203,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalSettings", "src\cas
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "OpenConsolePackage", "pkg\appx\OpenConsolePackage.wapproj", "{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.UI.Xaml.Markup", "src\cascadia\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.vcxproj", "{015A0047-772D-4F1A-88C9-45C18F0ADFB6}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalCore", "src\cascadia\UnitTests_TerminalCore\UnitTests.vcxproj", "{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Internal", "src\internal\internal.vcxproj", "{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}"
@@ -233,6 +232,24 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Shared", "Shared", "{89CDCC
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types.Unit.Tests", "src\types\ut_types\Types.Unit.Tests.vcxproj", "{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalApp", "src\cascadia\ut_app\TerminalApp.UnitTests.vcxproj", "{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAppLib", "src\cascadia\TerminalApp\lib\TerminalAppLib.vcxproj", "{CA5CAD1A-9A12-429C-B551-8562EC954746}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "LocalTests_TerminalApp", "src\cascadia\LocalTests_TerminalApp\TerminalApp.LocalTests.vcxproj", "{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty", "src\winconpty\winconpty.vcxproj", "{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
AuditMode|ARM64 = AuditMode|ARM64
@@ -246,12 +263,30 @@ Global
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Deploy.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Deploy.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Build.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Deploy.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Deploy.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Deploy.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Build.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Deploy.0 = Release|x86
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.Build.0 = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.Build.0 = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.Build.0 = Release|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
@@ -265,11 +300,8 @@ Global
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|ARM64.Build.0 = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x64.ActiveCfg = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x64.Build.0 = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x86.ActiveCfg = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x86.Build.0 = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.ActiveCfg = Debug|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.Build.0 = Debug|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x64.ActiveCfg = Debug|x64
@@ -283,11 +315,8 @@ Global
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.ActiveCfg = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.Build.0 = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|ARM64.Build.0 = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x64.ActiveCfg = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x64.Build.0 = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x86.ActiveCfg = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x86.Build.0 = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.Build.0 = Debug|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x64.ActiveCfg = Debug|x64
@@ -301,11 +330,8 @@ Global
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.ActiveCfg = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.Build.0 = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|ARM64.Build.0 = Release|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.ActiveCfg = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.Build.0 = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x86.ActiveCfg = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x86.Build.0 = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.Build.0 = Debug|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x64.ActiveCfg = Debug|x64
@@ -319,11 +345,8 @@ Global
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.ActiveCfg = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.Build.0 = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.Build.0 = Release|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.Build.0 = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
@@ -337,11 +360,8 @@ Global
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.Build.0 = Release|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.Build.0 = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
@@ -355,11 +375,8 @@ Global
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|ARM64.Build.0 = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.ActiveCfg = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.Build.0 = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x86.ActiveCfg = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x86.Build.0 = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.ActiveCfg = Debug|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.Build.0 = Debug|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x64.ActiveCfg = Debug|x64
@@ -373,11 +390,8 @@ Global
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.ActiveCfg = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.Build.0 = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|ARM64.Build.0 = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x64.ActiveCfg = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x64.Build.0 = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x86.ActiveCfg = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x86.Build.0 = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.Build.0 = Debug|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x64.ActiveCfg = Debug|x64
@@ -391,11 +405,8 @@ Global
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.ActiveCfg = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
@@ -409,11 +420,8 @@ Global
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x64.ActiveCfg = Debug|x64
@@ -427,11 +435,8 @@ Global
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.Build.0 = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|ARM64.Build.0 = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x86.Build.0 = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
@@ -445,11 +450,8 @@ Global
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|ARM64.Build.0 = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x86.Build.0 = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
@@ -463,11 +465,8 @@ Global
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|ARM64.Build.0 = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x64.ActiveCfg = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x64.Build.0 = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x86.ActiveCfg = Release|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x86.Build.0 = Release|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.ActiveCfg = Debug|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.Build.0 = Debug|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x64.ActiveCfg = Debug|x64
@@ -479,11 +478,8 @@ Global
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x64.Build.0 = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x86.ActiveCfg = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|ARM64.Build.0 = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x64.ActiveCfg = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x64.Build.0 = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x86.ActiveCfg = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x86.Build.0 = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.ActiveCfg = Debug|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.Build.0 = Debug|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x64.ActiveCfg = Debug|x64
@@ -497,11 +493,8 @@ Global
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.ActiveCfg = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.Build.0 = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|ARM64.Build.0 = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x64.ActiveCfg = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x64.Build.0 = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x86.ActiveCfg = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x86.Build.0 = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.ActiveCfg = Debug|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.Build.0 = Debug|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x64.ActiveCfg = Debug|x64
@@ -515,11 +508,8 @@ Global
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.ActiveCfg = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.Build.0 = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|ARM64.Build.0 = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x64.ActiveCfg = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x64.Build.0 = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x86.ActiveCfg = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x86.Build.0 = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.Build.0 = Debug|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x64.ActiveCfg = Debug|x64
@@ -533,11 +523,8 @@ Global
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.ActiveCfg = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.Build.0 = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|ARM64.Build.0 = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x64.ActiveCfg = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x64.Build.0 = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x86.ActiveCfg = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x86.Build.0 = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.Build.0 = Debug|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x64.ActiveCfg = Debug|x64
@@ -551,11 +538,8 @@ Global
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.ActiveCfg = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.Build.0 = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|ARM64.Build.0 = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x64.ActiveCfg = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x64.Build.0 = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x86.ActiveCfg = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x86.Build.0 = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.ActiveCfg = Debug|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.Build.0 = Debug|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x64.ActiveCfg = Debug|x64
@@ -569,11 +553,8 @@ Global
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.ActiveCfg = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.Build.0 = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|ARM64.Build.0 = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x86.Build.0 = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.Build.0 = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x64.ActiveCfg = Debug|x64
@@ -587,11 +568,8 @@ Global
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.Build.0 = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM64.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM64.Build.0 = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x64.ActiveCfg = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x64.Build.0 = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x86.ActiveCfg = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x86.Build.0 = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|ARM64.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.Build.0 = Debug|x64
@@ -603,11 +581,8 @@ Global
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.ActiveCfg = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.Build.0 = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM64.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM64.Build.0 = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x64.ActiveCfg = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x64.Build.0 = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x86.ActiveCfg = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x86.Build.0 = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|ARM64.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.ActiveCfg = Debug|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.Build.0 = Debug|x64
@@ -619,11 +594,8 @@ Global
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.ActiveCfg = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.Build.0 = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|ARM64.Build.0 = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x64.ActiveCfg = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x64.Build.0 = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x86.ActiveCfg = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x86.Build.0 = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.ActiveCfg = Debug|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.Build.0 = Debug|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x64.ActiveCfg = Debug|x64
@@ -637,11 +609,8 @@ Global
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.ActiveCfg = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.Build.0 = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|ARM64.Build.0 = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x64.ActiveCfg = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x64.Build.0 = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x86.ActiveCfg = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x86.Build.0 = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.Build.0 = Debug|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x64.ActiveCfg = Debug|x64
@@ -655,11 +624,8 @@ Global
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.ActiveCfg = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.Build.0 = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|ARM64.Build.0 = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x86.Build.0 = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
@@ -673,11 +639,8 @@ Global
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x64.ActiveCfg = Debug|x64
@@ -691,11 +654,8 @@ Global
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.Build.0 = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|ARM64.Build.0 = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x86.Build.0 = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
@@ -709,11 +669,8 @@ Global
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|ARM64.Build.0 = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x86.Build.0 = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.Build.0 = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x64.ActiveCfg = Debug|x64
@@ -727,11 +684,8 @@ Global
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.Build.0 = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|ARM64.Build.0 = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x64.ActiveCfg = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x64.Build.0 = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x86.ActiveCfg = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x86.Build.0 = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.ActiveCfg = Debug|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.Build.0 = Debug|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x64.ActiveCfg = Debug|x64
@@ -745,11 +699,8 @@ Global
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.ActiveCfg = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.Build.0 = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|ARM64.Build.0 = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x64.ActiveCfg = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x64.Build.0 = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x86.ActiveCfg = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x86.Build.0 = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.Build.0 = Debug|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x64.ActiveCfg = Debug|x64
@@ -763,11 +714,8 @@ Global
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.ActiveCfg = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.Build.0 = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|ARM64.Build.0 = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x86.Build.0 = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.Build.0 = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x64.ActiveCfg = Debug|x64
@@ -781,11 +729,8 @@ Global
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.Build.0 = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.Build.0 = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x64.Build.0 = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x86.Build.0 = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
@@ -799,11 +744,8 @@ Global
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.ActiveCfg = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.Build.0 = Release|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.Build.0 = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x64.Build.0 = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x86.Build.0 = Release|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
@@ -835,11 +777,8 @@ Global
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.Build.0 = Release|Win32
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|ARM64.Build.0 = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x86.Build.0 = Release|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.Build.0 = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x64.ActiveCfg = Debug|x64
@@ -889,11 +828,8 @@ Global
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x64.ActiveCfg = Debug|x64
@@ -907,11 +843,8 @@ Global
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
@@ -925,11 +858,8 @@ Global
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x64.ActiveCfg = Debug|x64
@@ -942,39 +872,9 @@ Global
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.Deploy.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.Deploy.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.Build.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.Deploy.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Deploy.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Deploy.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Build.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Deploy.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Deploy.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Deploy.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Build.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Deploy.0 = Release|x86
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
@@ -988,11 +888,8 @@ Global
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
@@ -1006,11 +903,8 @@ Global
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x64.Build.0 = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x64.ActiveCfg = Debug|x64
@@ -1024,14 +918,8 @@ Global
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.Build.0 = Release|Win32
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|ARM64.Build.0 = Release|ARM64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|ARM64.Deploy.0 = Release|ARM64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x64.ActiveCfg = Release|x64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x64.Build.0 = Release|x64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x64.Deploy.0 = Release|x64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x86.ActiveCfg = Release|x86
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x86.Build.0 = Release|x86
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.AuditMode|x86.Deploy.0 = Release|x86
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Debug|ARM64.Build.0 = Debug|ARM64
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Debug|ARM64.Deploy.0 = Debug|ARM64
@@ -1050,30 +938,9 @@ Global
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Release|x86.ActiveCfg = Release|x86
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Release|x86.Build.0 = Release|x86
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310}.Release|x86.Deploy.0 = Release|x86
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|ARM64.Build.0 = Release|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|x64.ActiveCfg = Release|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|x64.Build.0 = Release|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|x86.ActiveCfg = Release|Win32
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.AuditMode|x86.Build.0 = Release|Win32
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|ARM64.ActiveCfg = Debug|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|ARM64.Build.0 = Debug|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|x64.ActiveCfg = Debug|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|x64.Build.0 = Debug|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|x86.ActiveCfg = Debug|Win32
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Debug|x86.Build.0 = Debug|Win32
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|ARM64.ActiveCfg = Release|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|ARM64.Build.0 = Release|ARM64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|x64.ActiveCfg = Release|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|x64.Build.0 = Release|x64
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|x86.ActiveCfg = Release|Win32
{015A0047-772D-4F1A-88C9-45C18F0ADFB6}.Release|x86.Build.0 = Release|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.Build.0 = AuditMode|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.Build.0 = AuditMode|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
@@ -1105,11 +972,8 @@ Global
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.ActiveCfg = Release|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.Build.0 = Release|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x64.ActiveCfg = AuditMode|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x64.Build.0 = AuditMode|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x86.Build.0 = AuditMode|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.ActiveCfg = Debug|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.Build.0 = Debug|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x64.ActiveCfg = Debug|x64
@@ -1122,11 +986,72 @@ Global
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x64.Build.0 = Release|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.ActiveCfg = Release|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.Build.0 = Debug|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.Build.0 = Debug|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.Build.0 = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x64.ActiveCfg = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x86.ActiveCfg = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.ActiveCfg = Debug|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.Build.0 = Debug|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.ActiveCfg = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.Build.0 = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.ActiveCfg = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.Build.0 = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.ActiveCfg = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.Build.0 = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.ActiveCfg = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.Build.0 = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.ActiveCfg = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.Build.0 = Release|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(NestedProjects) = preSolution
{CA5CAD1A-224A-4171-B13A-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{4C8E6BB0-4713-4ADB-BD04-81628ECEAF20} = {81C352DB-1818-45B7-A284-18E259F1CC87}
@@ -1168,12 +1093,10 @@ Global
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-224A-4171-B13A-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {59840756-302F-44DF-AA47-441A9D673202}
{2D310963-F3E0-4EE5-8AC6-FBC94DCC3310} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{015A0047-772D-4F1A-88C9-45C18F0ADFB6} = {59840756-302F-44DF-AA47-441A9D673202}
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9} = {59840756-302F-44DF-AA47-441A9D673202}
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{16376381-CE22-42BE-B667-C6B35007008D} = {81C352DB-1818-45B7-A284-18E259F1CC87}
@@ -1181,6 +1104,10 @@ Global
{05500DEF-2294-41E3-AF9A-24E580B82836} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{1E4A062E-293B-4817-B20D-BF16B979E350} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {59840756-302F-44DF-AA47-441A9D673202}
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {3140B1B7-C8EE-43D1-A772-D82A7061A271}

View File

@@ -1,14 +1,40 @@
# Welcome\!
#### This repository contains the source code for:
* Windows Terminal
* [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701)
* The Windows console host (`conhost.exe`)
* Components shared between the two projects
* [ColorTool](https://github.com/Microsoft/Terminal/tree/master/src/tools/ColorTool)
* [Sample projects](https://github.com/Microsoft/Terminal/tree/master/samples) that show how to consume the Windows Console APIs
#### Other related repositories include:
* [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs/issues)
* [Console API Documentation](https://github.com/MicrosoftDocs/Console-Docs)
## Installation
_(Note: in order to run the Windows Terminal, you'll need to be running at least Windows build 18362 or higher.)_
### Microsoft Store
Download the Microsoft Terminal free from the Microsoft Store and it'll be continuously updated. Or, feel free to side-load [releases](https://github.com/microsoft/terminal/releases) from GitHub, but note they won't auto-update.
<a href='//www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge'><img src='https://assets.windowsphone.com/85864462-9c82-451e-9355-a3d5f874397a/English_get-it-from-MS_InvariantCulture_Default.png' alt='English badge' width="284" height="104" style='width: 284px; height: 104px;'/></a>
### Chocolatey (Unofficial)
Download and upgrade the Windows Terminal from [Chocolatey](https://chocolatey.org).
To install Windows Terminal, run the following command from the command line or from PowerShell:
```powershell
choco install microsoft-windows-terminal
```
To upgrade Windows Terminal, run the following command from the command line or from PowerShell:
```powershell
choco upgrade microsoft-windows-terminal
```
If you have any issues when installing/upgrading the package please go to the [package page](https://chocolatey.org/packages/microsoft-windows-terminal) and follow the [Chocolatey triage process](https://chocolatey.org/docs/package-triage-process)
### Build Status
@@ -17,6 +43,10 @@ Project|Build Status
Terminal|[![Build Status](https://dev.azure.com/ms/Terminal/_apis/build/status/Terminal%20CI?branchName=master)](https://dev.azure.com/ms/Terminal/_build?definitionId=136)
ColorTool|![](https://microsoft.visualstudio.com/_apis/public/build/definitions/c93e867a-8815-43c1-92c4-e7dd5404f1e1/17023/badge)
# Windows Terminal Project's Timeline
The plan for delivering Windows Terminal v1.0 [is described here](/doc/terminal-v1-timeline.md), and will be updated as the project proceeds.
# Terminal & Console Overview
Please take a few minutes to review the overview below before diving into the code:
@@ -55,16 +85,12 @@ Further, we realized that this would allow us to build the terminal's renderer a
## Where can I download Windows Terminal?
### There are no binaries to download quite yet.
The Windows Terminal is in the _very early_ alpha stage, and not ready for the general public quite yet. If you want to jump in early, you can try building it yourself from source.
Otherwise, you'll need to wait until Mid-June for an official preview build to drop.
The latest release of Windows Terminal can be downloaded from [this repo's Releases](https://github.com/microsoft/terminal/releases) page or [from the Microsoft Store](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701)
## I built and ran the new Terminal, but I just get a blank window app!
Make sure you are building for your computer's architecture. If your box has a 64-bit Windows change your Solution Platform to x64.
To check your OS architecture go to Settings -> System -> About (or Win+X -> System) and under `Device specifications` check for the `System type`
Make sure you are building for your computer's architecture. If your box has a 64-bit Windows, change your Solution Platform to x64.
To check your OS architecture go to Settings -> System -> About (or Win+X -> System) and under `Device specifications` check for the `System type`.
## I built and ran the new Terminal, but it looks just like the old console! What gives?
@@ -81,7 +107,7 @@ Secondly, try pressing <kbd>Ctrl</kbd> + <kbd>T</kbd>. The tabs are hidden when
## Debugging
* To debug in VS, right click on CascadiaPackage (from VS Solution Explorer) and go to properties, in the Debug menu, change "Application process" and "Background task process" to "Native Only"
* To debug in VS, right click on CascadiaPackage (from VS Solution Explorer) and go to properties, in the Debug menu, change "Application process" and "Background task process" to "Native Only".
## Contributing
@@ -117,14 +143,14 @@ If you would like to ask a question that you feel doesn't warrant an issue (yet)
## Build Prerequisites
* You must be running Windows 1903 (build >= 10.0.18362.0) or above in order to run Windows Terminal
* You must have the [1903 SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk) (build 10.0.18362.0) installed
* You must have at least [VS 2017](https://visualstudio.microsoft.com/downloads/) installed.
* You must install the following Workloads via the VS Installer. If you're running VS 2019, opening the solution will [prompt you to install missing components automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/).
* You must be running Windows 1903 (build >= 10.0.18362.0) or above in order to run Windows Terminal.
* You must have the [1903 SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk) (build 10.0.18362.0) installed.
* You must have at least [VS 2019](https://visualstudio.microsoft.com/downloads/) installed.
* You must install the following Workloads via the VS Installer. Opening the solution will [prompt you to install missing components automatically](https://devblogs.microsoft.com/setup/configure-visual-studio-across-your-organization-with-vsconfig/).
- Desktop Development with C++
- Universal Windows Platform Development
- Also install the following Individual Component:
- C++ (v141) Universal Windows Platform Tools
- **The following Individual Components**
- C++ (v142) Universal Windows Platform Tools
* You must also [enable Developer Mode in the Windows Settings app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development) to locally install and run the Terminal app.

41
SECURITY.md Normal file
View File

@@ -0,0 +1,41 @@
<!-- BEGIN MICROSOFT SECURITY.MD V0.0.2 BLOCK -->
## Security
Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [many more](https://opensource.microsoft.com/).
If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's [definition](https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc751383(v=technet.10)) of a security vulnerability, please report it to us as described below.
## Reporting Security Issues
**Please do not report security vulnerabilities through public GitHub issues.**
Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://msrc.microsoft.com/create-report).
If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the the [Microsoft Security Response Center PGP Key page](https://www.microsoft.com/en-us/msrc/pgp-key-msrc).
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc).
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
* Full paths of source file(s) related to the manifestation of the issue
* The location of the affected source code (tag/branch/commit or direct URL)
* Any special configuration required to reproduce the issue
* Step-by-step instructions to reproduce the issue
* Proof-of-concept or exploit code (if possible)
* Impact of the issue, including how an attacker might exploit the issue
This information will help us triage your report more quickly.
If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://microsoft.com/msrc/bounty) page for more details about our active programs.
## Preferred Languages
We prefer all communications to be in English.
## Policy
Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://www.microsoft.com/en-us/msrc/cvd).
<!-- END MICROSOFT SECURITY.MD BLOCK -->

View File

@@ -13,6 +13,11 @@ pr:
branches:
include:
- master
paths:
exclude:
- doc/*
- samples/*
- tools/*
# 0.0.yyMM.dd##
# 0.0.1904.0900

View File

@@ -8,7 +8,7 @@ jobs:
variables:
BuildConfiguration: AuditMode
BuildPlatform: ${{ parameters.platform }}
pool: { vmImage: vs2017-win2016 }
pool: { vmImage: windows-2019 }
steps:
- checkout: self
@@ -45,7 +45,7 @@ jobs:
displayName: 'Build solution **\OpenConsole.sln'
inputs:
solution: '**\OpenConsole.sln'
vsVersion: 15.0
vsVersion: 16.0
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
msbuildArgs: ${{ parameters.additionalBuildArguments }}

View File

@@ -9,7 +9,7 @@ jobs:
variables:
BuildConfiguration: ${{ parameters.configuration }}
BuildPlatform: ${{ parameters.platform }}
pool: { vmImage: vs2017-win2016 }
pool: { vmImage: windows-2019 }
steps:
- template: build-console-steps.yml

View File

@@ -39,13 +39,21 @@ steps:
displayName: 'Build solution **\OpenConsole.sln'
inputs:
solution: '**\OpenConsole.sln'
vsVersion: 15.0
vsVersion: 16.0
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
msbuildArgs: ${{ parameters.additionalBuildArguments }}
clean: true
maximumCpuCount: true
- task: PowerShell@2
displayName: 'Check MSIX for common regressions'
inputs:
targetType: inline
script: |
$Package = Get-ChildItem -Recurse -Filter "CascadiaPackage_*.msix"
.\build\scripts\Test-WindowsTerminalPackage.ps1 -Verbose -Path $Package.FullName
- task: VSTest@2
displayName: 'Run Unit Tests'
inputs:

View File

@@ -2,7 +2,7 @@
jobs:
- job: CodeFormatCheck
displayName: Proper Code Formatting Check
pool: { vmImage: vs2017-win2016 }
pool: { vmImage: windows-2019 }
steps:
- checkout: self

View File

@@ -0,0 +1,41 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="16.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<BeforeLinkTargets Condition="'$(WindowsTargetPlatformVersion)' &gt;= '10.0.18362.0'">
$(BeforeLinkTargets);
_ConsoleGenerateAdditionalWinmdManifests;
</BeforeLinkTargets>
</PropertyGroup>
<Target Name="_ConsoleMapWinmdsToManifestFiles" DependsOnTargets="ResolveAssemblyReferences">
<ItemGroup>
<!-- For each non-system .winmd file in References, generate a .manifest in IntDir for it. -->
<_ConsoleWinmdManifest Include="@(ReferencePath->'$(IntDir)\%(FileName).manifest')" Condition="'%(ReferencePath.IsSystemReference)' != 'true' and '%(ReferencePath.WinMDFile)' == 'true' and '%(ReferencePath.ReferenceSourceTarget)' == 'ResolveAssemblyReference'">
<WinMDPath>%(ReferencePath.FullPath)</WinMDPath>
<Implementation>%(ReferencePath.Implementation)</Implementation>
</_ConsoleWinmdManifest>
<!-- For each referenced project that _produces_ a winmd, generate a temporary item that maps to
the winmd, and use that temporary item to generate a .manifest in IntDir for it.
We don't set Implementation here because it's inherited from the _ResolvedNativeProjectReferencePaths. -->
<_ConsoleWinmdProjectReference Condition="'%(_ResolvedNativeProjectReferencePaths.ProjectType)' != 'StaticLibrary'" Include="@(_ResolvedNativeProjectReferencePaths-&gt;WithMetadataValue('FileType','winmd')-&gt;'%(RootDir)%(Directory)%(TargetPath)')" />
<_ConsoleWinmdManifest Include="@(_ConsoleWinmdProjectReference->'$(IntDir)\%(FileName).manifest')">
<WinMDPath>%(Identity)</WinMDPath>
</_ConsoleWinmdManifest>
</ItemGroup>
</Target>
<Target Name="_ConsoleGenerateAdditionalWinmdManifests"
Inputs="@(_ConsoleWinmdManifest.WinMDPath)"
Outputs="@(_ConsoleWinmdManifest)"
DependsOnTargets="_ConsoleMapWinmdsToManifestFiles">
<!-- This target is batched and a new Exec is spawned for each entry in _ConsoleWinmdManifest. -->
<Exec Command="mt.exe -winmd:%(_ConsoleWinmdManifest.WinMDPath) -dll:%(_ConsoleWinmdManifest.Implementation) -out:%(_ConsoleWinmdManifest.Identity)" />
<ItemGroup>
<!-- Emit the generated manifest into the Link inputs. -->
<Manifest Include="@(_ConsoleWinmdManifest)" />
</ItemGroup>
</Target>
</Project>

View File

@@ -0,0 +1,87 @@
[CmdletBinding()]
Param(
[Parameter(Mandatory=$true, ValueFromPipeline=$true,
HelpMessage="Path to the .appx/.msix to validate")]
[string]
$Path,
[Parameter(HelpMessage="Path to Windows Kit")]
[ValidateScript({Test-Path $_ -Type Leaf})]
[string]
$WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0"
)
$ErrorActionPreference = "Stop"
If ($null -Eq (Get-Item $WindowsKitPath -EA:SilentlyContinue)) {
Write-Error "Could not find a windows SDK at at `"$WindowsKitPath`".`nMake sure that WindowsKitPath points to a valid SDK."
Exit 1
}
$makeAppx = "$WindowsKitPath\x86\MakeAppx.exe"
$makePri = "$WindowsKitPath\x86\MakePri.exe"
Function Expand-ApplicationPackage {
Param(
[Parameter(Mandatory, ValueFromPipeline)]
[string]
$Path
)
$sentinelFile = New-TemporaryFile
$directory = New-Item -Type Directory "$($sentinelFile.FullName)_Package"
Remove-Item $sentinelFile -Force -EA:Ignore
& $makeAppx unpack /p $Path /d $directory /nv /o
If ($LastExitCode -Ne 0) {
Throw "Failed to expand AppX"
}
$directory
}
Write-Verbose "Expanding $Path"
$AppxPackageRoot = Expand-ApplicationPackage $Path
$AppxPackageRootPath = $AppxPackageRoot.FullName
Write-Verbose "Expanded to $AppxPackageRootPath"
Try {
& $makePri dump /if "$AppxPackageRootPath\resources.pri" /of "$AppxPackageRootPath\resources.pri.xml" /o
If ($LastExitCode -Ne 0) {
Throw "Failed to dump PRI"
}
$Manifest = [xml](Get-Content "$AppxPackageRootPath\AppxManifest.xml")
$PRIFile = [xml](Get-Content "$AppxPackageRootPath\resources.pri.xml")
### Check the activatable class entries for a few DLLs we need.
$inProcServers = $Manifest.Package.Extensions.Extension.InProcessServer.Path
$RequiredInProcServers = ("TerminalApp.dll", "TerminalControl.dll", "TerminalConnection.dll")
Write-Verbose "InProc Servers: $inProcServers"
ForEach ($req in $RequiredInProcServers) {
If ($req -NotIn $inProcServers) {
Throw "Failed to find $req in InProcServer list $inProcServers"
}
}
### Check that we have an App.xbf (which is a proxy for our resources having been merged)
$resourceXpath = '/PriInfo/ResourceMap/ResourceMapSubtree[@name="Files"]/NamedResource[@name="App.xbf"]'
$AppXbf = $PRIFile.SelectSingleNode($resourceXpath)
If ($null -eq $AppXbf) {
Throw "Failed to find App.xbf (TerminalApp project) in resources.pri"
}
If ($Manifest.Package.Identity.ProcessorArchitecture -Ne "arm64") {
### ARM64 doesn't package cpprest_2_10.
If (($null -eq (Get-Item "$AppxPackageRootPath\cpprest_2_10.dll" -EA:Ignore)) -And
($null -eq (Get-Item "$AppxPackageRootPath\cpprest_2_10d.dll" -EA:Ignore))) {
Throw "Failed to find cpprest_2_10.dll -- check the WAP packaging project"
}
}
} Finally {
Remove-Item -Recurse -Force $AppxPackageRootPath
}

View File

@@ -14,6 +14,7 @@
"/.vs/",
"/build/",
"/src/cascadia/",
"/src/winconpty/",
"/.nuget/",
"/.github/",
"/samples/"

Submodule dep/gsl updated: b74b286d5e...1212beae77

View File

@@ -1,7 +0,0 @@
These packages are redistributed inside this folder because they are not yet available on a public NuGet feed.
## Microsoft.UI.XAML
This package is a custom development build fork to help us light up tab support. It will eventually go onto the same public feed as the existing `Microsoft.UI.XAML` package that's currently available on NuGet.org
## TAEF.Redist.WLK
This package is vetted for public redistribution and release, but the TAEF team hasn't set up a public feed to consume it yet. If/when they do, we'll move to that.

Submodule dep/wil updated: fbcd1d2abb...e8c599bca6

View File

@@ -8,9 +8,9 @@ Settings in the Windows Console Host can be a bit tricky to understand. This is
|---------------------------|-----------------------|--------------------------------------|
|`FontSize` |Coordinate (REG_DWORD) |Size of font in pixels |
|`FontFamily` |REG_DWORD |GDI Font family |
|`ScreenBufferSize` |Coordinate (REG_DWORD) |Size of the screen buffer in WxH characters |
|`ScreenBufferSize` |Coordinate (REG_DWORD) |Size of the screen buffer in WxH characters\*\* |
|`CursorSize` |REG_DWORD |Cursor height as percentage of a single character |
|`WindowSize` |Coordinate (REG_DWORD) |Initial size of the window in WxH characters |
|`WindowSize` |Coordinate (REG_DWORD) |Initial size of the window in WxH characters\*\* |
|`WindowPosition` |Coordinate (REG_DWORD) |Initial position of the window in WxH pixels (if not set, use auto-positioning) |
|`WindowAlpha` |REG_DWORD |Opacity of the window (valid range: 0x4D-0xFF) |
|`ScreenColors` |REG_DWORD |Default foreground and background colors |
@@ -39,6 +39,10 @@ Settings in the Windows Console Host can be a bit tricky to understand. This is
*: Only applies to the improved version of the Windows Console Host
**: WxH stands for Width by Height, it's the fact that things like a Window size
store the Width and Height values in the high and low word in the registry's
double word values.
## The Settings Hierarchy
Settings are persisted to a variety of locations depending on how they are modified and how the Windows Console Host was invoked:

181
doc/Niksa.md Normal file
View File

@@ -0,0 +1,181 @@
# Niksa's explanations
Sometimes @miniksa will write a big, long explanatory comment in an issue thread that turns out to be a decent bit of reference material.
This document serves as a storage point for those posts.
- [Why do we avoid changing CMD.exe?](#cmd)
- [Why is typing-to-screen performance better than every other app?](#screenPerf)
- [How are the Windows graphics/messaging stack assembled?](#gfxMsgStack)
- [Output Processing between "Far East" and "Western"](#fesb)
- [Why do we not backport things?](#backport)
- [Why can't we have mixed elevated and non-elevated tabs in the Terminal?](#elevation)
## <a name="cmd"></a>Why do we avoid changing CMD.exe?
`setlocal` doesn't behave the same way as an environment variable. It's a thing that would have to be put in at the top of the batch script that is `somefile.cmd` as one of its first commands to adjust the way that one specific batch file is processed by the `cmd.exe` engine. That's probably not suitable for your needs, but that's the way we have to go.
I don't think anyone is disagreeing with you, @mikemaccana, that this would be a five minute development change to read that environment variable and change the behavior of `cmd.exe`. It absolutely would be a tiny development time.
It's just that from our experience, we know there's going to be a 3-24 month bug tail here where we get massive investigation callbacks by some billion dollar enterprise customer who for whatever reason was already using the environment variable we pick for another purpose. Their script that they give their rank-and-file folks will tell them to press Ctrl+C at some point in the batch script to do whatever happens, it will do something different, those people will notice the script doesn't match the computer anymore. They will then halt the production line and tell their supervisor. The supervisor tells some director. Their director comes screaming at their Microsoft enterprise support contract person that we've introduced a change to the OS that is costing them millions if not billions of dollars in shipments per month. Our directors at Microsoft then come bashing down our doors angry with us and make us fix it ASAP or revert it, we don't get to go home at 5pm to our families or friends because we're fixing it, we get stressed the heck out, we have to spin up servicing potentially for already shipped operating systems which is expensive and headache-causing...etc.
We can see this story coming a million miles away because it has happened before with other 'tiny' change we've been asked to make to `cmd.exe` in the past few years.
I would just ask you to understand that `cmd.exe` is very, very much in a maintenance mode and I just want to set expectations here. We maintain it, yes. We have a renewed interest in command-line development, yes. But our focuses are revolving around improving the terminal and platform itself and bringing modern, supported shells to be the best they can be on Windows. Paul will put this on the backlog of things that people want in `cmd.exe`, yes. But it will sink to the bottom of the backlog because changing `cmd.exe` is our worst nightmare as its compatibility story is among the heaviest of any piece of the operating system.
I would highly recommend that Gulp convert to using PowerShell scripts and that if such an issue exists with PowerShell, that we get their modern, supported, and better-engineered platform to support the scenario. I don't want you to sit around waiting for `cmd.exe` to change this because it's really not going to happen faster than that script could be converted to `ps1` and it fixed in PowerShell Core (if that's even a problem in that world.)
Original Source: https://github.com/microsoft/terminal/issues/217#issuecomment-404240443
## <a name="screenPerf"></a>Why is typing-to-screen performance better than every other app?
I really do not mind when someone comes by and decides to tell us that we're doing a good job at something. We hear so many complaints every day that a post like this is a breath of fresh air. Thanks for your thanks!
Also, I'm happy to discuss this with you until you're utterly sick of reading it. Please ask any follow-ons you want. I thrive on blathering about my work. :P
If I had to take an educated guess as to what is making us faster than pretty much any other application on Windows at putting your text on the screen... I would say it is because that is literally our only job! Also probably because we are using darn near the oldest and lowest level APIs that Windows has to accomplish this work.
Pretty much everything else you've listed has some sort of layer or framework involved, or many, many layers and frameworks, when you start talking about Electron and Javascript. We don't.
We have one bare, super un-special window with no additional controls attached to it. We get our keys fed into us from just barely above the kernel given that we're processing them from window messages and not from some sort of eventing framework common to pretty much any other more complicated UI framework than ours (WPF, WinForms, UWP, Electron). And we dump our text straight onto the window surface using GDI's [PolyTextOut](https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-polytextoutw) with no frills.
Even `notepad.exe` has multiple controls on its window at the very least and is probably (I haven't looked) using some sort of library framework in the edit control to figure out its text layout (which probably is using another library framework for internationalization support...)
Of course this also means that we have trade offs. We don't support fully international text like pretty much every other application will. RTL? No go zone right now. Surrogate pairs and emoji? We're getting there but not there yet. Indic scripts? Nope.
Why are we like this? For one, `conhost.exe` is old as dirt. It has to use the bare metal bottom layer of everything because it was created before most of those other frameworks were created. And also it maintains as low/bottom level as possible because it is pretty much the first thing that one needs to bring up when bringing up a new operating system edition or device before you have all the nice things like frameworks or what those frameworks require to operate. Also it's written in C/C++ which is about as low and bare metal as we can get.
Will this UI enhancement come to other apps on Windows? Almost certainly not. They have too much going on which is both a good and a bad thing. I'm jealous of their ability to just call one method and layout text in an uncomplicated manner in any language without manually calculating pixels or caring about what styles apply to their font. But my manual pixel calculations, dirty region math, scroll region madness, and more makes it so we go faster than them. I'm also jealous that when someone says "hey can you add a status bar to the bottom of your window" that they can pretty much click and drag that into place with their UI Framework and it will just work where as for us, it's been a backlog item forever and gives me heartburn to think about implementing.
Will we try to keep it from regressing? Yes! Right now it's sort of a manual process. We identify that something is getting slow and then we go haul out [WPR](https://docs.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-recorder) and start taking traces. We stare down the hot paths and try to reason out what is going on and then improve them. For instance, in the last cycle or two, we focused on heap allocations as a major area where we could improve our end-to-end performance, changing a ton of our code to use stack-constructed iterator-like facades over the underlying request buffer instead of translating and allocating it into a new heap space for each level of processing.
As an aside, @bitcrazed wants us to automate performance tests in some conhost specific way, but I haven't quite figured out a controlled environment to do this in yet. The Windows Engineering System runs performance tests each night that give us a coarse grained way of knowing if we messed something up for the whole operating system, and they technically offer a fine grained way for us to insert our own performance tests... but I just haven't got around to that yet. If you have an idea for a way for us to do this in an automated fashion, I'm all ears.
If there's anything else you'd like to know, let me know. I could go on all day. I deleted like 15 tangents from this reply before posting it....
Original Source: https://github.com/microsoft/terminal/issues/327#issuecomment-447391705
## <a name="gfxMsgStack"></a>How are the Windows graphics/messaging stack assembled?
@stakx, I am referring to USER32 and GDI32.
I'll give you a cursory overview of what I know off the top of my head without spending hours confirming the details. As such, some of this is subject to handwaving and could be mildly incorrect but is probably in the right direction. Consider every statement to be my personal knowledge on how the world works and subject to opinion or error.
For the graphics part of the pipeline (GDI32), the user-mode portions of GDI are pretty far down. The app calls GDI32, some work is done in that DLL on the user-mode side, then a kernel call jumps over to the kernel and drawing occurs.
The portion that you're thinking of regarding "silently converted to sit on top of other stuff" is probably that once we hit the kernel calls, a bunch of the kernel GDI stuff tends to be re-platformed on top of the same stuff as DirectX when it is actually handled by the NVIDIA/AMD/Intel/etc. graphics driver and the GPU at the bottom of the stack. I think this happened with the graphics driver re-architecture that came as a part of WDDM for Windows Vista. There's a document out there somewhere about what calls are still really fast in GDI and which are slower as a result of the re-platforming. Last time I found that document and checked, we were using the fast ones.
On top of GDI, I believe there are things like Common Controls or comctl32.dll which provided folks reusable sets of buttons and elements to make their UIs before we had nicer declarative frameworks. We don't use those in the console really (except in the property sheet off the right click menu).
As for DirectWrite and D2D and D3D and DXGI themselves, they're a separate set of commands and paths that are completely off to the side from GDI at all both in user and kernel mode. They're not really related other than that there's some interoperability provisions between the two. Most of our other UI frameworks tend to be built on top of the DirectX stack though. XAML is for sure. I think WPF is. Not sure about WinForms. And I believe the composition stack and the window manager are using DirectX as well.
As for the input/interaction part of the pipeline (USER32), I tend to find most other newer things (at least for desktop PCs) are built on top of what is already there. USER32's major concept is windows and window handles and everything is sent to a window handle. As long as you're on a desktop machine (or a laptop or whatever... I mean a classic-style Windows-powered machine), there's a window handle involved and messages floating around and that means we're talking USER32.
The window message queue is just a straight up FIFO (more or less) of whatever input has occurred relevant to that window while it's in the foreground + whatever has been sent to the window by other components in the system.
The newer technologies and the frameworks like XAML and WPF and WinForms tend to receive the messages from the window message queue one way or another and process them and turn them into event callbacks to various objects that they've provisioned within their world.
However, the newer technologies that also work on other non-desktop platforms like XAML tend to have the ability to process stuff off of a completely different non-USER32 stack as well. There's a separate parallel stack to USER32 with all of our new innovations and realizations on how input and interaction should occur that doesn't exactly deal with classic messaging queues and window handles the same way. This is the whole Core* family of things like CoreWindow and CoreMessaging. They also have a different concept of "what is a user" that isn't so centric around your butt in rolling chair in front of a screen with a keyboard and mouse on the desk.
Now, if you're on XAML or one of the other Frameworks... all this intricacy is handled for you. XAML figures out how to draw on DirectX for you and negotiates with the compositor and window manager for cool effects on your behalf. It figures out whether to get your input events from USER32 or Core* or whatever transparently depending on your platform and the input stacks can handle pen, touch, keyboard, mouse, and so on in a unified manner. It has provisions inside it embedded to do all the sorts of globalization, accessibility, input interaction, etc. stuff that make your life easy. But you could choose to go directly to the low-level and handle it yourself or skip handling what you don't care about.
The trick is that GDI32 and USER32 were designed for a limited world with a limited set of commands. Desktop PCs were the only thing that existed, single user at the keyboard and mouse, simple graphics output to a VGA monitor. So using them directly at the "low level" like conhost does is pretty easy. The new platforms could be used at the "low level" but they're orders of magnitude more complicated because they now account for everything that has happened with personal computing in 20+ years like different form factors, multiple active users, multiple graphics adapters, and on and on and on and on. So you tend to use a framework when using the new stuff so your head doesn't explode. They handle it for you, but they handle more than they ever did before so they're slower to some degree.
So are GDI32 and USER32 "lower" than the new stuff? Sort of.
Can you get that low with the newer stuff? Mostly yes, but you probably shouldn't and don't want to.
Does new live on top of old or is old replatformed on the new? Sometimes and/or partially.
Basically... it's like the answer to anything software... "it's an unmitigated disaster and if we all stepped back a moment, we should be astounded that it works at all." :P
Anyway, that's enough ramble for one morning. Hopefully that somewhat answered your questions and gave you a bit more insight.
Original Source: https://github.com/microsoft/terminal/issues/327#issuecomment-447926388
## <a name="fesb"></a>Output Processing between "Far East" and "Western"
>
> ```
> if (WI_IsFlagSet(CharType, C1_CNTRL))
> ```
In short, this is probably fine to fix.
However, I would personally feed a few characters through `WriteCharsLegacy` under the debugger and assert that your theory is correct first (that multiple flags coming back are what the problem is) before making the change.
I am mildly terrified, less than Dustin, because it is freaking `WriteCharsLegacy` which is the spawn of hell and I fear some sort of regression in it.
In long, why is it fine to fix?
For reference, this particular segment of code https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L514-L539 appears to only be used when the codepoint is < 0x20 or == 0x7F https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L408 and ENABLE_PROCESSED_OUTPUT is off. https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/host/_stream.cpp#L320
I looked back at the console v1 code and this particular section had a divergence for "Western" countries and "Far East" countries (a geopolitically-charged term, but what it was, nonetheless.)
For "Western" countries, we would unconditionally run all the characters through `MultiByteToWideChar` with `MB_USEGLYPHCHARS` without the `C1_CNTRL` test and move the result into the buffer.
For "Eastern" countries, we did the `C1_CNTRL` test and then if true, we would run through `MultiByteToWideChar` with `MB_USEGLYPHCHARS`. Otherwise, we would just move the original character into the buffer and call it a day.
Note in both of these, there is a little bit of indirection before `MultiByteToWideChar` is called through some other helper methods like `ConvertOutputToUnicode`, but that's the effective conversion point, as far as I can tell. And that's where the control characters would turn into acceptable low ASCII symbols.
When we took over the console codebase, this variation between "Western" and "Eastern" countries was especially painful because `conhost.exe` would choose which one it was in based on the `Codepage for Non-Unicode Applications` set in the Control Panel's Regional > Administrative panel and it could only be changed with a reboot. It wouldn't even change properly when you `chcp` to a different codepage. Heck, `chcp` would deny you from switching into many codepages. There was a block in place to prevent going to an "Eastern" codepage if you booted up in a "Western" codepage. There was also a block preventing you from going between "Eastern" codepages, if I recall correctly.
In modernizing, I decided a few things:
1. What's good for the "Far East" should be good for the rest of the world. CJK languages that encompassed the "Far East" code have to be able to handle "Western" text as well even if the reverse wasn't true.
2. We need to scrub all usages of "Far East" from the code. Someone already started that and replaced them with "East Asia" except then they left behind the shorthand of "FE" prefixing dozens of functions which made it hard to follow the code. It took us months to realize "FE" and "East Asia" were the same thing.
3. It's obnoxious that the way this was handled was to literally double-define every output function in the code base to have two definitions, compile them both into the conhost, then choose to run down the SB_ versions or the FE_ versions depending on the startup Non-Unicode codepage. It was a massive pile of complex pre-compilation `#ifdef` and `#else`s that would sometimes surround individual lines in the function bodies. Gross.
4. The fact that the FE_ versions of the functions were way slower than the SB_ ones was unacceptable even for the same output of Latin-character text.
5. Anyone should be free to switch between any codepage they want at any time and restricting it based on a value from OS startup or region/locale is not acceptable in the modern world.
6. I concluded by all of the above that I was going to tank/delete/remove the SB_ versions of everything and force the entire world to use the FE_ versions as truth. I would fix the FE_ versions to handle everything correctly, I would fix the performance characteristics of the FE_ versions so they were only slower when things were legitimately more complicated and never otherwise, I would banish all usage of "Far East", "East Asia", "FE_", and "SB_" from the codebase, and codepages would be freely switchable.
7. Oh. Also, the conhost used to rewrite its entire backing buffer into whatever your current codepage was whenever you switched codepages. I changed that to always hold it as UTF-16.
Now, after that backstory. This is where the problem comes in. It looks like the code you're pointing to that didn't check flags and instead checked direct equality... is the way that it was ALWAYS done for the "Eastern" copy of the code. So it was ALWAYS broken for the "Eastern" codepages and country variants of the OS.
I don't know why the "Eastern" copy was checking `C1_CNTRL` at all in the first place. There is no documentation. I presume it has to do with Shift-JIS or GB-2312 or Unified Hangul or something having a conflict < 0x20 || == 0x7F. Or alternatively, it's because someone wrote the code naively thinking it was a good idea in a hurry and never tested it. Very possible and even probable.
Presuming CJK codepages have no conflict in this range for their DBCS codepages... we could probably remove the check with `GetStringTypeW` entirely and always run everything through `ConvertOutputToUnicode`. More risky than just the flag test change... but theoretically an option as well.
Original Source: https://github.com/microsoft/terminal/issues/166#issuecomment-510953359
## <a name="backport"></a>Why do we not backport things?
Someone has to prove that this is costing millions to billions of dollars of lost productivity or revenue to outweigh the risks of shipping the fix to hundreds of millions of Windows machines and potentially breaking something.
Our team generally finds it pretty hard to prove that against the developer audience given that they're only a small portion of the total installed market of Windows machines.
Our only backport successes really come from corporations with massive addressable market (like OEMs shipping PCs) who complain that this is fouling up their manufacturing line (or something of that ilk). Otherwise, our management typically says that the risks don't outweigh the benefits.
It's also costly in terms of time, effort, and testing for us to validate a modification to a released OS. We have a mindbogglingly massive amount of automated machinery dedicated to processing and validating the things that we check in while developing the current OS builds. But it's a special costly ask to spin up some to all of those activities to validate backported fixes. We do it all the time for Patch Tuesday, but in those patches, they only pass through the minimum number of fixes required to maximize the restoration of productivity/security/revenue/etc. because every additional fix adds additional complexity and additional risk.
So from our little team working hard to make developers happy, we virtually never make the cut for servicing. We're sorry, but we hope you can understand. It's just the reality of the situation to say "nope" when people ask for a backport. In our team's ideal world, you would all be running the latest console bits everywhere everytime we make a change. But that's just not how it is today.
Original Source: https://github.com/microsoft/terminal/issues/279#issuecomment-439179675
## <a name="elevation"></a>Why can't we have mixed elevated and non-elevated tabs in the Terminal?
_guest speaker @DHowett-MSFT_
[1] It is trivial when you are _hosting traditional windows_ with traditional window handles. That works very well in the conemu case, or in the tabbed shell case, where you can take over a window in an elevated session and re-parent it under a window in a non-elevated session.
When you do that, there's a few security features that I'll touch on in [2]. Because of those, you can parent it but you can't really force it to do anything.
There's a problem, though. The Terminal isn't architected as a collection of re-parentable windows. For example, it's not running a console host and moving its window into a tab. It was designed to support a "connection" -- something that can read and write text. It's a lower-level primitive than a window. We realized the error of our ways and decided that the UNIX model was right the entire time, and pipes and text and streams are _where it's at._
Given that we're using Xaml islands to host a modern UI and stitching a DirectX surface into it, we're far beyond the world of standard window handles anyway. Xaml islands are fully composed into a single HWND, much like Chrome and Firefox and the gamut of DirectX/OpenGL/SDL games. We don't **have** components that can be run in one process (elevated) and hosted in another (non-elevated) that aren't the aforementioned "connections".
Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.
[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.
That "security" feature (call it what you like, it was probably intended to be a security feature at one point) only exists for a few session-global object types. Windows are one of them. Pipes aren't really one of them.
Because of that, it's trivial to break that security. Take the terminal as an example of that. If we start an elevated connection and host it in a _non-elevated_ window, we've suddenly created a conduit through that security boundary. The elevated thing on the other end isn't a window, it's just a text-mode application. It immediately does the bidding of the non-elevated host.
Anybody that can _control_ the non-elevated host (like `WScript.Shell::SendKeys`) _also_ gets an instant conduit through the elevation boundary. Suddenly, any medium integrity application on your system can control a high-integrity process. This could be your browser, or the bitcoin miner that got installed with the `left-pad` package from NPM, or really any number of things.
It's a small risk, but it _is_ a risk.
---
Other platforms have accepted that risk in preference for user convenience. They aren't wrong to do so, but I think Microsoft gets less of a "pass" on things like "accepting risk for user convenience". Windows 9x was an unmitigated security disaster, and limited user accounts and elevation prompts and kernel-level security for window management were the answer to those things. They're not locks to be loosened lightly.
Original Source: https://github.com/microsoft/terminal/issues/632#issuecomment-519375707

View File

@@ -8,12 +8,12 @@ We'll be using tags, primarily, to help us understand what needs attention, what
### Quick-Guidance to Core Contributors
1. Look at `Needs-Attention` as top priority
1. Look at `Needs-Triage` during triage meetings to get a handle on what's new and sort it out
1. Look at `Needs-Tag-Fix` when you have a few minutes to fix up things tagged impoperly
1. Look at `Needs-Tag-Fix` when you have a few minutes to fix up things tagged improperly
1. Manually add `Needs-Author-Feedback` when there's something we need the author to follow up on and want attention if they return it or an auto-close for inactivity if it goes stale.
### Tagging/Process Details
1. When new issues arrive, or when issues are not properly tagged... we'll mark them as `Needs-Triage` automatically.
- The core contributor team will then come through and mark them up as appropriate. The goal is to have a tag that fits the `Product`, `Area`, and `Issue` category.
- The core contributor team will then come through and mark them up as appropriate. The goal is to have a tag that fits the `Product`, `Area`, and `Issue` category.
- The `Needs-Triage` tag will be removed manually by the core contributor team during a triage meeting. (Exception, triage may also be done offline by senior team members during high-volume times.)
- An issue may or may not be assigned to a contributor during triage. It is not necessary to assign someone to complete it.
- We're not focusing on Projects yet.
@@ -22,7 +22,7 @@ We'll be using tags, primarily, to help us understand what needs attention, what
- When this tag drops off, the bot will apply the `Needs-Attention` tag to get the core contribution team's attention again. If an author cares enough to be active, we will attempt to prioritize engaging with that author.
- If the author doesn't come back around in a while, this will become a `No-Recent-Activity` tag.
- If there's activity on an issue, the `No-Recent-Activity` tag will automatically drop.
- If the `No-Recent-Activity` stays, the issue will be closed as stale.
- If the `No-Recent-Activity` stays, the issue will be closed as stale.
1. PRs will automatically get a `Needs-Author-Feedback` tag when reviewers wait on the author
- This follows a similar decay strategy to issues.
- If the author responds, the `Needs-Author-Feedback` tag will drop.
@@ -33,11 +33,22 @@ We'll be using tags, primarily, to help us understand what needs attention, what
## Rules
### Triage Shorthand
- All rules in this category apply to triaging issues. They're shorthand comments that the triage team can use in order to complete the triage process faster.
- Only individuals with `Write` or `Admin` privileges on the repository can use these responses.
#### Duplicate Issues
- When a comment on the thread says `/dup #<issue ID>`...
1. Reply with a comment explaining that the issue is a duplicate and recommend that the opener and interested parties follow the issue on the listed ID number.
1. Close the issue
1. Remove all `Needs-*` tags
1. Add `Resolution-Duplicate`
### Issue Management
#### Mark as Triage Needed
- When an issue doesn't meet triage criteria, applies `Needs-Triage` tag. Right now, this is just when it's opened.
#### Author Has Responded
- When an issue with `Needs-Author-Feedback` gets an author response, drops that tag in favor of `Needs-Attention` to flag core contributors to drop by.
@@ -56,6 +67,21 @@ We'll be using tags, primarily, to help us understand what needs attention, what
#### Enforce tag system
- When an issue is opened or labels are changed in any way, we will check if the tagging matches the system. If not, it will get `Needs-Tag-Fix`. The system is to have an `Area-`, `Issue-`, and `Product-` tag for all open things, and also a `Resolution-` for closed ones.
- When the tags from appropriate categories are applied, it will auto-remove the `Needs-Tag-Fix` tag.
- `Resolution-Duplicate` is sufficient to fix all tagging. (`Area-`, `Issue-`, and `Product-` are not needed for a duplicate.)
#### Clean-up low quality issues
- If an issue is filed with an incomplete title...
- If an issue is filed with nothing in the body...
- If an issue is filed matching a pattern that happens all the time (common duplicate phrase, obvious multiple-issues-in-one pattern)...
- Then close the issue automatically informing the opener that they can resolve the problem and reopen the issue. (See Bug/Feature templates for example situations.)
#### Help ask for Feedback Hub
- When a comment on the thread says `/feedback`...
1. Then reply to the issue with a bit of text on asking the author to send us data with Feedback Hub and give us the link.
1. And add the `Needs-Author-Feedback` tag
#### Remove Help Wanted from In PR issues
- If an issue gets the `In-PR` tag when a new PR is created, we will remove the `Help-Wanted` tag to avoid someone trying to work on an issue where another person has already submitted a proposed fix.
### PR Management
@@ -80,10 +106,25 @@ We'll be using tags, primarily, to help us understand what needs attention, what
#### Auto-Merge pull requests
- When a pull request has the `AutoMerge` label...
- If it has been at least 480 minutes and all the statuses pass, merge it in.
- Will use Squash merge stratgy
- Will use Squash merge strategy
- Will attempt to delete branch after merge, if possible
- Will automatically remove the `AutoMerge` label if changes are pushed by someone *without* Write Access.
- More information on bot-logic that can be controlled with comments is [here](https://github.com/OfficeDev/office-ui-fabric-react/wiki/Advanced-auto-merge)
#### Mark issues with an active PR
- If there is an active PR for an issue, label that issue with the `In-PR` label
#### Add committed fix tag for completed PRs
- When a PR is finished and there's no outstanding work left on a linked issue, add the `Resolution-Fix-Committed` label
#### Remove Needs-Second from completed PRs
- If a PR is closed and it has the `Needs-Second` tag, the bot will remove the tag.
### Release Management
When a release is created, if the PR ID number is linked inside the release description, the bot will walk through the related PR and all of its related issues and leave a message.
- PR message: "🎉{release name} {release version} has been released which incorporates this pull request.🎉
- Issue message: 🎉This issue was addressed in #{pull request ID}, which has now been successfully released as {release name} {release version}.🎉"
## Admin Panel
[Here](https://fabric-cp.azurewebsites.net/bot/)

View File

@@ -1,7 +1,7 @@
# How to build Openconsole
Openconsole can be built with Visual Studio or from the command line. There are build scripts for both cmd and powershell in /tools.
Openconsole can be built with Visual Studio or from the command line. There are build scripts for both cmd and PowerShell in /tools.
When using Visual Studio, be sure to set up the path for code formatting. This can be done in Visual Studio by going to Tools > Options > Text Editor > C++ > Formatting and checking "Use custom clang-format.exe file" and choosing the clang-format.exe in the repository at /dep/llvm/clang-format.exe by clicking "browse" right under the check box.
@@ -33,4 +33,4 @@ Openconsole has three configuration types:
- Release
- AuditMode
AuditMode is an experimental mode that enables some additional static analyis from CppCoreCheck.
AuditMode is an experimental mode that enables some additional static analysis from CppCoreCheck.

View File

@@ -6,7 +6,7 @@
## Abstract
It should be possible to configure the terminal so that it doesn't send certain keystrokes as input to the terminal, and instead triggers certain actions. Examples of these actions could be copy/pasting text, opening a new tab, or changing the font size.
This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idomatic way, and UWP could implement them in their own way.
This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idiomatic way, and UWP could implement them in their own way.
## Terminology
* **Key Chord**: This is any possible keystroke that a user can input

View File

@@ -3,45 +3,53 @@
## Globals
Properties listed below affect the entire window, regardless of the profile settings.
| Property | Necessity | Type | Description |
| -------- | ---- | ----------- | ----------- |
| `alwaysShowTabs` | _Required_ | Boolean | When set to `true`, tabs are always displayed. When set to `false` and `showTabsInTitlebar` is set to `false`, tabs only appear after typing <kbd>Ctrl</kbd> + <kbd>T</kbd>. |
| `defaultProfile` | _Required_ | String | Sets the default profile. Opens by typing <kbd>Ctrl</kbd> + <kbd>T</kbd> or by clicking the '+' icon. The guid of the desired default profile is used as the value. |
| `initialCols` | _Required_ | Integer | The number of columns displayed in the window upon first load. |
| `initialRows` | _Required_ | Integer | The number of rows displayed in the window upon first load. |
| `requestedTheme` | _Required_ | String | Sets the theme of the application. Possible values: `"light"`, `"dark"`, `"system"` |
| `showTerminalTitleInTitlebar` | _Required_ | Boolean | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
| `showTabsInTitlebar` | Optional | Boolean | 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. |
| Property | Necessity | Type | Default | Description |
| -------- | --------- | ---- | ------- | ----------- |
| `alwaysShowTabs` | _Required_ | Boolean | `true` | When set to `true`, tabs are always displayed. When set to `false` and `showTabsInTitlebar` is set to `false`, tabs only appear after typing <kbd>Ctrl</kbd> + <kbd>T</kbd>. |
| `copyOnSelect` | Optional | Boolean | `false` | When set to `true`, a selection is immediately copied to your clipboard upon creation. When set to `false`, the selection persists and awaits further action. |
| `defaultProfile` | _Required_ | String | PowerShell guid | Sets the default profile. Opens by typing <kbd>Ctrl</kbd> + <kbd>T</kbd> or by clicking the '+' icon. The guid of the desired default profile is used as the value. |
| `initialCols` | _Required_ | Integer | `120` | The number of columns displayed in the window upon first load. |
| `initialRows` | _Required_ | Integer | `30` | The number of rows displayed in the window upon first load. |
| `requestedTheme` | _Required_ | String | `system` | Sets the theme of the application. Possible values: `"light"`, `"dark"`, `"system"` |
| `showTerminalTitleInTitlebar` | _Required_ | Boolean | `true` | When set to `true`, titlebar displays the title of the selected tab. When set to `false`, titlebar displays "Windows Terminal". |
| `showTabsInTitlebar` | Optional | Boolean | `true` | When set to `true`, the tabs are moved into the titlebar and the titlebar disappears. When set to `false`, the titlebar sits above the tabs. |
| `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. |
## Profiles
Properties listed below are specific to each unique profile.
| Property | Necessity | Type | Description |
| -------- | ---- | ----------- | ----------- |
| `acrylicOpacity` | _Required_ | Number | When `useAcrylic` is set to `true`, it sets the transparency of the window for the profile. Accepts floating point values from 0-1. |
| `background` | _Required_ | String | Sets the background color of the profile. Overrides `background` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `closeOnExit` | _Required_ | Boolean | When set to `true`, the selected tab closes when `exit` is typed. When set to `false`, the tab will remain open when `exit` is typed. |
| `colorScheme` | _Required_ | String | Name of the terminal color scheme to use. Color schemes are defined under `schemes`. |
| `commandline` | _Required_ | String | Executable used in the profile. |
| `cursorColor` | _Required_ | String | Sets the cursor color for the profile. Uses hex color format: `"#rrggbb"`. |
| `cursorShape` | _Required_ | String | Sets the cursor shape for the profile. Possible values: `"vintage"` ( &#x2583; ), `"bar"` ( &#x2503; ), `"underscore"` ( &#x2581; ), `"filledBox"` ( &#x2588; ), `"emptyBox"` ( &#x25AF; ) |
| `fontFace` | _Required_ | String | Name of the font face used in the profile. |
| `fontSize` | _Required_ | Integer | Sets the font size. |
| `guid` | _Required_ | String | Unique identifier of the profile. Written in registry format: `"{00000000-0000-0000-0000-000000000000}"`. |
| `historySize` | _Required_ | Integer | The number of lines above the ones displayed in the window you can scroll back to. |
| `name` | _Required_ | String | Name of the profile. Displays in the dropdown menu. |
| `padding` | _Required_ | String | Sets the padding around the text within the window. Can have three different formats: `"#"` sets the same padding for all sides, `"#, #"` sets the same padding for left-right and top-bottom, and `"#, #, #, #"` sets the padding individually for left, top, right, and bottom. |
| `snapOnInput` | _Required_ | Boolean | 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. |
| `startingDirectory` | _Required_ | String | The directory the shell starts in when it is loaded. |
| `useAcrylic` | _Required_ | Boolean | When set to `true`, the window will have an acrylic background. When set to `false`, the window will have a plain, untextured background. |
| `colorTable` | Optional | Array[String] | Array of colors used in the profile if `colorscheme` is not set. Colors use hex color format: `"#rrggbb"`. Ordering is as follows: `[black, red, green, yellow, blue, magenta, cyan, white, bright black, bright red, bright green, bright yellow, bright blue, bright magenta, bright cyan, bright white]` |
| `cursorHeight` | Optional | Integer | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
| `foreground` | Optional | String | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `icon` | Optional | String | Image file location of the icon used in the profile. Displays within the tab and the dropdown menu. |
| `scrollbarState` | Optional | String | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
| Property | Necessity | Type | Default | Description |
| -------- | --------- | ---- | ------- | ----------- |
| `acrylicOpacity` | _Required_ | Number | `0.5` | When `useAcrylic` is set to `true`, it sets the transparency of the window for the profile. Accepts floating point values from 0-1. |
| `closeOnExit` | _Required_ | Boolean | `true` | When set to `true`, the selected tab closes when `exit` is typed. When set to `false`, the tab will remain open when `exit` is typed. |
| `colorScheme` | _Required_ | String | `Campbell` | Name of the terminal color scheme to use. Color schemes are defined under `schemes`. |
| `commandline` | _Required_ | String | `powershell.exe` | Executable used in the profile. |
| `cursorColor` | _Required_ | String | `#FFFFFF` | Sets the cursor color for the profile. Uses hex color format: `"#rrggbb"`. |
| `cursorShape` | _Required_ | String | `bar` | Sets the cursor shape for the profile. Possible values: `"vintage"` ( &#x2583; ), `"bar"` ( &#x2503; ), `"underscore"` ( &#x2581; ), `"filledBox"` ( &#x2588; ), `"emptyBox"` ( &#x25AF; ) |
| `fontFace` | _Required_ | String | `Consolas` | Name of the font face used in the profile. We will try to fallback to Consolas if this can't be found or is invalid. |
| `fontSize` | _Required_ | Integer | `12` | Sets the font size. |
| `guid` | _Required_ | String | | Unique identifier of the profile. Written in registry format: `"{00000000-0000-0000-0000-000000000000}"`. |
| `hidden` | Optional | Boolean | `false` | If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamicially generated profiles, while leaving them in your settings file. |
| `historySize` | _Required_ | Integer | `9001` | The number of lines above the ones displayed in the window you can scroll back to. |
| `name` | _Required_ | String | `PowerShell Core` | Name of the profile. Displays in the dropdown menu. <br>Additionally, this value will be used as the "title" to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application. This "title" behavior can be overriden by using `tabTitle`. |
| `padding` | _Required_ | String | `8, 8, 8, 8` | Sets the padding around the text within the window. Can have three different formats: `"#"` sets the same padding for all sides, `"#, #"` sets the same padding for left-right and top-bottom, and `"#, #, #, #"` sets the padding individually for left, top, right, and bottom. |
| `snapOnInput` | _Required_ | 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. |
| `startingDirectory` | _Required_ | String | `%USERPROFILE%` | The directory the shell starts in when it is loaded. This path must be formatted as a Windows path.|
| `useAcrylic` | _Required_ | Boolean | `false` | When set to `true`, the window will have an acrylic background. When set to `false`, the window will have a plain, untextured background. |
| `background` | Optional | String | | Sets the background color of the profile. Overrides `background` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `backgroundImage` | Optional | String | | Sets the file location of the Image to draw over the window background. |
| `backgroundImageAlignment` | Optional | String | `center` | Sets how the background image aligns to the boundaries of the window. Possible values: `"center"`, `"left"`, `"top"`, `"right"`, `"bottom"`, `"topLeft"`, `"topRight"`, `"bottomLeft"`, `"bottomRight"` |
| `backgroundImageOpacity` | Optional | Number | `1.0` | Sets the transparency of the background image. Accepts floating point values from 0-1. |
| `backgroundImageStretchMode` | Optional | String | `uniformToFill` | Sets how the background image is resized to fill the window. Possible values: `"none"`, `"fill"`, `"uniform"`, `"uniformToFill"` |
| `colorTable` | Optional | Array[String] | | Array of colors used in the profile if `colorscheme` is not set. Colors use hex color format: `"#rrggbb"`. Ordering is as follows: `[black, red, green, yellow, blue, magenta, cyan, white, bright black, bright red, bright green, bright yellow, bright blue, bright magenta, bright cyan, bright white]` |
| `cursorHeight` | Optional | Integer | | Sets the percentage height of the cursor starting from the bottom. Only works when `cursorShape` is set to `"vintage"`. Accepts values from 25-100. |
| `foreground` | Optional | String | | Sets the foreground color of the profile. Overrides `foreground` set in color scheme if `colorscheme` is set. Uses hex color format: `"#rrggbb"`. |
| `icon` | Optional | String | | Image file location of the icon used in the profile. Displays within the tab and the dropdown menu. See [Background Images and Icons](./SettingsSchema.md#background-images-and-icons) below for help on specifying your own icons |
| `scrollbarState` | Optional | String | | Defines the visibility of the scrollbar. Possible values: `"visible"`, `"hidden"` |
| `tabTitle` | Optional | String | | If set, will replace the `name` as the title to pass to the shell on startup. Some shells (like `bash`) may choose to ignore this initial value, while others (`cmd`, `powershell`) may use this value over the lifetime of the application. |
## Schemes
Properties listed below are specific to each color scheme. ColorTool is a great tool you can use to create and explore new color schemes. All colors use hex color format.
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 |
| -------- | ---- | ----------- | ----------- |
@@ -72,3 +80,102 @@ Properties listed below are specific to each custom key binding.
| -------- | ---- | ----------- | ----------- |
| `command` | _Required_ | String | The command executed when the associated key bindings are pressed. |
| `keys` | _Required_ | Array[String] | Defines the key combinations used to call the command. |
### Implemented Keybindings
Bindings listed below are per the implementation in `src/cascadia/TerminalApp/AppKeyBindingsSerialization.cpp`
- copy
- copyTextWithoutNewlines
- paste
- newTab
- openNewTabDropdown
- duplicateTab
- newTabProfile0
- newTabProfile1
- newTabProfile2
- newTabProfile3
- newTabProfile4
- newTabProfile5
- newTabProfile6
- newTabProfile7
- newTabProfile8
- newWindow
- closeWindow
- closeTab
- closePane
- switchToTab
- nextTab
- prevTab
- increaseFontSize
- decreaseFontSize
- scrollUp
- scrollDown
- scrollUpPage
- scrollDownPage
- switchToTab0
- switchToTab1
- switchToTab2
- switchToTab3
- switchToTab4
- switchToTab5
- switchToTab6
- switchToTab7
- switchToTab8
- openSettings
- splitHorizontal
- splitVertical
- resizePaneLeft
- resizePaneRight
- resizePaneUp
- resizePaneDown
- moveFocusLeft
- moveFocusRight
- moveFocusUp
- moveFocusDown
## Background Images and Icons
Some Terminal settings allow you to specify custom background images and icons. It is recommended that custom images and icons are stored in system-provided folders and are referred to using the correct [URI Schemes](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes). URI Schemes provide a way to reference files independent of their physical paths (which may change in the future).
The most useful URI schemes to remember when customizing background images and icons are:
| URI Scheme | Corresponding Physical Path | Use / description |
| --- | --- | ---|
| `ms-appdata:///Local/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\` | Per-machine files |
| `ms-appdata:///Roaming/` | `%localappdata%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\RoamingState\` | Common files |
> ⚠ Note: Do not rely on file references using the `ms-appx` URI Scheme (i.e. icons). These files are considered an internal implementation detail and may change name/location or may be omitted in the future.
### Icons
Terminal displays icons for each of your profiles which Terminal generates for any built-in shells - PowerShell Core, PowerShell, and any installed Linux/WSL distros. Each profile refers to a stock icon via the `ms-appx` URI Scheme.
> ⚠ Note: Do not rely on the files referenced by the `ms-appx` URI Scheme - they are considered an internal implementation detail and may change name/location or may be omitted in the future.
You can refer to you own icons if you wish, e.g.:
```json
"icon" : "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\icon-ubuntu-32.png",
```
> 👉 Tip: Icons should be sized to 32x32px in an appropriate raster image format (e.g. .PNG, .GIF, or .ICO) to avoid having to scale your icons during runtime (causing a noticeable delay and loss of quality.)
### Custom Background Images
You can apply a background image to each of your profiles, allowing you to configure/brand/style each of your profiles independently from one another if you wish.
To do so, specify your preferred `backgroundImage`, position it using `backgroundImageAlignment`, set its opacity with `backgroundImageOpacity`, and/or specify how your image fill the available space using `backgroundImageStretchMode`.
For example:
```json
"backgroundImage": "C:\\Users\\richturn\\OneDrive\\WindowsTerminal\\bg-ubuntu-256.png",
"backgroundImageAlignment": "bottomRight",
"backgroundImageOpacity": 0.1,
"backgroundImageStretchMode": "none"
```
> 👉 Tip: You can easily roam your collection of images and icons across all your machines by storing your icons and images in OneDrive (as shown above).
With these settings, your Terminal's Ubuntu profile would look similar to this:
![Custom icon and background image](../images/custom-icon-and-background-image.jpg)

View File

@@ -33,7 +33,7 @@ This spec will outline how various terminal frontends will be able to interact w
5. Visual Studio should be able to persist and edit settings globally, without
the need for a globals/profiles structure.
6. The Terminal should be able to read information from a settings structure
that's independant of how it's persisted / implemented by the Application
that's independent of how it's persisted / implemented by the Application
7. The Component should be able to have its own settings independent of the
application that's embedding it, such as font size and face, scrollbar
visibility, etc. These should be settings that are specific to the component,
@@ -79,7 +79,7 @@ Shell Commandline |
### Simple Settings
An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specifc to Project Cascadia.
An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specific to Project Cascadia.
### Interface Descriptions
@@ -228,6 +228,6 @@ I don't like that - if we change the font size, we should just recalculate how m
## Questions / TODO
* How does this interplay with setting properties of the terminal component in XAML?
* I would think that the component would load the XAML properties first, and if the controlling application calls `UpdateSettings` on the component, then those in-XAML properties would likely get overwritten.
* It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entriely in XAML, go right ahead.
* It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entirely in XAML, go right ahead.
* Any settings that *are* exposed through XAML properties *should* also be exposed in the component's settings implementation as well.
* Can that be enforced any way? I doubt it.

View File

@@ -0,0 +1,527 @@
# Getting TAEF unittests to work with a C++/WinRT XAML Islands application
* __Author__: Mike Griese @zadjii-msft
* __Created on__: 2019-06-06
So you've built a Win32 application that uses XAML Islands to display it's UI
with C++/WinRT. How do you go about adding unittests to this application? I'm
going to cover the steps that I took to get the Windows Terminal updated to be
able to test not only our C++/WinRT components, but also pure c++ classes that
were used in the application, and components that used XAML UI elements.
## Prerequisites
Make sure you're using at least the 2.0.190605.7 version of the CppWinRT nuget
package. Prior to this version, there are some bugs with C++/WinRT's detection
of static lib dependencies. You might be able to get your build working with
Visual Studio on earlier versions, but not straight from MsBuild.
Also, if you're going to be running your tests in a CI build of some sort, make
sure that your tests are running on a machine running at least Windows 18362. If
your CI isn't running that version, then this doesn't matter at all.
Furthermore, you may need an updated TAEF package as well. Our CI uses the TAEF
VsTest adapter to allow ADO to run TAEF tests in CI. However, there's a bug in
the tests adapter that prevents it from running tests in a UAP context. The
`10.38.190605002` TAEF is the most recent release at the time of writing,
however, that doesn't have the fix necessary. Fortunately, the TAEF team was
kind enough to prototype a fix for us, which is the version
`10.38.190610001-uapadmin`, which we're using in this repo until an official
release with the fix is available.
## Move the C++/WinRT implementation to a static lib
By default, most (newly authored) C++/WinRT components are authored as a dll
that can be used to activate your types. However, you might have other classes
in that binary that you want to be able to test, which aren't winrt types. If
the implementation is sitting in a DLL, it'll be hard to write a TAEF unittest
dll that can call the pure c++ types you've defined.
The first thing you're going to need to do is move the implementation of your
winrt component from a dll to a static lib. Once you have the static lib, we'll
be able to link it into the dll you were previously producing, as well as being
able to link it into the dll we'll be using to test the types. Once this is
complete, your dll project will exist as little more than some extra packaging
for your new lib, as all your code will be built by the lib.
To aid in this description, I'll be referring to the projects that we changed.
The dll project we changed to a lib was the `TerminalApp` project. From it, we
created a new `TerminalAppLib` project, and changed `TerminalApp` to create a
dll by linking the lib `TerminalAppLib` produced.
### Create the static lib project
We'll start by creating a new static lib project. The easiest way to do this is
by copying your existing dll `vcxproj` file into a new file. Make sure to change
the `ProjectGuid` and to add the new project to your `.sln` file. Then, change
the `ConfigurationType` to `StaticLibrary`. This Lib should be responsible for
building all of your headers, `.cpp` files, `.idl`s for your winrt types, and
any `.xaml` files you might have.
You'll likely need to place this new file into a separate directory from the
existing dll project, as C++/WinRT uses the project directory as the root of the
intermediate build tree. Each directory should only have one `.vcxproj` file in
it. For the Terminal project, we created a subdirectory `lib/` underneath
`TerminalApp/`, and updated the `Include` paths to properly point at the
original files. You could alternatively put all the source in one directory, and
have separate `dll/` and `lib/` subdirectories from the source that are solely
responsible for building their binary.
At this point, you might face some difficulty including the right wimnd
references, especially from other C++/WinRT dependencies for this project that
exist in your solution. I don't know why, but I had a fair amount of difficulty
using a `ProjectReference` from a C++/WinRT StaticLibrary to another C++/WinRT
project in my solution. If you're referring to any other projects, you'll need
to set up a reference to their built `.winmd`'s manually.
As an example, here's how we've added a reference to the `TerminalSettings`
project from our `TerminalAppLib` project:
```xml
<ItemGroup>
<!-- Manually add references to each of our dependent winmds. Mark them as
private=false and CopyLocalSatelliteAssemblies=false, so that we don't
propagate them upwards (which can make referencing this project result in
duplicate type definitions)-->
<Reference Include="Microsoft.Terminal.Settings">
<HintPath>$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\Microsoft.Terminal.Settings.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
</ItemGroup>
```
The `HintPath` may be different depending on your project structure - verify
locally the right path to the `.winmd` file you're looking for.
Notably, you'll also need to put a `pch.h` and `pch.cpp` in the new lib's
directory, and use them instead of the `pch.h` used by the dll. C++/WinRT will be
very angry with you if you try to use a `pch.h` in another directory. Since
we're putting all the code into the static lib project, take your existing
`pch.h` and move it to the lib project's directory and create an empty `pch.h`
in the dll project's directory.
### Update the dll project
Now that we have a lib that builds all your code, we can go ahead and tear out
most of the dead code from the old dll project. Remove all the source files from
the dll's `.vcxproj` file, save for the `pch.h` and `pch.cpp` files. You _may_
need to leave the headers for any C++/WinRT types you've authored in this project
- I'm not totally sure it's necessary.
Now, to link the static lib we've created. For whatever reason, adding a
`ProjectReference` to the static lib doesn't work. So, we'll need to manually
link the lib from the lib project. You can do that by adding the lib's output
dir to your `AdditionalLibraryDirectories`, and adding the lib to your
`AdditionalDependencies`, like so:
```xml
<ItemDefinitionGroup>
<Link>
<!-- Manually link with the TerminalAppLib.lib we've built. -->
<AdditionalLibraryDirectories>$(SolutionDir)\$(Platform)\$(Configuration)\TerminalAppLib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<AdditionalDependencies>TerminalAppLib.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
```
We are NOT adding a reference to the static lib project's .winmd here. As of the
2.0.190605.7 CppWinRT nuget package, this is enough for MsBuild and Visual
Studio to be able to determine that the static lib's `.winmd` should be included
in this package.
At this point, you might have some mdmerge errors, which complain about
duplicate types in one of your dependencies. This might especially happen if one
of your dependencies (ex `A.dll`) is also a dependency for one of your _other_
dependencies (ex `B.dll`). In this example, your final output project `C.dll`
depends on both `A.dll` and `B.dll`, and `B.dll` _also_ depends on `A.dll`. If
you're seeing this, I recommend adding `Private=false` and
`CopyLocalSatelliteAssemblies=false` to your dependent dlls. In this example,
add similar code to `B.dll`:
```xml
<ProjectReference Include="$(SolutionDir)src\cascadia\TerminalSettings\TerminalSettings.vcxproj">
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</ProjectReference>
```
where `TerminalSettings` is your `A.dll`, which is included by both `B` and `C`.
We additionally had an `.exe` project that was including our `TerminalApp`
project, and all its `.xbf` and `.pri` files. If you have a similar project
aggregating all your resources, you might need to update the paths to point to
the new static lib project.
At this point, you should be able to rebuild your solution, and everything
should be working just the same as before.
## Add TAEF Tests
Now that you have a static library project, you can start building your unittest
dll. Start by creating a new directory for your unittest code, and creating a
`.vcxproj` for a TAEF unittest dll. For the Terminal solution, we use the TAEF
nuget package `Taef.Redist.Wlk`.
### Referencing your C++/WinRT static lib
This step is the easiest. Add a `ProjectReference` to your static lib project,
and your lib will be linked into your unittest dll.
```xml
<ProjectReference Include="$(SolutionDir)\src\cascadia\TerminalApp\lib\TerminalAppLib.vcxproj" />
```
Congratulations, you can now instantiate the pure c++ types you've authored in
your static lib. But what if you want to test your C++/WinRT types too?
### Using your C++/WinRT types
To be able to instantiate your C++/WinRT types in a TAEF unittest, you'll need
to rely on a new feature to Windows in version 1903 which enables unpackaged
activation of WinRT types. To do this, we'll need to author a SxS manifest that
lists each of our types, and include it in the dll, and also activate it
manually from TAEF.
#### Creating the manifest
First, you need to create a manifest file that lists each dll your test depends
upon, and each of the types in that dll. For example, here's an excerpt from the
Terminal's manifest:
```xml
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<file name="TerminalSettings.dll" hashalg="SHA1">
<activatableClass name="Microsoft.Terminal.Settings.KeyChord" threadingModel="both" xmlns="urn:schemas-microsoft-com:winrt.v1"></activatableClass>
<activatableClass name="Microsoft.Terminal.Settings.TerminalSettings" threadingModel="both" xmlns="urn:schemas-microsoft-com:winrt.v1"></activatableClass>
</file>
<file name="TerminalApp.dll" hashalg="SHA1">
<activatableClass name="TerminalApp.App" threadingModel="both" xmlns="urn:schemas-microsoft-com:winrt.v1"></activatableClass>
<activatableClass name="TerminalApp.AppKeyBindings" threadingModel="both" xmlns="urn:schemas-microsoft-com:winrt.v1"></activatableClass>
<activatableClass name="TerminalApp.XamlmetaDataProvider" threadingModel="both" xmlns="urn:schemas-microsoft-com:winrt.v1"></activatableClass>
</file>
</assembly>
```
Here we have two dlls that we depend upon, `TerminalSettings.dll` and
`TerminalApp.dll`. `TerminalSettings` implements two types,
`Microsoft.Terminal.Settings.KeyChord` and
`Microsoft.Terminal.Settings.TerminalSettings`.
#### Linking the manifest to the test dll
Now that we have a manifest file, we need to embed it in your unittest dll. This
is done with the following properties in your `vcxproj` file:
```xml
<PropertyGroup>
<GenerateManifest>true</GenerateManifest>
<EmbedManifest>true</EmbedManifest>
</PropertyGroup>
<ItemGroup>
<Manifest Include="TerminalApp.Unit.Tests.manifest" />
</ItemGroup>
```
where `TerminalApp.Unit.Tests.manifest` is the name of your manifest file.
Additionally, you'll need to binplace the manifest _adjacent to your test
binary_, so TAEF can find it at runtime. I've done this in the following way,
though I'm sure there's a better way:
```xml
<ItemDefinitionGroup>
<PostBuildEvent>
<!-- Manually copy the manifest to our outdir, because the test will need
to find it adjacent to us. -->
<Command>
(xcopy /Y &quot;$(OpenConsoleDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.manifest&quot; &quot;$(OutDir)\TerminalApp.Unit.Tests.manifest*&quot; )
</Command>
</PostBuildEvent>
</ItemDefinitionGroup>
```
#### Copying your dependencies
Additionally, any dlls that implement any types your test is dependent upon will
also need to be in the output directory for the test. Manually copy those DLLs
to the tests' output directory too. The updated `PostBuildEvent` looks like
this:
```xml
<ItemDefinitionGroup>
<PostBuildEvent>
<Command>
echo OutDir=$(OutDir)
(xcopy /Y &quot;$(SolutionDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.manifest&quot; &quot;$(OutDir)\TerminalApp.Unit.Tests.manifest*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalConnection\TerminalConnection.dll&quot; &quot;$(OutDir)\TerminalConnection.dll*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\TerminalSettings.dll&quot; &quot;$(OutDir)\TerminalSettings.dll*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalControl\TerminalControl.dll&quot; &quot;$(OutDir)\TerminalControl.dll*&quot; )
</Command>
</PostBuildEvent>
</ItemDefinitionGroup>
```
Again, verify the correct paths to your dependant C++/WinRT dlls, as they may be
different than the above
#### Activating the manifest from TAEF
Now that the manifest lives adjacent to your test dll, and all your dependent
dlls are also adjacent to the unittest dll, there's only one thing left to do.
TAEF will not use your dll's manifest by default, so you'll need to add a
property to your test class/method to tell TAEF to do so. You can do this with
the following:
```c++
class SettingsTests
{
// Use a custom manifest to ensure that we can activate winrt types from
// our test. This property will tell taef to manually use this as the
// sxs manifest during this test class. It includes all the C++/WinRT
// types we've defined, so if your test is crashing for an unknown
// reason, make sure it's included in that file.
BEGIN_TEST_CLASS(SettingsTests)
TEST_CLASS_PROPERTY(L"ActivationContext", L"TerminalApp.Unit.Tests.manifest")
END_TEST_CLASS()
// Other Test code here
}
```
Now, if you try to add any test methods that instantiate WinRT types you've
authored, they'll work. That is of course, so long as they don't use XAML. If
you want to use any XAML types, then you'll have to keep reading.
### Using Xaml Types (with XAML Islands)
To be able to instantiate XAML types in your unittest, we'll need to make use of
the [XAML Hosting
API](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api)
(Xaml Islands). This enables you to use XAML APIs from a Win32 context.
#### Adding XAML Hosting code
First and foremost, you'll need to add the following to your test's `precomp.h`:
```c++
#include <winrt/Windows.system.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.UI.Xaml.Hosting.h>
#include <windows.ui.xaml.hosting.desktopwindowxamlsource.h>
```
If you hit a compile warning that refers to `GetCurrentTime`, you'll probably
also need the following, after you've `#include`'d `Windows.h`:
```c++
#ifdef GetCurrentTime
#undef GetCurrentTime
#endif
```
Then, somewhere in your test code, you'll need to start up Xaml Islands. I've done this in my `TEST_CLASS_SETUP`, so that I only create it once, and re-use it for each method.
```c++
class TabTests
{
TEST_CLASS_SETUP(ClassSetup)
{
winrt::init_apartment(winrt::apartment_type::single_threaded);
// Initialize the Xaml Hosting Manager
_manager = winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread();
_source = winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource{};
return true;
}
private:
winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager _manager{ nullptr };
winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource _source{ nullptr };
```
#### Authoring your test's `AppxManifest.xml`
This alone however is not enough to get XAML Islands to work. There was a fairly
substantial change to the XAML Hosting API around Windows build 18295, so it
explicitly requires that you have your executable's manifest set
`maxversiontested` to higher than that version. However, because TAEF's `te.exe`
is not so manifested, we can't just use our SxS manifest from before to set that
version. Instead, you'll need to make TAEF run your test binary in a packaged
content, with our own appxmanifest.
To do this, we'll need to author an `Appxmanifest.xml` to use with the test, and
associate that manifest with the test.
Here's the AppxManifest we're using:
```xml
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" IgnorableNamespaces="uap">
<Identity Name="TerminalApp.Unit.Tests.Package"
ProcessorArchitecture="neutral"
Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
Version="1.0.0.0"
ResourceId="en-us" />
<Properties>
<DisplayName>TerminalApp.Unit.Tests.Package Host Process</DisplayName>
<PublisherDisplayName>Microsoft Corp.</PublisherDisplayName>
<Logo>taef.png</Logo>
<Description>TAEF Packaged Cwa FullTrust Application Host Process</Description>
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>
<Resources>
<Resource Language="en-us" />
</Resources>
<Applications>
<Application Id="TE.ProcessHost" Executable="TE.ProcessHost.exe" EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements DisplayName="TAEF Packaged Cwa FullTrust Application Host Process" Square150x150Logo="taef.png" Square44x44Logo="taef.png" Description="TAEF Packaged Cwa Application Host Process" BackgroundColor="#222222">
<uap:SplashScreen Image="taef.png" />
</uap:VisualElements>
</Application>
</Applications>
<Capabilities>
<rescap:Capability Name="runFullTrust"/>
</Capabilities>
<Extensions>
<Extension Category="windows.activatableClass.inProcessServer">
<InProcessServer>
<Path>TerminalSettings.dll</Path>
<ActivatableClass ActivatableClassId="Microsoft.Terminal.Settings.TerminalSettings" ThreadingModel="both" />
<ActivatableClass ActivatableClassId="Microsoft.Terminal.Settings.KeyChord" ThreadingModel="both" />
</InProcessServer>
</Extension>
<!-- More extensions here -->
</Extensions>
</Package>
```
Change the `Identity.Name` and `Properties.DisplayName` to be more appropriate
for your test, as well as other properties if you feel the need. TAEF will
deploy the test package and remove it from your machine during testing, so it
doesn't terribly matter what these values are.
MAKE SURE that `MaxVersionTested` is higher than `10.0.18295.0`. If it isn't,
XAML islands will still prevent you from activating it.
UNDER NO CIRCUMSTANCE should you change the `<Application Id="TE.ProcessHost"
Executable="TE.ProcessHost.exe" EntryPoint="Windows.FullTrustApplication">`
line. This is how TAEF activates the TAEF host for your test binary. You might
get a warning about `TE.ProcessHost.exe` being deprecated in favor of
`TE.ProcessHost.UAP.exe`, but I haven't had success with the UAP version.
Lower in the file, you'll see the `Extensions` block. In here you'll put each of
the winrt dependencies that your test needs, much like we did for the previous
manifest. Note that the syntax is _not_ exactly the same as the SxS manifest.
#### Copy the AppxManifest to your `$(OutDir)`
Again, we'll need to copy this appxmanifest adjacent to the test binary so we
can load it from the test. We'll do this similar to how we did the SxS manifest
before. The complete `PostBuildEvent` now looks like this:
```xml
<ItemDefinitionGroup>
<PostBuildEvent>
<Command>
(xcopy /Y &quot;$(SolutionDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.manifest&quot; &quot;$(OutDir)\TerminalApp.Unit.Tests.manifest*&quot; )
(xcopy /Y &quot;$(SolutionDir)src\cascadia\ut_app\TerminalApp.Unit.Tests.AppxManifest.xml&quot; &quot;$(OutDir)\TerminalApp.Unit.Tests.AppxManifest.xml*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalConnection\TerminalConnection.dll&quot; &quot;$(OutDir)\TerminalConnection.dll*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalSettings\TerminalSettings.dll&quot; &quot;$(OutDir)\TerminalSettings.dll*&quot; )
(xcopy /Y &quot;$(SolutionDir)$(Platform)\$(Configuration)\TerminalControl\TerminalControl.dll&quot; &quot;$(OutDir)\TerminalControl.dll*&quot; )
</Command>
</PostBuildEvent>
</ItemDefinitionGroup>
```
The new line here is the line referencing
`TerminalApp.Unit.Tests.AppxManifest.xml`. You can only have one
`PostBuildEvent` per project, so don't go re-defining it for each additional
step - MsBuild will only use the last one. Again, this is probably not the best
way of copying these files over, but it works.
#### Use the AppxManifest in the test code
Now that we have the AppxManifest being binplaced next to our test, we can
finally reference it in the test. Instead of using the `ActivationContext` from
before, we'll use two new properties to tell TAEF to run this test as a package,
and to use our manifest as the AppxManifest for the package.
```c++
BEGIN_TEST_CLASS(TabTests)
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TerminalApp.Unit.Tests.AppxManifest.xml")
END_TEST_CLASS()
```
The complete Xaml Hosting test now looks like this:
```c++
class TabTests
{
BEGIN_TEST_CLASS(TabTests)
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TerminalApp.Unit.Tests.AppxManifest.xml")
END_TEST_CLASS()
TEST_METHOD(TryCreateXamlObjects);
TEST_CLASS_SETUP(ClassSetup)
{
winrt::init_apartment(winrt::apartment_type::single_threaded);
// Initialize the Xaml Hosting Manager
_manager = winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread();
_source = winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource{};
return true;
}
private:
winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager _manager{ nullptr };
winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource _source{ nullptr };
};
void TabTests::TryCreateXamlObjects(){ ... }
```
Congratulations, you can now use XAML types from your unittest.
### Using types from `Microsoft.UI.Xaml`
Let's say you're extra crazy and you're using the `Microsoft.UI.Xaml` nuget
package. If you've followed all the steps above exactly, you're probably already
fine! You've already put the types in your appxmanifest (there are a lot of
them). You should be able to call the `Microsoft.UI.Xaml` types without any
problems.
This is because of a few key lines we already put in the appxmanifest:
```xml
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>
```
Without these `PackageDependency` entries for the VCLibs, Microsoft.UI.Xaml.dll
will not be able to load.

Binary file not shown.

After

Width:  |  Height:  |  Size: 135 KiB

View File

@@ -0,0 +1,362 @@
---
author: Mike Griese @zadjii-msft
created on: 2019-06-19
last updated: 2019-07-14
issue id: 1142
---
# Arbitrary Keybindings Arguments
## Abstract
The goal of this change is to both simplify the keybindings, and also enable far
more flexibility when editing a user's keybindings.
Currently, we have many actions that are very similar in implementation - for
example, `newTabProfile0`, `newTabProfile1`, `newTabProfile2`, etc. All these
actions are _fundamentally_ the same function. However, we've needed to define 9
different actions to enable the user to provide different values to the `newTab`
function.
With this change, we'll be able to remove these _essentially_ duplicated events,
and allow the user to specify arbitrary arguments to these functions.
## Inspiration
Largely inspired by the keybindings in VsCode and Sublime Text. Additionally,
much of the content regarding keybinding events being "handled" was designed as
a solution for [#2285].
## Solution Design
We'll need to introduce args to some actions that we already have defined. These
are the actions I'm thinking about when writing this spec:
```csharp
// These events already exist like this:
delegate void NewTabWithProfileEventArgs(Int32 profileIndex);
delegate void SwitchToTabEventArgs(Int32 profileIndex);
delegate void ResizePaneEventArgs(Direction direction);
delegate void MoveFocusEventArgs(Direction direction);
// These events either exist in another form or don't exist.
delegate void CopyTextEventArgs(Boolean copyWhitespace);
delegate void ScrollEventArgs(Int32 numLines);
delegate void SplitProfileEventArgs(Orientation splitOrientation, Int32 profileIndex);
```
Ideally, after this change, the bindings for these actions would look something
like the following:
```js
{ "keys": ["ctrl+shift+1"], "command": "newTabProfile", "args": { "profileIndex":0 } },
{ "keys": ["ctrl+shift+2"], "command": "newTabProfile", "args": { "profileIndex":1 } },
// etc...
{ "keys": ["alt+1"], "command": "switchToTab", "args": { "index":0 } },
{ "keys": ["alt+2"], "command": "switchToTab", "args": { "index":1 } },
// etc...
{ "keys": ["alt+shift+down"], "command": "resizePane", "args": { "direction":"down" } },
{ "keys": ["alt+shift+up"], "command": "resizePane", "args": { "direction":"up" } },
// etc...
{ "keys": ["alt+down"], "command": "moveFocus", "args": { "direction":"down" } },
{ "keys": ["alt+up"], "command": "moveFocus", "args": { "direction":"up" } },
// etc...
{ "keys": ["ctrl+c"], "command": "copy", "args": { "copyWhitespace":true } },
{ "keys": ["ctrl+shift+c"], "command": "copy", "args": { "copyWhitespace":false } },
{ "keys": ["ctrl+shift+down"], "command": "scroll", "args": { "numLines":1 } },
{ "keys": ["ctrl+shift+up"], "command": "scroll", "args": { "numLines":-1 } },
{ "keys": ["ctrl+alt+1"], "command": "splitProfile", "args": { "orientation":"vertical", "profileIndex": 0 } },
{ "keys": ["ctrl+alt+shift+1"], "command": "splitProfile", "args": { "orientation":"horizontal", "profileIndex": 0 } },
{ "keys": ["ctrl+alt+2"], "command": "splitProfile", "args": { "orientation":"vertical", "profileIndex": 1 } },
{ "keys": ["ctrl+alt+shift+2"], "command": "splitProfile", "args": { "orientation":"horizontal", "profileIndex": 1 } },
// etc...
```
Note that instead of having 9 different `newTabProfile<N>` actions, we have a
singular `newTabProfile` action, and that action requires a `profileIndex` in
the `args` object.
Also, pay attention to the last set of keybindings, the `splitProfile` ones.
This is a function that requires two arguments, both an `orientation` and a
`profileIndex`. Before this change we would have needed to create 20 separate
actions (10 profile indices * 2 directions) to handle these cases. Now it can
be done with a single action that can be much more flexible in its
implementation.
### Parsing KeyBinding Arguments
We'll add two new interfaces: `IActionArgs` and `IActionEventArgs`. Classes that
implement `IActionArgs` will contain all the per-action args, like
`CopyWhitespace` or `ProfileIndex`. `IActionArgs` by itself will be an empty
interface, but all other arguments will derive from it. `IActionEventArgs` will
have a single property `Handled`, which will be used for indicating if a
particular event was processed or not. When parsing args, we'll build
`IActionArgs` to contain all the parameters. When dispatching events, we'll
build `IActionEventArgs` using the `IActionArgs` to set all the parameter values.
All current keybinding events will be changed from their current types to
`TypedEventHandler`s. These `TypedEventHandler`s second param will always be an
instance of `IActionEventArgs`. So, for example:
```csharp
delegate void CopyTextEventArgs();
delegate void NewTabEventArgs();
delegate void NewTabWithProfileEventArgs(Int32 profileIndex);
// ...
[default_interface]
runtimeclass AppKeyBindings : Microsoft.Terminal.Settings.IKeyBindings
{
event CopyTextEventArgs CopyText;
event NewTabEventArgs NewTab;
event NewTabWithProfileEventArgs NewTabWithProfile;
```
Becomes:
```csharp
interface IActionArgs { /* Empty */ }
runtimeclass ActionEventArgs
{
Boolean Handled;
ActionArgs Args;
}
runtimeclass CopyTextArgs : IActionArgs
{
Boolean CopyWhitespace;
}
runtimeclass NewTabWithProfileArgs : IActionArgs
{
Int32 ProfileIndex;
}
runtimeclass NewTabWithProfileEventArgs : NewTabWithProfileArgs, IActionArgs { }
[default_interface]
runtimeclass AppKeyBindings : Microsoft.Terminal.Settings.IKeyBindings
{
event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> CopyText;
event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> NewTab;
event Windows.Foundation.TypedEventHandler<AppKeyBindings, ActionEventArgs> NewTabWithProfile;
```
In this above example, the `CopyTextArgs` class actually contains all the
potential arguments to the Copy action. `ActionEventArgs` is the class that
holds any `ActionArgs`. When we parse the arguments, we'll build a
`CopyTextArgs`, and when we're dispatching the event, we'll build a
`ActionEventArgs` that holds a `CopyTextArgs` as its `Args` value, and dispatch
the `ActionEventArgs` object.
We'll also change our existing map in the `AppKeyBindings` implementation.
Currently, it's a `std::unordered_map<KeyChord, ShortcutAction, ...>`, which
uses the `KeyChord` to lookup the `ShortcutAction`. We'll need to introduce a
new type `ActionAndArgs`:
```csharp
runtimeclass ActionAndArgs
{
ShortcutAction Action;
IActionArgs Args;
}
```
and we'll change the map in `AppKeyBindings` to a `std::unordered_map<KeyChord,
ActionAndArgs, ...>`.
When we're parsing keybindings, we'll need to construct args for each of the
events to go with each binding. When we find some key chord bound to a given
Action, we'll construct the `IActionArgs` for that action. For many actions,
these args will be an empty class. However, when we do find an action that needs
additional parsing, `AppKeyBindingsSerialization` will do the extra work to
parse the args for that action.
We'll keep a collection of functions that can be used for quickly determining
how to parse the args for an action if necessary. This map will be a
`std::unordered_map<ShortcutAction, function<IActionArgs(Json::Value)>>`. For
most actions which don't require args, the function in this map will be set to
nullptr, and we'll know that the action doesn't need to parse any more args.
However, for actions that _do_ require args, we'll set up a global function that
can be used to parse a json blob into an `IActionArgs`.
Once the `IActionArgs` is built for the keybinding, we'll set it in
`AppKeyBindings` with a updated `AppKeyBindings::SetKeyBinding` call.
`SetKeyBinding`'s signature will be updated to take a `ActionAndArgs` instead.
Should an action not need arguments, the `Args` member can be left `null` in the
`ActionAndArgs`.
### Executing KeyBinding Actions with Arguments
When we're handling a keybinding in `AppKeyBindings::_DoAction`, we'll trigger
the event handlers with the `IActionArgs` we've stored in the map with the
`ShortcutAction`.
Then, in `App`, we'll handle each of these events. We set up lambdas as event
handlers for each event in `App::_HookupKeyBindings`. In each of those
functions, we'll inspect the `IActionArgs` parameter, and use args from its
implementation to call callbacks in the `App` class. We will update `App` to
have methods defined with the actual keybinding function signatures.
Instead of:
```c++
void App::_HookupKeyBindings(TerminalApp::AppKeyBindings bindings) noexcept
{
// ...
bindings.NewTabWithProfile([this](const auto index) { _OpenNewTab({ index }); });
}
```
The code will look like:
```c++
void App::_HookupKeyBindings(TerminalApp::AppKeyBindings bindings) noexcept
{
// ...
bindings.NewTabWithProfile({ this, &App::_OpenNewTab });
}
// ...
void App::_OpenNewTab(const TerminalApp::AppKeyBindings& sender, const NewTabEventArgs& args)
{
auto profileIndex = args.ProfileIndex();
args.Handled(true);
// ...
}
```
### Handling Keybinding Events
Common to all implementations of `IActionArgs` is the `Handled` property. This
will let the app indicate if it was able to actually process a keybinding event
or not. While in the large majority of cases, the events will all be marked
handled, there are some scenarios where the Terminal will need to know if the
event could not be performed. For example, in the case of the `copy` event, the
Terminal is only capable of copying text if there's actually a selection active.
If there isn't a selection active, the `App` should make sure to not mark the
event as not handled (it will leave `args.Handled(false)`). The App should only
mark an event handled if it has actually dispatched the event.
When an event is handled, we'll make sure to return `true` from
`AppKeyBindings::TryKeyChord`, so that the terminal does not actually process
that keypress. For events that were not handled by the application, the terminal
will get another chance to dispatch the keypress.
### Serializing KeyBinding Arguments
Similar to how we parse arguments from the json, we'll need to update the
`AppKeyBindingsSerialization` code to be able to serialize the arguments from a
particular `IActionArgs`.
## UI/UX Design
### Keybindings in the New Tab Dropdown
Small modifications will need to be made to the code responsible for the new tab
dropdown. The new tab dropdown currently also displays the keybindings for each
profile in the new tab dropdown. It does this by querying for the keybinding
associated with each action. As we'll be removing the old `ShortcutAction`s that
this dropdown uses, we'll need a new way to find which key chord corresponds to
opening a given profile.
We'll need to be able to not only lookup a keybinding by `ShortcutAction`, but
also by a `ShortcutAction` and `IActionArgs`. We'll need to update the
`AppKeyBindings::GetKeyBinding` method to also accept a `IActionArgs`. We'll
also probably want each `IActionArgs` implementation to define an
`Equals(IActionArgs)` method, so that we can easily check if two different
`IActionArgs` are the same in this method.
## Capabilities
### Accessibility
N/A
### 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 keybindings are ignored. Currently, we
already gracefully ignore keybindings that have invalid `keys` or invalid
`commands`. We'll need to add additional validation on invalid sets of `args`.
When we're parsing the args from a Json blob, we'll make sure to only ever look
for keys we're expecting and ignore everything else.
If a keybinding requires certain args, but those args are not provided, we'll
need to make sure those args each have reasonable default values to use. If for
any reason a reasonable default can't be used for a keybinding argument, then
we'll need to make sure to display an error dialog to the user for that
scenario.
When we're re-serializing settings, we'll only know about the keybinding arg
keys that were successfully parsed. Other keys will be lost on re-serialization.
### Compatibility
This change will need to carefully be crafted to enable upgrading the legacy
keybindings seamlessly. For most actions, the upgrade should be seamless. Since
they already don't have args, their serializations will remain exactly the same.
However, for the following actions that we'll be removing in favor of actions
with arguments, we'll need to leave legacy deserialization in place to be able
to find these old actions, and automatically build the correct `IActionArgs`
for them:
* `newTabProfile<n>`
- We'll need to make sure to build args with the right `profileIndex`
corresponding to the old action.
* `switchToTab<n>`
- We'll need to make sure to build args with the right `index` corresponding
to the old action.
* `resizePane<direction>` and `moveFocus<direction>`
- We'll need to make sure to build args with the right `direction`
corresponding to the old action.
* `scroll<direction>`
- We'll need to make sure to build args with the right `amount` value
corresponding to the old action. `Up` will be -1, and `Down` will be 1.
### Performance, Power, and Efficiency
N/A
## Potential Issues
N/A
## Future considerations
* Should we support some sort of conversion from num keys to an automatic arg?
For example, by default, <kbd>Alt+&lt;N&gt;</kbd> to focuses the
Nth tab. Currently, those are 8 separate entries in the keybindings. Should we
enable some way for them be combined into a single binding entry, where the
binding automatically recieves the number pressed as an arg? I couldn't find
any prior art of this, so it doesn't seem worth it to try and invent
currently. This might be something that we want to loop back on, but for the
time being, it remains out of scope of this PR.
* When we inevitable support extensions, we'll need to allow extensions to also
be able to support their own custom keybindings and args. We'll probably want
to pass the settings to the extension to have the extension parse its own
settings. We'll want to be able to ask the extension for its own set of
`ActionAndArgs`<sup>[1]</sup> that it builds from the `keybindings`. Once we
have that set of actions, we'll be able to store them locally, and dispatch
them quickly.
- [1] We probably won't be able to use the `ActionAndArgs` class directly,
since that class is specific to the actions we define. We'll need another
way for extensions to be able to uniquely identify their own actions.
## Resources
N/A
[#2285]: https://github.com/microsoft/terminal/issues/2285

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.5 KiB

View File

@@ -0,0 +1,78 @@
---
author: Pankaj Bhojwani pankaj.d.bhoj@gmail.com
created on: 2019-06-12
last updated: 2019-06-12
issue id: #1235
---
# Azure cloud shell connector
## Abstract
This spec goes over the details of how a feature enabling Windows Terminal users to connect to the Azure cloud shell should behave. It includes implementation and design considerations.
## Inspiration
The idea is to give developers access to their Azure services smoothly within the Windows Terminal app, letting them engage with Azure technologies in a convenient manner. By integrating the Azure cloud shell into Windows Terminal, we can do just that.
## Solution Design
The flowchart below shows the process by which the Azure cloud shell will be integrated into Windows Terminal.
![Sol Design](images/solDesign.png)
The first three steps - authenticating the user, requesting a cloud shell and requesting a terminal - will be done via http requests. These requests will use the [cpprestsdk](https://github.com/Microsoft/cpprestsdk) library as that library is also owned by Microsoft, making it easy to resolve issues should any arise.
Authenticating the user will use [device code flow](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Device-Code-Flow) since Windows Terminal does not support browser access (yet). As for the authentication endpoint, Azure AD v1.0 will be used because Azure AD v2.0 (also known as Microsoft Identity Platform) [does not support login to personal accounts with device code flow](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Device-Code-Flow#constraints) at this time. Furthermore, upon successful authentication, the login/token information will be stored so that users will not need to repeatedly go through device code flow for future logins. Since this is sensitive information, the tokens will be stored with [Windows Storage](https://docs.microsoft.com/en-us/uwp/api/windows.storage) and encrypted with [Windows Security Data Protection](https://docs.microsoft.com/en-us/uwp/api/windows.security.cryptography.dataprotection.dataprotectionprovider).
The last step - connecting to the terminal - will be done via a websocket connection to allow easier communication between the app and the server.
The entire feature will be implemented in an isolated manner - i.e. it should have little to no dependency on the Windows Terminal app itself. This will allow the feature to become a plugin/extension once Windows Terminal supports plugins. More specifically, the connector will ascribe to the existing ITerminalConnection interface, making this simply another type of connection that Windows Terminal can make.
## UI/UX Design
Upon successful implementation, a new profile option will appear for users as illustrated in the picture below (the profile will have its own unique icon when implemented).
![Az Prof](images/azProf.png)
As for the rest of the UI, the implementation will adopt the user's preferences from the Windows Terminal app.
## Capabilities
### Accessibility
This feature will not impact accessibility of Windows Terminal.
### Security
Any feature that connects to a network introduces some security risks. However, with proper usage of Azure AD v1.0 and careful storage of tokens received from the server, these risks will be mitigated.
### Reliability
This feature will not impact reliability of Windows Terminal.
### Compatibility
With the implementation being mostly decoupled from the Windows Terminal app itself, no existing code/behaviours should break due to this feature.
### Performance, Power, and Efficiency
This feature will not impact performance, power or efficiency of Windows Terminal.
## Potential Issues
1. This implementation depends on another open source project, [cpprestsdk](https://github.com/Microsoft/cpprestsdk). Thus, any issues with their code will affect this feature. However, given that cpprestsdk is a Microsoft project, we can expect a level of reliability and also solve issues internally if needed.
2. The proposed authentication endpoint is Azure AD v1.0 instead of Azure AD v2.0 (also known as Microsoft Identity Platform). Azure AD v1.0 is still supported for now, but there is a risk of it becoming deprecated at some point in the future. However, given that it is once again another Microsoft-owned project, we can request support for it through an internal channel. In the worst case, our implementation can switch to Microsoft Identity Platform (which would only requires some minor edits to the http requests).
3. The Azure cloud shell API is not public, meaning that implementing this feature in an official capacity would require app permissions from the Azure cloud shell team. This brings about another dependency, but once again issues can be resolved through internal Microsoft channels.
## Future considerations
This could potentially be the first plugin for Windows Terminal once the app allows for plugins/extensions!
## Resources
* [Azure AD v1.0](https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-overview)
* [cpprestsdk](https://github.com/Microsoft/cpprestsdk)
* [Device code flow](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Device-Code-Flow)
* [Windows Storage](https://docs.microsoft.com/en-us/uwp/api/windows.storage)
* [Windows Security Data Protection](https://docs.microsoft.com/en-us/uwp/api/windows.security.cryptography.dataprotection.dataprotectionprovider)

View File

@@ -1,6 +1,8 @@
---
author: "Mike Griese @zadjii-msft"
created on: 2019-May-16
created on: 2019-05-16
last updated: 2019-07-07
issue id: 523
---
# Panes in the Windows Terminal
@@ -24,7 +26,7 @@ Windows Terminal.
Panes within the context of a single terminal window are not a new idea. The
design of the panes for the Windows Terminal was heavily inspired by the
application `tmux`, which is a commandline application which acts as a "terminal
multiplexer", allowing for the easy managment of many terminal sessions from a
multiplexer", allowing for the easy management of many terminal sessions from a
single application.
Other applications that include pane-like functionality include (but are not
@@ -113,7 +115,7 @@ We could also split `A` in horizontally, creating a fourth terminal pane `D`.
+---------------+
```
While it may appear that there's a single horizonal separator and a single
While it may appear that there's a single horizontal separator and a single
vertical separator here, that's not actually the case. Due to the tree-like
structure of the pane splitting, the horizontal splits exist only between the
two panes they're splitting. So, the user could move each of the horizontal
@@ -228,5 +230,5 @@ for swapping the positions of tabs, or a shortcut for both "zooming" a tab
tab. Additionally, a right-click menu option could be added to do the
aformentioned actions. Discoverability of these two actions is not as high as
just dragging a tab from one pane to another; however, it's believed that panes
are more of a power-user scenario, and power users will not neccessarily be
are more of a power-user scenario, and power users will not necessarily be
turned off by the feature's discoverability.

View File

@@ -0,0 +1,717 @@
---
author: Mike Griese @zadjii-msft
created on: 2019-05-31
last updated: 2019-07-31
issue id: 754
---
# Cascading Default + User Settings
## Abstract
This spec outlines adding support for a cascading settings model. In this model,
there are two settings files, instead of one.
1. The default settings file
2. The user's settings file
The default settings file would be a static, read-only file shipped with the
terminal. The user settings file would then contain all the user's chosen
customizations to the settings. These two files would then be composed together
when the app is launched, so that the runtime settings are the union of both the
defaults and whatever modifications the user has chosen. This will enable the
app to always use a default schema that it knows will be valid, and minimize the
settings that the user needs to customize.
Should the settings schema ever change, the defaults file will change, without
needing to re-write the user's settings file.
It also outlines a mechanism by which profiles could be dynamically added or
hidden from the profiles list, based on some external source.
## Inspiration
Largely inspired by the settings model that both VS Code (and Sublime Text) use.
### Goal: Minimize Re-Serializing `profiles.json`
We want to re-serialize the user settings file, `profiles.json`, as little as
possible. Each time we serialize the file, there's the possibility that we've
re-ordered the keys, as `jsoncpp` provides no ordering guarantee of the keys.
This isn't great, as each write of the file will randomly re-order the file.
One of our overarching goals with this change should be to re-serialize the user
settings file as little as possible.
### Goal: Minimize Content in `profiles.json`
We want the user to only have to make the minimal number of changes possible to
the user settings file. Additionally, the user should only have to have the
settings that they've changed in that file. If the user wants to change only the
`cursorColor` of a profile, they should only need to set that property in the
user settings file, and not need an entire copy of the `Profile` object in their
user settings file. That would create additional noise that's not relevant to
the user.
### Goal: Remove the Need to Reset Settings Entirely to get New Settings
One problem with the current settings design is that we only generate "default"
settings for the user when there's no settings file present at all. So, when we
want to do things like update the default profiles to have an icon, or add
support for generating WSL profiles, it will only apply to users for fresh
installs. Otherwise, a user needs to completely delete the settings file to have
the terminal re-generate the default settings.
This is fairly annoying to the end-user, so ideally we'll find a way to be able
to prevent this scenario.
### Goal: Prevent Roaming Settings from Failing
Another problem currently is that when settings roam to another machine, it's
possible that the second machine doesn't have the same applications installed as
the first, and some profiles might be totally invalid on the second machine.
Take for example, profiles for WSL distros. If you have and Ubuntu profile on
your first machine, and roam that profile to a second machine without Ubuntu
installed, then the Ubuntu profile would be totally broken on the second
machine.
While we won't be able to non-destructively prevent all failures of this case,
we should be able to catch it in certain scenarios.
## Solution Design
The settings are now composed from two files: a "Default" settings file, and a
"User" settings file.
When we load the settings, we'll perform the following steps, each mentioned in
greater detail below:
1. Load from disk the `defaults.json` (the default settings) -> DefaultsJson
1. Load from disk the `profiles.json` (the user settings) -> UserJson
1. Parse DefaultsJson to create all the default profiles, schemes, keybindings.
1. [Not covered in this spec] Check the UserJson to find the list of dynamic
profile sources that should run.
1. Run all the _enabled_ dynamic profile generators. Those profiles will be
added to the set of profiles.
- During this step, check if any of the profiles added here don't exist in
UserJson. If they _don't_, the generator created a profile that didn't
exist before. Return a value indicating the user settings should be
re-saved (with the new profiles added).
1. [Not covered in this spec] Layer the UserJson.globals.defaults settings to
every profile in the set, both the defaults, and generated profiles.
1. Apply the user settings from UserJson. Layer the profiles on top of the
existing profiles if possible (if both `guid` and `source` match). If a
profile from the user settings does not already exist, make sure to apply the
UserJson.globals.defaults settings first. Also layer Color schemes and
keybindings.
- If a profile has a `source` key, but there is not an existing profile with
a matching `guid` and `source`, don't create a new Profile object for it.
Either that generator didn't run, or the generator wanted to delete that
profile, so we'll effectively hide the profile.
1. Re-order the list of profiles, to match the ordering in the UserJson. If a
profile doesn't exist in UserJson, it should follow all the profiles in the
UserJson. If a profile listed in UserJson doesn't exist, we can skip it
safely in this step (the profile will be a dynamic profile that didn't get
populated.)
1. Validate the settings.
1. If requested in step 5, write the modified settings back to `profiles.json`.
### Default Settings
We'll have a static version of the "Default" file **hardcoded within the
application package**. This `defaults.json` file will live within the
application's package, which will prevent users from being able to edit it.
```json
// This is an auto-generated file. Place any modifications to your settings in "profiles.json"
```
This disclaimer will help identify that the file shouldn't be modified. The file
won't actually be generated, but because it's shipped with our app, it'll be
overridden each time the app is updated. "Auto-generated" should be good enough
to indicate to users that it should not be modified.
Because the `defaults.json` file is hardcoded within our application, we can use
its text directly, without loading the file from disk. This should help save
some startup time, as we'll only need to load the user settings from disk.
When we make changes to the default settings, or we make changes to the settings
schema, we should make sure that we update the hardcoded `defaults.json` with
the new values. That way, the `defaults.json` file will always have the complete
set of settings in it.
### Layering settings
When we load the settings, we'll do it in three stages. First, we'll deserialize
the default settings that we've hardcoded. We'll then generate any profiles that
might come from dynamic profile sources. Then, we'll intelligently layer the
user's setting upon those we've already loaded. If a user wants to make changes
to some objects, like the default profiles, we'll need to make sure to load from
the user settings into the existing objects we created from the default
settings.
* We'll need to make sure that any profile in the user settings that has a GUID
matching a default profile loads the user settings into the object created
from the defaults.
* We'll need to make sure that there's only one action bound to each key chord
for a keybinding. If there are any key chords in the user settings that match
a default key chord, we should bind them to the action from the user settings
instead.
* For any color schemes whose name matches the name of a default color scheme,
we'll need to apply the user settings to the existing color scheme. For
example, a user could override the `red` entry of the "Campbell" scheme to be
`#ff9900` if they want. This would then apply to all profiles using the
"Campbell" scheme.
* For profiles that were created from a dynamic profile source, they'll have
both a `guid` and `source` guid that must _both_ match. If a user profile with
a `source` set does not find a matching profile at load time, the profile will
be ignored. See more details in the [Dynamic Profiles](#dynamic-profiles)
section.
### Hiding Default Profiles
What if a user doesn't want to see one of the profiles that we've included in
the default profiles?
We will add a `hidden` key to each profile, which defaults to false. When we
want to mark a profile as hidden, we'd just set that value to `true`, instead of
trying to look up the profile's guid.
So, if someone wanted to hide the default cmd.exe profile, all they'd have to do
is add `"hidden": true` to the cmd.exe entry in their user settings, like so:
```js
{
"profiles": [
{
// Make changes here to the cmd.exe profile
"guid": "{6239a42c-1de4-49a3-80bd-e8fdd045185c}",
"hidden": true
}
],
```
#### Hidden Profiles and the Open New Tab shortcuts
Currently, there are keyboard shortcuts for "Open New Tab With Profile
&lt;N&gt;". These shortcuts will open up the Nth profile in the new tab
dropdown. Considering we're adding the ability to remove profiles from that
list, but keep them in the overall list of profiles, we'll need to make sure
that the handler for that event still opens the Nth _visible_ profile.
### Serializing User Settings
How can we tell that a setting should be written back to the user settings file?
If the value of the setting isn't the same as the defaults, then it could easily
be added to the user's `profiles.json`. We'll have to do a smart serialization
of the various settings models. We'll pass in the default version **of that
model** during the serialization. If that object finds that a particular setting
is the same as a default setting, then we'll skip serializing it.
What happens if a user has chosen to set the value to _coincidentally_ the same
value as the default value? We should keep that key in the user's settings file,
even though it is the same.
In order to facilitate this, we'll need to keep the originally parsed user
settings around in memory. When we go to serialize the settings, we'll check if
either the setting exists already in the user settings file, or the setting has
changed. If either is true, then we'll make sure to write that setting back out.
For serializing settings for the default profiles, we'll check if the setting is
in the user settings file, or if the value of the setting is different from the
version of that `Profile` from the default settings. For user-created profiles,
we'll compare the value of the setting with the value of the _default
constructed_ `Profile` object. This will help ensure that each profile in the
user's settings file maintains the minimal amount of info necessary.
When we're adding profiles due to their generation in a dynamic profile
generator, we'll need to serialize them, then insert them back into the
originally parsed json object to be serialized. We don't want the automatic
creation of a new profile to automatically trigger re-writing the entire user
settings file, but we do want newly created dynamic profiles to have an entry
the user can easily edit.
### Dynamic Profiles
Sometimes, we may want to auto-generate a profile on the user's behalf. Consider
the case of WSL distros on their machine, or VMs running in Azure they may want
to auto-connect to. These _dynamic_ profiles have a source that might be added
or removed after the app is installed, and they will be different from user to
user.
Currently, these profiles are only generated when a user first launches the
Terminal. If they already have a `profiles.json` file, then we won't run the
auto-generation behavior. This is obviously not great - if any new types of
dynamic profiles are added, then users that already have the Terminal installed
won't get any of these dynamic profiles. Furthermore, if any of the sources of
these dynamic profiles are removed, then the app won't auto-remove the
associated profile.
In the new model, with a combined defaults & user settings, how should these
dynamic profiles work?
I propose we add functionality to automatically search for these profile sources
and add/remove them on _every_ Terminal launch. To make this functionality work
appropriately, we'll need to introduce a constraint on dynamic profiles.
**For any dynamic profiles, they must be able to be generated using a stable
GUID**. For example, any time we try adding the "Ubuntu" profile, we must be
able to generate the same GUID every time. This way, when a dynamic profile
generator runs, it can check if that profile source already has a profile
associated with it, and do nothing (as to not create many duplicate "Ubuntu"
profiles, for example).
Additionally, each dynamic profile generator **must have a unique source guid**
to associate with the profile. When a dynamic profile is generated, the source's
guid will be added to the profile, to make sure the profile is correlated with
the source it came from.
We'll generate these dynamic profiles immediately after parsing the default
profiles and settings. When a generator runs, it'll be able to create unique
profile GUIDs for each source it wants to generate a profile for. It'll hand
back a list of Profile objects, with settings set up how the generator likes,
with GUIDs set.
After a dynamic profile generator runs, we will determine what new profiles need
to be added to the user settings, so we can append those to the list of
profiles. The deserializer will look at the list of generated profiles and check
if each and every one already has a entry in the user settings. The generator
will just blind hand back a list of profiles, and the deserializer will figure
out if any of them need to be added to the user settings. We'll store some sort
of result indicating that we want a save operation to occur. After the rest of
the deserializing is done, the app will then save the `profiles.json` file,
including these new profiles.
When we're serializing the settings, instead of comparing a dynamic profile to
the default-constructed `Profile`, we'll compare it to the state of the
`Profile` after the dynamic profile generator created it. It'd then only
serialize settings that are different from the auto-generated version. It will
also always make sure that the `guid` of the dynamic profile is included in the
user settings file, as a point for the user to add customizations to the dynamic
profile to. Additionally, we'll also make sure the `source` is always serialized
as well, to keep the profile correlated with the generator that created it.
We'll need to keep the state of these dynamically generated profiles around in
memory during runtime to be able to ensure the only state we're serializing is
that which is different from the initially generated dynamic profile.
When the generator is run, and determines that a new profile has been added,
we'll need to make sure to add the profile to the user's settings file. This
will create an easy point for users to customize the dynamic profiles. When
added to the user settings, all that will be added is the `name`, `guid`, and
`source`.
Additionally, a user might not want a dynamic profile generator to always run.
They might want to keep their Azure connections visible in the list of profiles,
even if its no longer a valid target. Or they might want to not automatically
connect to Azure to find new instances every time they launch the terminal. To
enable scenarios like this, we'll add an additional setting,
`disabledProfileSources`. This is an array of guids. If any guids are in that
list, then those dynamic profile generators _won't_ be run, suppressing those
profiles from appearing in the profiles list.
If a dynamic profile generator needs to "delete" a profile, this will also work
naturally with the above rules. Lets examine the case where the user has
uninstalled the Ubuntu distro. When the WSL generator runs, it won't create the
Ubuntu profile. When we get to the Ubuntu profile in the user's settings, it'll
have a `source`, but we won't already have a profile with that `guid` and
`source`. So we'll just ignore it, because whatever source for that profile
doesn't want it anymore. Effectively, this will act like it was "deleted",
though the artifacts still remain untouched in the user's json.
#### What if a dynamic profile is removed, but it's the default?
I'll direct our attention to [#1348] - Display a specific error for not finding
the default profile. When we're done loading, and we determine that the default
profile doesn't exist in the finalized list of profiles, we'll display a dialog
to the user. This includes both hidden profiles and dynamic profiles that have
been "deleted". We'll temporarily use the _first_ profile instead.
#### Dynamic profile GUID generation
In order to help facilitate the generation of stable, unique GUIDs for
dynamically generated profiles, we'll enforce a few methods on each generator.
The Generator should implement a method that returns its _unique_ namespace for
profiles it generates:
```c++
class IDynamicProfileGenerator
{
...
virtual std::wstring GetNamespace() = 0;
...
}
```
For example, the WSL generator would return `Microsoft.Terminal.WSL`. The
Powershell Core generator would return `Microsoft.Terminal.PowershellCore`.
We'll use these names to be able to generate uuidv5 GUIDs that will be unique
(so long as the names are unique).
The generator should also be able to ask the app for two other pieces of
functionality:
* The generator should be able to ask the app for the generator's own namespace
GUID
* The generator should be able to ask the app for a uuidv5 in the generator's
namespace, given a specific name key.
These two functions will be exposed to the generator like so:
```c++
GUID GetNamespaceGuid(IDynamicProfileGenerator& generator);
GUID GetGuidForName(IDynamicProfileGenerator& generator, std::wstring& name);
```
The generator does not _need_ to use `GetGuidForName` to generate guids for it's
profiles. If the generator can determine another way to generate stable GUIDs
for its profiles, it's free to use whatever method it wants. `GetGuidForName` is
provided as a convenience.
It's not the responsibility of the dynamic profile generator to fill in the
`source` of the profiles it generates. The deserializer will make sure to go
through and fill in the guid for the generated profiles given the generator's
namespace GUID.
### Powershell Core & the Defaults
How do we handle the potential existence of Powershell Core in this model?
Powershell core is unique as far as the default profiles goes - it may or may
not exist on the user's system. Not only that, but depending on the user's
install of Powershell Core, it might have a path in either `Program Files` or
`Program Files(x86)`.
Additionally, if it _is_ installed, we set it as the default profile instead of
Windows Powershell.
Powershell core acts much like a dynamic profile. It has an installation source
that may or not be there. So we'll add a dynamic profile generator for
Powershell Core. This will automatically create a profile for Powershell Core if
necessary.
Unlike the other dynamic profiles, if Powershell Core is present on
_first_ launch of the terminal, we set that as the default profile. This can
still be done - we'll need to do some special-case work when we're loading the
user settings and we _don't_ find any existing settings. When that happens,
we'll generate all the default user settings. Before we commit them, we'll check
if the Powershell Core profile exists, and if it does, we'll set that as the
default profile before writing the settings to disk.
### Unbinding a Keybinding
How can a user unbind a key that's part of the default keybindings? What if a
user really wants <kbd>ctrl</kbd>+<kbd>t</kbd> to fall through to the
commandline application attached to the shell, instead of opening a new tab?
We'll need to introduce a new keybinding command that should indicate that the
key is unbound. We'll load the user keybindings and layer them on the defaults
as described above. If during the deserializing we find an entry that's bound to
the command `"unbound"` or any other string that we don't understand, instead of
trying to _set_ the keybinding, we'll _clear_ the keybinding with a new method
`AppKeyBindings::ClearKeyBinding(chord)`.
### Removing the Globals Object
As a part of #[1005](https://github.com/microsoft/terminal/pull/1005), all the
global settings were moved to their own object within the serialized settings.
This was to try and make the file easier to parse as a user, considering global
settings would be intermingled with profiles, keybindings, color schemes, etc.
Since this change will make the user settings dramatically easier to navigate,
we should probably remove the `globals` object, and have globals at the root
level again.
### Default `profiles.json`
Below is an example of what the default user settings file might look like when
it's first generated, taking all the above points into consideration.
```js
// To view the default settings, open <path-to-app-package>\defaults.json
{
"defaultProfile" : "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
"profiles": [
{
// Make changes here to the cmd.exe profile
"guid": "{6239a42c-1de4-49a3-80bd-e8fdd045185c}"
},
{
// Make changes here to the Windows Powershell profile
"guid": "{086a83cd-e4ef-418b-89b1-3f6523ff9195}",
},
{
"guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
"name" : "Powershell Core",
"source": "{2bde4a90-d05f-401c-9492-e40884ead1d8}",
}
],
// Add custom color schemes to this array
"schemes": [],
// Add any keybinding overrides to this array.
// To unbind a default keybinding, set the command to "unbound"
"keybindings": []
}
```
Note the following:
* cmd.exe and powershell.exe are both in the file, as to give users an easy
point to extend the settings for those default profiles.
* Powershell Core is included in the file, and the default profile has been set
to its GUID. The `source` has been set, indicating that it came from a dynamic profile source.
* There are a few helpful comments scattered throughout the file to help point
the user in the right direction.
### Re-ordering profiles
Since there are shortcuts to open the Nth profile in the list of profiles, we
need to expose a way for the user to change the order of the profiles. This was
not a problem when there was only a single list of profiles, but if the defaults
are applied _first_ to the list of profiles, then the user wouldn't be able to
change the order of the default profiles. Additionally, any profiles they add
would _always_ show up after the defaults.
To remedy this, we could scan the user profiles in the user settings first, and
create `Profile` objects for each of those profiles first. These `Profile`s
would only be initialized with their GUID temporarily, but they'd be placed into
the list of profiles in the order they appear in the user's settings. Then, we'd
load all the default settings, overlaying any default profiles on the `Profile`
objects that might already exist in the list of profiles. If there are any
default profiles that don't appear in the user's settings, they'll appear
_after_ any profiles in the user's settings. Then, we'll overlay the full user
settings on top of the defaults.
## UI/UX Design
### Opening `defaults.json`
How do we open both these files to show to the user (for the interim period
before a proper Settings UI is created)? Currently, the "Settings" button only
opens a single json file, `profiles.json`. We could keep that button doing the
same thing, though we want the user to be able to also view the default settings
file, to be able to inspect what settings they wish to change.
We could have the "Settings" button open _both_ files at the same
time. I'm not sure that `ShellExecute` (which is used to open these files)
provides any ordering guarantees, so it's possible that the `defaults.json`
would open in the foreground of the default json editor, while making in unclear
that there's another file they should be opening instead. Additionally, if
there's _no_ `.json` editor for the user, I believe the shell will attempt
_twice_ to ask the user to select a program to open the file with, and it might
not be clear that they need to select a program in both dialogs.
Alternatively, we could make the defaults file totally inaccessible from the
Terminal UI, and instead leave a comment in the auto-generated `profiles.json`
like so:
```json
// To view the default settings, open the defaults.json file in this directory
```
The "Settings" button would then only open the file the user needs to edit, and
provide them instructions on how to open the defaults file.
There could alternatively be a hidden option for the "Open Settings" button,
where holding <kbd>Alt</kbd> while clicking on the button would open the
`defaults.json` instead.
We could additionally add a `ShortcutAction` (to be bound to a keybinding) that
would `openDefaultSettings`, and we could bind that to
<kbd>ctrl</kbd>+<kbd>alt</kbd>+<kbd>\`</kbd>, similar to `openSettings` on
<kbd>ctrl</kbd>+<kbd>\`</kbd>.
### How does this work with the settings UI?
If we only have one version of the settings models (Globals, Profiles,
ColorShemes, Keybindings) at runtime, and the user changes one of the settings
with the settings UI, how can we tell that settings changed?
Fortunately, this should be handled cleanly by the algorithm proposed above, in
the "Serializing User Settings" section. We'll only be serializing settings that
have changed from the defaults, so only the actual changes they've made will be
persisted back to the user settings file.
## Capabilities
### Security
I don't think this will introduce any new security issues that weren't already
present
### Reliability
I don't think this will introduce any new reliability concerns that weren't
already present. We will likely improve our reliability, as dynamic profiles
that no longer exist will not cause the terminal to crash on startup anymore.
### Performance, Power, and Efficiency
By not writing the defaults to disk, we'll theoretically marginally improve the
load and save times for the `profiles.json` file, by simply having a smaller
file to load. However we'll also be doing more work to process the layering of
defaults and user settings, which will likely slightly increase the load times.
Overall, I expect the difference to be negligible due to these factors.
One potential concern is long-running dynamic profile generators. Because
they'll need to run on startup, they could negatively impact startup time. You
can read more below, in "Dynamic Profile Generators Need to be Enabled".
### Accessibility
N/A
## Potential Issues
### Profiles with the same `guid` as a dynamic profile but not the same `source`
What happens if the User settings has a profile with a `guid` that matches a
dynamic or default profile, but the user profile doesn't have a matching source?
This could happen trivially easily if the user deletes the `source` key from a
profile that has dynamically generated.
We could:
1. Treat the profile as an entirely separate profile
- There's lots of other code that assumes each profile has only a unique GUID,
so we'd have to change the GUID of this profile. This would mean writing out
the user settings, which we'd like to avoid.
- We'll still end up generating the entry for the dynamic profile in the
user's settings, so we'll need to write out the user settings anyways.
- This other profile will likely not have a commandline set, so it might not
work at all.
1. Ignore the profile entirely.
- When the dynamic profile generator runs, we're not going to find another
entry in the user profiles with both a matching `guid` and a matching
`source`. So we'll end up creating _another_ entry in the user profiles for
the dynamic profile.
- How could the user know that the profile is being ignored? There's nothing
in the file itself that indicates obviously that this profile is now
invalid.
1. Treat the user settings as part of the dynamic profile
- In this scenario, the user profile continues to exist as part of the dynamic profile.
- When the dynamic profile generator runs, we're not going to find another
entry in the user profiles with both a matching `guid` and a matching
`source`. So we'll end up creating _another_ entry in the user profiles for
the dynamic profile.
- These two entries will each be layered upon the dynamically generated
profile, so the settings in the second profile entry will override
settings from the first.
- If the user disables the generator, or the profile source is removed, the
dynamic profile will cease to exist. However, the profile without the
`source` entry will remain, though likely will not work.
- How do we order these profiles for the user? When we're parsing the user
profiles list to build an ordering of profiles, do we use the first entry as
the index for that profile?
1. (Variant of the above) Treat the profile as part of the dynamic profile, and
re-insert the `source` key.
- This will re-connect the user profile to the dynamic one.
- We'll need to make sure to do this before determining the new dynamic
profiles to add to the user settings.
- Given all the scenarios are going to cause a user settings write anyways,
this isn't terrible.
- If the user _really_ wants to split the profile in their user settings from
the dynamic one, they're free to always generate a new guid _and_ delete the
`source` key.
Given the drawbacks associated with options 1-3, I propose we choose option 4 as
our solution to this case.
### Migrating Existing Settings
I believe that existing `profiles.json` files will smoothly update to this
model, without breaking. While in the new model, the `profiles.json` file can be
much more sparse, users who have existing `profiles.json` files will have full
settings in their user settings. We'll leave their files largely untouched, as
we won't touch keys that have the same values as defaults that are currently in
the `profiles.json` file. Fortunately though, users should be able to remove
much of the boilerplate from their `profiles.json` files, and trim it down just
to their modifications.
#### Migrating Powershell Core
Right now, default-generated Powershell Core profiles exist with a stable guid
we've generated for them. However, when we move Powershell Core to being a
dynamically generated profile, we'll have to ensure that we don't create a
duplicated "dynamic" entry for that profile. If we want to convert the existing
Powershell Core profiles into a dynamic profile, we'll need to make sure to add
a `source` key to the profile. Everything else in the profile can remain the
same. Once the `source` is added, we'll know to treat it as a dynamic profile,
and it'll respond dynamically.
This is actually something that will automatically be covered by the scenario
mentioned above in "Profiles with the same `guid` as a dynamic profile but not
the same `source`". When we encounter the existing Powershell Core profiles that
don't have a `source`, we'll automatically think they're the dynamically
generated ones, and auto-migrate them.
#### Migrating Existing WSL Profiles
Similar to the above, so long as we ensure the WSL dynamic profile generator
generates the _same_ GUIDs as it does currently, all the existing WSL profiles
will automatically be migrated to dynamic profiles.
### Dynamic Profile Generators Need to be Enabled
With the current proposal, profiles that are generated by a dynamic profile
generator _need_ that generator to be enabled for the profile to appear in the
list of profiles. If the generator isn't enabled, then the important parts of
the profile (name, commandline) will never be set, and the profile's settings
from the user settings will be ignored at runtime.
For generators where the generation of profiles might be a lengthy process, this
could negatively impact startup time. Take for example, some hypothetical
generator that needs to make web requests to generate dynamic profiles. Because
we need the finalized settings to be able to launch the terminal, we'll be stuck
loading until that generator is complete.
However, if the user disables that generator entirely, we'll never display that
profile to the user, even if they've done that setup before.
So the trade-off with this design is that non-existent dynamic profiles will
never roam to machines where they don't exist and aren't valid, but the
generators _must_ be enabled to use the dynamic profiles.
## Future considerations
* It's possible that a very similar layering loading mechanism could be used to
layer per-machine settings with roaming settings. Currently, there's only one
settings file, and it roams to all your devices. This could be problematic,
for example, if one of your machines has a font installed, but another
doesn't. A proposed solution to that problem was to have both roaming settings
and per-machine settings. The code to layer settings from the defaults and the
user settings could be re-used to handle layer the roaming and per-machine
settings.
* What if an extension wants to generate their own dynamic profiles? We've
already outlined a contract that profile generators would have to follow to
behave correctly. It's possible that we could abstract our implementation into
a WinRT interface that extensions could implement, and be triggered just like
other dynamic profile generators.
* **Multiple settings files** - This could enable us to place color schemes into
a seperate file (like `colorschemes.json`) and put keybindings into their own
file as well, and reduce the number of settings in the user's `profiles.json`.
It's unclear if this is something that we need quite yet, but the same
layering functionality that enables this scenario could also enable more than
two sources for settings.
* **Global Default Profile Settings** - Say a user wants to override what the
defaults for a profile are, so that they can set settings for _all_ their
profiles at once? We could maybe introduce a profile in the user settings file
with a special guid set to `"default`, that we look for first, and treat
specially. We wouldn't include it in the list of profiles. When we're creating
profiles, we'll start with that profile as our prototype, instead of using the
default-constructed `Profile`. When we're serializing profiles, we'd again use
that as the point of comparison to check if a setting's value has changed.
There may be more unknowns with this proposal, so I leave it for a future
feature spec.
- We'll also want to make sure that when we're serializing default/dynamic
profiles, we take into account the state from the global defaults, and we
don't duplicate that information into the entries for those types of profiles
in the user profiles.
* **Re-ordering profiles** - Under "Solution Design", we provide an algorithm
for decoding the settings. One of the steps mentioned is parsing the user
settings to determine the ordering of the profiles. It's possible in the
future we may want to give the user more control over this ordering. Maybe
we'll want to allow the user to manually index the profiles. Or, as discussed
in issues like #1571, we may want to allow the user to further customize the
new tab dropdown, beyond just the order of profiles. The re-ordering step
would be a great place to add code to support this re-ordering, with whatever
algorithm we eventually land on. Determining such an algorithm is outside the
scope of this spec, however.
## Resources
N/A
<!-- Footnotes -->
[#1348]: https://github.com/microsoft/terminal/issues/1348

View File

@@ -0,0 +1,255 @@
---
author: James Holderness @j4james
created on: 2019-07-17
last updated: 2019-07-28
issue id: 976
---
# VT52 Escape Sequences
## Abstract
This spec outlines the work required to split off the existing VT52 commands from the VT100 implementation, and extend the VT52 support to cover all of the core commands.
## Inspiration
The existing VT52 commands aren't currently implemented as a separate mode, so they conflict with sequences defined in the VT100 specification. This is blocking us from adding support for the VT100 Index (IND) escape sequence, which is one of the missing commands required to pass the test of cursor movements in Vttest.
## Solution Design
The basic idea is to add support for the [DECANM private mode sequence](https://vt100.net/docs/vt100-ug/chapter3.html#DECANM), which can then be used to switch from the default _ANSI_ mode, to a new _VT52_ mode. Once in _VT52_ mode, there is a separate [_Enter ANSI Mode_ sequence](https://vt100.net/docs/vt100-ug/chapter3.html#VT52ANSI) (`ESC <`) to switch back again.
In terms of implementation, there are a number of areas of the system that would need to be updated.
### The State Machine
In order to implement the VT52 compatibility mode correctly, we'll need to introduce a flag in the `StateMachine` class that indicates the mode that is currently active. When in VT52 mode, certain paths in the state diagram should not be followed - for example, you can't have CSI, OSC, or SS3 escape sequences. There would also need to be an additional state to handle VT52 parameters (for the _Direct Cursor Address_ command). These parameters take a different form to the typical VT100 parameters, as they follow the command character instead of preceding it.
It would probably be best to introduce a new dispatch method in the `IStateMachineEngine` interface to handle the parsed VT52 sequences, since the existing `ActionEscDispatch` does not support parameters (which are required for the _Direct Cursor Address_ command). I think it would also make for a cleaner implementation to have the VT52 commands separate from the VT100 code, and would likely have less impact on the performance that way.
### The Terminal Input
The escape sequences generated by the keyboard for function keys, cursor keys, and the numeric keypad, are not the same in VT52 mode as they are in ANSI mode. So there would need to be a flag in the `TerminalInput` class to keep track of the current mode, and thus be able to generate the appropriate sequences for that mode.
Technically the VT52 keyboard doesn't map directly to a typical PC keyboard, so we can't always work from the specs in deciding what sequences are required for each key. When in doubt, we should probably be trying to match the key sequences generated by XTerm. The sequences below are based on the default XTerm mappings.
**Function Keys**
The functions keys <kbd>F1</kbd> to <kbd>F4</kbd> generate a simple ESC prefix instead of SS3 (or CSI). These correspond with the four function keys on the VT100 keypad. In V52 mode they are not affected by modifiers.
Key | ANSI mode | VT52 mode
---------------|-----------|-----------
<kbd>F1</kbd> | `SS3 P` | `ESC P`
<kbd>F2</kbd> | `SS3 Q` | `ESC Q`
<kbd>F3</kbd> | `SS3 R` | `ESC R`
<kbd>F4</kbd> | `SS3 S` | `ESC S`
The function keys <kbd>F5</kbd> to <kbd>F12</kbd> generate the same sequences as they do in ANSI mode, except that they are not affected by modifiers. These correspond with a subset of the top-row functions keys on the VT220, along with the Windows <kbd>Menu</kbd> key mapping to the VT220 <kbd>DO</kbd> key.
Key | Sequence
----------------|-------------
<kbd>F5</kbd> | `CSI 1 5 ~`
<kbd>F6</kbd> | `CSI 1 7 ~`
<kbd>F7</kbd> | `CSI 1 8 ~`
<kbd>F8</kbd> | `CSI 1 9 ~`
<kbd>F9</kbd> | `CSI 2 0 ~`
<kbd>F10</kbd> | `CSI 2 1 ~`
<kbd>F11</kbd> | `CSI 2 3 ~`
<kbd>F12</kbd> | `CSI 2 4 ~`
<kbd>Menu</kbd> | `CSI 2 9 ~`
**Cursor and Editing Keys**
The cursor keys generate a simple ESC prefix instead of CSI or SS3. These correspond with the cursor keys on the VT100, except for <kbd>Home</kbd> and <kbd>End</kbd>, which are XTerm extensions. In V52 mode, they are not affected by modifiers, nor are they affected by the DECCKM _Cursor Keys_ mode.
Key | ANSI mode | VT52 mode
-----------------|-----------|-----------
<kbd>Up</kbd> | `CSI A` | `ESC A`
<kbd>Down</kbd> | `CSI B` | `ESC B`
<kbd>Right</kbd> | `CSI C` | `ESC C`
<kbd>Left</kbd> | `CSI D` | `ESC D`
<kbd>End</kbd> | `CSI F` | `ESC F`
<kbd>Home</kbd> | `CSI H` | `ESC H`
The "editing" keys generate the same sequences as they do in ANSI mode, except that they are not affected by modifiers. These correspond with a subset of the editing keys on the VT220.
Key | Sequence
----------------|-----------
<kbd>Ins</kbd> | `CSI 2 ~`
<kbd>Del</kbd> | `CSI 3 ~`
<kbd>PgUp</kbd> | `CSI 5 ~`
<kbd>PgDn</kbd> | `CSI 6 ~`
**Numeric Keypad**
With <kbd>Num Lock</kbd> disabled, most of the keys on the numeric keypad function the same as cursor keys or editing keys, but with the addition of a center <kbd>5</kbd> key. As a described above, the cursor keys generate a simple ESC prefix instead of CSI or SS3, while the editing keys remain unchanged (with the exception of modifiers).
In V52 mode, most modifiers are ignored, except for <kbd>Shift</kbd>, which is the equivalent of enabling <kbd>Num Lock</kbd> (i.e. the keys just generate their corresponding digit characters or `.`). With <kbd>Num Lock</kbd> enabled, it's the other way around - the digits are generated by default, while <kbd>Shift</kbd> enables the cursor/editing functionality.
Key | Alias | ANSI mode | VT52 mode
-------------|-------|-----------|-----------
<kbd>.</kbd> | Del | `CSI 3 ~` | `CSI 3 ~`
<kbd>0</kbd> | Ins | `CSI 2 ~` | `CSI 2 ~`
<kbd>1</kbd> | End | `CSI F` | `ESC F`
<kbd>2</kbd> | Down | `CSI B` | `ESC B`
<kbd>3</kbd> | PgDn | `CSI 6 ~` | `CSI 6 ~`
<kbd>4</kbd> | Left | `CSI D` | `ESC D`
<kbd>4</kbd> | Clear | `CSI E` | `ESC E`
<kbd>6</kbd> | Right | `CSI C` | `ESC C`
<kbd>7</kbd> | Home | `CSI H` | `ESC H`
<kbd>8</kbd> | Up | `CSI A` | `ESC A`
<kbd>9</kbd> | PgUp | `CSI 5 ~` | `CSI 5 ~`
When the DECKPAM _Alternate/Application Keypad Mode_ is set, though, the <kbd>Shift</kbd> modifier has a different affect on the numeric keypad. The sequences generated now correspond with the VT100/V52 numeric keypad keys. In VT52 mode, these sequences are not affected by any other modifiers, and this mode only applies when <kbd>Num Lock</kbd> is disabled.
Key | Alias | ANSI mode | VT52 mode
-------------|-------|-----------|-----------
<kbd>.</kbd> | Del | `SS3 2 n` | `ESC ? n`
<kbd>0</kbd> | Ins | `SS3 2 p` | `ESC ? p`
<kbd>1</kbd> | End | `SS3 2 q` | `ESC ? q `
<kbd>2</kbd> | Down | `SS3 2 r` | `ESC ? r`
<kbd>3</kbd> | PgDn | `SS3 2 s` | `ESC ? s`
<kbd>4</kbd> | Left | `SS3 2 t` | `ESC ? t`
<kbd>4</kbd> | Clear | `SS3 2 u` | `ESC ? u`
<kbd>6</kbd> | Right | `SS3 2 v` | `ESC ? v`
<kbd>7</kbd> | Home | `SS3 2 w` | `ESC ? w`
<kbd>8</kbd> | Up | `SS3 2 x` | `ESC ? x`
<kbd>9</kbd> | PgUp | `SS3 2 y` | `ESC ? y`
When the DECKPAM _Alternate/Application Keypad Mode_ is set, the "arithmetic" keys on the numeric keypad are also affected (this includes the <kbd>Enter</kbd> key). The sequences generated again correspond with the VT100/VT52 numeric keys (more or less), but this mapping is active even without the <kbd>Shift</kbd> modifier (and in VT52 mode all other modifiers are ignored too). As above, the mode only applies when <kbd>Num Lock</kbd> is disabled.
Key | ANSI mode | VT52 mode
-----------------|-----------|-----------
<kbd>*</kbd> | `SS3 j` | `ESC ? j`
<kbd>+</kbd> | `SS3 k` | `ESC ? k`
<kbd>-</kbd> | `SS3 m` | `ESC ? m`
<kbd>/</kbd> | `SS3 o` | `ESC ? o`
<kbd>Enter</kbd> | `SS3 M` | `ESC ? M`
Note that the DECKPAM _Application Keypad Mode_ is not currently implemented in ANSI mode, so perhaps that needs to be addressed first, before trying to add support for the VT52 _Alternate Keypad Mode_.
### Changing Modes
The `_PrivateModeParamsHelper` method in the `AdaptDispatch` class would need to be extended to handle the DECANM mode parameter, and trigger a function to switch to VT52 mode. The typical pattern for this seems to be through a `PrivateXXX` method in the `ConGetSet` interface. Then the `ConhostInternalGetSet` implementation can pass that flag on to the active output buffer's `StateMachine`, and the active input buffer's `TerminalInput` instance.
Changing back from VT52 mode to ANSI mode would need to be achieved with a separate VT52 command (`ESC <`), since the VT100 CSI mode sequences would no longer be active. This would be handled in the same place as the other VT52 commands, in the `OutputStateMachineEngine`, and then passed on to the mode selection method in the `AdaptDispatch` class described above (essentially the equivalent of the DECANM private mode being set).
### Additional VT52 Commands
Most of the missing VT52 functionality can be implemented in terms of existing VT100 methods.
* The _Cursor Up_ (`ESC A`), _Cursor Down_ (`ESC B`), _Cursor Left_ (`ESC D`), and _Cursor Right_ (`ESC C`) commands are already implemented.
* The _Enter Graphics Mode_ (`ESC F`) and _Exit Graphics Mode_ (`ESC G`) commands can probably use the existing `DesignateCharset` method, although this would require a new `VTCharacterSets` option with a corresponding table of characters (see below).
* The _Reverse Line Feed_ (`ESC I`) command can use the existing `ReverseLineFeed` method.
* The _Erase to End of Display_ (`ESC J`) and _Erase to End of Line_ (`ESC K`) commands can use the existing `EraseInDisplay` and `EraseInLine` methods.
* The _Cursor Home_ (`ESC H`) and _Direct Cursor Address_ (`ESC Y`) commands can probably be implemented using the `CursorPosition` method. Technically the _Direct Cursor Address_ has different rules for the boundary conditions (the CUP command clamps out of range coordinates, while the _Direct Cursor Address_ command ignores them, judged individually - one may be ignored while the other is interpreted). Nobody seems to get that right, though, so it's probably not that big a deal.
* The _Identify_ (`ESC Z`) command may be the only one that doesn't build on existing functionality, but it should be a fairly trivial addition to the `AdaptDispatch` class. For a terminal emulating VT52, the identifying sequence should be `ESC / Z`.
* The _Enter Keypad Mode_ (`ESC =`) and _Exit Keypad Mode_ (`ESC >`) commands can use the existing `SetKeypadMode` method, assuming the `TerminalInput` class already knows to generate different sequences when in VT52 mode (as described in the _Terminal Input_ section above).
* The _Enter ANSI Mode_ (`ESC <`) command can just call through to the new mode selection method in the `AdaptDispatch` class as discussed in the _Changing Modes_ section above.
There are also a few VT52 print commands, but those are not technically part of the core command set, and considering we don't yet support any of the VT102 print commands, I think they can probably be considered out of scope for now. Briefly they are:
* _Auto Print_ on (`ESC ^`) and off (`ESC _`) commands. In auto print mode, a display line prints after you move the cursor off the line, or during an auto wrap.
* _Print Controller_ on (`ESC W`) and off (`ESC X`) commands. When enabled, the terminal transmits received characters to the printer without displaying them.
* The _Print Cursor Line_ (`ESC V`) command prints the display line with the cursor.
* The _Print Screen_ (`ESC ]`) command prints the screen (or at least the scrolling region).
I suspect most, if not all of these, would be direct equivalents of the VT102 print commands, if we ever implemented those.
### Graphic Mode Character Set
The table below lists suggested mappings for the _Graphics Mode_ character set, based on the descriptions in the [VT102 User Guide](https://vt100.net/docs/vt102-ug/table5-15.html).
Note that there is only the one _fraction numerator_ character in Unicode, so superscript digits have instead been used for the numerators 3, 5, and 7. There are also not enough _horizontal scan line_ characters (for the _bar at scan x_ characters), so each of them is used twice to cover the full range.
ASCII Character |Mapped Glyph |Unicode Value |Spec Description
----------------|---------------|---------------|----------------
_ | |U+0020 |Blank
` | |U+0020 |Reserved
a |█ |U+2588 |Solid rectangle
b |⅟ |U+215F |1/
c |³ |U+00B3 |3/
d |⁵ |U+2075 |5/
e |⁷ |U+2077 |7/
f |° |U+00B0 |Degrees
g |± |U+00B1 |Plus or minus
h |→ |U+2192 |Right arrow
i |… |U+2026 |Ellipsis (dots)
j |÷ |U+00F7 |Divide by
k |↓ |U+2193 |Down arrow
l |⎺ |U+23BA |Bar at scan 0
m |⎺ |U+23BA |Bar at scan 1
n |⎻ |U+23BB |Bar at scan 2
o |⎻ |U+23BB |Bar at scan 3
p |⎼ |U+23BC |Bar at scan 4
q |⎼ |U+23BC |Bar at scan 5
r |⎽ |U+23BD |Bar at scan 6
s |⎽ |U+23BD |Bar at scan 7
t |₀ |U+2080 |Subscript 0
u |₁ |U+2081 |Subscript 1
v |₂ |U+2082 |Subscript 2
w |₃ |U+2083 |Subscript 3
x |₄ |U+2084 |Subscript 4
y |₅ |U+2085 |Subscript 5
z |₆ |U+2086 |Subscript 6
{ |₇ |U+2087 |Subscript 7
\| |₈ |U+2088 |Subscript 8
} |₉ |U+2089 |Subscript 9
\~ |¶ |U+00B6 |Paragraph
### Testing
A simple unit test will need to be added to the `AdapterTest` class, to confirm that calls to toggle between the ANSI and VT52 modes in the `AdaptDispatch` class are correctly forwarded to the corresponding `PrivateXXX` handler in the `ConGetSet` interface.
The majority of the testing would be handled in the `StateMachineExternalTest` class though. These tests would confirm that the various VT52 sequences trigger the expected methods in the `ITermDispatch` interface when VT52 Mode is enabled, and also that they don't do anything when in ANSI mode.
There shouldn't really be any need for additional tests in the `ScreenBufferTests` class, since we're relying on existing VT100 functionality which should already be tested there.
For fuzzing support, we'll need to add the DECANM option to the `GeneratePrivateModeParamToken` method in the `VTCommandFuzzer` class, and also probably add two additional token generator methods - one specifically for the _Direct Cursor Address_ command, which requires parameters, and another to handle the remaining parameterless commands.
In terms of manual testing, it can be useful to run the _Test of VT52 mode_ option in Vttest, and confirm that everything looks correct there. It's also worth going through some of the options in the The _Test of keyboard_ section, since those tests aren't only intended for the later VT models - they do cover the VT52 keyboard as well.
## UI/UX Design
There is no additional UI associated with this feature.
## Capabilities
### Accessibility
This should not impact accessibility any more than the existing escape sequences.
### Security
This should not introduce any new security issues.
### Reliability
This should not introduce any new reliability issues.
### Compatibility
This could be a breaking change for code that relies on the few existing VT52 commands being available without a mode change. However, that functionality is non-standard, and has not been around for that long. There is almost certainly more benefit in being able to implement the missing VT100 functionality than there is in retaining that non-standard behaviour.
### Performance, Power, and Efficiency
The additional mode flags and associated processing in the `StateMachine` and `TerminalInput` classes could have some performance impact, but that is unlikely to be significant.
## Potential Issues
The only negative impacts I can think of would be the potential for breaking changes, and the possible impact on performance, as discussed in the _Compatibility_ and _Performance_ sections above. But as with any new code, there is always the possibility of new bugs being introduced as well.
## Future considerations
As mentioned in the _Inspiration_ section, having the VT52 functionality isolated with a new mode would enable us to implement the VT100 Index (IND) escape sequence, which currently conflicts with the VT52 _Cursor Left_ command.
## Resources
* [VT52 Mode Control Sequences](https://vt100.net/docs/vt100-ug/chapter3.html#S3.3.5)
* [VT100 ANSI/VT52 Mode (DECANM)](https://vt100.net/docs/vt100-ug/chapter3.html#DECANM)
* [VT100 Index Sequence (IND)](https://vt100.net/docs/vt100-ug/chapter3.html#IND)
* [VTTEST Test Utility](https://invisible-island.net/vttest/)
* [DEC STD 070 Video Systems Reference Manual](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381)

View File

@@ -3,7 +3,7 @@
In Openconsole, `dev/main` is the master branch for the repo.
Any branch that begins with `dev/` is recognized by our CI system and will automatically run x86 and amd64 builds and run our unit and feature tests. For feature branchs the pattern we use is `dev/<alias>/<whatever you want here>`. ex. `dev/austdi/SomeCoolUnicodeFeature`. The important parts are the dev prefix and your alias.
Any branch that begins with `dev/` is recognized by our CI system and will automatically run x86 and amd64 builds and run our unit and feature tests. For feature branches the pattern we use is `dev/<alias>/<whatever you want here>`. ex. `dev/austdi/SomeCoolUnicodeFeature`. The important parts are the dev prefix and your alias.
`inbox` is a special branch that coordinates Openconsole code to the main OS repo.
@@ -15,12 +15,12 @@ Because we build outside of the OS repo, we need a way to get code back into it
## What to do when cherry-picking to inbox fails
Sometimes VSTS doesn't want to allow a cherry pick to the inbox branch. It might have a valid reason or it might just be finicky. You'll need to complete the merge manually on a local machine. The steps are:
Sometimes VSTS doesn't want to allow a cherry pick to the inbox branch. It might have a valid reason, or it might just be finicky. You'll need to complete the merge manually on a local machine. The steps are:
1. make sure you have pulled the latest commits for the `dev/main` and `inbox` branches
2. make a new branch from inbox
3. cherry-pick the commits from the PR to the newly created branch (this is easier if you squashed your commits when you merged into `dev/main`
4. fix any merge conficts and commit
4. fix any merge conflicts and commit
5. push the new branch to the remote
6. create a new PR of that branch in `inbox`
7. complete PR and continue on to completing the auto-created PR in the OS repo

View File

@@ -0,0 +1,95 @@
# Terminal v1.0 Roadmap
## Overview
This document outlines our roadmap to delivering Windows Terminal v1.0 by spring 2020.
## Milestones
The Windows Terminal project is engineered and delivered as a set of 4-week milestones:
| 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://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701) & [GitHub Releases](https://github.com/microsoft/terminal/releases) (Tues of 4th week)</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
Ultimately, we're aiming for Terminal v1.0 to be feature-complete by Dec 2019, and to declare v1.0 by April 2020:
> ⚠ Note: Terminal v1.0 will be a quality-oriented release driven in large part by the community. So, ___if you see bugs, find/file them___!
| Milestone end date | Phase | Key features |
| --- | --- | --- |
| 2019-05-07 | [Announcement](https://devblogs.microsoft.com/commandline/introducing-windows-terminal/) | Terminal announced & open-sourced ([Build 2019 Terminal session](https://www.youtube.com/watch?v=KMudkRcwjCw), ["Sizzle" video](https://www.youtube.com/watch?v=8gw0rXPMMPE&list=PLEHMQNlPj-Jzh9DkNpqipDGCZZuOwrQwR&index=2&t=0s)) |
| 2019-07-09 | [v0.2 (update)](https://github.com/microsoft/terminal/releases/tag/v0.2.1831.0) | First version of the Terminal released via the Microsoft Store, fundamental features in place, basic tab control, basic UI layout, config & settings via JSON file |
| 2019-08-02 | [v0.3](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) | Major UI improvements, improved tab bar layout & color, basic a11y support, Azure Cloud Shell connection |
| 2019-08-27 | [v0.4](https://github.com/microsoft/terminal/releases/tag/v0.4.2382.0) | HTML Copy, Tab Titles, Double/Triple Click Selection, Local Settings, JSON settings validation, A11y improvements |
| 2019-09-24 | [1909]( http://devblogs.microsoft.com/commandline/windows-terminal-preview-1909) | Stability & Quality improvements, installs [Cascadia Code](https://github.com/microsoft/cascadia-code) font, adds JSON schema to `profiles.json` settings file enabling Intellisense in VSCode, etc. |
| 2019-10-22 | 1910 | Cascading Settings, Dynamic Profiles |
| 2019-11-19 | 1911 | Final v1.0 feature work |
| 2019-12-17 | 1912 | "Feature Complete" - All v1.0 Features in-place |
| Winter Vacation | N/A | None planned |
| 2020-01-28 | Beta 1 | Pri 0/1/2 Bug fixes & polish |
| 2020-02-25 | Beta 2 | Pri 0/1 Bug fixes & polish |
| 2020-03-24 | RC | Pri 0 bug fixes |
| 2020-04-01 ? | v1.0 | Terminal v1.0 Release |
## GitHub Milestones
Each milestone above is/will be reflected in our [GitHub milestones](https://github.com/microsoft/terminal/milestones):
| Milestone | Description |
| --- | --- |
| [Terminal-1909](https://github.com/microsoft/terminal/milestone/12) | Work planned for 1909 |
| [Terminal-1910](https://github.com/microsoft/terminal/milestone/15) | Work planned for 1910 |
| [Terminal-1911](https://github.com/microsoft/terminal/milestone/16) | Work planned for 1911 |
| [Terminal-1912](https://github.com/microsoft/terminal/milestone/17) | Work planned for 1912 |
| &lt;Future Milestones&gt; | &lt;Coming soon&gt; |
| [Terminal v1.0](https://github.com/microsoft/terminal/milestone/6) | Work planned for v1.0, but not yet assigned to a milestone |
| [Terminal Backlog](https://github.com/microsoft/terminal/milestone/7) | Work not yet assigned to a milestone or release |
## Issue Triage & Prioritization
Incoming issues/asks/etc. are triaged several times a week, labelled 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 v1.0 milestone](https://github.com/microsoft/terminal/milestone/6) for future assignment, if required to deliver a v1.0 feature
* Issues/features/asks not on our list of v1.0 features is assigned to the [Terminal Backlog](https://github.com/microsoft/terminal/milestone/7) for subsequent triage, prioritization & scheduling.
## v1.0 Features
The following are a list of the key features/feature-areas we're aiming to deliver for Terminal v1.0.
> 👉 Note: There are many other features that don't fit within v1.0, but will be re-assessed and prioritized for v2.0, the plan for which will be published in early in 2020.
| Release | Priority\* | Feature | Description/Notes |
| --- | --- | --- | --- |
| V1 | 0 | Performance & Efficiency | Terminal shall be fast and efficient. Input latency should be eliminated wherever possible. Terminal will be very memory-efficient, and will avoid utilizing unnecessary dependencies to minimize memory consumption and disk footprint |
| V1 | 0 | Reliability | Every reasonable step should be taken to ensure that Terminal will not crash unexpectedly. Crashing is considered harmful to the user's well-being & state of mind. Crashing issues are prioritized Pri-0 by default |
| V1 | 0 | Code Reuse | Terminal's core engine will reuse & share componentry from within Windows Console wherever feasible to minimize support & maintenance costs for both|
| V1 | 0 | Terminal Reuse | Terminal's core will be hostable as a UWP (and perhaps WPF) Control so that apps can host/embed a high quality Terminal. This will satisfy a long-standing ask from many customers and partners for a hostable/embeddable Terminal Control. |
| V1 | 0 | Rich, modern text renderer | Terminal must be able to render glyphs from East Asian and Middle Asian languages, inc. Chinese, Hebrew, Arabic, etc. Terminal will also be able to render Emoji - an increasingly important feature considering that several programming languages now support Emoji in method and variable names! To render such glyphs, the Terminal needs a DirectWrite-based layout & rendering system which supports font fallback, customizable text layout, GPU accelerated rendering, and many other features not currently supported by the built-in Windows Console |
| V1 | 0 | Solid Unicode & UTF-8 support | Terminal must be able to store data encoded as Unicode UTF-16/UCS-2 and UTF-8, including surrogate pairs. Note: Terminal v1.0 won't be able to support composing characters or grapheme clusters that are not representable with a single unicode codepoint - this will be addressed in a subsequent release |
| V1 | 0 | International text rendering | The Terminal will support rendering text for almost every language for which there is a fixed-width font including East Asian languages. Bonus points for RTL languages/scripts. |
| V1 | 0 | Multiple instances | Users must be able to launch multiple independent instances of the Terminal in order to run tools side-by-side / independently |
| V1 | 0 | Elevation | Terminal can be launched "elevated" with Admin rights if required so that the user can perform operations that affect machine-wide state |
| V1 | 0 | Multiple Tabs per instance | Each Terminal instance must support one or more independent tabs. This is the #1 ask from the community! |
| V1 | 0 | Configurability & Customization | The new Terminal will have a modern, flexible settings mechanism that persists settings to/from a JSON file stored in the user's app data folders, and/or in files synchronized between machines via OneDrive, etc. There will be no settings UI in Terminal v1 - this is a feature for a future Terminal release. |
| V1 | 0 | Accessibility (A11y) | The Terminal will be highly accessible and inclusive. It will expose its contents via [UIA](https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-overview) to support tools such as [Windows Narrator](https://support.microsoft.com/en-us/help/22798/windows-10-complete-guide-to-narrator), and UI automation tools including [WinAppDriver](https://github.com/Microsoft/WinAppDriver) |
| V1 | 1 | Color Theming & Styling | The Terminal will honor the user's Windows dark/light theme settings, and/or color accent settings. Also, the Terminal background & text colors will be highly configurable, and importable/exportable via settings files.|
| V1 | 1 | Background transparency | Background transparency is a valuable feature for many command-line users. Terminal will (optionally) support transparent backgrounds, but without making the Terminal's text content itself transparent (like the Windows Console currently does due to GDI limitations)|
| V1 | 1 | Fluent "Acrylic" blurred backgrounds | While full transparency is valuable to some, clear/full-transparency can be distracting. Some would like blurred transparency similar to Fluent Acrylic |
| V1 | 1 | Customizable Key Bindings | Terminal will provide a way for users to customize key bindings, enabling them to configure specific key chords to particular Terminal actions |
| V1 | 1 | Mouse Support | Terminal will support mouse input, passing mouse movements and actions to command-line apps |
| V1 | 2 | Azure Cloud Shell | Enable users to register their Azure account/subscription, and allow the Terminal to enumerate and automatically configure a connection to the user's Cloud Shell |
| V1 | 2 | Multiple panes | Multiple tabs are useful to some, but developers often need to see several files/logs on the same screen at the same time. Windows Terminal should allow a "page" to be split into "panes", each running independent commands/shells/etc. similar to [tmux](https://www.ocf.berkeley.edu/~ckuehl/tmux/) on *NIX/macOS |
Feature Notes:
\* Feature Priorities:
0. Mandatory <br/>
1. Optimal <br/>
2. Optional / Stretch-goal <br/>

View File

@@ -0,0 +1,277 @@
# Editing Windows Terminal JSON Settings
One way (currently the only way) to configure Windows Terminal is by editing the
`profiles.json` settings file. At the time of writing you can open the settings
file in your default editor by selecting `Settings` from the WT pull down menu.
The settings are stored in the file `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>\LocalState\profiles.json`.
As of [#2515](https://github.com/microsoft/terminal/pull/2515), the settings are
split into _two_ files: a hardcoded `defaults.json`, and `profiles.json`, which
contains the user settings. Users should only be concerned with the contents of
the `profiles.json`, which contains their customizations. The `defaults.json`
file is only provided as a reference of what the default settings are. For more
details on how these two files work, see [Settings
Layering](#settings-layering). To view the default settings file, click on the
"Settings" button while holding the <kbd>Alt</kbd> key.
Details of specific settings can be found [here](../cascadia/SettingsSchema.md).
A general introduction is provided below.
The settings are grouped under four headings:
1. Global: Settings that apply to the whole application e.g. Default profile, initial size etc.
2. Key Bindings: Actually a sub field of the global settings, but worth discussing separately
3. Profiles: A group of settings to be applied to a tab when it is opened using that profile. E.g. shell to use, cursor shape etc.
4. Schemes: Sets of colors for background, text etc. that can be used by profiles
## Global Settings
These settings define startup defaults, and application-wide settings that might
not affect a particular terminal instance.
* Theme
* Title Bar options
* Initial size
* Default profile used when the Windows Terminal is started
Example settings include
```json
"defaultProfile" : "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
"initialCols" : 120,
"initialRows" : 50,
"requestedTheme" : "system",
"keybindings" : []
...
```
These global properties can exist either in the root json object, or in and
object under a root property `"globals"`.
## Key Bindings
This is an array of key chords and shortcuts to invoke various commands.
Each command can have more than one key binding.
NOTE: Key bindings is a subfield of the global settings and
key bindings apply to all profiles in the same manner.
For example, here's a sample of the default keybindings:
```json
{
"keybindings":
[
{ "command": "closePane", "keys": ["ctrl+shift+w"] },
{ "command": "copy", "keys": ["ctrl+shift+c"] },
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
// etc.
]
}
```
## Profiles
A profile contains the settings applied when a new WT tab is opened. Each
profile is identified by a GUID and contains a number of other fields.
> 👉 **Note**: The `guid` property is the unique identifier for a profile. If
> multiple profiles all have the same `guid` value, you may see unexpected
> behavior.
* Which command to execute on startup - this can include arguments.
* Starting directory
* Which color scheme to use (see Schemes below)
* Font face and size
* Various settings to control appearance. E.g. Opacity, icon, cursor appearance, display name etc.
* Other behavioural settings. E.g. Close on exit, snap on input, .....
Example settings include
```json
"closeOnExit" : true,
"colorScheme" : "Campbell",
"commandline" : "wsl.exe -d Debian",
"cursorColor" : "#FFFFFF",
"cursorShape" : "bar",
"fontFace" : "Hack",
"fontSize" : 9,
"guid" : "{58ad8b0c-3ef8-5f4d-bc6f-13e4c00f2530}",
"name" : "Debian",
"startingDirectory" : "%USERPROFILE%\\wslhome"
....
```
> 👉 **Note**: To use backslashes in any path field, you'll need to escape them following JSON escaping rules (like shown above). As an alternative, you can use forward slashes ("%USERPROFILE%/wslhome").
The profile GUID is used to reference the default profile in the global settings.
The values for background image stretch mode are documented [here](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.media.stretch)
### Hiding a profile
If you want to remove a profile from the list of profiles in the new tab
dropdown, but keep the profile around in your `profiles.json` file, you can add
the property `"hidden": true` to the profile's json. This can also be used to
remove the default `cmd` and PowerShell profiles, if the user does not wish to
see them.
## Color Schemes
Each scheme defines the color values to be used for various terminal escape sequences.
Each schema is identified by the name field. Examples include
```json
"name" : "Campbell",
"background" : "#0C0C0C",
"black" : "#0C0C0C",
"blue" : "#0037DA",
"foreground" : "#F2F2F2",
"green" : "#13A10E",
"red" : "#C50F1F",
"white" : "#CCCCCC",
"yellow" : "#C19C00"
...
```
The schema name can then be referenced in one or more profiles.
## Settings layering
The runtime settings are actually constructed from _three_ sources:
* The default settings, which are hardcoded into the application, and available
in `defaults.json`. This includes the default keybindings, color schemes, and
profiles for both Windows PowerShell and Command Prompt (`cmd.exe`).
* Dynamic Profiles, which are generated at runtime. These include Powershell
Core, the Azure Cloud Shell connector, and profiles for and WSL distros.
* The user settings from `profiles.json`.
Settings from each of these sources are "layered" upon the settings from
previous sources. In this manner, the user settings in `profiles.json` can
contain _only the changes from the default settings_. For example, if a user
would like to only change the color scheme of the default `cmd` profile to
"Solarized Dark", you could change your cmd profile to the following:
```js
{
// Make changes here to the cmd.exe profile
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"colorScheme": "Solarized Dark"
}
```
Here, we're know we're changing the `cmd` profile, because the `guid`
`"{0caa0dad-35be-5f56-a8ff-afceeeaa6101}"` is `cmd`'s unique GUID. Any profiles
with that GUID will all be treated as the same object. Any changes in that
profile will overwrite those from the defaults.
Similarly, you can overwrite settings from a color scheme by defining a color
scheme in `profiles.json` with the same name as a default color scheme.
If you'd like to unbind a keystroke that's bound to an action in the default
keybindings, you can set the `"command"` to `"unbound"` or `null`. This will
allow the keystroke to fallthough to the commandline application instead of
performing the default action.
### Dynamic Profiles
When dynamic profiles are created at runtime, they'll be added to the
`profiles.json` file. You can identify these profiles by the presence of a
`"source"` property. These profiles are tied to their source - if you uninstall
a linux distro, then the profile will remain in your `profiles.json` file, but
the profile will be hidden.
If you'd like to disable a particular dynamic profile source, you can add that
`source` to the global `"disabledProfileSources"` array. For example, if you'd
like to hide all the WSL profiles, you could add the following setting:
```json
"disabledProfileSources": ["Microsoft.Terminal.WSL"],
...
```
## Configuration Examples:
### Add a custom background to the WSL Debian terminal profile
1. Download the Debian JPG logo https://www.debian.org/logos/openlogo-100.jpg
2. Put the image in the
`$env:LocalAppData\Packages\Microsoft.WindowsTerminal_<randomString>\LocalState\`
directory (same directory as your `profiles.json` file).
__NOTE__: You can put the image anywhere you like, the above suggestion happens to be convenient.
3. Open your WT json properties file.
4. Under the Debian Linux profile, add the following fields:
```json
"backgroundImage": "ms-appdata:///Local/openlogo-100.jpg",
"backgroundImageOpacity": 1,
"backgroundImageStretchMode" : "none",
"backgroundImageAlignment" : "topRight",
```
5. Make sure that `useAcrylic` is `false`.
6. Save the file.
7. Jump over to WT and verify your changes.
Notes:
1. You will need to experiment with different color settings
and schemes to make your terminal text visible on top of your image
2. If you store the image in the UWP directory (the same directory as your profiles.json file),
then you should use the URI style path name given in the above example.
More information about UWP URI schemes [here](https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes).
3. Instead of using a UWP URI you can use a:
1. URL such as
`http://open.esa.int/files/2017/03/Mayer_and_Bond_craters_seen_by_SMART-1-350x346.jpg`
2. Local file location such as `C:\Users\Public\Pictures\openlogo.jpg`
### Adding Copy and Paste Keybindings
As of [#1093](https://github.com/microsoft/terminal/pull/1093) (first available
in Windows Terminal v0.3), the Windows Terminal now supports copy and paste
keyboard shortcuts. However, if you installed and ran the terminal before that,
you won't automatically get the new keybindings added to your settings. If you'd
like to add shortcuts for copy and paste, you can do so by inserting the
following objects into your `globals.keybindings` array:
```json
{ "command": "copy", "keys": ["ctrl+shift+c"] },
{ "command": "paste", "keys": ["ctrl+shift+v"] }
```
This will add copy and paste on <kbd>ctrl+shift+c</kbd>
and <kbd>ctrl+shift+v</kbd> respectively.
You can set the keybindings to whatever you'd like. If you prefer
<kbd>ctrl+c</kbd> to copy, then set the `keys` to `"ctrl+c"`.
You can even set multiple keybindings for a single action if you'd like. For example:
```json
{
"command" : "paste",
"keys" :
[
"ctrl+shift+v"
]
},
{
"command" : "paste",
"keys" :
[
"shift+insert"
]
}
```
will bind both <kbd>ctrl+shift+v</kbd> and
<kbd>shift+Insert</kbd> to `paste`.
Note: If you set your copy keybinding to `"ctrl+c"`, you'll only be able to send
an interrupt to the commandline application using <kbd>Ctrl+C</kbd> when there's
no text selection. Additionally, if you set `paste` to `"ctrl+v"`, commandline
applications won't be able to read a ctrl+v from the input. For these reasons,
we suggest `"ctrl+shift+c"` and `"ctrl+shift+v"`

91
doc/user-docs/index.md Normal file
View File

@@ -0,0 +1,91 @@
# Windows Terminal User Documentation
NOTE: At the time of writing Windows Terminal is still under active development and many things will
change. If you notice an error in the docs, please raise an issue. Or better yet, please file a PR with an appropriate update!
## Installing Windows Terminal
### From Source Code
To compile Windows Terminal yourself using the source code, follow the instructions in the [README](/README.md#developer-guidance).
### From the Microsoft Store
1. Make sure you have upgraded to the current Windows 10 release (at least build `1903`). To determine your build number, see [winver](https://docs.microsoft.com/en-us/windows/client-management/windows-version-search).
2. Open the Windows Terminal listing in the [Microsoft Store](https://aka.ms/install-terminal).
3. Review the minimum system requirements to confirm you can successfully install Windows Terminal.
4. Click `Get` to begin the installation process.
## Starting Windows Terminal
From the Windows Start menu, select Windows Terminal and run the application.
Note: You can right click on the application item and run with Windows Administrator privilege if required.
The default shell is PowerShell.
### Command line options
None at this time. See issue [#607](https://github.com/microsoft/terminal/issues/607)
## Multiple Tabs
Additional shells can be started by hitting the `+` button from the tab bar -- a new instance of the
default shell is displayed (default shortcut `Ctrl+Shift+1`).
## Running a Different Shell
Note: This section assumes you already have _Windows Subsystem for Linux_ (WSL) installed. For more information, see [the installation guide](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
Windows Terminal uses PowerShell as its default shell. You can also use Windows Terminal to launch other shells, such as `cmd.exe` or WSL's `bash`:
1. In the tab bar, click the `⌵` button to view the available shells.
2. Choose your shell from the dropdown list. The new shell session will open in a new tab.
To customize the shell list, see the _Configuring Windows Terminal_ section below.
## Starting a new PowerShell tab with admin privilege
There is no current plan to support this feature for security reasons. See issue [#623](https://github.com/microsoft/terminal/issues/632)
## Using cut and paste in the Terminal window
### With PowerShell
* Copy - Select the text with mouse (default left button), then right click with mouse
* Paste - by default use `<ctrl>+v`>, or right click with mouse
### With Bash
* Copy - Select the text with mouse (default left button), then right click with mouse
* Paste - Right click with mouse
## Add a "Open Windows Terminal Here" to File Explorer
Not currently supported "out of the box". See issue [#1060](https://github.com/microsoft/terminal/issues/1060)
## Configuring Windows Terminal
All Windows Terminal settings are currently managed using the `profiles.json` file, located within `$env:LocalAppData\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe/LocalState`.
To open the settings file from Windows Terminal:
1. Click the `⌵` button in the top bar.
2. From the dropdown list, click `Settings`. You can also use a shortcut: `Ctrl+,`.
3. Your default `json` editor will open the settings file.
For an introduction to the various settings, see [Using Json Settings](UsingJsonSettings.md). The list of valid settings can be found in the [profiles.json documentation](../cascadia/SettingsSchema.md) section.
## Tips and Tricks:
1. In PowerShell you can discover if the Windows Terminal is being used by checking for the existence of the environment variable `WT_SESSION`.
Under pwsh you can also use
`(Get-Process -Id $pid).Parent.Parent.ProcessName -eq 'WindowsTerminal'`
(ref https://twitter.com/r_keith_hill/status/1142871145852440576)
2. Terminal zoom can be changed by holding `Ctrl` and scrolling with mouse.
3. If `useAcrylic` is enabled in profiles.json, background opacity can be changed by holding `Ctrl+Shift` and scrolling with mouse.
4. Please add more Tips and Tricks

View File

@@ -27,7 +27,7 @@ You may ask yourself, why is the destructor deleted, then later defined to the
strangeness that can occur as well, the details of which escape my memory from
when @austdi and I first investigaved this early 2018.
The end result of not defining your interfaces exacly like this will be that
The end result of not defining your interfaces exactly like this will be that
occasionally, when destructing objects, you'll get a segfault.
To check that this behavior works, I direct your attention to the VtIoTests.

BIN
res/Cascadia.ttf Normal file

Binary file not shown.

View File

@@ -1,6 +1,21 @@
# Windows Terminal and Console Assets
The assets in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
## Images
The images in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
of the Windows Terminal code.
Please consult the [license](./LICENSE) in this directory for applicable terms.
Please consult the [license](./LICENSE) in this directory for terms applicable to the image assets in this directory.
## Fonts
The fonts in this directory do not fall under the same [license](https://raw.githubusercontent.com/microsoft/terminal/master/LICENSE) as the rest
of the Windows Terminal code.
Please consult the [license](https://raw.githubusercontent.com/microsoft/cascadia-code/master/LICENSE) in the
[microsoft/cascadia-code](https://github.com/microsoft/cascadia-code) repository for terms applicable to the fonts in this directory.
### Fonts Included
* Cascadia Code
* from microsoft/cascadia-code@5f91b87e12c9af709fa406c22a79145879edc3d2

View File

@@ -18,7 +18,7 @@ namespace MiniTerm
internal static Process Start(string command, IntPtr attributes, IntPtr hPC)
{
var startupInfo = ConfigureProcessThread(hPC, attributes);
var processInfo = RunProcess(ref startupInfo, "cmd.exe");
var processInfo = RunProcess(ref startupInfo, command);
return new Process(startupInfo, processInfo);
}

View File

@@ -1,11 +1,15 @@
<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Console Rules" Description="These rules enforce static analysis on console code." ToolsVersion="15.0">
<Include Path="cppcorecheckrules.ruleset" Action="Default" />
<Include Path="cppcorecheckrules.ruleset" Action="Error" />
<Rules AnalyzerId="Microsoft.Analyzers.NativeCodeAnalysis" RuleNamespace="Microsoft.Rules.Native">
<Rule Id="C6001" Action="Error" />
<Rule Id="C6011" Action="Error" />
<Rules AnalyzerId="Microsoft.Analyzers.NativeCodeAnalysis" RuleNamespace="Microsoft.Rules.Native">
<Rule Id="C6001" Action="Error" />
<Rule Id="C6011" Action="Error" />
<!-- We can't do dynamic cast because RTTI is off. -->
<!-- RTTI is off because Windows OS policies believe RTTI has too much binary size impact for the value and is less portable than RTTI-off modules. -->
<Rule Id="C26466" Action="None" />
</Rules>
</RuleSet>

View File

@@ -46,7 +46,7 @@ void ATTR_ROW::Resize(const size_t newWidth)
{
// Get the attribute that covers the final column of old width.
const auto runPos = FindAttrIndex(_cchRowWidth - 1, nullptr);
auto& run = _list[runPos];
auto& run = _list.at(runPos);
// Extend its length by the additional columns we're adding.
run.SetLength(run.GetLength() + newWidth - _cchRowWidth);
@@ -60,7 +60,7 @@ void ATTR_ROW::Resize(const size_t newWidth)
// Get the attribute that covers the final column of the new width
size_t CountOfAttr = 0;
const auto runPos = FindAttrIndex(newWidth - 1, &CountOfAttr);
auto& run = _list[runPos];
auto& run = _list.at(runPos);
// CountOfAttr was given to us as "how many columns left from this point forward are covered by the returned run"
// So if the original run was B5 covering a 5 size OldWidth and we have a NewWidth of 3
@@ -108,7 +108,7 @@ TextAttribute ATTR_ROW::GetAttrByColumn(const size_t column,
{
THROW_HR_IF(E_INVALIDARG, column >= _cchRowWidth);
const auto runPos = FindAttrIndex(column, pApplies);
return _list[runPos].GetAttributes();
return _list.at(runPos).GetAttributes();
}
// Routine Description:
@@ -290,10 +290,10 @@ void ATTR_ROW::ReplaceAttrs(const TextAttribute& toBeReplacedAttr, const TextAtt
// two elements in our internal list.
else if (_list.size() == 2 && newAttrs.at(0).GetLength() == 1)
{
auto left = _list.begin();
const auto left = _list.begin();
if (iStart == left->GetLength() && NewAttr == left->GetAttributes())
{
auto right = left + 1;
const auto right = left + 1;
left->IncrementLength();
right->DecrementLength();

View File

@@ -6,21 +6,21 @@
#include "AttrRowIterator.hpp"
#include "AttrRow.hpp"
AttrRowIterator AttrRowIterator::CreateEndIterator(const ATTR_ROW* const attrRow)
AttrRowIterator AttrRowIterator::CreateEndIterator(const ATTR_ROW* const attrRow) noexcept
{
AttrRowIterator it{ attrRow };
it._setToEnd();
return it;
}
AttrRowIterator::AttrRowIterator(const ATTR_ROW* const attrRow) :
AttrRowIterator::AttrRowIterator(const ATTR_ROW* const attrRow) noexcept :
_pAttrRow{ attrRow },
_run{ attrRow->_list.cbegin() },
_currentAttributeIndex{ 0 }
{
}
AttrRowIterator::operator bool() const noexcept
AttrRowIterator::operator bool() const
{
return _run < _pAttrRow->_list.cend();
}
@@ -139,7 +139,7 @@ void AttrRowIterator::_decrement(size_t count)
// Routine Description:
// - sets fields on the iterator to describe the end() state of the ATTR_ROW
void AttrRowIterator::_setToEnd()
void AttrRowIterator::_setToEnd() noexcept
{
_run = _pAttrRow->_list.cend();
_currentAttributeIndex = 0;

View File

@@ -29,11 +29,11 @@ public:
using pointer = TextAttribute*;
using reference = TextAttribute&;
static AttrRowIterator CreateEndIterator(const ATTR_ROW* const attrRow);
static AttrRowIterator CreateEndIterator(const ATTR_ROW* const attrRow) noexcept;
AttrRowIterator(const ATTR_ROW* const attrRow);
AttrRowIterator(const ATTR_ROW* const attrRow) noexcept;
operator bool() const noexcept;
operator bool() const;
bool operator==(const AttrRowIterator& it) const;
bool operator!=(const AttrRowIterator& it) const;
@@ -57,5 +57,5 @@ private:
void _increment(size_t count);
void _decrement(size_t count);
void _setToEnd();
void _setToEnd() noexcept;
};

View File

@@ -84,7 +84,7 @@ size_t CharRow::size() const noexcept
// - sRowWidth - The width of the row.
// Return Value:
// - <none>
void CharRow::Reset()
void CharRow::Reset() noexcept
{
for (auto& cell : _data)
{
@@ -209,7 +209,7 @@ const DbcsAttribute& CharRow::DbcsAttrAt(const size_t column) const
// Note: will throw exception if column is out of bounds
DbcsAttribute& CharRow::DbcsAttrAt(const size_t column)
{
return const_cast<DbcsAttribute&>(static_cast<const CharRow* const>(this)->DbcsAttrAt(column));
return _data.at(column).DbcsAttr();
}
// Routine Description:
@@ -250,29 +250,6 @@ CharRow::reference CharRow::GlyphAt(const size_t column)
return { *this, column };
}
// Routine Description:
// - returns string containing text data exactly how it's stored internally, including doubling of
// leading/trailing cells.
// Arguments:
// - none
// Return Value:
// - text stored in char row
// - Note: will throw exception if out of memory
std::wstring CharRow::GetTextRaw() const
{
std::wstring wstr;
wstr.reserve(_data.size());
for (size_t i = 0; i < _data.size(); ++i)
{
auto glyph = GlyphAt(i);
for (auto it = glyph.begin(); it != glyph.end(); ++it)
{
wstr.push_back(*it);
}
}
return wstr;
}
std::wstring CharRow::GetText() const
{
std::wstring wstr;
@@ -280,24 +257,24 @@ std::wstring CharRow::GetText() const
for (size_t i = 0; i < _data.size(); ++i)
{
auto glyph = GlyphAt(i);
const auto glyph = GlyphAt(i);
if (!DbcsAttrAt(i).IsTrailing())
{
for (auto it = glyph.begin(); it != glyph.end(); ++it)
for (const auto wch : glyph)
{
wstr.push_back(*it);
wstr.push_back(wch);
}
}
}
return wstr;
}
UnicodeStorage& CharRow::GetUnicodeStorage()
UnicodeStorage& CharRow::GetUnicodeStorage() noexcept
{
return _pParent->GetUnicodeStorage();
}
const UnicodeStorage& CharRow::GetUnicodeStorage() const
const UnicodeStorage& CharRow::GetUnicodeStorage() const noexcept
{
return _pParent->GetUnicodeStorage();
}
@@ -308,7 +285,7 @@ const UnicodeStorage& CharRow::GetUnicodeStorage() const
// - column - the column to generate the key for
// Return Value:
// - the COORD key for data access from UnicodeStorage for the column
COORD CharRow::GetStorageKey(const size_t column) const
COORD CharRow::GetStorageKey(const size_t column) const noexcept
{
return { gsl::narrow<SHORT>(column), _pParent->GetId() };
}

View File

@@ -53,7 +53,7 @@ public:
void SetDoubleBytePadded(const bool doubleBytePadded) noexcept;
bool WasDoubleBytePadded() const noexcept;
size_t size() const noexcept;
void Reset();
void Reset() noexcept;
[[nodiscard]] HRESULT Resize(const size_t newSize) noexcept;
size_t MeasureLeft() const;
size_t MeasureRight() const noexcept;
@@ -64,9 +64,6 @@ public:
void ClearGlyph(const size_t column);
std::wstring GetText() const;
// other functions implemented at the template class level
std::wstring GetTextRaw() const;
// working with glyphs
const reference GlyphAt(const size_t column) const;
reference GlyphAt(const size_t column);
@@ -78,9 +75,9 @@ public:
iterator end() noexcept;
const_iterator cend() const noexcept;
UnicodeStorage& GetUnicodeStorage();
const UnicodeStorage& GetUnicodeStorage() const;
COORD GetStorageKey(const size_t column) const;
UnicodeStorage& GetUnicodeStorage() noexcept;
const UnicodeStorage& GetUnicodeStorage() const noexcept;
COORD GetStorageKey(const size_t column) const noexcept;
void UpdateParent(ROW* const pParent) noexcept;

View File

@@ -8,13 +8,13 @@
// default glyph value, used for reseting the character data portion of a cell
static constexpr wchar_t DefaultValue = UNICODE_SPACE;
CharRowCell::CharRowCell() :
CharRowCell::CharRowCell() noexcept :
_wch{ DefaultValue },
_attr{}
{
}
CharRowCell::CharRowCell(const wchar_t wch, const DbcsAttribute attr) :
CharRowCell::CharRowCell(const wchar_t wch, const DbcsAttribute attr) noexcept :
_wch{ wch },
_attr{ attr }
{
@@ -22,7 +22,7 @@ CharRowCell::CharRowCell(const wchar_t wch, const DbcsAttribute attr) :
// Routine Description:
// - "erases" the glyph. really sets it back to the default "empty" value
void CharRowCell::EraseChars()
void CharRowCell::EraseChars() noexcept
{
if (_attr.IsGlyphStored())
{

View File

@@ -27,10 +27,10 @@ Author(s):
class CharRowCell final
{
public:
CharRowCell();
CharRowCell(const wchar_t wch, const DbcsAttribute attr);
CharRowCell() noexcept;
CharRowCell(const wchar_t wch, const DbcsAttribute attr) noexcept;
void EraseChars();
void EraseChars() noexcept;
void Reset() noexcept;
bool IsSpace() const noexcept;

View File

@@ -91,6 +91,9 @@ CharRowCellReference::const_iterator CharRowCellReference::begin() const
// - get read-only iterator to the end of the glyph data
// Return Value:
// - end iterator of the glyph data
#pragma warning(push)
#pragma warning(disable : 26481)
// TODO GH 2672: eliminate using pointers raw as begin/end markers in this class
CharRowCellReference::const_iterator CharRowCellReference::end() const
{
if (_cellData().DbcsAttr().IsGlyphStored())
@@ -103,6 +106,7 @@ CharRowCellReference::const_iterator CharRowCellReference::end() const
return &_cellData().Char() + 1;
}
}
#pragma warning(pop)
bool operator==(const CharRowCellReference& ref, const std::vector<wchar_t>& glyph)
{

View File

@@ -25,7 +25,7 @@ class CharRowCellReference final
public:
using const_iterator = const wchar_t*;
CharRowCellReference(CharRow& parent, const size_t index) :
CharRowCellReference(CharRow& parent, const size_t index) noexcept :
_parent{ parent },
_index{ index }
{

View File

@@ -63,7 +63,7 @@ public:
return _glyphStored;
}
void SetGlyphStored(const bool stored)
void SetGlyphStored(const bool stored) noexcept
{
_glyphStored = stored;
}

View File

@@ -11,7 +11,7 @@
static constexpr TextAttribute InvalidTextAttribute{ INVALID_COLOR, INVALID_COLOR };
OutputCell::OutputCell() :
OutputCell::OutputCell() noexcept :
_text{},
_dbcsAttribute{},
_textAttribute{ InvalidTextAttribute },
@@ -111,7 +111,5 @@ void OutputCell::_setFromOutputCellView(const OutputCellView& cell)
_dbcsAttribute = cell.DbcsAttr();
_textAttribute = cell.TextAttr();
_behavior = cell.TextAttrBehavior();
const auto& view = cell.Chars();
_text = view;
_text = cell.Chars();
}

View File

@@ -25,7 +25,7 @@ Author:
class InvalidCharInfoConversionException : public std::exception
{
const char* what() const noexcept
const char* what() const noexcept override
{
return "Cannot convert to CHAR_INFO without explicit TextAttribute";
}
@@ -34,7 +34,7 @@ class InvalidCharInfoConversionException : public std::exception
class OutputCell final
{
public:
OutputCell();
OutputCell() noexcept;
OutputCell(const std::wstring_view charData,
const DbcsAttribute dbcsAttribute,

View File

@@ -17,7 +17,7 @@ static constexpr TextAttribute InvalidTextAttribute{ INVALID_COLOR, INVALID_COLO
// Arguments:
// - wch - The character to use for filling
// - fillLimit - How many times to allow this value to be viewed/filled. Infinite if 0.
OutputCellIterator::OutputCellIterator(const wchar_t& wch, const size_t fillLimit) :
OutputCellIterator::OutputCellIterator(const wchar_t& wch, const size_t fillLimit) noexcept :
_mode(Mode::Fill),
_currentView(s_GenerateView(wch)),
_run(),
@@ -33,7 +33,7 @@ OutputCellIterator::OutputCellIterator(const wchar_t& wch, const size_t fillLimi
// Arguments:
// - attr - The color attribute to use for filling
// - fillLimit - How many times to allow this value to be viewed/filled. Infinite if 0.
OutputCellIterator::OutputCellIterator(const TextAttribute& attr, const size_t fillLimit) :
OutputCellIterator::OutputCellIterator(const TextAttribute& attr, const size_t fillLimit) noexcept :
_mode(Mode::Fill),
_currentView(s_GenerateView(attr)),
_run(),
@@ -50,7 +50,7 @@ OutputCellIterator::OutputCellIterator(const TextAttribute& attr, const size_t f
// - wch - The character to use for filling
// - attr - The color attribute to use for filling
// - fillLimit - How many times to allow this value to be viewed/filled. Infinite if 0.
OutputCellIterator::OutputCellIterator(const wchar_t& wch, const TextAttribute& attr, const size_t fillLimit) :
OutputCellIterator::OutputCellIterator(const wchar_t& wch, const TextAttribute& attr, const size_t fillLimit) noexcept :
_mode(Mode::Fill),
_currentView(s_GenerateView(wch, attr)),
_run(),
@@ -66,7 +66,7 @@ OutputCellIterator::OutputCellIterator(const wchar_t& wch, const TextAttribute&
// Arguments:
// - charInfo - The legacy character and color data to use for fililng (uses Unicode portion of text data)
// - fillLimit - How many times to allow this value to be viewed/filled. Infinite if 0.
OutputCellIterator::OutputCellIterator(const CHAR_INFO& charInfo, const size_t fillLimit) :
OutputCellIterator::OutputCellIterator(const CHAR_INFO& charInfo, const size_t fillLimit) noexcept :
_mode(Mode::Fill),
_currentView(s_GenerateView(charInfo)),
_run(),
@@ -116,7 +116,12 @@ OutputCellIterator::OutputCellIterator(const std::wstring_view utf16Text, const
// razzle cannot distinguish between a std::wstring_view and a std::basic_string_view<WORD>
// NOTE: This one internally casts to wchar_t because Razzle sees WORD and wchar_t as the same type
// despite that Visual Studio build can tell the difference.
OutputCellIterator::OutputCellIterator(const std::basic_string_view<WORD> legacyAttrs, const bool /*unused*/) :
#pragma warning(push)
#pragma warning(suppress : 26490)
// Suppresses reinterpret_cast. We're only doing this because Windows doesn't understand the type difference between wchar_t and DWORD.
// It is not worth trying to separate that out further or risking performance over this particular warning here.
// TODO GH 2673 - Investigate real wchar_t flag in Windows and resolve this audit issue
OutputCellIterator::OutputCellIterator(const std::basic_string_view<WORD> legacyAttrs, const bool /*unused*/) noexcept :
_mode(Mode::LegacyAttr),
_currentView(s_GenerateViewLegacyAttr(legacyAttrs.at(0))),
_run(std::wstring_view(reinterpret_cast<const wchar_t*>(legacyAttrs.data()), legacyAttrs.size())),
@@ -126,12 +131,13 @@ OutputCellIterator::OutputCellIterator(const std::basic_string_view<WORD> legacy
_fillLimit(0)
{
}
#pragma warning(pop)
// Routine Description:
// - This is an iterator over legacy cell data. We will use the unicode text and the legacy color attribute.
// Arguments:
// - charInfos - Multiple cell with unicode text and legacy color data.
OutputCellIterator::OutputCellIterator(const std::basic_string_view<CHAR_INFO> charInfos) :
OutputCellIterator::OutputCellIterator(const std::basic_string_view<CHAR_INFO> charInfos) noexcept :
_mode(Mode::CharInfo),
_currentView(s_GenerateView(charInfos.at(0))),
_run(charInfos),
@@ -315,7 +321,7 @@ OutputCellIterator OutputCellIterator::operator++(int)
// - Reference the view to fully-formed output cell data representing the underlying data source.
// Return Value:
// - Reference to the view
const OutputCellView& OutputCellIterator::operator*() const
const OutputCellView& OutputCellIterator::operator*() const noexcept
{
return _currentView;
}
@@ -324,7 +330,7 @@ const OutputCellView& OutputCellIterator::operator*() const
// - Get pointer to the view to fully-formed output cell data representing the underlying data source.
// Return Value:
// - Pointer to the view
const OutputCellView* OutputCellIterator::operator->() const
const OutputCellView* OutputCellIterator::operator->() const noexcept
{
return &_currentView;
}
@@ -338,7 +344,7 @@ const OutputCellView* OutputCellIterator::operator->() const
// - True if we just turned a lead half into a trailing half (and caller doesn't
// need to further update the view).
// - False if this wasn't applicable and the caller should update the view.
bool OutputCellIterator::_TryMoveTrailing()
bool OutputCellIterator::_TryMoveTrailing() noexcept
{
if (_currentView.DbcsAttr().IsLeading())
{
@@ -421,7 +427,7 @@ OutputCellView OutputCellIterator::s_GenerateView(const std::wstring_view view,
// - wch - View representing a single UTF-16 character (that can be represented without surrogates)
// Return Value:
// - Object representing the view into this cell
OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch)
OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch) noexcept
{
const auto glyph = std::wstring_view(&wch, 1);
@@ -443,7 +449,7 @@ OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch)
// - attr - View representing a single color
// Return Value:
// - Object representing the view into this cell
OutputCellView OutputCellIterator::s_GenerateView(const TextAttribute& attr)
OutputCellView OutputCellIterator::s_GenerateView(const TextAttribute& attr) noexcept
{
return OutputCellView({}, {}, attr, TextAttributeBehavior::StoredOnly);
}
@@ -458,7 +464,7 @@ OutputCellView OutputCellIterator::s_GenerateView(const TextAttribute& attr)
// - attr - View representing a single color
// Return Value:
// - Object representing the view into this cell
OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch, const TextAttribute& attr)
OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch, const TextAttribute& attr) noexcept
{
const auto glyph = std::wstring_view(&wch, 1);
@@ -480,12 +486,12 @@ OutputCellView OutputCellIterator::s_GenerateView(const wchar_t& wch, const Text
// - legacyAttr - View representing a single legacy color
// Return Value:
// - Object representing the view into this cell
OutputCellView OutputCellIterator::s_GenerateViewLegacyAttr(const WORD& legacyAttr)
OutputCellView OutputCellIterator::s_GenerateViewLegacyAttr(const WORD& legacyAttr) noexcept
{
WORD cleanAttr = legacyAttr;
WI_ClearAllFlags(cleanAttr, COMMON_LVB_SBCSDBCS); // don't use legacy lead/trailing byte flags for colors
TextAttribute attr(cleanAttr);
const TextAttribute attr(cleanAttr);
return s_GenerateView(attr);
}
@@ -498,7 +504,7 @@ OutputCellView OutputCellIterator::s_GenerateViewLegacyAttr(const WORD& legacyAt
// - charInfo - character and attribute pair representing a single cell
// Return Value:
// - Object representing the view into this cell
OutputCellView OutputCellIterator::s_GenerateView(const CHAR_INFO& charInfo)
OutputCellView OutputCellIterator::s_GenerateView(const CHAR_INFO& charInfo) noexcept
{
const auto glyph = std::wstring_view(&charInfo.Char.UnicodeChar, 1);

View File

@@ -33,14 +33,14 @@ public:
using pointer = OutputCellView*;
using reference = OutputCellView&;
OutputCellIterator(const wchar_t& wch, const size_t fillLimit = 0);
OutputCellIterator(const TextAttribute& attr, const size_t fillLimit = 0);
OutputCellIterator(const wchar_t& wch, const TextAttribute& attr, const size_t fillLimit = 0);
OutputCellIterator(const CHAR_INFO& charInfo, const size_t fillLimit = 0);
OutputCellIterator(const wchar_t& wch, const size_t fillLimit = 0) noexcept;
OutputCellIterator(const TextAttribute& attr, const size_t fillLimit = 0) noexcept;
OutputCellIterator(const wchar_t& wch, const TextAttribute& attr, const size_t fillLimit = 0) noexcept;
OutputCellIterator(const CHAR_INFO& charInfo, const size_t fillLimit = 0) noexcept;
OutputCellIterator(const std::wstring_view utf16Text);
OutputCellIterator(const std::wstring_view utf16Text, const TextAttribute attribute);
OutputCellIterator(const std::basic_string_view<WORD> legacyAttributes, const bool unused);
OutputCellIterator(const std::basic_string_view<CHAR_INFO> charInfos);
OutputCellIterator(const std::basic_string_view<WORD> legacyAttributes, const bool unused) noexcept;
OutputCellIterator(const std::basic_string_view<CHAR_INFO> charInfos) noexcept;
OutputCellIterator(const std::basic_string_view<OutputCell> cells);
~OutputCellIterator() = default;
@@ -55,8 +55,8 @@ public:
OutputCellIterator& operator++();
OutputCellIterator operator++(int);
const OutputCellView& operator*() const;
const OutputCellView* operator->() const;
const OutputCellView& operator*() const noexcept;
const OutputCellView* operator->() const noexcept;
private:
enum class Mode
@@ -97,7 +97,7 @@ private:
TextAttribute _attr;
bool _TryMoveTrailing();
bool _TryMoveTrailing() noexcept;
static OutputCellView s_GenerateView(const std::wstring_view view);
@@ -108,11 +108,11 @@ private:
const TextAttribute attr,
const TextAttributeBehavior behavior);
static OutputCellView s_GenerateView(const wchar_t& wch);
static OutputCellView s_GenerateViewLegacyAttr(const WORD& legacyAttr);
static OutputCellView s_GenerateView(const TextAttribute& attr);
static OutputCellView s_GenerateView(const wchar_t& wch, const TextAttribute& attr);
static OutputCellView s_GenerateView(const CHAR_INFO& charInfo);
static OutputCellView s_GenerateView(const wchar_t& wch) noexcept;
static OutputCellView s_GenerateViewLegacyAttr(const WORD& legacyAttr) noexcept;
static OutputCellView s_GenerateView(const TextAttribute& attr) noexcept;
static OutputCellView s_GenerateView(const wchar_t& wch, const TextAttribute& attr) noexcept;
static OutputCellView s_GenerateView(const CHAR_INFO& charInfo) noexcept;
static OutputCellView s_GenerateView(const OutputCell& cell);

View File

@@ -7,7 +7,7 @@
// Routine Description:
// - Constucts an empty in-memory region for holding output buffer cell data.
OutputCellRect::OutputCellRect() :
OutputCellRect::OutputCellRect() noexcept :
_rows(0),
_cols(0)
{
@@ -64,7 +64,7 @@ OutputCellIterator OutputCellRect::GetRowIter(const size_t row) const
// - Pointer to the location in the rectangle that represents the start of the requested row.
OutputCell* OutputCellRect::_FindRowOffset(const size_t row)
{
return (_storage.data() + (row * _cols));
return &_storage.at(row * _cols);
}
// Routine Description:
@@ -76,7 +76,7 @@ OutputCell* OutputCellRect::_FindRowOffset(const size_t row)
// - Pointer to the location in the rectangle that represents the start of the requested row.
const OutputCell* OutputCellRect::_FindRowOffset(const size_t row) const
{
return (_storage.data() + (row * _cols));
return &_storage.at(row * _cols);
}
// Routine Description:

View File

@@ -29,7 +29,7 @@ Revision History:
class OutputCellRect final
{
public:
OutputCellRect();
OutputCellRect() noexcept;
OutputCellRect(const size_t rows, const size_t cols);
gsl::span<OutputCell> GetRow(const size_t row);

View File

@@ -15,7 +15,7 @@
OutputCellView::OutputCellView(const std::wstring_view view,
const DbcsAttribute dbcsAttr,
const TextAttribute textAttr,
const TextAttributeBehavior behavior) :
const TextAttributeBehavior behavior) noexcept :
_view(view),
_dbcsAttr(dbcsAttr),
_textAttr(textAttr),
@@ -27,7 +27,9 @@ OutputCellView::OutputCellView(const std::wstring_view view,
// - Returns reference to view over text data
// Return Value:
// - Reference to UTF-16 character data
const std::wstring_view& OutputCellView::Chars() const noexcept
// C26445 - suppressed to enable the `TextBufferTextIterator::operator->` method which needs a non-temporary memory location holding the wstring_view.
// TODO: GH 2681 - remove this suppression by reconciling the probably bad design of the iterators that leads to this being required.
[[gsl::suppress(26445)]] const std::wstring_view& OutputCellView::Chars() const noexcept
{
return _view;
}

View File

@@ -28,7 +28,7 @@ public:
OutputCellView(const std::wstring_view view,
const DbcsAttribute dbcsAttr,
const TextAttribute textAttr,
const TextAttributeBehavior behavior);
const TextAttributeBehavior behavior) noexcept;
const std::wstring_view& Chars() const noexcept;
size_t Columns() const noexcept;

View File

@@ -30,14 +30,14 @@ size_t ROW::size() const noexcept
return _rowWidth;
}
const CharRow& ROW::GetCharRow() const
const CharRow& ROW::GetCharRow() const noexcept
{
return _charRow;
}
CharRow& ROW::GetCharRow()
CharRow& ROW::GetCharRow() noexcept
{
return const_cast<CharRow&>(static_cast<const ROW* const>(this)->GetCharRow());
return _charRow;
}
const ATTR_ROW& ROW::GetAttrRow() const noexcept
@@ -47,7 +47,7 @@ const ATTR_ROW& ROW::GetAttrRow() const noexcept
ATTR_ROW& ROW::GetAttrRow() noexcept
{
return const_cast<ATTR_ROW&>(static_cast<const ROW* const>(this)->GetAttrRow());
return _attrRow;
}
SHORT ROW::GetId() const noexcept
@@ -132,12 +132,12 @@ RowCellIterator ROW::AsCellIter(const size_t startIndex, const size_t count) con
return RowCellIterator(*this, startIndex, count);
}
UnicodeStorage& ROW::GetUnicodeStorage()
UnicodeStorage& ROW::GetUnicodeStorage() noexcept
{
return _pParent->GetUnicodeStorage();
}
const UnicodeStorage& ROW::GetUnicodeStorage() const
const UnicodeStorage& ROW::GetUnicodeStorage() const noexcept
{
return _pParent->GetUnicodeStorage();
}

View File

@@ -36,8 +36,8 @@ public:
size_t size() const noexcept;
const CharRow& GetCharRow() const;
CharRow& GetCharRow();
const CharRow& GetCharRow() const noexcept;
CharRow& GetCharRow() noexcept;
const ATTR_ROW& GetAttrRow() const noexcept;
ATTR_ROW& GetAttrRow() noexcept;
@@ -54,8 +54,8 @@ public:
RowCellIterator AsCellIter(const size_t startIndex) const;
RowCellIterator AsCellIter(const size_t startIndex, const size_t count) const;
UnicodeStorage& GetUnicodeStorage();
const UnicodeStorage& GetUnicodeStorage() const;
UnicodeStorage& GetUnicodeStorage() noexcept;
const UnicodeStorage& GetUnicodeStorage() const noexcept;
OutputCellIterator WriteCells(OutputCellIterator it, const size_t index, const bool setWrap, std::optional<size_t> limitRight = std::nullopt);

View File

@@ -37,38 +37,38 @@ bool RowCellIterator::operator!=(const RowCellIterator& it) const noexcept
return !(*this == it);
}
RowCellIterator& RowCellIterator::operator+=(const ptrdiff_t& movement)
RowCellIterator& RowCellIterator::operator+=(const ptrdiff_t& movement) noexcept
{
_pos += movement;
return (*this);
}
RowCellIterator& RowCellIterator::operator++()
RowCellIterator& RowCellIterator::operator++() noexcept
{
return this->operator+=(1);
}
RowCellIterator RowCellIterator::operator++(int)
RowCellIterator RowCellIterator::operator++(int) noexcept
{
auto temp(*this);
operator++();
return temp;
}
RowCellIterator RowCellIterator::operator+(const ptrdiff_t& movement)
RowCellIterator RowCellIterator::operator+(const ptrdiff_t& movement) noexcept
{
auto temp(*this);
temp += movement;
return temp;
}
const OutputCellView& RowCellIterator::operator*() const
const OutputCellView& RowCellIterator::operator*() const noexcept
{
return _view;
}
const OutputCellView* RowCellIterator::operator->() const
const OutputCellView* RowCellIterator::operator->() const noexcept
{
return &_view;
}

View File

@@ -38,13 +38,13 @@ public:
bool operator==(const RowCellIterator& it) const noexcept;
bool operator!=(const RowCellIterator& it) const noexcept;
RowCellIterator& operator+=(const ptrdiff_t& movement);
RowCellIterator& operator++();
RowCellIterator operator++(int);
RowCellIterator operator+(const ptrdiff_t& movement);
RowCellIterator& operator+=(const ptrdiff_t& movement) noexcept;
RowCellIterator& operator++() noexcept;
RowCellIterator operator++(int) noexcept;
RowCellIterator operator+(const ptrdiff_t& movement) noexcept;
const OutputCellView& operator*() const;
const OutputCellView* operator->() const;
const OutputCellView& operator*() const noexcept;
const OutputCellView* operator->() const noexcept;
private:
const ROW& _row;

View File

@@ -16,7 +16,7 @@ bool TextAttribute::IsLegacy() const noexcept
// - color that should be displayed as the foreground color
COLORREF TextAttribute::CalculateRgbForeground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultFgColor,
COLORREF defaultBgColor) const
COLORREF defaultBgColor) const noexcept
{
return _IsReverseVideo() ? _GetRgbBackground(colorTable, defaultBgColor) : _GetRgbForeground(colorTable, defaultFgColor);
}
@@ -29,7 +29,7 @@ COLORREF TextAttribute::CalculateRgbForeground(std::basic_string_view<COLORREF>
// - color that should be displayed as the background color
COLORREF TextAttribute::CalculateRgbBackground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultFgColor,
COLORREF defaultBgColor) const
COLORREF defaultBgColor) const noexcept
{
return _IsReverseVideo() ? _GetRgbForeground(colorTable, defaultFgColor) : _GetRgbBackground(colorTable, defaultBgColor);
}
@@ -42,7 +42,7 @@ COLORREF TextAttribute::CalculateRgbBackground(std::basic_string_view<COLORREF>
// Return Value:
// - color that is stored as the foreground color
COLORREF TextAttribute::_GetRgbForeground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultColor) const
COLORREF defaultColor) const noexcept
{
return _foreground.GetColor(colorTable, defaultColor, _isBold);
}
@@ -55,7 +55,7 @@ COLORREF TextAttribute::_GetRgbForeground(std::basic_string_view<COLORREF> color
// Return Value:
// - color that is stored as the background color
COLORREF TextAttribute::_GetRgbBackground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultColor) const
COLORREF defaultColor) const noexcept
{
return _background.GetColor(colorTable, defaultColor, false);
}
@@ -75,22 +75,22 @@ WORD TextAttribute::GetMetaAttributes() const noexcept
return wMeta;
}
void TextAttribute::SetForeground(const COLORREF rgbForeground)
void TextAttribute::SetForeground(const COLORREF rgbForeground) noexcept
{
_foreground = TextColor(rgbForeground);
}
void TextAttribute::SetBackground(const COLORREF rgbBackground)
void TextAttribute::SetBackground(const COLORREF rgbBackground) noexcept
{
_background = TextColor(rgbBackground);
}
void TextAttribute::SetFromLegacy(const WORD wLegacy) noexcept
{
_wAttrLegacy = static_cast<WORD>(wLegacy & META_ATTRS);
_wAttrLegacy = gsl::narrow_cast<WORD>(wLegacy & META_ATTRS);
WI_ClearAllFlags(_wAttrLegacy, COMMON_LVB_SBCSDBCS);
BYTE fgIndex = static_cast<BYTE>(wLegacy & FG_ATTRS);
BYTE bgIndex = static_cast<BYTE>(wLegacy & BG_ATTRS) >> 4;
const BYTE fgIndex = gsl::narrow_cast<BYTE>(wLegacy & FG_ATTRS);
const BYTE bgIndex = gsl::narrow_cast<BYTE>(wLegacy & BG_ATTRS) >> 4;
_foreground = TextColor(fgIndex);
_background = TextColor(bgIndex);
}
@@ -98,16 +98,16 @@ void TextAttribute::SetFromLegacy(const WORD wLegacy) noexcept
void TextAttribute::SetLegacyAttributes(const WORD attrs,
const bool setForeground,
const bool setBackground,
const bool setMeta)
const bool setMeta) noexcept
{
if (setForeground)
{
BYTE fgIndex = (BYTE)(attrs & FG_ATTRS);
const BYTE fgIndex = gsl::narrow_cast<BYTE>(attrs & FG_ATTRS);
_foreground = TextColor(fgIndex);
}
if (setBackground)
{
BYTE bgIndex = (BYTE)(attrs & BG_ATTRS) >> 4;
const BYTE bgIndex = gsl::narrow_cast<BYTE>(attrs & BG_ATTRS) >> 4;
_background = TextColor(bgIndex);
}
if (setMeta)
@@ -133,17 +133,17 @@ void TextAttribute::SetIndexedAttributes(const std::optional<const BYTE> foregro
{
if (foreground)
{
BYTE fgIndex = (*foreground) & 0xFF;
const BYTE fgIndex = (*foreground) & 0xFF;
_foreground = TextColor(fgIndex);
}
if (background)
{
BYTE bgIndex = (*background) & 0xFF;
const BYTE bgIndex = (*background) & 0xFF;
_background = TextColor(bgIndex);
}
}
void TextAttribute::SetColor(const COLORREF rgbColor, const bool fIsForeground)
void TextAttribute::SetColor(const COLORREF rgbColor, const bool fIsForeground) noexcept
{
if (fIsForeground)
{

View File

@@ -39,9 +39,9 @@ public:
}
constexpr TextAttribute(const WORD wLegacyAttr) noexcept :
_wAttrLegacy{ static_cast<WORD>(wLegacyAttr & META_ATTRS) },
_foreground{ static_cast<BYTE>(wLegacyAttr & FG_ATTRS) },
_background{ static_cast<BYTE>((wLegacyAttr & BG_ATTRS) >> 4) },
_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) },
_isBold{ false }
{
// If we're given lead/trailing byte information with the legacy color, strip it.
@@ -59,9 +59,9 @@ public:
constexpr WORD GetLegacyAttributes() const noexcept
{
BYTE fg = (_foreground.GetIndex() & FG_ATTRS);
BYTE bg = (_background.GetIndex() << 4) & BG_ATTRS;
WORD meta = (_wAttrLegacy & META_ATTRS);
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);
}
@@ -80,20 +80,20 @@ public:
constexpr WORD GetLegacyAttributes(const BYTE defaultFgIndex,
const BYTE defaultBgIndex) const noexcept
{
BYTE fgIndex = _foreground.IsLegacy() ? _foreground.GetIndex() : defaultFgIndex;
BYTE bgIndex = _background.IsLegacy() ? _background.GetIndex() : defaultBgIndex;
BYTE fg = (fgIndex & FG_ATTRS);
BYTE bg = (bgIndex << 4) & BG_ATTRS;
WORD meta = (_wAttrLegacy & META_ATTRS);
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);
}
COLORREF CalculateRgbForeground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultFgColor,
COLORREF defaultBgColor) const;
COLORREF defaultBgColor) const noexcept;
COLORREF CalculateRgbBackground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultFgColor,
COLORREF defaultBgColor) const;
COLORREF defaultBgColor) const noexcept;
bool IsLeadingByte() const noexcept;
bool IsTrailingByte() const noexcept;
@@ -110,7 +110,7 @@ public:
void SetLegacyAttributes(const WORD attrs,
const bool setForeground,
const bool setBackground,
const bool setMeta);
const bool setMeta) noexcept;
void SetIndexedAttributes(const std::optional<const BYTE> foreground,
const std::optional<const BYTE> background) noexcept;
@@ -133,9 +133,9 @@ public:
bool IsLegacy() const noexcept;
bool IsBold() const noexcept;
void SetForeground(const COLORREF rgbForeground);
void SetBackground(const COLORREF rgbBackground);
void SetColor(const COLORREF rgbColor, const bool fIsForeground);
void SetForeground(const COLORREF rgbForeground) noexcept;
void SetBackground(const COLORREF rgbBackground) noexcept;
void SetColor(const COLORREF rgbColor, const bool fIsForeground) noexcept;
void SetDefaultForeground() noexcept;
void SetDefaultBackground() noexcept;
@@ -150,9 +150,9 @@ public:
private:
COLORREF _GetRgbForeground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultColor) const;
COLORREF defaultColor) const noexcept;
COLORREF _GetRgbBackground(std::basic_string_view<COLORREF> colorTable,
COLORREF defaultColor) const;
COLORREF defaultColor) const noexcept;
bool _IsReverseVideo() const noexcept;
void _SetBoldness(const bool isBold) noexcept;

View File

@@ -11,7 +11,7 @@
// - rgbColor: the COLORREF containing the color information for this TextColor
// Return Value:
// - <none>
void TextColor::SetColor(const COLORREF rgbColor)
void TextColor::SetColor(const COLORREF rgbColor) noexcept
{
_meta = ColorType::IsRgb;
_red = GetRValue(rgbColor);
@@ -25,7 +25,7 @@ void TextColor::SetColor(const COLORREF rgbColor)
// - index: the index of the colortable we should use for this TextColor.
// Return Value:
// - <none>
void TextColor::SetIndex(const BYTE index)
void TextColor::SetIndex(const BYTE index) noexcept
{
_meta = ColorType::IsIndex;
_index = index;
@@ -38,7 +38,7 @@ void TextColor::SetIndex(const BYTE index)
// - <none>
// Return Value:
// - <none>
void TextColor::SetDefault()
void TextColor::SetDefault() noexcept
{
_meta = ColorType::IsDefault;
}
@@ -63,7 +63,7 @@ void TextColor::SetDefault()
// - a COLORREF containing the real value of this TextColor.
COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
const COLORREF defaultColor,
bool brighten) const
bool brighten) const noexcept
{
if (IsDefault())
{
@@ -81,9 +81,9 @@ COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
// If we find a match, return instead the bright version of this color
for (size_t i = 0; i < 8; i++)
{
if (colorTable[i] == defaultColor)
if (colorTable.at(i) == defaultColor)
{
return colorTable[i + 8];
return colorTable.at(i + 8);
}
}
}
@@ -102,12 +102,12 @@ COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
if (brighten && _index < 8)
{
FAIL_FAST_IF(colorTable.size() < 16);
FAIL_FAST_IF((size_t)(_index + 8) > (size_t)(colorTable.size()));
return colorTable[_index + 8];
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[_index];
return colorTable.at(_index);
}
}
}
@@ -119,7 +119,7 @@ COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
// - <none>
// Return Value:
// - a COLORREF containing our stored value
COLORREF TextColor::_GetRGB() const
COLORREF TextColor::_GetRGB() const noexcept
{
return RGB(_red, _green, _blue);
}

View File

@@ -91,13 +91,13 @@ public:
return _meta == ColorType::IsRgb;
}
void SetColor(const COLORREF rgbColor);
void SetIndex(const BYTE index);
void SetDefault();
void SetColor(const COLORREF rgbColor) noexcept;
void SetIndex(const BYTE index) noexcept;
void SetDefault() noexcept;
COLORREF GetColor(std::basic_string_view<COLORREF> colorTable,
const COLORREF defaultColor,
const bool brighten) const;
const bool brighten) const noexcept;
constexpr BYTE GetIndex() const noexcept
{
@@ -113,7 +113,7 @@ private:
BYTE _green;
BYTE _blue;
COLORREF _GetRGB() const;
COLORREF _GetRGB() const noexcept;
#ifdef UNIT_TESTING
friend class TextBufferTests;

View File

@@ -4,7 +4,7 @@
#include "precomp.h"
#include "UnicodeStorage.hpp"
UnicodeStorage::UnicodeStorage() :
UnicodeStorage::UnicodeStorage() noexcept :
_map{}
{
}
@@ -35,7 +35,7 @@ void UnicodeStorage::StoreGlyph(const key_type key, const mapped_type& glyph)
// - erases key and its associated data from the storage
// Arguments:
// - key - the key to remove
void UnicodeStorage::Erase(const key_type key) noexcept
void UnicodeStorage::Erase(const key_type key)
{
_map.erase(key);
}

View File

@@ -47,13 +47,13 @@ public:
using key_type = typename COORD;
using mapped_type = typename std::vector<wchar_t>;
UnicodeStorage();
UnicodeStorage() noexcept;
const mapped_type& GetText(const key_type key) const;
void StoreGlyph(const key_type key, const mapped_type& glyph);
void Erase(const key_type key) noexcept;
void Erase(const key_type key);
void Remap(const std::map<SHORT, SHORT>& rowMap, const std::optional<SHORT> width);

View File

@@ -11,7 +11,7 @@
// - Constructor to set default properties for Cursor
// Arguments:
// - ulSize - The height of the cursor within this buffer
Cursor::Cursor(const ULONG ulSize, TextBuffer& parentBuffer) :
Cursor::Cursor(const ULONG ulSize, TextBuffer& parentBuffer) noexcept :
_parentBuffer{ parentBuffer },
_cPosition{ 0 },
_fHasMoved(false),
@@ -87,36 +87,36 @@ ULONG Cursor::GetSize() const noexcept
return _ulSize;
}
void Cursor::SetHasMoved(const bool fHasMoved)
void Cursor::SetHasMoved(const bool fHasMoved) noexcept
{
_fHasMoved = fHasMoved;
}
void Cursor::SetIsVisible(const bool fIsVisible)
void Cursor::SetIsVisible(const bool fIsVisible) noexcept
{
_fIsVisible = fIsVisible;
_RedrawCursor();
}
void Cursor::SetIsOn(const bool fIsOn)
void Cursor::SetIsOn(const bool fIsOn) noexcept
{
_fIsOn = fIsOn;
_RedrawCursorAlways();
}
void Cursor::SetBlinkingAllowed(const bool fBlinkingAllowed)
void Cursor::SetBlinkingAllowed(const bool fBlinkingAllowed) noexcept
{
_fBlinkingAllowed = fBlinkingAllowed;
_RedrawCursorAlways();
}
void Cursor::SetIsDouble(const bool fIsDouble)
void Cursor::SetIsDouble(const bool fIsDouble) noexcept
{
_fIsDouble = fIsDouble;
_RedrawCursor();
}
void Cursor::SetIsConversionArea(const bool fIsConversionArea)
void Cursor::SetIsConversionArea(const bool fIsConversionArea) noexcept
{
// Functionally the same as "Hide cursor"
// Never called with TRUE, it's only used in the creation of a
@@ -125,19 +125,19 @@ void Cursor::SetIsConversionArea(const bool fIsConversionArea)
_RedrawCursorAlways();
}
void Cursor::SetIsPopupShown(const bool fIsPopupShown)
void Cursor::SetIsPopupShown(const bool fIsPopupShown) noexcept
{
// Functionally the same as "Hide cursor"
_fIsPopupShown = fIsPopupShown;
_RedrawCursorAlways();
}
void Cursor::SetDelay(const bool fDelay)
void Cursor::SetDelay(const bool fDelay) noexcept
{
_fDelay = fDelay;
}
void Cursor::SetSize(const ULONG ulSize)
void Cursor::SetSize(const ULONG ulSize) noexcept
{
_ulSize = ulSize;
_RedrawCursor();
@@ -195,7 +195,7 @@ void Cursor::_RedrawCursorAlways() noexcept
CATCH_LOG();
}
void Cursor::SetPosition(const COORD cPosition)
void Cursor::SetPosition(const COORD cPosition) noexcept
{
_RedrawCursor();
_cPosition.X = cPosition.X;
@@ -204,50 +204,50 @@ void Cursor::SetPosition(const COORD cPosition)
ResetDelayEOLWrap();
}
void Cursor::SetXPosition(const int NewX)
void Cursor::SetXPosition(const int NewX) noexcept
{
_RedrawCursor();
_cPosition.X = (SHORT)NewX;
_cPosition.X = gsl::narrow<SHORT>(NewX);
_RedrawCursor();
ResetDelayEOLWrap();
}
void Cursor::SetYPosition(const int NewY)
void Cursor::SetYPosition(const int NewY) noexcept
{
_RedrawCursor();
_cPosition.Y = (SHORT)NewY;
_cPosition.Y = gsl::narrow<SHORT>(NewY);
_RedrawCursor();
ResetDelayEOLWrap();
}
void Cursor::IncrementXPosition(const int DeltaX)
void Cursor::IncrementXPosition(const int DeltaX) noexcept
{
_RedrawCursor();
_cPosition.X += (SHORT)DeltaX;
_cPosition.X += gsl::narrow<SHORT>(DeltaX);
_RedrawCursor();
ResetDelayEOLWrap();
}
void Cursor::IncrementYPosition(const int DeltaY)
void Cursor::IncrementYPosition(const int DeltaY) noexcept
{
_RedrawCursor();
_cPosition.Y += (SHORT)DeltaY;
_cPosition.Y += gsl::narrow<SHORT>(DeltaY);
_RedrawCursor();
ResetDelayEOLWrap();
}
void Cursor::DecrementXPosition(const int DeltaX)
void Cursor::DecrementXPosition(const int DeltaX) noexcept
{
_RedrawCursor();
_cPosition.X -= (SHORT)DeltaX;
_cPosition.X -= gsl::narrow<SHORT>(DeltaX);
_RedrawCursor();
ResetDelayEOLWrap();
}
void Cursor::DecrementYPosition(const int DeltaY)
void Cursor::DecrementYPosition(const int DeltaY) noexcept
{
_RedrawCursor();
_cPosition.Y -= (SHORT)DeltaY;
_cPosition.Y -= gsl::narrow<SHORT>(DeltaY);
_RedrawCursor();
ResetDelayEOLWrap();
}
@@ -262,7 +262,7 @@ void Cursor::DecrementYPosition(const int DeltaY)
// - OtherCursor - The cursor to copy properties from
// Return Value:
// - <none>
void Cursor::CopyProperties(const Cursor& OtherCursor)
void Cursor::CopyProperties(const Cursor& OtherCursor) noexcept
{
// We shouldn't copy the position as it will be already rearranged by the resize operation.
//_cPosition = pOtherCursor->_cPosition;
@@ -288,34 +288,34 @@ void Cursor::CopyProperties(const Cursor& OtherCursor)
_color = OtherCursor._color;
}
void Cursor::DelayEOLWrap(const COORD coordDelayedAt)
void Cursor::DelayEOLWrap(const COORD coordDelayedAt) noexcept
{
_coordDelayedAt = coordDelayedAt;
_fDelayedEolWrap = true;
}
void Cursor::ResetDelayEOLWrap()
void Cursor::ResetDelayEOLWrap() noexcept
{
_coordDelayedAt = { 0 };
_fDelayedEolWrap = false;
}
COORD Cursor::GetDelayedAtPosition() const
COORD Cursor::GetDelayedAtPosition() const noexcept
{
return _coordDelayedAt;
}
bool Cursor::IsDelayedEOLWrap() const
bool Cursor::IsDelayedEOLWrap() const noexcept
{
return _fDelayedEolWrap;
}
void Cursor::StartDeferDrawing()
void Cursor::StartDeferDrawing() noexcept
{
_fDeferCursorRedraw = true;
}
void Cursor::EndDeferDrawing()
void Cursor::EndDeferDrawing() noexcept
{
if (_fHaveDeferredCursorRedraw)
{
@@ -325,27 +325,27 @@ void Cursor::EndDeferDrawing()
_fDeferCursorRedraw = FALSE;
}
const CursorType Cursor::GetType() const
const CursorType Cursor::GetType() const noexcept
{
return _cursorType;
}
const bool Cursor::IsUsingColor() const
const bool Cursor::IsUsingColor() const noexcept
{
return GetColor() != INVALID_COLOR;
}
const COLORREF Cursor::GetColor() const
const COLORREF Cursor::GetColor() const noexcept
{
return _color;
}
void Cursor::SetColor(const unsigned int color)
void Cursor::SetColor(const unsigned int color) noexcept
{
_color = (COLORREF)color;
_color = gsl::narrow_cast<COLORREF>(color);
}
void Cursor::SetType(const CursorType type)
void Cursor::SetType(const CursorType type) noexcept
{
_cursorType = type;
}

View File

@@ -28,7 +28,7 @@ class Cursor final
public:
static const unsigned int s_InvertCursorColor = INVALID_COLOR;
Cursor(const ULONG ulSize, TextBuffer& parentBuffer);
Cursor(const ULONG ulSize, TextBuffer& parentBuffer) noexcept;
~Cursor();
@@ -50,41 +50,41 @@ public:
ULONG GetSize() const noexcept;
COORD GetPosition() const noexcept;
const CursorType GetType() const;
const bool IsUsingColor() const;
const COLORREF GetColor() const;
const CursorType GetType() const noexcept;
const bool IsUsingColor() const noexcept;
const COLORREF GetColor() const noexcept;
void StartDeferDrawing();
void EndDeferDrawing();
void StartDeferDrawing() noexcept;
void EndDeferDrawing() noexcept;
void SetHasMoved(const bool fHasMoved);
void SetIsVisible(const bool fIsVisible);
void SetIsOn(const bool fIsOn);
void SetBlinkingAllowed(const bool fIsOn);
void SetIsDouble(const bool fIsDouble);
void SetIsConversionArea(const bool fIsConversionArea);
void SetIsPopupShown(const bool fIsPopupShown);
void SetDelay(const bool fDelay);
void SetSize(const ULONG ulSize);
void SetHasMoved(const bool fHasMoved) noexcept;
void SetIsVisible(const bool fIsVisible) noexcept;
void SetIsOn(const bool fIsOn) noexcept;
void SetBlinkingAllowed(const bool fIsOn) noexcept;
void SetIsDouble(const bool fIsDouble) noexcept;
void SetIsConversionArea(const bool fIsConversionArea) noexcept;
void SetIsPopupShown(const bool fIsPopupShown) noexcept;
void SetDelay(const bool fDelay) noexcept;
void SetSize(const ULONG ulSize) noexcept;
void SetStyle(const ULONG ulSize, const COLORREF color, const CursorType type) noexcept;
void SetPosition(const COORD cPosition);
void SetXPosition(const int NewX);
void SetYPosition(const int NewY);
void IncrementXPosition(const int DeltaX);
void IncrementYPosition(const int DeltaY);
void DecrementXPosition(const int DeltaX);
void DecrementYPosition(const int DeltaY);
void SetPosition(const COORD cPosition) noexcept;
void SetXPosition(const int NewX) noexcept;
void SetYPosition(const int NewY) noexcept;
void IncrementXPosition(const int DeltaX) noexcept;
void IncrementYPosition(const int DeltaY) noexcept;
void DecrementXPosition(const int DeltaX) noexcept;
void DecrementYPosition(const int DeltaY) noexcept;
void CopyProperties(const Cursor& OtherCursor);
void CopyProperties(const Cursor& OtherCursor) noexcept;
void DelayEOLWrap(const COORD coordDelayedAt);
void ResetDelayEOLWrap();
COORD GetDelayedAtPosition() const;
bool IsDelayedEOLWrap() const;
void DelayEOLWrap(const COORD coordDelayedAt) noexcept;
void ResetDelayEOLWrap() noexcept;
COORD GetDelayedAtPosition() const noexcept;
bool IsDelayedEOLWrap() const noexcept;
void SetColor(const unsigned int color);
void SetType(const CursorType type);
void SetColor(const unsigned int color) noexcept;
void SetType(const CursorType type) noexcept;
private:
TextBuffer& _parentBuffer;

View File

@@ -6,10 +6,12 @@
#include "textBuffer.hpp"
#include "CharRow.hpp"
#include "../types/inc/utils.hpp"
#include "../types/inc/convert.hpp"
#pragma hdrstop
using namespace Microsoft::Console;
using namespace Microsoft::Console::Types;
// Routine Description:
@@ -47,7 +49,7 @@ TextBuffer::TextBuffer(const COORD screenBufferSize,
// - OtherBuffer - The text buffer to copy properties from
// Return Value:
// - <none>
void TextBuffer::CopyProperties(const TextBuffer& OtherBuffer)
void TextBuffer::CopyProperties(const TextBuffer& OtherBuffer) noexcept
{
GetCursor().CopyProperties(OtherBuffer.GetCursor());
}
@@ -58,9 +60,9 @@ void TextBuffer::CopyProperties(const TextBuffer& OtherBuffer)
// - <none>
// Return Value:
// - Total number of rows in the buffer
UINT TextBuffer::TotalRowCount() const
UINT TextBuffer::TotalRowCount() const noexcept
{
return static_cast<UINT>(_storage.size());
return gsl::narrow<UINT>(_storage.size());
}
// Routine Description:
@@ -76,7 +78,7 @@ const ROW& TextBuffer::GetRowByOffset(const size_t index) const
// Rows are stored circularly, so the index you ask for is offset by the start position and mod the total of rows.
const size_t offsetIndex = (_firstRow + index) % totalRows;
return _storage[offsetIndex];
return _storage.at(offsetIndex);
}
// Routine Description:
@@ -88,7 +90,11 @@ const ROW& TextBuffer::GetRowByOffset(const size_t index) const
// - reference to the requested row. Asserts if out of bounds.
ROW& TextBuffer::GetRowByOffset(const size_t index)
{
return const_cast<ROW&>(static_cast<const TextBuffer*>(this)->GetRowByOffset(index));
const size_t totalRows = TotalRowCount();
// Rows are stored circularly, so the index you ask for is offset by the start position and mod the total of rows.
const size_t offsetIndex = (_firstRow + index) % totalRows;
return _storage.at(offsetIndex);
}
// Routine Description:
@@ -540,7 +546,7 @@ bool TextBuffer::IncrementCircularBuffer()
_renderTarget.TriggerCircling();
// First, clean out the old "first row" as it will become the "last row" of the buffer after the circle is performed.
bool fSuccess = _storage.at(_firstRow).Reset(_currentAttributes);
const bool fSuccess = _storage.at(_firstRow).Reset(_currentAttributes);
if (fSuccess)
{
// Now proceed to increment.
@@ -558,30 +564,45 @@ bool TextBuffer::IncrementCircularBuffer()
//Routine Description:
// - Retrieves the position of the last non-space character on the final line of the text buffer.
// - By default, we search the entire buffer to find the last non-space character
//Arguments:
// - <none>
//Return Value:
// - Coordinate position in screen coordinates (offset coordinates, not array index coordinates).
COORD TextBuffer::GetLastNonSpaceCharacter() const
{
COORD coordEndOfText;
// Always search the whole buffer, by starting at the bottom.
coordEndOfText.Y = GetSize().BottomInclusive();
return GetLastNonSpaceCharacter(GetSize());
}
const ROW* pCurrRow = &GetRowByOffset(coordEndOfText.Y);
//Routine Description:
// - Retrieves the position of the last non-space character in the given viewport
// - This is basically an optimized version of GetLastNonSpaceCharacter(), and can be called when
// - we know the last character is within the given viewport (so we don't need to check the entire buffer)
//Arguments:
// - The viewport
//Return value:
// - Coordinate position (relative to the text buffer)
COORD TextBuffer::GetLastNonSpaceCharacter(const Microsoft::Console::Types::Viewport viewport) const
{
COORD coordEndOfText = { 0 };
// Search the given viewport by starting at the bottom.
coordEndOfText.Y = viewport.BottomInclusive();
const auto& currRow = GetRowByOffset(coordEndOfText.Y);
// The X position of the end of the valid text is the Right draw boundary (which is one beyond the final valid character)
coordEndOfText.X = static_cast<short>(pCurrRow->GetCharRow().MeasureRight()) - 1;
coordEndOfText.X = gsl::narrow<short>(currRow.GetCharRow().MeasureRight()) - 1;
// If the X coordinate turns out to be -1, the row was empty, we need to search backwards for the real end of text.
bool fDoBackUp = (coordEndOfText.X < 0 && coordEndOfText.Y > 0); // this row is empty, and we're not at the top
const auto viewportTop = viewport.Top();
bool fDoBackUp = (coordEndOfText.X < 0 && coordEndOfText.Y > viewportTop); // this row is empty, and we're not at the top
while (fDoBackUp)
{
coordEndOfText.Y--;
pCurrRow = &GetRowByOffset(coordEndOfText.Y);
const auto& backupRow = GetRowByOffset(coordEndOfText.Y);
// We need to back up to the previous row if this line is empty, AND there are more rows
coordEndOfText.X = static_cast<short>(pCurrRow->GetCharRow().MeasureRight()) - 1;
fDoBackUp = (coordEndOfText.X < 0 && coordEndOfText.Y > 0);
coordEndOfText.X = gsl::narrow<short>(backupRow.GetCharRow().MeasureRight()) - 1;
fDoBackUp = (coordEndOfText.X < 0 && coordEndOfText.Y > viewportTop);
}
// don't allow negative results
@@ -623,7 +644,7 @@ COORD TextBuffer::_GetPreviousFromCursor() const
return coordPosition;
}
const SHORT TextBuffer::GetFirstRowIndex() const
const SHORT TextBuffer::GetFirstRowIndex() const noexcept
{
return _firstRow;
}
@@ -632,7 +653,7 @@ const Viewport TextBuffer::GetSize() const
return Viewport::FromDimensions({ 0, 0 }, { gsl::narrow<SHORT>(_storage.at(0).size()), gsl::narrow<SHORT>(_storage.size()) });
}
void TextBuffer::_SetFirstRowIndex(const SHORT FirstRowIndex)
void TextBuffer::_SetFirstRowIndex(const SHORT FirstRowIndex) noexcept
{
_firstRow = FirstRowIndex;
}
@@ -738,12 +759,12 @@ void TextBuffer::ScrollRows(const SHORT firstRow, const SHORT size, const SHORT
_RefreshRowIDs(std::nullopt);
}
Cursor& TextBuffer::GetCursor()
Cursor& TextBuffer::GetCursor() noexcept
{
return _cursor;
}
const Cursor& TextBuffer::GetCursor() const
const Cursor& TextBuffer::GetCursor() const noexcept
{
return _cursor;
}
@@ -778,7 +799,7 @@ void TextBuffer::Reset()
// - newSize - new size of screen.
// Return Value:
// - Success if successful. Invalid parameter if screen buffer size is unexpected. No memory if allocation failed.
[[nodiscard]] NTSTATUS TextBuffer::ResizeTraditional(const COORD newSize) noexcept
[[nodiscard]] NTSTATUS TextBuffer::ResizeTraditional(const COORD newSize)
{
RETURN_HR_IF(E_INVALIDARG, newSize.X < 0 || newSize.Y < 0);
@@ -795,7 +816,7 @@ void TextBuffer::Reset()
// rotate rows until the top row is at index 0
try
{
const ROW& newTopRow = _storage[TopRowIndex];
const ROW& newTopRow = _storage.at(TopRowIndex);
while (&newTopRow != &_storage.front())
{
_storage.push_back(std::move(_storage.front()));
@@ -826,12 +847,12 @@ void TextBuffer::Reset()
return S_OK;
}
const UnicodeStorage& TextBuffer::GetUnicodeStorage() const
const UnicodeStorage& TextBuffer::GetUnicodeStorage() const noexcept
{
return _unicodeStorage;
}
UnicodeStorage& TextBuffer::GetUnicodeStorage()
UnicodeStorage& TextBuffer::GetUnicodeStorage() noexcept
{
return _unicodeStorage;
}
@@ -906,7 +927,7 @@ ROW& TextBuffer::_GetPrevRowNoWrap(const ROW& Row)
}
THROW_HR_IF(E_FAIL, Row.GetId() == _firstRow);
return _storage[prevRowIndex];
return _storage.at(prevRowIndex);
}
// Method Description:
@@ -915,7 +936,7 @@ ROW& TextBuffer::_GetPrevRowNoWrap(const ROW& Row)
// - <none>
// Return Value:
// - This buffer's current render target.
Microsoft::Console::Render::IRenderTarget& TextBuffer::GetRenderTarget()
Microsoft::Console::Render::IRenderTarget& TextBuffer::GetRenderTarget() noexcept
{
return _renderTarget;
}
@@ -960,9 +981,9 @@ const TextBuffer::TextAndColor TextBuffer::GetTextForClipboard(const bool lineSe
std::vector<COLORREF> selectionBkAttr;
// preallocate to avoid reallocs
selectionText.reserve(highlight.Width() + 2); // + 2 for \r\n if we munged it
selectionFgAttr.reserve(highlight.Width() + 2);
selectionBkAttr.reserve(highlight.Width() + 2);
selectionText.reserve(gsl::narrow<size_t>(highlight.Width()) + 2); // + 2 for \r\n if we munged it
selectionFgAttr.reserve(gsl::narrow<size_t>(highlight.Width()) + 2);
selectionBkAttr.reserve(gsl::narrow<size_t>(highlight.Width()) + 2);
// copy char data into the string buffer, skipping trailing bytes
while (it)
@@ -981,6 +1002,8 @@ const TextBuffer::TextAndColor TextBuffer::GetTextForClipboard(const bool lineSe
selectionBkAttr.push_back(CellBkAttr);
}
}
#pragma warning(suppress : 26444)
// TODO GH 2675: figure out why there's custom construction/destruction happening here
it++;
}
@@ -1028,3 +1051,193 @@ const TextBuffer::TextAndColor TextBuffer::GetTextForClipboard(const bool lineSe
return data;
}
// Routine Description:
// - Generates a CF_HTML compliant structure based on the passed in text and color data
// Arguments:
// - rows - the text and color data we will format & encapsulate
// - backgroundColor - default background color for characters, also used in padding
// - fontHeightPoints - the unscaled font height
// - fontFaceName - the name of the font used
// - htmlTitle - value used in title tag of html header. Used to name the application
// Return Value:
// - string containing the generated HTML
std::string TextBuffer::GenHTML(const TextAndColor& rows, const int fontHeightPoints, const PCWCHAR fontFaceName, const COLORREF backgroundColor, const std::string& htmlTitle)
{
try
{
// TODO: GH 602 the font name needs to be passed and stored around as an actual bounded type, not an implicit bounds on LF_FACESIZE
const auto faceLength = wcsnlen_s(fontFaceName, LF_FACESIZE);
const std::wstring_view faceNameView{ fontFaceName, faceLength };
std::ostringstream htmlBuilder;
// First we have to add some standard
// HTML boiler plate required for CF_HTML
// as part of the HTML Clipboard format
const std::string htmlHeader =
"<!DOCTYPE><HTML><HEAD><TITLE>" + htmlTitle + "</TITLE></HEAD><BODY>";
htmlBuilder << htmlHeader;
htmlBuilder << "<!--StartFragment -->";
// apply global style in div element
{
htmlBuilder << "<DIV STYLE=\"";
htmlBuilder << "display:inline-block;";
htmlBuilder << "white-space:pre;";
htmlBuilder << "background-color:";
htmlBuilder << Utils::ColorToHexString(backgroundColor);
htmlBuilder << ";";
htmlBuilder << "font-family:";
htmlBuilder << "'";
htmlBuilder << ConvertToA(CP_UTF8, faceNameView);
htmlBuilder << "',";
// even with different font, add monospace as fallback
htmlBuilder << "monospace;";
htmlBuilder << "font-size:";
htmlBuilder << fontHeightPoints;
htmlBuilder << "pt;";
// note: MS Word doesn't support padding (in this way at least)
htmlBuilder << "padding:";
htmlBuilder << 4; // todo: customizable padding
htmlBuilder << "px;";
htmlBuilder << "\">";
}
// copy text and info color from buffer
bool hasWrittenAnyText = false;
std::optional<COLORREF> fgColor = std::nullopt;
std::optional<COLORREF> bkColor = std::nullopt;
for (size_t row = 0; row < rows.text.size(); row++)
{
size_t startOffset = 0;
if (row != 0)
{
htmlBuilder << "<BR>";
}
for (size_t col = 0; col < rows.text.at(row).length(); col++)
{
// do not include \r nor \n as they don't have attributes
// and are not HTML friendly. For line break use '<BR>' instead.
const bool isLastCharInRow =
col == rows.text.at(row).length() - 1 ||
rows.text.at(row).at(col + 1) == '\r' ||
rows.text.at(row).at(col + 1) == '\n';
bool colorChanged = false;
if (!fgColor.has_value() || rows.FgAttr.at(row).at(col) != fgColor.value())
{
fgColor = rows.FgAttr.at(row).at(col);
colorChanged = true;
}
if (!bkColor.has_value() || rows.BkAttr.at(row).at(col) != bkColor.value())
{
bkColor = rows.BkAttr.at(row).at(col);
colorChanged = true;
}
const auto writeAccumulatedChars = [&](bool includeCurrent) {
if (col > startOffset)
{
const auto unescapedText = ConvertToA(CP_UTF8, std::wstring_view(rows.text.at(row)).substr(startOffset, col - startOffset + includeCurrent));
for (const auto c : unescapedText)
{
switch (c)
{
case '<':
htmlBuilder << "&lt;";
break;
case '>':
htmlBuilder << "&gt;";
break;
case '&':
htmlBuilder << "&amp;";
break;
default:
htmlBuilder << c;
}
}
startOffset = col;
}
};
if (colorChanged)
{
writeAccumulatedChars(false);
if (hasWrittenAnyText)
{
htmlBuilder << "</SPAN>";
}
htmlBuilder << "<SPAN STYLE=\"";
htmlBuilder << "color:";
htmlBuilder << Utils::ColorToHexString(fgColor.value());
htmlBuilder << ";";
htmlBuilder << "background-color:";
htmlBuilder << Utils::ColorToHexString(bkColor.value());
htmlBuilder << ";";
htmlBuilder << "\">";
}
hasWrittenAnyText = true;
if (isLastCharInRow)
{
writeAccumulatedChars(true);
break;
}
}
}
if (hasWrittenAnyText)
{
// last opened span wasn't closed in loop above, so close it now
htmlBuilder << "</SPAN>";
}
htmlBuilder << "</DIV>";
htmlBuilder << "<!--EndFragment -->";
constexpr std::string_view HtmlFooter = "</BODY></HTML>";
htmlBuilder << HtmlFooter;
// once filled with values, there will be exactly 157 bytes in the clipboard header
constexpr size_t ClipboardHeaderSize = 157;
// these values are byte offsets from start of clipboard
const size_t htmlStartPos = ClipboardHeaderSize;
const size_t htmlEndPos = ClipboardHeaderSize + gsl::narrow<size_t>(htmlBuilder.tellp());
const size_t fragStartPos = ClipboardHeaderSize + gsl::narrow<size_t>(htmlHeader.length());
const size_t fragEndPos = htmlEndPos - HtmlFooter.length();
// header required by HTML 0.9 format
std::ostringstream clipHeaderBuilder;
clipHeaderBuilder << "Version:0.9\r\n";
clipHeaderBuilder << std::setfill('0');
clipHeaderBuilder << "StartHTML:" << std::setw(10) << htmlStartPos << "\r\n";
clipHeaderBuilder << "EndHTML:" << std::setw(10) << htmlEndPos << "\r\n";
clipHeaderBuilder << "StartFragment:" << std::setw(10) << fragStartPos << "\r\n";
clipHeaderBuilder << "EndFragment:" << std::setw(10) << fragEndPos << "\r\n";
clipHeaderBuilder << "StartSelection:" << std::setw(10) << fragStartPos << "\r\n";
clipHeaderBuilder << "EndSelection:" << std::setw(10) << fragEndPos << "\r\n";
return clipHeaderBuilder.str() + htmlBuilder.str();
}
catch (...)
{
LOG_HR(wil::ResultFromCaughtException());
return {};
}
}

View File

@@ -72,7 +72,7 @@ public:
~TextBuffer() = default;
// Used for duplicating properties to another text buffer
void CopyProperties(const TextBuffer& OtherBuffer);
void CopyProperties(const TextBuffer& OtherBuffer) noexcept;
// row manipulation
const ROW& GetRowByOffset(const size_t index) const;
@@ -105,17 +105,18 @@ public:
bool IncrementCircularBuffer();
COORD GetLastNonSpaceCharacter() const;
COORD GetLastNonSpaceCharacter(const Microsoft::Console::Types::Viewport viewport) const;
Cursor& GetCursor();
const Cursor& GetCursor() const;
Cursor& GetCursor() noexcept;
const Cursor& GetCursor() const noexcept;
const SHORT GetFirstRowIndex() const;
const SHORT GetFirstRowIndex() const noexcept;
const Microsoft::Console::Types::Viewport GetSize() const;
void ScrollRows(const SHORT firstRow, const SHORT size, const SHORT delta);
UINT TotalRowCount() const;
UINT TotalRowCount() const noexcept;
[[nodiscard]] TextAttribute GetCurrentAttributes() const noexcept;
@@ -123,12 +124,12 @@ public:
void Reset();
[[nodiscard]] HRESULT ResizeTraditional(const COORD newSize) noexcept;
[[nodiscard]] HRESULT ResizeTraditional(const COORD newSize);
const UnicodeStorage& GetUnicodeStorage() const;
UnicodeStorage& GetUnicodeStorage();
const UnicodeStorage& GetUnicodeStorage() const noexcept;
UnicodeStorage& GetUnicodeStorage() noexcept;
Microsoft::Console::Render::IRenderTarget& GetRenderTarget();
Microsoft::Console::Render::IRenderTarget& GetRenderTarget() noexcept;
class TextAndColor
{
@@ -144,6 +145,12 @@ public:
std::function<COLORREF(TextAttribute&)> GetForegroundColor,
std::function<COLORREF(TextAttribute&)> GetBackgroundColor) const;
static std::string GenHTML(const TextAndColor& rows,
const int fontHeightPoints,
const PCWCHAR fontFaceName,
const COLORREF backgroundColor,
const std::string& htmlTitle);
private:
std::deque<ROW> _storage;
Cursor _cursor;
@@ -159,7 +166,7 @@ private:
Microsoft::Console::Render::IRenderTarget& _renderTarget;
void _SetFirstRowIndex(const SHORT FirstRowIndex);
void _SetFirstRowIndex(const SHORT FirstRowIndex) noexcept;
COORD _GetPreviousFromCursor() const;

View File

@@ -65,7 +65,7 @@ TextBufferCellIterator::operator bool() const noexcept
// - it - The other iterator to compare to this one.
// Return Value:
// - True if it's the same text buffer and same cell position. False otherwise.
bool TextBufferCellIterator::operator==(const TextBufferCellIterator& it) const noexcept
bool TextBufferCellIterator::operator==(const TextBufferCellIterator& it) const
{
return _pos == it._pos &&
&_buffer == &it._buffer &&
@@ -81,7 +81,7 @@ bool TextBufferCellIterator::operator==(const TextBufferCellIterator& it) const
// - it - The other iterator to compare to this one.
// Return Value:
// - True if it's the same text buffer and different cell position or if they're different buffers. False otherwise.
bool TextBufferCellIterator::operator!=(const TextBufferCellIterator& it) const noexcept
bool TextBufferCellIterator::operator!=(const TextBufferCellIterator& it) const
{
return !(*this == it);
}
@@ -212,7 +212,7 @@ void TextBufferCellIterator::_SetPos(const COORD newPos)
if (newPos.X != _pos.X)
{
const ptrdiff_t diff = newPos.X - _pos.X;
const auto diff = gsl::narrow_cast<ptrdiff_t>(newPos.X) - gsl::narrow_cast<ptrdiff_t>(_pos.X);
_attrIter += diff;
}

View File

@@ -28,12 +28,10 @@ public:
TextBufferCellIterator(const TextBuffer& buffer, COORD pos);
TextBufferCellIterator(const TextBuffer& buffer, COORD pos, const Microsoft::Console::Types::Viewport limits);
~TextBufferCellIterator() = default;
operator bool() const noexcept;
bool operator==(const TextBufferCellIterator& it) const noexcept;
bool operator!=(const TextBufferCellIterator& it) const noexcept;
bool operator==(const TextBufferCellIterator& it) const;
bool operator!=(const TextBufferCellIterator& it) const;
TextBufferCellIterator& operator+=(const ptrdiff_t& movement);
TextBufferCellIterator& operator-=(const ptrdiff_t& movement);

View File

@@ -16,7 +16,7 @@ using namespace Microsoft::Console::Types;
// - Narrows the view of a cell iterator into a text only iterator.
// Arguments:
// - A cell iterator
TextBufferTextIterator::TextBufferTextIterator(const TextBufferCellIterator& cellIt) :
TextBufferTextIterator::TextBufferTextIterator(const TextBufferCellIterator& cellIt) noexcept :
TextBufferCellIterator(cellIt)
{
}
@@ -25,7 +25,8 @@ TextBufferTextIterator::TextBufferTextIterator(const TextBufferCellIterator& cel
// - Returns the text information from the text buffer position addressed by this iterator.
// Return Value:
// - Read only UTF-16 text data
const std::wstring_view TextBufferTextIterator::operator*() const
// TODO GH 2682, fix design so this doesn't have to be suppressed.
[[gsl::suppress(26434)]] const std::wstring_view TextBufferTextIterator::operator*() const noexcept
{
return _view.Chars();
}
@@ -34,7 +35,8 @@ const std::wstring_view TextBufferTextIterator::operator*() const
// - Returns the text information from the text buffer position addressed by this iterator.
// Return Value:
// - Read only UTF-16 text data
const std::wstring_view* TextBufferTextIterator::operator->() const
// TODO GH 2682, fix design so this doesn't have to be suppressed.
[[gsl::suppress(26434)]] const std::wstring_view* TextBufferTextIterator::operator->() const noexcept
{
return &_view.Chars();
}

View File

@@ -22,10 +22,10 @@ class SCREEN_INFORMATION;
class TextBufferTextIterator final : public TextBufferCellIterator
{
public:
TextBufferTextIterator(const TextBufferCellIterator& cellIter);
TextBufferTextIterator(const TextBufferCellIterator& cellIter) noexcept;
const std::wstring_view operator*() const;
const std::wstring_view* operator->() const;
const std::wstring_view operator*() const noexcept;
const std::wstring_view* operator->() const noexcept;
protected:
#if UNIT_TESTING

View File

@@ -1,18 +1,15 @@
<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
<Import Project="$(OpenConsoleDir)src\wap-common.build.pre.props" />
<PropertyGroup Label="Version">
<!-- These fields are picked up by PackageES -->
<VersionMajor>0</VersionMajor>
<VersionMinor>2</VersionMinor>
<VersionMinor>5</VersionMinor>
</PropertyGroup>
<PropertyGroup Label="Configuration">
<TargetPlatformVersion>10.0.17763.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<TargetPlatformVersion>10.0.18362.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.18362.0</TargetPlatformMinVersion>
<!--
These two properties are very important!
Without them, msbuild will stomp MinVersion and MaxVersionTested in the
@@ -22,27 +19,23 @@
<AppxOSMinVersionReplaceManifestVersion>false</AppxOSMinVersionReplaceManifestVersion>
<AppxOSMaxVersionTestedReplaceManifestVersion>false</AppxOSMaxVersionTestedReplaceManifestVersion>
</PropertyGroup>
<PropertyGroup>
<ProjectGuid>CA5CAD1A-224A-4171-B13A-F16E576FDD12</ProjectGuid>
<EntryPointProjectUniqueName>..\WindowsTerminal\WindowsTerminal.vcxproj</EntryPointProjectUniqueName>
<DebuggerType>NativeOnly</DebuggerType>
</PropertyGroup>
<PropertyGroup Condition="!Exists('CascadiaPackage_TemporaryKey.pfx')">
<AppxPackageSigningEnabled>false</AppxPackageSigningEnabled>
<AppxBundle>Never</AppxBundle>
</PropertyGroup>
<PropertyGroup Condition="Exists('CascadiaPackage_TemporaryKey.pfx')">
<AppxPackageSigningEnabled>true</AppxPackageSigningEnabled>
<AppxAutoIncrementPackageRevision>False</AppxAutoIncrementPackageRevision>
<PackageCertificateKeyFile>CascadiaPackage_TemporaryKey.pfx</PackageCertificateKeyFile>
</PropertyGroup>
<ItemGroup Condition="Exists('CascadiaPackage_TemporaryKey.pfx')">
<None Include="CascadiaPackage_TemporaryKey.pfx" />
</ItemGroup>
<ItemGroup>
<AppxManifest Include="Package.appxmanifest" Condition="'$(WindowsTerminalReleaseBuild)'=='true'">
<SubType>Designer</SubType>
@@ -51,7 +44,6 @@
<SubType>Designer</SubType>
</AppxManifest>
</ItemGroup>
<ItemGroup>
<Content Include="$(OpenConsoleDir)res\terminal\LargeTile.scale-100.png">
<Link>Images\LargeTile.scale-100.png</Link>
@@ -257,6 +249,11 @@
<Content Include="$(OpenConsoleDir)res\terminal\Wide310x150Logo.scale-400.png">
<Link>Images\Wide310x150Logo.scale-400.png</Link>
</Content>
<!-- Fonts -->
<Content Include="$(OpenConsoleDir)res\Cascadia.ttf" Condition="'$(WindowsTerminalReleaseBuild)'=='true'">
<Link>Cascadia.ttf</Link>
</Content>
<!-- Profile Icons -->
<Content Include="ProfileIcons\{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.scale-100.png" />
<Content Include="ProfileIcons\{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.scale-200.png" />
<Content Include="ProfileIcons\{574e775e-4f2a-5b96-ac1e-a2962a402336}.scale-100.png" />
@@ -265,64 +262,81 @@
<Content Include="ProfileIcons\{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.scale-200.png" />
<Content Include="ProfileIcons\{9acb9455-ca41-5af7-950f-6bca1bc9722f}.scale-100.png" />
<Content Include="ProfileIcons\{9acb9455-ca41-5af7-950f-6bca1bc9722f}.scale-200.png" />
<Content Include="ProfileIcons\{b453ae62-4e3d-5e58-b989-0a998ec441b8}.scale-100.png" />
<Content Include="ProfileIcons\{b453ae62-4e3d-5e58-b989-0a998ec441b8}.scale-200.png" />
<!-- Default Settings -->
<Content Include="$(OpenConsoleDir)src\cascadia\TerminalApp\defaults.json">
<Link>defaults.json</Link>
</Content>
<!-- Resources -->
<PRIResource Include="Resources\en-US\Resources.resw" />
</ItemGroup>
<Import Project="$(OpenConsoleDir)src\wap-common.build.post.props" />
<!--
This exists to work around Microsoft/microsoft-ui-xaml#494.
https://github.com/Microsoft/microsoft-ui-xaml/issues/494
Because the MUX nuget package hardcodes a requirement that the consuming project
be of type 'UAP', its resources are included in packaging and dependency resolution
by default. Inject them here.
This does mean that version changes to Microsoft.UI.Xaml must be manually reflected
here.
-->
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.1.190405001-prerelease\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.1.190405001-prerelease\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.1.190405001-prerelease\build\native\Microsoft.UI.Xaml.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\..\packages\Microsoft.UI.Xaml.2.1.190405001-prerelease\build\native\Microsoft.UI.Xaml.targets'))" />
</Target>
<PropertyGroup>
<WapProjBeforeGenerateAppxManifestDependsOn>
$(WapProjBeforeGenerateAppxManifestDependsOn);
_ConsoleInjectMUXWinmdIntoReferences;
</WapProjBeforeGenerateAppxManifestDependsOn>
</PropertyGroup>
<Target Name="_ConsoleInjectMUXWinmdIntoReferences">
<ItemGroup>
<_WinmdFilesFromReferences Include="@(Reference)" Condition="'%(Reference.Filename)' == 'Microsoft.UI.Xaml' and '%(Reference.Extension)' == '.winmd'" />
</ItemGroup>
</Target>
<!-- End workaround -->
<ItemGroup>
<ProjectReference Include="..\WindowsTerminal\WindowsTerminal.vcxproj" />
<ProjectReference Include="..\..\host\exe\Host.EXE.vcxproj" />
</ItemGroup>
<!-- Stomp the path to conhost.exe.
This task will copy OpenConsole.exe to the appx as conhost.exe, and place it
adjacent to WindowsTerminal.exe.
-->
  <Target Name="OpenConsoleStompSourceProjectForWapProject" BeforeTargets="_ConvertItems">
    <ItemGroup>
<Target Name="OpenConsoleStompSourceProjectForWapProject" BeforeTargets="_ConvertItems">
<ItemGroup>
<!-- Stomp all "SourceProject" values for all incoming dependencies to flatten the package. -->
      <_TemporaryFilteredWapProjOutput
Include="@(_FilteredNonWapProjProjectOutput)" />
      <_FilteredNonWapProjProjectOutput Remove="@(_TemporaryFilteredWapProjOutput)" />
      <_FilteredNonWapProjProjectOutput Include="@(_TemporaryFilteredWapProjOutput)">
<_TemporaryFilteredWapProjOutput Include="@(_FilteredNonWapProjProjectOutput)" />
<_FilteredNonWapProjProjectOutput Remove="@(_TemporaryFilteredWapProjOutput)" />
<_FilteredNonWapProjProjectOutput Include="@(_TemporaryFilteredWapProjOutput)">
<!-- Override the filename for OpenConsole.exe (only) -->
<TargetPath Condition="'%(Filename)' == 'OpenConsole' and '%(Extension)' == '.exe'">conhost.exe</TargetPath>
<!-- Blank the SourceProject here to vend all files into the root of the pacakge. -->
        <SourceProject></SourceProject>
      </_FilteredNonWapProjProjectOutput>
    </ItemGroup>
  </Target>
<!-- Blank the SourceProject here to vend all files into the root of the package. -->
<SourceProject>
</SourceProject>
</_FilteredNonWapProjProjectOutput>
</ItemGroup>
</Target>
<!-- Move all the PRI files that would be packaged into the appx into _PriFile so that
GenerateProjectPriFile catches them. This requires us to move payload collection
up before GenerateProjectPriFile, when it is typically _after_ it (because the
DesktopBridge project type is built to only prepare the payload during appx manifest
generation.
Since PRI file generation is _before_ manifest generation (for possibly obvious or
important reasons), that doesn't work for us.
-->
<PropertyGroup>
<!-- Only for MSBuild versions < 16.3.0 -->
<_GenerateProjectPriFileDependsOn Condition="$(MSBuildVersion) &lt; '16.3.0'">OpenConsoleLiftDesktopBridgePriFiles;$(_GenerateProjectPriFileDependsOn)</_GenerateProjectPriFileDependsOn>
</PropertyGroup>
<Target Name="OpenConsoleLiftDesktopBridgePriFiles" DependsOnTargets="_ConvertItems">
<ItemGroup>
<_PriFile Include="@(_NonWapProjProjectOutput)" Condition="'%(Extension)' == '.pri'" />
<!-- Remove all other .pri files from the appx payload. -->
<AppxPackagePayload Remove="@(AppxPackagePayload)" Condition="'%(Extension)' == '.pri'" />
</ItemGroup>
</Target>
<!-- VS 16.3.0 added a rule to the WAP packaging project that removes all non-WAP payload, which we were relying on to
roll up our subproject resources. We have to suppress that rule but keep part of its logic, because that rule is
where the AppxPackagePayload items are created. -->
<PropertyGroup>
<!-- Only for MSBuild versions <= 16.4.0 -->
<!-- TODO: Change this to hard less than once the 16.4.0 previews fix the bug. -->
<WapProjBeforeGenerateAppxManifestDependsOn
Condition="$(MSBuildVersion) &lt;= '16.4.0'">
$([MSBuild]::Unescape('$(WapProjBeforeGenerateAppxManifestDependsOn.Replace('_RemoveAllNonWapUWPItems', '_OpenConsoleRemoveAllNonWapUWPItems'))'))
</WapProjBeforeGenerateAppxManifestDependsOn>
</PropertyGroup>
<Target Name="_OpenConsoleRemoveAllNonWapUWPItems">
<ItemGroup>
<AppxPackagePayload Include="@(WapProjPackageFile)" />
<AppxUploadPackagePayload Include="@(UploadWapProjPackageFile)" />
<!-- 16.3.0 - remove non-resources.pri PRI files since we just forced them back in. -->
<AppxPackagePayload Remove="@(AppxPackagePayload)" Condition="'%(Extension)' == '.pri' and '%(Filename)' != 'resources'" />
<AppxUploadPackagePayload Remove="@(AppxUploadPackagePayload)" Condition="'%(Extension)' == '.pri' and '%(Filename)' != 'resources'" />
</ItemGroup>
</Target>
</Project>

View File

@@ -21,7 +21,7 @@
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
</Dependencies>
<Resources>

View File

@@ -5,6 +5,8 @@
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
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:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp rescap">
@@ -21,7 +23,7 @@
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
</Dependencies>
<Resources>
@@ -67,4 +69,12 @@
<Capability Name="internetClient" />
<rescap:Capability Name="runFullTrust" />
</Capabilities>
<Extensions>
<uap7:Extension Category="windows.sharedFonts">
<uap7:SharedFonts>
<uap4:Font File="Cascadia.ttf" />
</uap7:SharedFonts>
</uap7:Extension>
</Extensions>
</Package>

Binary file not shown.

After

Width:  |  Height:  |  Size: 314 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 573 B

View File

@@ -1,17 +1,17 @@
<?xml version="1.0" encoding="utf-8"?>
<root>
<!--
Microsoft ResX Schema
<!--
Microsoft ResX Schema
Version 2.0
The primary goals of this format is to allow a simple XML format
that is mostly human readable. The generation and parsing of the
various data types are done through the TypeConverter classes
The primary goals of this format is to allow a simple XML format
that is mostly human readable. The generation and parsing of the
various data types are done through the TypeConverter classes
associated with the data types.
Example:
... ado.net/XML headers & schema ...
<resheader name="resmimetype">text/microsoft-resx</resheader>
<resheader name="version">2.0</resheader>
@@ -26,36 +26,36 @@
<value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
<comment>This is a comment</comment>
</data>
There are any number of "resheader" rows that contain simple
There are any number of "resheader" rows that contain simple
name/value pairs.
Each data row contains a name, and value. The row also contains a
type or mimetype. Type corresponds to a .NET class that support
text/value conversion through the TypeConverter architecture.
Classes that don't support this are serialized and stored with the
Each data row contains a name, and value. The row also contains a
type or mimetype. Type corresponds to a .NET class that support
text/value conversion through the TypeConverter architecture.
Classes that don't support this are serialized and stored with the
mimetype set.
The mimetype is used for serialized objects, and tells the
ResXResourceReader how to depersist the object. This is currently not
The mimetype is used for serialized objects, and tells the
ResXResourceReader how to depersist the object. This is currently not
extensible. For a given mimetype the value must be set accordingly:
Note - application/x-microsoft.net.object.binary.base64 is the format
that the ResXResourceWriter will generate, however the reader can
Note - application/x-microsoft.net.object.binary.base64 is the format
that the ResXResourceWriter will generate, however the reader can
read any of the formats listed below.
mimetype: application/x-microsoft.net.object.binary.base64
value : The object must be serialized with
value : The object must be serialized with
: System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.soap.base64
value : The object must be serialized with
value : The object must be serialized with
: System.Runtime.Serialization.Formatters.Soap.SoapFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.bytearray.base64
value : The object must be serialized into a byte array
value : The object must be serialized into a byte array
: using a System.ComponentModel.TypeConverter
: and then encoded with base64 encoding.
-->
@@ -123,37 +123,16 @@
<data name="AppName" xml:space="preserve">
<value>Windows Terminal (Preview)</value>
</data>
<data name="InitialJsonParseErrorText" xml:space="preserve">
<value>Settings could not be loaded from file - temporarily using the default settings. Check for syntax errors, including trailing commas.</value>
</data>
<data name="InitialJsonParseErrorTitle" xml:space="preserve">
<value>Failed to load settings</value>
</data>
<data name="Ok" xml:space="preserve">
<value>Ok</value>
</data>
<data name="ReloadJsonParseErrorText" xml:space="preserve">
<value>Settings could not be reloaded from file. Check for syntax errors, including trailing commas.</value>
</data>
<data name="ReloadJsonParseErrorTitle" xml:space="preserve">
<value>Failed to reload settings</value>
</data>
<data name="AppDescriptionDev" xml:space="preserve">
<value>The Windows Terminal, but Unofficial</value>
</data>
<data name="AppNameDev" xml:space="preserve">
<value>Windows Terminal (Dev Build)</value>
</data>
<data name="AboutTitleText" xml:space="preserve">
<value>About</value>
</data>
<data name="VersionLabelText" xml:space="preserve">
<value>Version:</value>
</data>
<data name="AppShortName" xml:space="preserve">
<value>Terminal</value>
</data>
<data name="AppShortNameDev" xml:space="preserve">
<value>Terminal (Dev)</value>
</data>
</root>
</root>

View File

@@ -0,0 +1,234 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "precomp.h"
#include "../TerminalApp/ColorScheme.h"
#include "../TerminalApp/CascadiaSettings.h"
#include "JsonTestClass.h"
using namespace Microsoft::Console;
using namespace TerminalApp;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
using namespace WEX::Common;
namespace TerminalAppLocalTests
{
// Unfortunately, these tests _WILL NOT_ work in our CI, until we have a lab
// machine available that can run Windows version 18362.
class ColorSchemeTests : public JsonTestClass
{
// Use a custom manifest to ensure that we can activate winrt types from
// our test. This property will tell taef to manually use this as the
// sxs manifest during this test class. It includes all the cppwinrt
// types we've defined, so if your test is crashing for an unknown
// reason, make sure it's included in that file.
// If you want to do anything XAML-y, you'll need to run your test in a
// packaged context. See TabTests.cpp for more details on that.
BEGIN_TEST_CLASS(ColorSchemeTests)
TEST_CLASS_PROPERTY(L"ActivationContext", L"TerminalApp.LocalTests.manifest")
END_TEST_CLASS()
TEST_METHOD(CanLayerColorScheme);
TEST_METHOD(LayerColorSchemeProperties);
TEST_METHOD(LayerColorSchemesOnArray);
TEST_CLASS_SETUP(ClassSetup)
{
InitializeJsonReader();
return true;
}
};
void ColorSchemeTests::CanLayerColorScheme()
{
const std::string scheme0String{ R"({
"name": "scheme0",
"foreground": "#000000",
"background": "#010101"
})" };
const std::string scheme1String{ R"({
"name": "scheme1",
"foreground": "#020202",
"background": "#030303"
})" };
const std::string scheme2String{ R"({
"name": "scheme0",
"foreground": "#040404",
"background": "#050505"
})" };
const std::string scheme3String{ R"({
// "name": "scheme3",
"foreground": "#060606",
"background": "#070707"
})" };
const auto scheme0Json = VerifyParseSucceeded(scheme0String);
const auto scheme1Json = VerifyParseSucceeded(scheme1String);
const auto scheme2Json = VerifyParseSucceeded(scheme2String);
const auto scheme3Json = VerifyParseSucceeded(scheme3String);
const auto scheme0 = ColorScheme::FromJson(scheme0Json);
VERIFY_IS_TRUE(scheme0.ShouldBeLayered(scheme0Json));
VERIFY_IS_FALSE(scheme0.ShouldBeLayered(scheme1Json));
VERIFY_IS_TRUE(scheme0.ShouldBeLayered(scheme2Json));
VERIFY_IS_FALSE(scheme0.ShouldBeLayered(scheme3Json));
const auto scheme1 = ColorScheme::FromJson(scheme1Json);
VERIFY_IS_FALSE(scheme1.ShouldBeLayered(scheme0Json));
VERIFY_IS_TRUE(scheme1.ShouldBeLayered(scheme1Json));
VERIFY_IS_FALSE(scheme1.ShouldBeLayered(scheme2Json));
VERIFY_IS_FALSE(scheme1.ShouldBeLayered(scheme3Json));
const auto scheme3 = ColorScheme::FromJson(scheme3Json);
VERIFY_IS_FALSE(scheme3.ShouldBeLayered(scheme0Json));
VERIFY_IS_FALSE(scheme3.ShouldBeLayered(scheme1Json));
VERIFY_IS_FALSE(scheme3.ShouldBeLayered(scheme2Json));
VERIFY_IS_FALSE(scheme3.ShouldBeLayered(scheme3Json));
}
void ColorSchemeTests::LayerColorSchemeProperties()
{
const std::string scheme0String{ R"({
"name": "scheme0",
"foreground": "#000000",
"background": "#010101",
"red": "#010000",
"green": "#000100",
"blue": "#000001"
})" };
const std::string scheme1String{ R"({
"name": "scheme1",
"foreground": "#020202",
"background": "#030303",
"red": "#020000",
"blue": "#000002"
})" };
const std::string scheme2String{ R"({
"name": "scheme0",
"foreground": "#040404",
"background": "#050505",
"red": "#030000",
"green": "#000300"
})" };
const auto scheme0Json = VerifyParseSucceeded(scheme0String);
const auto scheme1Json = VerifyParseSucceeded(scheme1String);
const auto scheme2Json = VerifyParseSucceeded(scheme2String);
auto scheme0 = ColorScheme::FromJson(scheme0Json);
VERIFY_ARE_EQUAL(L"scheme0", scheme0._schemeName);
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 0), scheme0._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), scheme0._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 1, 0, 0), scheme0._table[XTERM_RED_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 1, 0), scheme0._table[XTERM_GREEN_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 1), scheme0._table[XTERM_BLUE_ATTR]);
Log::Comment(NoThrowString().Format(
L"Layering scheme1 on top of scheme0"));
scheme0.LayerJson(scheme1Json);
VERIFY_ARE_EQUAL(ARGB(0, 2, 2, 2), scheme0._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 3, 3, 3), scheme0._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 2, 0, 0), scheme0._table[XTERM_RED_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 1, 0), scheme0._table[XTERM_GREEN_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 2), scheme0._table[XTERM_BLUE_ATTR]);
Log::Comment(NoThrowString().Format(
L"Layering scheme2Json on top of (scheme0+scheme1)"));
scheme0.LayerJson(scheme2Json);
VERIFY_ARE_EQUAL(ARGB(0, 4, 4, 4), scheme0._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 5, 5, 5), scheme0._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 3, 0, 0), scheme0._table[XTERM_RED_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 3, 0), scheme0._table[XTERM_GREEN_ATTR]);
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 2), scheme0._table[XTERM_BLUE_ATTR]);
}
void ColorSchemeTests::LayerColorSchemesOnArray()
{
const std::string scheme0String{ R"({
"name": "scheme0",
"foreground": "#000000",
"background": "#010101"
})" };
const std::string scheme1String{ R"({
"name": "scheme1",
"foreground": "#020202",
"background": "#030303"
})" };
const std::string scheme2String{ R"({
"name": "scheme0",
"foreground": "#040404",
"background": "#050505"
})" };
const std::string scheme3String{ R"({
// "name": "scheme3",
"foreground": "#060606",
"background": "#070707"
})" };
const auto scheme0Json = VerifyParseSucceeded(scheme0String);
const auto scheme1Json = VerifyParseSucceeded(scheme1String);
const auto scheme2Json = VerifyParseSucceeded(scheme2String);
const auto scheme3Json = VerifyParseSucceeded(scheme3String);
CascadiaSettings settings;
VERIFY_ARE_EQUAL(0u, settings._globals.GetColorSchemes().size());
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme0Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme1Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme2Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme3Json));
settings._LayerOrCreateColorScheme(scheme0Json);
VERIFY_ARE_EQUAL(1u, settings._globals.GetColorSchemes().size());
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme0Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme2Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme3Json));
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 0), settings._globals.GetColorSchemes().at(0)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), settings._globals.GetColorSchemes().at(0)._defaultBackground);
settings._LayerOrCreateColorScheme(scheme1Json);
VERIFY_ARE_EQUAL(2u, settings._globals.GetColorSchemes().size());
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme2Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme3Json));
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 0), settings._globals.GetColorSchemes().at(0)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), settings._globals.GetColorSchemes().at(0)._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 2, 2, 2), settings._globals.GetColorSchemes().at(1)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 3, 3, 3), settings._globals.GetColorSchemes().at(1)._defaultBackground);
settings._LayerOrCreateColorScheme(scheme2Json);
VERIFY_ARE_EQUAL(2u, settings._globals.GetColorSchemes().size());
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme2Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme3Json));
VERIFY_ARE_EQUAL(ARGB(0, 4, 4, 4), settings._globals.GetColorSchemes().at(0)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 5, 5, 5), settings._globals.GetColorSchemes().at(0)._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 2, 2, 2), settings._globals.GetColorSchemes().at(1)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 3, 3, 3), settings._globals.GetColorSchemes().at(1)._defaultBackground);
settings._LayerOrCreateColorScheme(scheme3Json);
VERIFY_ARE_EQUAL(3u, settings._globals.GetColorSchemes().size());
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingColorScheme(scheme2Json));
VERIFY_IS_NULL(settings._FindMatchingColorScheme(scheme3Json));
VERIFY_ARE_EQUAL(ARGB(0, 4, 4, 4), settings._globals.GetColorSchemes().at(0)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 5, 5, 5), settings._globals.GetColorSchemes().at(0)._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 2, 2, 2), settings._globals.GetColorSchemes().at(1)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 3, 3, 3), settings._globals.GetColorSchemes().at(1)._defaultBackground);
VERIFY_ARE_EQUAL(ARGB(0, 6, 6, 6), settings._globals.GetColorSchemes().at(2)._defaultForeground);
VERIFY_ARE_EQUAL(ARGB(0, 7, 7, 7), settings._globals.GetColorSchemes().at(2)._defaultBackground);
}
}

View File

@@ -0,0 +1,36 @@
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- JsonTestClass.h
Abstract:
- This class is a helper that can be used to quickly create tests that need to
read & parse json data. Test classes that need to read JSON should make sure
to derive from this class, and also make sure to call InitializeJsonReader()
in the TEST_CLASS_SETUP().
Author(s):
Mike Griese (migrie) August-2019
--*/
class JsonTestClass
{
public:
void InitializeJsonReader()
{
_reader = std::unique_ptr<Json::CharReader>(Json::CharReaderBuilder::CharReaderBuilder().newCharReader());
};
Json::Value VerifyParseSucceeded(std::string content)
{
Json::Value root;
std::string errs;
const bool parseResult = _reader->parse(content.c_str(), content.c_str() + content.size(), &root, &errs);
VERIFY_IS_TRUE(parseResult, winrt::to_hstring(errs).c_str());
return root;
};
protected:
std::unique_ptr<Json::CharReader> _reader;
};

View File

@@ -0,0 +1,159 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "precomp.h"
#include "../TerminalApp/ColorScheme.h"
#include "../TerminalApp/CascadiaSettings.h"
#include "JsonTestClass.h"
using namespace Microsoft::Console;
using namespace TerminalApp;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
using namespace WEX::Common;
namespace TerminalAppLocalTests
{
// Unfortunately, these tests _WILL NOT_ work in our CI, until we have a lab
// machine available that can run Windows version 18362.
class KeyBindingsTests : public JsonTestClass
{
// Use a custom manifest to ensure that we can activate winrt types from
// our test. This property will tell taef to manually use this as the
// sxs manifest during this test class. It includes all the cppwinrt
// types we've defined, so if your test is crashing for an unknown
// reason, make sure it's included in that file.
// If you want to do anything XAML-y, you'll need to run your test in a
// packaged context. See TabTests.cpp for more details on that.
BEGIN_TEST_CLASS(KeyBindingsTests)
TEST_CLASS_PROPERTY(L"ActivationContext", L"TerminalApp.LocalTests.manifest")
END_TEST_CLASS()
TEST_METHOD(ManyKeysSameAction);
TEST_METHOD(LayerKeybindings);
TEST_METHOD(UnbindKeybindings);
TEST_CLASS_SETUP(ClassSetup)
{
InitializeJsonReader();
return true;
}
};
void KeyBindingsTests::ManyKeysSameAction()
{
const std::string bindings0String{ R"([ { "command": "copy", "keys": ["ctrl+c"] } ])" };
const std::string bindings1String{ R"([ { "command": "copy", "keys": ["enter"] } ])" };
const std::string bindings2String{ R"([
{ "command": "paste", "keys": ["ctrl+v"] },
{ "command": "paste", "keys": ["ctrl+shift+v"] }
])" };
const auto bindings0Json = VerifyParseSucceeded(bindings0String);
const auto bindings1Json = VerifyParseSucceeded(bindings1String);
const auto bindings2Json = VerifyParseSucceeded(bindings2String);
auto appKeyBindings = winrt::make_self<winrt::TerminalApp::implementation::AppKeyBindings>();
VERIFY_IS_NOT_NULL(appKeyBindings);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings1Json);
VERIFY_ARE_EQUAL(2u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings2Json);
VERIFY_ARE_EQUAL(4u, appKeyBindings->_keyShortcuts.size());
}
void KeyBindingsTests::LayerKeybindings()
{
const std::string bindings0String{ R"([ { "command": "copy", "keys": ["ctrl+c"] } ])" };
const std::string bindings1String{ R"([ { "command": "paste", "keys": ["ctrl+c"] } ])" };
const std::string bindings2String{ R"([ { "command": "copy", "keys": ["enter"] } ])" };
const auto bindings0Json = VerifyParseSucceeded(bindings0String);
const auto bindings1Json = VerifyParseSucceeded(bindings1String);
const auto bindings2Json = VerifyParseSucceeded(bindings2String);
auto appKeyBindings = winrt::make_self<winrt::TerminalApp::implementation::AppKeyBindings>();
VERIFY_IS_NOT_NULL(appKeyBindings);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings1Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings2Json);
VERIFY_ARE_EQUAL(2u, appKeyBindings->_keyShortcuts.size());
}
void KeyBindingsTests::UnbindKeybindings()
{
const std::string bindings0String{ R"([ { "command": "copy", "keys": ["ctrl+c"] } ])" };
const std::string bindings1String{ R"([ { "command": "paste", "keys": ["ctrl+c"] } ])" };
const std::string bindings2String{ R"([ { "command": "unbound", "keys": ["ctrl+c"] } ])" };
const std::string bindings3String{ R"([ { "command": null, "keys": ["ctrl+c"] } ])" };
const std::string bindings4String{ R"([ { "command": "garbage", "keys": ["ctrl+c"] } ])" };
const std::string bindings5String{ R"([ { "command": 5, "keys": ["ctrl+c"] } ])" };
const auto bindings0Json = VerifyParseSucceeded(bindings0String);
const auto bindings1Json = VerifyParseSucceeded(bindings1String);
const auto bindings2Json = VerifyParseSucceeded(bindings2String);
const auto bindings3Json = VerifyParseSucceeded(bindings3String);
const auto bindings4Json = VerifyParseSucceeded(bindings4String);
const auto bindings5Json = VerifyParseSucceeded(bindings5String);
auto appKeyBindings = winrt::make_self<winrt::TerminalApp::implementation::AppKeyBindings>();
VERIFY_IS_NOT_NULL(appKeyBindings);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
appKeyBindings->LayerJson(bindings1Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
Log::Comment(NoThrowString().Format(
L"Try unbinding a key using `\"unbound\"` to unbind the key"));
appKeyBindings->LayerJson(bindings2Json);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
Log::Comment(NoThrowString().Format(
L"Try unbinding a key using `null` to unbind the key"));
// First add back a good binding
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
// Then try layering in the bad setting
appKeyBindings->LayerJson(bindings3Json);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
Log::Comment(NoThrowString().Format(
L"Try unbinding a key using an unrecognized command to unbind the key"));
// First add back a good binding
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
// Then try layering in the bad setting
appKeyBindings->LayerJson(bindings4Json);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
Log::Comment(NoThrowString().Format(
L"Try unbinding a key using a straight up invalid value to unbind the key"));
// First add back a good binding
appKeyBindings->LayerJson(bindings0Json);
VERIFY_ARE_EQUAL(1u, appKeyBindings->_keyShortcuts.size());
// Then try layering in the bad setting
appKeyBindings->LayerJson(bindings5Json);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
Log::Comment(NoThrowString().Format(
L"Try unbinding a key that wasn't bound at all"));
appKeyBindings->LayerJson(bindings2Json);
VERIFY_ARE_EQUAL(0u, appKeyBindings->_keyShortcuts.size());
}
}

View File

@@ -0,0 +1,296 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "precomp.h"
#include "../TerminalApp/ColorScheme.h"
#include "../TerminalApp/CascadiaSettings.h"
#include "JsonTestClass.h"
using namespace Microsoft::Console;
using namespace TerminalApp;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
using namespace WEX::Common;
namespace TerminalAppLocalTests
{
// Unfortunately, these tests _WILL NOT_ work in our CI, until we have a lab
// machine available that can run Windows version 18362.
class ProfileTests : public JsonTestClass
{
// Use a custom manifest to ensure that we can activate winrt types from
// our test. This property will tell taef to manually use this as the
// sxs manifest during this test class. It includes all the cppwinrt
// types we've defined, so if your test is crashing for an unknown
// reason, make sure it's included in that file.
// If you want to do anything XAML-y, you'll need to run your test in a
// packaged context. See TabTests.cpp for more details on that.
BEGIN_TEST_CLASS(ProfileTests)
TEST_CLASS_PROPERTY(L"ActivationContext", L"TerminalApp.LocalTests.manifest")
END_TEST_CLASS()
TEST_METHOD(CanLayerProfile);
TEST_METHOD(LayerProfileProperties);
TEST_METHOD(LayerProfileIcon);
TEST_METHOD(LayerProfilesOnArray);
TEST_CLASS_SETUP(ClassSetup)
{
InitializeJsonReader();
return true;
}
};
void ProfileTests::CanLayerProfile()
{
const std::string profile0String{ R"({
"name" : "profile0",
"guid" : "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile1String{ R"({
"name" : "profile1",
"guid" : "{6239a42c-2222-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile2String{ R"({
"name" : "profile2",
"guid" : "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile3String{ R"({
"name" : "profile3"
})" };
const auto profile0Json = VerifyParseSucceeded(profile0String);
const auto profile1Json = VerifyParseSucceeded(profile1String);
const auto profile2Json = VerifyParseSucceeded(profile2String);
const auto profile3Json = VerifyParseSucceeded(profile3String);
const auto profile0 = Profile::FromJson(profile0Json);
VERIFY_IS_FALSE(profile0.ShouldBeLayered(profile1Json));
VERIFY_IS_TRUE(profile0.ShouldBeLayered(profile2Json));
VERIFY_IS_FALSE(profile0.ShouldBeLayered(profile3Json));
const auto profile1 = Profile::FromJson(profile1Json);
VERIFY_IS_FALSE(profile1.ShouldBeLayered(profile0Json));
// A profile _can_ be layered with itself, though what's the point?
VERIFY_IS_TRUE(profile1.ShouldBeLayered(profile1Json));
VERIFY_IS_FALSE(profile1.ShouldBeLayered(profile2Json));
VERIFY_IS_FALSE(profile1.ShouldBeLayered(profile3Json));
const auto profile3 = Profile::FromJson(profile3Json);
VERIFY_IS_FALSE(profile3.ShouldBeLayered(profile0Json));
// A profile _can_ be layered with itself, though what's the point?
VERIFY_IS_FALSE(profile3.ShouldBeLayered(profile1Json));
VERIFY_IS_FALSE(profile3.ShouldBeLayered(profile2Json));
VERIFY_IS_FALSE(profile3.ShouldBeLayered(profile3Json));
}
void ProfileTests::LayerProfileProperties()
{
const std::string profile0String{ R"({
"name": "profile0",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"foreground": "#000000",
"background": "#010101"
})" };
const std::string profile1String{ R"({
"name": "profile1",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"foreground": "#020202",
"startingDirectory": "C:/"
})" };
const std::string profile2String{ R"({
"name": "profile2",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"foreground": "#030303"
})" };
const auto profile0Json = VerifyParseSucceeded(profile0String);
const auto profile1Json = VerifyParseSucceeded(profile1String);
const auto profile2Json = VerifyParseSucceeded(profile2String);
auto profile0 = Profile::FromJson(profile0Json);
VERIFY_IS_TRUE(profile0._defaultForeground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 0, 0, 0), profile0._defaultForeground.value());
VERIFY_IS_TRUE(profile0._defaultBackground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), profile0._defaultBackground.value());
VERIFY_ARE_EQUAL(L"profile0", profile0._name);
VERIFY_IS_FALSE(profile0._startingDirectory.has_value());
Log::Comment(NoThrowString().Format(
L"Layering profile1 on top of profile0"));
profile0.LayerJson(profile1Json);
VERIFY_IS_TRUE(profile0._defaultForeground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 2, 2, 2), profile0._defaultForeground.value());
VERIFY_IS_TRUE(profile0._defaultBackground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), profile0._defaultBackground.value());
VERIFY_ARE_EQUAL(L"profile1", profile0._name);
VERIFY_IS_TRUE(profile0._startingDirectory.has_value());
VERIFY_ARE_EQUAL(L"C:/", profile0._startingDirectory.value());
Log::Comment(NoThrowString().Format(
L"Layering profile2 on top of (profile0+profile1)"));
profile0.LayerJson(profile2Json);
VERIFY_IS_TRUE(profile0._defaultForeground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 3, 3, 3), profile0._defaultForeground.value());
VERIFY_IS_TRUE(profile0._defaultBackground.has_value());
VERIFY_ARE_EQUAL(ARGB(0, 1, 1, 1), profile0._defaultBackground.value());
VERIFY_ARE_EQUAL(L"profile2", profile0._name);
VERIFY_IS_TRUE(profile0._startingDirectory.has_value());
VERIFY_ARE_EQUAL(L"C:/", profile0._startingDirectory.value());
}
void ProfileTests::LayerProfileIcon()
{
const std::string profile0String{ R"({
"name": "profile0",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"icon": "not-null.png"
})" };
const std::string profile1String{ R"({
"name": "profile1",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"icon": null
})" };
const std::string profile2String{ R"({
"name": "profile2",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile3String{ R"({
"name": "profile3",
"guid": "{6239a42c-1111-49a3-80bd-e8fdd045185c}",
"icon": "another-real.png"
})" };
const auto profile0Json = VerifyParseSucceeded(profile0String);
const auto profile1Json = VerifyParseSucceeded(profile1String);
const auto profile2Json = VerifyParseSucceeded(profile2String);
const auto profile3Json = VerifyParseSucceeded(profile3String);
auto profile0 = Profile::FromJson(profile0Json);
VERIFY_IS_TRUE(profile0._icon.has_value());
VERIFY_ARE_EQUAL(L"not-null.png", profile0._icon.value());
Log::Comment(NoThrowString().Format(
L"Verify that layering an object the key set to null will clear the key"));
profile0.LayerJson(profile1Json);
VERIFY_IS_FALSE(profile0._icon.has_value());
profile0.LayerJson(profile2Json);
VERIFY_IS_FALSE(profile0._icon.has_value());
profile0.LayerJson(profile3Json);
VERIFY_IS_TRUE(profile0._icon.has_value());
VERIFY_ARE_EQUAL(L"another-real.png", profile0._icon.value());
Log::Comment(NoThrowString().Format(
L"Verify that layering an object _without_ the key will not clear the key"));
profile0.LayerJson(profile2Json);
VERIFY_IS_TRUE(profile0._icon.has_value());
VERIFY_ARE_EQUAL(L"another-real.png", profile0._icon.value());
auto profile1 = Profile::FromJson(profile1Json);
VERIFY_IS_FALSE(profile1._icon.has_value());
profile1.LayerJson(profile3Json);
VERIFY_IS_TRUE(profile1._icon.has_value());
VERIFY_ARE_EQUAL(L"another-real.png", profile1._icon.value());
}
void ProfileTests::LayerProfilesOnArray()
{
const std::string profile0String{ R"({
"name" : "profile0",
"guid" : "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile1String{ R"({
"name" : "profile1",
"guid" : "{6239a42c-1111-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile2String{ R"({
"name" : "profile2",
"guid" : "{6239a42c-2222-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile3String{ R"({
"name" : "profile3",
"guid" : "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
})" };
const std::string profile4String{ R"({
"name" : "profile4",
"guid" : "{6239a42c-0000-49a3-80bd-e8fdd045185c}"
})" };
const auto profile0Json = VerifyParseSucceeded(profile0String);
const auto profile1Json = VerifyParseSucceeded(profile1String);
const auto profile2Json = VerifyParseSucceeded(profile2String);
const auto profile3Json = VerifyParseSucceeded(profile3String);
const auto profile4Json = VerifyParseSucceeded(profile4String);
CascadiaSettings settings;
VERIFY_ARE_EQUAL(0u, settings._profiles.size());
VERIFY_IS_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile4Json));
settings._LayerOrCreateProfile(profile0Json);
VERIFY_ARE_EQUAL(1u, settings._profiles.size());
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile4Json));
settings._LayerOrCreateProfile(profile1Json);
VERIFY_ARE_EQUAL(2u, settings._profiles.size());
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile4Json));
settings._LayerOrCreateProfile(profile2Json);
VERIFY_ARE_EQUAL(3u, settings._profiles.size());
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile4Json));
VERIFY_ARE_EQUAL(L"profile0", settings._profiles.at(0)._name);
settings._LayerOrCreateProfile(profile3Json);
VERIFY_ARE_EQUAL(3u, settings._profiles.size());
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile4Json));
VERIFY_ARE_EQUAL(L"profile3", settings._profiles.at(0)._name);
settings._LayerOrCreateProfile(profile4Json);
VERIFY_ARE_EQUAL(3u, settings._profiles.size());
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile0Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile1Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile2Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile3Json));
VERIFY_IS_NOT_NULL(settings._FindMatchingProfile(profile4Json));
VERIFY_ARE_EQUAL(L"profile4", settings._profiles.at(0)._name);
}
}

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,110 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "precomp.h"
#include "../TerminalApp/ColorScheme.h"
#include "../TerminalApp/Tab.h"
using namespace Microsoft::Console;
using namespace TerminalApp;
using namespace WEX::Logging;
using namespace WEX::TestExecution;
namespace TerminalAppLocalTests
{
// Unfortunately, these tests _WILL NOT_ work in our CI, until we have a lab
// machine available that can run Windows version 18362.
class TabTests
{
// For this set of tests, we need to activate some XAML content. To do
// that, we need to be able to activate Xaml Islands(XI), using the Xaml
// Hosting APIs. Because XI looks at the manifest of the exe running, we
// can't just use the TerminalApp.Unit.Tests.manifest as our
// ActivationContext. XI is going to inspect `te.exe`s manifest to try
// and find the maxversiontested property, but te.exe hasn't set that.
// Instead, this test will run as a UAP application, as a packaged
// centenial (win32) app. We'll specify our own AppxManifest, so that
// we'll be able to also load all the dll's for the types we've defined
// (and want to use here). This does come with a minor caveat, as
// deploying the appx takes a bit, so use sparingly (though it will
// deploy once per class when used like this.)
BEGIN_TEST_CLASS(TabTests)
TEST_CLASS_PROPERTY(L"RunAs", L"UAP")
TEST_CLASS_PROPERTY(L"UAP:AppXManifest", L"TerminalApp.LocalTests.AppxManifest.xml")
END_TEST_CLASS()
// These four tests act as canary tests. If one of them fails, then they
// can help you identify if something much lower in the stack has
// failed.
TEST_METHOD(TryInitXamlIslands);
TEST_METHOD(TryCreateLocalWinRTType);
TEST_METHOD(TryCreateXamlObjects);
TEST_METHOD(TryCreateTab);
TEST_CLASS_SETUP(ClassSetup)
{
winrt::init_apartment(winrt::apartment_type::single_threaded);
// Initialize the Xaml Hosting Manager
_manager = winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread();
_source = winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource{};
return true;
}
private:
winrt::Windows::UI::Xaml::Hosting::WindowsXamlManager _manager{ nullptr };
winrt::Windows::UI::Xaml::Hosting::DesktopWindowXamlSource _source{ nullptr };
};
void TabTests::TryInitXamlIslands()
{
// Ensures that XAML Islands was initialized correctly
VERIFY_IS_NOT_NULL(_manager);
VERIFY_IS_NOT_NULL(_source);
}
void TabTests::TryCreateLocalWinRTType()
{
// Verify we can create a WinRT type we authored
// Just creating it is enough to know that everything is working.
winrt::Microsoft::Terminal::Settings::TerminalSettings settings;
VERIFY_IS_NOT_NULL(settings);
auto oldFontSize = settings.FontSize();
settings.FontSize(oldFontSize + 5);
auto newFontSize = settings.FontSize();
VERIFY_ARE_NOT_EQUAL(oldFontSize, newFontSize);
}
void TabTests::TryCreateXamlObjects()
{
// Verify we can create a some XAML objects
// Just creating all of them is enough to know that everything is working.
winrt::Windows::UI::Xaml::Controls::UserControl controlRoot;
VERIFY_IS_NOT_NULL(controlRoot);
winrt::Windows::UI::Xaml::Controls::Grid root;
VERIFY_IS_NOT_NULL(root);
winrt::Windows::UI::Xaml::Controls::SwapChainPanel swapChainPanel;
VERIFY_IS_NOT_NULL(swapChainPanel);
winrt::Windows::UI::Xaml::Controls::Primitives::ScrollBar scrollBar;
VERIFY_IS_NOT_NULL(scrollBar);
}
void TabTests::TryCreateTab()
{
// Just try creating all of:
// 1. one of our pure c++ types (Profile)
// 2. one of our c++winrt types (TermControl)
// 3. one of our types that uses MUX/Xaml (Tab).
// Just creating all of them is enough to know that everything is working.
const auto profileGuid{ Utils::CreateGuid() };
winrt::Microsoft::Terminal::TerminalControl::TermControl term{};
VERIFY_IS_NOT_NULL(term);
auto newTab = std::make_shared<Tab>(profileGuid, term);
VERIFY_IS_NOT_NULL(newTab);
}
}

View File

@@ -0,0 +1,52 @@
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" IgnorableNamespaces="uap">
<!-- This file is used as the Appxmanifest for tests that _need_ to run in a
packaged environment. It will be copied to the test's OutDir as part of the
PostBuid step. It's highly similar to the "PackagedCwaFullTrust" manifest that
TAEF ships with, with the following modifications:
1. All of our winrt types are included in this manifest, including types from
MUX.dll. Should this list of types ever change, we'll need to manually
update this file. The easiest way of doing that is deploying the app from
VS, then copying the Extensions from the Appxmanifest.xml that's generated
under `src/cascadia/CascadiaPackage/bin/$(platform)/$(configuration)/appx`.
2. We also _NEED_ the two vclibs listed under the `PackageDependency` block.
If your test fails for whatever reason, it's likely possible you're testing a
type that's _not_ included in this file for some reason. So, here be dragons. -->
<Identity Name="TerminalApp.LocalTests.Package"
ProcessorArchitecture="neutral"
Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
Version="1.0.0.0"
ResourceId="en-us" />
<Properties>
<DisplayName>TerminalApp.LocalTests.Package Host Process</DisplayName>
<PublisherDisplayName>Microsoft Corp.</PublisherDisplayName>
<Logo>taef.png</Logo>
<Description>TAEF Packaged Cwa FullTrust Application Host Process</Description>
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>
<Resources>
<Resource Language="en-us" />
</Resources>
<Applications>
<Application Id="TE.ProcessHost" Executable="TE.ProcessHost.exe" EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements DisplayName="TAEF Packaged Cwa FullTrust Application Host Process" Square150x150Logo="taef.png" Square44x44Logo="taef.png" Description="TAEF Packaged Cwa Application Host Process" BackgroundColor="#222222">
<uap:SplashScreen Image="taef.png" />
</uap:VisualElements>
</Application>
</Applications>
<Capabilities>
<rescap:Capability Name="runFullTrust"/>
</Capabilities>
</Package>

View File

@@ -0,0 +1,24 @@
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<!-- This file is copied into ut_app/TerminalApp.Unit.Tests.manifest as part
of the pre-build step for that project. Changes should only be made to the
WindowsTerminal version of the file. -->
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 1903 -->
<!-- See https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/xaml-islands -->
<!-- "maxversiontested" is CASE SENSITIVE. Do not change this.-->
<maxversiontested Id="10.0.18362.0"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</windowsSettings>
</application>
</assembly>

View File

@@ -0,0 +1,180 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(SolutionDir)\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
<Import Project="$(OpenConsoleDir)\src\common.build.pre.props" />
<!-- ========================= Headers ======================== -->
<ItemGroup>
<ClInclude Include="precomp.h" />
<ClInclude Include="JsonTestClass.h" />
</ItemGroup>
<!-- ========================= Cpp Files ======================== -->
<ItemGroup>
<ClCompile Include="SettingsTests.cpp" />
<ClCompile Include="ProfileTests.cpp" />
<ClCompile Include="ColorSchemeTests.cpp" />
<ClCompile Include="KeyBindingsTests.cpp" />
<ClCompile Include="TabTests.cpp" />
<ClCompile Include="precomp.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
<!-- You _NEED_ to include this file and the jsoncpp IncludePath (below) if
you want to use jsoncpp -->
<ClCompile Include="$(OpenConsoleDir)\dep\jsoncpp\jsoncpp.cpp">
<PrecompiledHeader>NotUsing</PrecompiledHeader>
</ClCompile>
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup>
<ProjectReference Include="$(OpenConsoleDir)\src\cascadia\TerminalApp\lib\TerminalAppLib.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)\src\types\lib\types.vcxproj" />
<!-- If you don't reference these projects here, the
_ConsoleGenerateAdditionalWinmdManifests step won't gather the winmd's -->
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalSettings\TerminalSettings.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalControl\TerminalControl.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalConnection\TerminalConnection.vcxproj" />
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\TerminalApp\TerminalApp.vcxproj" />
</ItemGroup>
<!-- ========================= Globals ======================== -->
<PropertyGroup>
<ProjectGuid>{CA5CAD1A-b11c-4ddb-a4fe-c3afae9b5506}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
<RootNamespace>TerminalAppLocalTests</RootNamespace>
<ProjectName>LocalTests_TerminalApp</ProjectName>
<TargetName>TerminalApp.LocalTests</TargetName>
<WindowsTargetPlatformMinVersion>10.0.18362.0</WindowsTargetPlatformMinVersion>
<WindowsTargetPlatformVersion>10.0.18362.0</WindowsTargetPlatformVersion>
</PropertyGroup>
<!-- ====================== Compiler & Linker Flags ===================== -->
<ItemDefinitionGroup>
<ClCompile>
<AdditionalIncludeDirectories>..;$(OpenConsoleDir)\dep\jsoncpp\json;$(OpenConsoleDir)src\inc;$(OpenConsoleDir)src\inc\test;$(WinRT_IncludePath)\..\cppwinrt\winrt;"$(OpenConsoleDir)\src\cascadia\TerminalApp\lib\Generated Files";%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<PrecompiledHeaderFile>precomp.h</PrecompiledHeaderFile>
<!-- Manually disable unreachable code warning, because jconcpp has a ton of that. -->
<DisableSpecificWarnings>4702;%(DisableSpecificWarnings)</DisableSpecificWarnings>
</ClCompile>
<Link>
<AdditionalDependencies>WindowsApp.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
<PropertyGroup>
<GenerateManifest>true</GenerateManifest>
<EmbedManifest>true</EmbedManifest>
</PropertyGroup>
<!-- Careful reordering these. Some default props (contained in these files) are order sensitive. -->
<Import Project="$(OpenConsoleDir)src\common.build.dll.props" />
<Import Project="$(OpenConsoleDir)src\common.build.post.props" />
<Import Project="$(OpenConsoleDir)src\common.build.tests.props" />
<PropertyGroup>
<!-- Manually change our outdir to be in a subdirectory. We don't really want
to put our output in the bin root, because if we do, we'll copy
TerminalApp.winmd to the bin root, and then every subsequent mdmerge step
(in _any_ cppwinrt project) will automatically try to pick up
TerminalApp.winmd as a dependency (which is just wrong). This MUST be done
after importing common.build.post.props-->
<OutDir>$(OpenConsoleDir)\bin\$(Platform)\$(Configuration)\$(ProjectName)\</OutDir>
<IntDir>$(OpenConsoleDir)\obj\$(Platform)\$(Configuration)\$(ProjectName)\</IntDir>
</PropertyGroup>
<PropertyGroup>
<_CppWinrtBinRoot>&quot;$(OpenConsoleDir)$(Platform)\$(Configuration)\&quot;</_CppWinrtBinRoot>
<!-- 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.2.190611001-prerelease\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.2.190611001-prerelease\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.2.190611001-prerelease\build\native\Microsoft.UI.Xaml.targets')" />
<Import Project="..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.0.0-preview6.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets" Condition="Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.0.0-preview6.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" />
<!-- This project will generate individual sxs manifests for each of our winrt libraries -->
<Import Project="$(OpenConsoleDir)\build\rules\GenerateSxsManifestsFromWinmds.targets" />
<!-- This is important: actually add the _LocalTestsGenerateCombinedManifests
target to the list of targets to run. -->
<PropertyGroup>
<BeforeLinkTargets Condition="'$(WindowsTargetPlatformVersion)' &gt;= '10.0.18362.0'">
$(BeforeLinkTargets);
_LocalTestsGenerateCombinedManifests;
_LocalTestsBuildAppxManifest;
_LocalTestsCopyDependencies;
</BeforeLinkTargets>
</PropertyGroup>
<!-- Step 1: Combine all our SxS manifests into a single SxS manifest. TAEF
needs us to specify a single activation context at runtime, so we need a
single file with all our types in it.-->
<Target Name="_LocalTestsGenerateCombinedManifests"
Inputs="@(_ConsoleWinmdManifest)"
Outputs="$(OutDir)$(TargetName).manifest"
DependsOnTargets="_ConsoleGenerateAdditionalWinmdManifests">
<Exec Command="mt.exe -manifest @(_ConsoleWinmdManifest, ' -manifest ') -out:$(OutDir)$(TargetName).manifest" />
</Target>
<!-- Step 2: Take our combined SxS manifest, and use it to build an
Appxmanifest.xml. We'll use the Appxmanifest.prototype.xml in this project's
directory as a base, and the script will tak all our activatableClasses and
turn them into appxmanifest-compatible Extensions -->
<Target Name="_LocalTestsBuildAppxManifest"
Inputs="$(OutDir)$(TargetName).manifest"
Outputs="$(OutDir)$(TargetName).AppxManifest.xml"
DependsOnTargets="_LocalTestsGenerateCombinedManifests">
<Exec Command="powershell.exe -noprofile ExecutionPolicy Unrestricted $(OpenConsoleDir)\tools\GenerateAppxFromManifest.ps1 -SxSManifest $(OutDir)$(TargetName).manifest -AppxManifestPrototype $(TargetName).AppxManifest.prototype.xml -OutPath $(OutDir)$(TargetName).AppxManifest.xml" />
</Target>
<!-- Step 3: Manually copy all our dependent DLLs into our OutDir. For SxS
activation to work, they all need to be in the same directory as our test dll.
This is using code that's heavliy cribbed from WindowsTerminal.vcxproj, which
is already cribbed from the GetPackagingOutputs in
Microsoft.*.AppxPackage.targets. We're filtering this list down to the dlls,
pris and xbfs, because this list _can_ contain directories, which will make
the Copy task explode. -->
<PropertyGroup>
<_ContinueOnError Condition="'$(BuildingProject)' == 'true'">true</_ContinueOnError>
<_ContinueOnError Condition="'$(BuildingProject)' != 'true'">false</_ContinueOnError>
</PropertyGroup>
<!-- First gather the files... -->
<Target Name="MyGetPackagingOutputs" Returns="@(MyPackagingOutputs)">
<MSBuild
Projects="@(ProjectReferenceWithConfiguration)"
Targets="GetPackagingOutputs"
BuildInParallel="$(BuildInParallel)"
Properties="%(ProjectReferenceWithConfiguration.SetConfiguration); %(ProjectReferenceWithConfiguration.SetPlatform)"
Condition="'@(ProjectReferenceWithConfiguration)' != ''
and '%(ProjectReferenceWithConfiguration.BuildReference)' == 'true'
and '%(ProjectReferenceWithConfiguration.ReferenceOutputAssembly)' == 'true'"
ContinueOnError="$(_ContinueOnError)">
<Output TaskParameter="TargetOutputs" ItemName="_PackagingOutputsFromOtherProjects"/>
</MSBuild>
<ItemGroup>
<MyPackagingOutputs Include="@(_PackagingOutputsFromOtherProjects)" Condition="'%(Extension)'=='.dll' Or '%(Extension)'=='.pri' Or '%(Extension)'=='.xbf'" />
</ItemGroup>
</Target>
<!-- Then copy the files to our outdir -->
<Target Name="_LocalTestsCopyDependencies"
DependsOnTargets="MyGetPackagingOutputs">
<Copy SourceFiles="@(MyPackagingOutputs)"
SkipUnchangedFiles="true"
DestinationFolder="$(OutDir)"
/>
</Target>
</Project>

View File

@@ -0,0 +1,4 @@
// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
#include "precomp.h"

View File

@@ -0,0 +1,53 @@
/*++
Copyright (c) Microsoft Corporation
Licensed under the MIT license.
Module Name:
- precomp.h
Abstract:
- Contains external headers to include in the precompile phase of console build process.
- Avoid including internal project headers. Instead include them only in the classes that need them (helps with test project building).
Author(s):
- Carlos Zamora (cazamor) April 2019
--*/
#pragma once
// This includes support libraries from the CRT, STL, WIL, and GSL
#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 <WexTestClass.h>
#include <json.h>
#include "consoletaeftemplates.hpp"
// Needed just for XamlIslands to work at all:
#include <winrt/Windows.system.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.UI.Xaml.Hosting.h>
#include <windows.ui.xaml.hosting.desktopwindowxamlsource.h>
// Common includes for most tests:
#include "../../inc/argb.h"
#include "../../inc/conattrs.hpp"
#include "../../types/inc/utils.hpp"
#include "../../inc/DefaultSettings.h"
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/windows.ui.core.h>
#include <winrt/Windows.ui.input.h>
#include <winrt/Windows.UI.Xaml.Controls.h>
#include <winrt/Windows.UI.Xaml.Controls.Primitives.h>
#include <winrt/Windows.ui.xaml.media.h>
#include <winrt/Windows.ui.xaml.input.h>
#include <windows.ui.xaml.media.dxinterop.h>

View File

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

View File

@@ -1,68 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
<PropertyGroup>
<!-- 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>
</PropertyGroup>
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
<PropertyGroup Label="Globals">
<ProjectGuid>{015a0047-772d-4f1a-88c9-45c18f0adfb6}</ProjectGuid>
<ProjectName>Microsoft.UI.Xaml.Markup</ProjectName>
<RootNamespace>Microsoft.UI.Xaml.Markup</RootNamespace>
</PropertyGroup>
<ItemDefinitionGroup>
<Link>
<OutputFile>$(OutDir)\$(TargetName)$(TargetExt)</OutputFile>
<AdditionalDependencies>WindowsApp.lib;Kernel32.lib;User32.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
<ItemGroup>
<ClInclude Include="pch.h" />
<ClInclude Include="XamlApplication.h">
<DependentUpon>XamlApplication.idl</DependentUpon>
</ClInclude>
</ItemGroup>
<ItemGroup>
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
<ClCompile Include="XamlApplication.cpp">
<DependentUpon>XamlApplication.idl</DependentUpon>
</ClCompile>
<ClCompile Include="$(GeneratedFilesDir)module.g.cpp" />
</ItemGroup>
<ItemGroup>
<Midl Include="XamlApplication.idl" />
</ItemGroup>
<ItemGroup>
<None Include="Microsoft.UI.Xaml.Markup.def" />
<None Include="packages.config" />
<None Include="ReadMe.md" />
</ItemGroup>
<PropertyGroup>
<!--
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="$(OpenConsoleDir)src\common.build.post.props" />
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.post.props" />
</Project>

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