Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MEGA THREAD: Design still subject to change, UI is pretty okay though #1375

Open
20 of 29 tasks
DHowett-MSFT opened this issue Jun 22, 2019 · 303 comments
Open
20 of 29 tasks

MEGA THREAD: Design still subject to change, UI is pretty okay though #1375

DHowett-MSFT opened this issue Jun 22, 2019 · 303 comments

Comments

@DHowett-MSFT
Copy link
Contributor

@DHowett-MSFT DHowett-MSFT commented Jun 22, 2019

I am creating this so I can pin it & to help keep track of several related issues/work-items.

Things we know:

  • The grab handles are bright white/accent color/dark black
  • The grab handles are too narrow / the borders are too thick / why can't I use the area outside the window frame to resize?
  • #994 Split panes need an indicator to show which is focused
  • #1000 Literally anything having to do with panes
  • Click/Right click icon should display Minimize/Maximize/Close menu
  • When you click Cascade Windows , Show windows stacked etc is completely ignored by Terminal
  • #376, #545 Commandline applications can't receive mouse input
  • #4980 system theme light = light borders, even if terminal theme dark
  • The title bar isn't acrylic, but now since architectural changes could be!

Things related to tabs:

  • #1625 Has another giant bucket of work that's more specific to the non-client area (where the tabs are)
  • The area above the tabs isn't draggable
  • Can't pop/drag out tabs
  • Can't reorder tabs
  • #597 Without using tabs don't shrink/expand like browser tabs / I want to set a min width for my tabs / I want a fixed width for my tabs / I want tabs to expand to split the available space / any other possible tab sizing]
  • #3300 Tab bar doesn't grow when you resize the window, it only shrinks (Regressed in v0.6)

Things that people want, but we won't be able to fix:

  • #1753 Can only set "Opacity" of acrylic, not "Blur" / Can't have a non-acrylic transparency

Things fixed in v0.6:

  • #2513 Double click to non-client area should maximize the Window.
  • #771 The default 'active' tab contrast is very low (especially light mode)
  • The tabs don't look as good as you'd like #702
    grafik
  • #857 When the window is smaller than the sum of the width of the tabs, the tabs are cut off, without indication to scroll

Things fixed in v0.5:

  • #1589 Alt+F4 doesn't close the Window (PR#2526)

Things fixed in v0.3:

  • The non-client area looks wrong; PR #929, Issue #872
    grafik grafik

  • The plus button is too big, too small, too wide, too narrow (fixed in #1934)
    grafik

  • #564 draggable area in title bar (PR #1948)

  • When maximized on displays with a different DPI, the edges of the window are cut off. (Fixed by #1921)

  • #608 the text of my tabs is too long

  • I'm using the dark theme but am still seeing a white border and header are still white. (Might be fixed by #929)
    image

  • (caused by #929, tracked in #1625 #1963) The titlebar does not have my accent color in it
    image

  • Resizing the window causes the UI to disapper/reappear.
    ezgif-2-9dc95bf607e7

@mdtauk
Copy link

@mdtauk mdtauk commented Jun 22, 2019

The plus glyph will probably shrink, I commented on the TabControl issue, and it seems they will push the change, to match the smaller glyph used by UWP Edge.

image

@Jaykul
Copy link
Contributor

@Jaykul Jaykul commented Jun 22, 2019

Yeah, I think we can all agree "make the tabs like Edge Chrome" is nice, but "make the tabs like the promo video" is even better ... 😣

@mdtauk
Copy link

@mdtauk mdtauk commented Jun 22, 2019

I think the UWP Edge had nicer tabs than Edge Chrome. 🤔

@19lmyers
Copy link

@19lmyers 19lmyers commented Jun 22, 2019

Personally I wish they'd make Edge Chrome's tabs like UWP Edge, but nobody asked me...

@Jaykul
Copy link
Contributor

@Jaykul Jaykul commented Jun 22, 2019

Yeah, yeah, but ... either of them is waaaay ahead of Terminal 🤡
Edgium has almost 20 pixels above the tabs that are ugly ... but ... draggable!
And with both of them, you can at least tell which tab is active 🙄

@3dWrecker
Copy link

@3dWrecker 3dWrecker commented Jun 22, 2019

There is no PRACTICAL use for acrylic when coding. However transparency is very useful. It means I can view code beneath the Terminal window like this:
Annotation 2019-06-22 154553
Please add an adjustment for the BLUR factor that acrylic uses. I can't read blurred out text.
Annotation 2019-06-22 154657
Also if the Terminal did not go black when inactive like this:

Annotation 2019-06-22 154746
it would be really useful to be able to have a pin button which pinned the terminal above all other windows. This would enable seamless switching between the terminal and whatever code editor you are using (especially if you can read code beneath the Terminal window.)
I suggest that the acrylic theme should stay active instead of "going black" if an "Always on top" feature is added and enabled.

What it could look like:
dhdghjdy
The pin icon, to pin the Terminal above all windows.
@nacorv,

I would like to know if "Always on top" is a feature that would be considered.

@3dWrecker
Copy link

@3dWrecker 3dWrecker commented Jun 22, 2019

Selecting and dragging anywhere within the tab area currently does not move the window. This makes it necessary to move the mouse to the right of the tab area, which leaves a very small amount of titlebar which can be used to move the window. Please change this. No rush!

@Plasma
Copy link

@Plasma Plasma commented Jun 22, 2019

  1. Turning on acrylic in Powershell makes the purple parameters like -abc appear near invisible.

@sachinjoseph
Copy link
Member

@sachinjoseph sachinjoseph commented Jun 22, 2019

Resolution: 4K
Display Scaling: 100%

Light theme:

image

Dark theme:
image

@liamfoneill
Copy link

@liamfoneill liamfoneill commented Jun 22, 2019

ezgif-2-9dc95bf607e7

Resizing the window causes the UI to disapper/reappear. I am using the Windows Store Preview Version 0.2.1715.0

@momos11
Copy link

@momos11 momos11 commented Jun 22, 2019

Fullscreen:
image

Resized:
image

If the window is not big enough, all the other tabs are hidden.

@benc-uk
Copy link

@benc-uk benc-uk commented Jun 22, 2019

If the tab bar can't be acrylic, that's a major shame.
Anything that can be done to make them integrate better would be most welcome

The non drag-able tab/title bar is the #1 complaint I've heard from everyone that has tried the early builds

Split panes need some visual polish, make it clear which is in focus, some animation even as it opens

@thejsa
Copy link

@thejsa thejsa commented Jun 22, 2019

When maximised on my 2nd monitor (1366x768 laptop built-in display, not set as main), the edges of the app are cut off:
image

@robster2001
Copy link

@robster2001 robster2001 commented Jun 22, 2019

Tabs show the path to the executable instead of the name of the app; if the path is too long, the "x" to close the tab is pushed off the right side of the tab and is invisible.

Clicking "Settings" attempts to open a JSON file. I'm guessing that the UI for that hasn't been built yet. :)

@allen-chin
Copy link

@allen-chin allen-chin commented Jun 22, 2019

As an addition to @robster2001's comments, it'd be nice if each tab showed the actual path like Ubuntu and if it was in administrator mode (e.g. Command Prompt (Admin) - C:\current\path\that\you\are\in).

When you don't have terminal maximized, as I usually don't, the issue #857 combined with the long titles allows for much less tabs than what it could be.

@GenesisCraig
Copy link

@GenesisCraig GenesisCraig commented Jun 22, 2019

The tabs are just too wide to be useful. Perhaps just show the executable and give the path/etc information when you hover over the tab in a tooltip or something.

@DHowett-MSFT
Copy link
Contributor Author

@DHowett-MSFT DHowett-MSFT commented Jun 22, 2019

Two things:
Panes are not bound by default because they are incomplete. If you enable them yourself, YMMV.

If you want a custom tab title, you should look at how to set that up for your shell. It’ll benefit you everywhere you use your shell. By making powershell set the title, you change the title for Windows Terminal, legacy console, VSCode, ConEmu and a bunch of other things. It can even change in the middle of a session!

@DHowett-MSFT
Copy link
Contributor Author

@DHowett-MSFT DHowett-MSFT commented Jun 22, 2019

Panes epic: #1000

@csells
Copy link

@csells csells commented Jun 22, 2019

I couldn't find anywhere along the caption at the top of the window that allowed me to drag and move the window. I had to resort to keyboard shortcuts.

@csells
Copy link

@csells csells commented Jun 22, 2019

two-finger scrolling doesn't work, although it works great on cmd.com and PowerShell.

@thomthom
Copy link

@thomthom thomthom commented Jun 22, 2019

Tabs cannot be moved/rearranged.

@mxrsoon
Copy link

@mxrsoon mxrsoon commented Jul 26, 2020

It's like saying you're gonna do something wrong just because everybody does.

@dafzor
Copy link

@dafzor dafzor commented Jul 26, 2020

So after some digging in this and other issue comments.

There's was already an issue for titlebar not respecting respecting system theming #1963 that was piled up on another issue #3327. With this "Mega Thread" issue listing being outdated/deprecated.

Given the age of both issues seems there's very low developer interests which makes implementation unlikely.

So I've personally decided to discard the tab functionality to get the visual consistency.

    "alwaysShowTabs": false,
    "showTabsInTitlebar": false,

image

Just leaving this info here in case it's relevant for someone else.

@zadjii-msft
Copy link
Member

@zadjii-msft zadjii-msft commented Jul 27, 2020

Hey so for the record, there's a pretty heavy amount of discussion about ways to configure the color of tabs and the tab row (title bar) over in #3327 and #5772. Options discussed in there include matching the titlebar to the system accent color, or tabs to the color of the control that's focused in the window.

Just because an issue's old doesn't mean it's abandoned. #3327 is one of my favorite issues that I'm really looking forward to getting time to work on.

@Poopooracoocoo
Copy link

@Poopooracoocoo Poopooracoocoo commented Aug 21, 2020

same thing that happens in XAML Controls Gallery: microsoft/Xaml-Controls-Gallery#108 happens in Windows Terminal

ThunderPower added a commit to ThunderPower/terminal that referenced this issue Sep 5, 2020
* Draw the cursor underneath text, and above the background (#6337)

## Summary of the Pull Request

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

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

## References

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

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

## Detailed Description of the Pull Request / Additional comments

* This is essentially `"cursorTextColor": "textForeground"` from #6151.
* A follow up work item is needed to add support for the current behavior, (`"cursorTextColor": null`), and hooking up that setting to the renderer.

* Add a test to ensure support for trailing commas in `settings.json` (#6312)

## Summary of the Pull Request

Adds support for trailing commas in our json files. 

## References

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

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

* Improve support for VT character sets (#4496)

This PR improves our VT character set support, enabling the [`SCS`]
escape sequences to designate into all four G-sets with both 94- and
96-character sets, and supports invoking those G-sets into both the GL
and GR areas of the code table, with [locking shifts] and [single
shifts]. It also adds [`DOCS`] sequences to switch between UTF-8 and the
ISO-2022 coding system (which is what the VT character sets require),
and adds support for a lot more characters sets, up to around the level
of a VT510.

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

## Detailed Description of the Pull Request / Additional comments

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

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

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

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

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

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

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

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

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

## Validation Steps Performed

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

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

Closes #3377
Closes #3487

* Reflect OS build fixes on 7b489128ac back to inbox

Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 677d15a4e298a0e1e3ce093bc1dff8d832e3c2b1

Related work items: #26765368

* Allow Ctrl+Alt <> AltGr aliasing to be disabled (#6212)

## Summary of the Pull Request

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

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

## Validation Steps Performed

* Choose a German keyboard layout
* Using `showkey -a` ensured that both `Ctrl+Alt+Q/E` and `AltGr+Q/E` produce `@/€`
* Added `"altGrAliasing": false` to the WSL profile
* Using `showkey -a` ensured `Ctrl+Alt+Q/E` now produces `^[^Q/E` while `AltGr+Q/E` continues to produce `@/€`

* Move to Microsoft.UI.Xaml 2.4.0 (#5778)

This brings support for "Compact" tab sizing, which compresses all inactive tabs to just the size of their icons plus the close button. Neat!

It also just keeps us generally up-to-date and good citizens.

* Spec for tab tear off and default app (#2080)

docs have no build, cleaning out draft spec from PR queue

* First draft of a spec for panes with non-terminal content (#1080)

Co-authored-by: Michael Niksa <miniksa@microsoft.com>

putting outdated draft spec into drafts folder and closing PR. CI has no function on docs.

* fix spell things I forced into master.

* Add support for `compact` tab sizing (#5787)

## Summary of the Pull Request

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

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

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

## Detailed Description of the Pull Request / Additional comments

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

In this screenshot, tab 2 is focused:
![image](https://user-images.githubusercontent.com/18356694/81302383-ea82c700-903f-11ea-9820-92348d5adc64.png)

* spelling I

* spelling II

* Last round of master spelling fixes

* Update the tab's close button color to match the tab text color (#5789)

## Summary of the Pull Request

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

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

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

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

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

A dark tab color:
![image](https://user-images.githubusercontent.com/18356694/81303953-04250e00-9042-11ea-8db2-be97af519fae.png)

* Make the conversion from WORD to TextAttribute explicit (#6380)

In Windows, we build with /Zc:wchar_t- (which makes wchar_t an unsigned
short typedef.) This causes build breaks when we compare two wchar_t
values (or a wchar_t and an enum class that's of type wchar_t) and the
compiler decides that it might want to _promote them to TextAttribute_
before doing the comparison.

* Reflect OS build fixes back from f90f3bf99

Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp 272dfa1c4ad5e4202c4c56f3db7a445dc0b003cf

* Improve the legacy color conversions (#6358)

This PR provides a faster algorithm for converting 8-bit and 24-bit
colors into the 4-bit legacy values that are required by the Win32
console APIs. It also fixes areas of the code that were incorrectly
using a simple 16-color conversion that didn't handle 8-bit and 24-bit
values.

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

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

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

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

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

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

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

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

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

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

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

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

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

## Validation Steps Performed

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

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

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

Closes #5940 
Closes #6247

* Move all wildcards into targets or expand them (#6406)

Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must
be generated by targets.

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

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

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

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

Fixes #6214.

* Remove the shell extension from directory backgrounds (#6415)

We're removing this because of MSFT:24623699, which prevents us from being able to do the right thing when we're called on the background of a directory for a range of OS builds. 

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

* [x] closes #6245
* I work here

* Add support for win32-input-mode to conhost, ConPTY, Terminal (#6309)

Adds support for `win32-input-mode` to conhost, conpty, and the Windows
Terminal.

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

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

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

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

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

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

Closes #879
Closes #2865
Closes #530 
Closes #3079
Closes #1119
Closes #1694 
Closes #3608 
Closes #4334
Closes #4446

* Remove parentheses from Preview and Dev build (#6418)

## Summary of the Pull Request
Remove parentheses from the Preview and Dev build. Now they're called Windows Terminal Preview and Windows Terminal Dev Build respectively.

Also removed them from other identifiers of Terminal for consistency.

## PR Checklist
* [X] Closes #5974

* Upload Windows Terminal 2.0 roadmap (#6419)

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Upload the roadmap for Windows Terminal 2.0 and link to it on the README.

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

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

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

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

* wpf: add a .NET Core WPF Test project for the WPF Control (#6441)

This commit introduces a new project that lets you F5 a working instance
of the Wpf Terminal Control.

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

It's all quite cool when it works.

* Set tab title as early as possible (#6433)

When opening a new tab, it takes a few milliseconds before title to
appears. This PR makes it instantaneous.

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

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

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

## Validation

I ran the terminal and opened a new tab. The title appears instantly.

* Don't snap on input nor dismiss selection for just a modifier key (#6431)

Does what it says on the label. Pure modifier keys weren't making it
this far at all prior to #6309. This PR changes these methods to make
sure that we only dismiss a selection or snap on input when the key
pressed isn't a modifier key.

## References

* regressed in #6309

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

## Validation Steps Performed

* Tried to repro this in the Terminal, couldn't anymore.

* Don't send a manual F7 keyup (#6442)

## Summary of the Pull Request

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

## References

* regressed in #6309

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

## Validation Steps Performed

* Checked this with the debug tap

* Tie up some A11y loose threads (#6417)

This pull request moves WindowUiaProvider back into Win32 interactivity
and deletes all mention of it from Windows Terminal. Terminal does not
have a single toplevel window that requires Console-like UIA, as each
Xaml control inside it is in charge of its own destiny.

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

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

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

## Validation

Carlos validated conhost and terminal on this branch.

* WpfTest: Add an x86/Win32 build, make DPI aware (#6455)

This matches more closely how Visual Studio uses the WPF control.
It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.

* Improve perf by avoiding vector reallocation in renderer clusters and VT output graphics options (#6420)

## Summary of the Pull Request
Caches vectors in the class and uses a new helper to opportunistically shrink/grow as viewport sizes change in order to save performance on alloc/free of commonly used vectors.

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

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

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

Case | Before | After
---|---|---|
`big.txt` | ![image](https://user-images.githubusercontent.com/18221333/84088632-cbaa8400-a9a1-11ea-8932-04b2e12a0477.png) | ![image](https://user-images.githubusercontent.com/18221333/84088996-b6822500-a9a2-11ea-837c-5e32a110156e.png)
`cacafire` | ![image](https://user-images.githubusercontent.com/18221333/84089153-22648d80-a9a3-11ea-8567-c3d80efa16a6.png) | ![image](https://user-images.githubusercontent.com/18221333/84089190-34463080-a9a3-11ea-98e5-a236b12330d6.png)

* Reduce latency with DXGI 1.3 GetFrameLatencyWaitableObject (#6435)

This pull request reduces input lag, especially with selection, by using
`IDXGISwapChain2::GetFrameLatencyWaitableObject`.

This is based on the [DXGI 1.3 documentation].

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

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

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

[DXGI 1.3 documentation]: https://docs.microsoft.com/en-us/windows/uwp/gaming/reduce-latency-with-dxgi-1-3-swap-chains
[DXGI 1.3 improvement list]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-1-3-improvements:

* Open the system menu when user right clicks the drag bar (#6443)

Related to #1375 ("Click/Right click icon should display
Minimize/Maximize/Close menu")

* Deps: Bump Newtonsoft.Json from 10.0.3 to 12.0.3 (#6369)

Bump Newtonsoft.Json from 10.0.3 to 12.0.3

## References
Part of #5297

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

## Validation Steps Performed
CI builds successfully

* Fix the x86 build and re-enable x86 CI (#6467)

This was a miss.

* Add Mini-Spec for openSettings (#5915)

The spec introduces a keybinding argument of 'target' to be able to open a specific settings file. When the Settings UI gets implemented, it will also become an option.

Alternative designs were presented but the 'target' model was decided on.

* Fix 3 different bugs in the WPF control (#6464)

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

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

Closes #6444
Closes #6445
Closes #6446

* Finalize Command Palette Spec (#5674)

## Summary of the Pull Request

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

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

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

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

## Detailed Description of the Pull Request / Additional comments

_read the spec_

* Pass <Alt> to the application (#6461)

For mysterious reasons lost to the sands of time, XAML will _never_ pass
us a VK_MENU event. This is something that'll probably get fixed in
WinUI 3, but considering we're stuck on system XAML for the time being,
the only way to work around this bug is to pass the event through
manually. This change generalizes the F7 handler into a "direct key
event" handler that uses the same focus and tunneling method to send
different key events, and then uses it to send VK_MENU.

## Validation Steps Performed

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

Closes #6421

* Throttle scrollbar updates in TermControl to ~one per 8ms (#4608)

In addition to the below (original) description, this commit introduces
a ThrottledFunc template that can throttle _any_ function. It applies
that type to muffle updates to the scrollbar.

---

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

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

### Explanation

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

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

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

### Note

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

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

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

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

Closes #3622

* Add keybinding arg to openSettings (#6299)

## Summary of the Pull Request
Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`.

## References
#5915 - mini-spec

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

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

## Validation Steps Performed
Added the following to my settings.json:
```json
{ "command": "openSettings", "keys":... },
{ "command": { "action": "openSettings" }, "keys":... },
{ "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "allFiles" }, "keys":... }
```

* Add fast path to til::bitmap::translate using bitshifts (#6493)

This commit adds a fast path to `til::bitmap::translate`: use bit shifts
when the delta is vertical.

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

Before:
* translate represents 13.08% of samples in InvalidateScroll

After:
* translate represents  0.32% of samples in InvalidateScroll

## Validation

Tests passed.

* Clear cached runs after translate_y (#6501)

"While re-reading the code, I found out that I forgot to do clear cached runs
after translate_y in c360b7588ff8d389b49a4ed60cdee51401a5e172."

* Reintroduce the check for VT_INPUT_MODE in AdaptDispatch (#6485)

This commit reverts the removal of the "SSH hack" in #5383. It was
originally added as a solution to #4911, when we realized that SSH would
request the SS3 cursor key encoding but we weren't equipped to handle
it.

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

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

Fixes #6476.
Fixes #6196.
Fixes #5704.
Fixes #5608.

* Extract `ActionAndArgs::FromJson` into its own class (#6351)

## Summary of the Pull Request

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

## References

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

## PR Checklist
* [x] Closes nothing, this is code refactoring
* [x] I work here
* [x] Current tests passed
* [n/a] Requires documentation to be updated

* Fix sending a NUL on alt key up (#6516)

## Summary of the Pull Request

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

## References
* regressed in #6421 

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

## Validation Steps Performed
Tested `showkeys -a`

* Only snap on key _downs_ (#6517)

## Summary of the Pull Request
Prior to #6309, we'd only snap on input for non-modifier key_down_ events. #6423 fixed this for modifier keys, but didn't fix this for keyups.

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

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

* Fix openSettings misspelling in defaults (#6520)

Fixes #6486.

* Remove the WinTelnetEngine (#6526)

Nobody was using it.

Discussed in #2661.

* Spec: Advanced Tab Switcher (#3753)

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This is the spec for the Advanced Tab Switcher. This would allow the user to navigate through a vertical list of tabs through a UI, similar to those found in VSCode and Visual Studio.

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

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Spec for #1502
* [x] CLA signed.

* Introduce JsonUtilsNew as documented in #5875 (#6355)

Read the [JsonUtils Spec] for more details.

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

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

### Implementer's Notes

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

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

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

## Validation Steps Performed

So many tests.

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

Refs #2550

* Fixed #6377: TerminalCore::_altGrAliasing is undefined by default (#6571)

## Summary of the Pull Request

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

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

* Use early returns in TermControl::_KeyHandler (#6575)

## Summary of the Pull Request

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

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

## Validation Steps Performed

Everything still works as expected.

* doc: copyedit the roadmap a little bit (#6587)

* Add 1.1 blog post to 2.0 roadmap (#6581)

* Update PR template with link to docs (#6583)

* Improved ATTR_ROW::ReplaceAttrs performance (#6573)

## Summary of the Pull Request

Improve `ATTR_ROW::ReplaceAttrs` performance by only reserving the necessary capacity instead of resizing the new run.
That way `TextAttributeRun`s are only instantiated once instead of twice.

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

## Detailed Description of the Pull Request / Additional comments

Performance could be further improved by directly moving `TextAttributeRun`s into the new vector, but I considered this out of scope for this PR.

## Validation Steps Performed

CPU usage when running `cacafire` is slightly reduced.

* Add schema check to PR template (#6599)

This adds a check for updating the schema, and rewords the documentation checkbox to match the wording of the others.

* Enable hot reload of renderer settings that aren't already hot reload capable (#6551)

## Summary of the Pull Request

## PR Checklist
* [x] Closes #3927
* [x] I work here.
* [x] Tested manually.
* [x] Requires documentation to be updated: (generate doc bug here)
* [x] Am core contributor.

## Detailed Description of the Pull Request / Additional comments
- I found four settings that weren't hot reloadable with the 3927 comment above them:
1. Experimental retro terminal effect
2. Experimental software rendering
3. Experimental full repaint rendering
4. Antialiasing settings for text

I made them all hot reloadable by telling the `TermControl` to propagate them on settings change to the `DxEngine`.
Then I set up the `DxEngine` inside the setters to only set them if they changed. And if they do change, to trigger a full repaint and/or a complete drop and recreate of the entire DX device chain (as would happen if it were lost for another reason like a user-mode graphics failure, disconnected display, etc.)
I made the boolean an atomic because the settings can be coming in off of another thread (the XAML eventing one) and the renderer is picking the status up on its thread at the top of the BeginPaint frame.

## Validation Steps Performed
- [x] Opened it up and toggled all the settings while staring at PowerShell
- [x] Opened it up and toggled all the settings while staring at something intensive like a `cacafire` fire

* Improve bitmap::_calculateArea performance (#6572)

`bitmap::_calculateArea` performance can be improved by leveraging the
optimized `find_first`/`find_next` methods instead of iterating through
the bitmap manually.

* Use D2DDeviceContext and friends over D2DRenderTarget (#6527)

I was told that the DeviceContext version supercedes the RenderTarget
one. This moves us to it so we can gain access to a higher level of
control over the various pieces in our pipeline as we continue to evolve
the renderer.

The underlying motivation here is to potentially use a
`ID2D1CommandList` to batch our commands and run them all later outside
the lock. That can only really be done with this more granular level of
control over the pipeline. So this moves to that in a single step that
is easily findable in history should we have problems

I discussed this with @NiklasBorson of the Direct2D/DirectWrite team as
well as with @DHowett before doing it.

## Validation
- [x] Checked docs to make sure that these work on Windows 7 with
  Platform Update
- [x] Manual smoke test real quick
- [ ] Try running on Win7 + Platform Update after change
- [x] Probably do more than just a smoke test manually or otherwise

Closes #6525

* Always use the dark window borders (#6624)

* Recycle assorted rendering components to accelerate drawing (#6483)

This saves an awful lot of construction/destruction and memory
allocation, especially with text that changes a lot (see: cacafire).

Three things:
1. Recycling the text layouts. This holds onto the `CustomTextLayout` so
   all the things that don't change related to drawing targets and
   whatnot aren't freed and recreated every frame.
2. Reordering the runs in place. This saves a vector
   allocation/copy/delete every time OrderRuns is called. They can be
   rearranged in place.
3. Only clip once per row. This reduces the clip push/pop to only one
   time per row. Since we're always redrawing an entire row at a time,
   this saves a lot of alloc/free of the clip frame, dramatically
   reduces queued commands, and makes less work on the flush since
   clipping requires staging the drawing and then bringing it back to
   the main surface.

* Double-click a tab to rename it (#6628)

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

When the user double clicks on a tab, show the tab rename box
as if they right clicked on the tab and clicked on "Rename".

<!-- 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 #6600
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

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

I added a handler for the `DoubleTapped` event on the tab view item
when we are constructing it for the tab (in `Tab::_MakeTabViewItem`).

The code for that handler was copied the "rename tab menu item" click
handler.

I did not extract the code into a member function because it is very
short (only 2 lines of code) and only used twice so it is not worth
it IMO.

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

* Spec for unified keybindings and commands, and synthesized action names (#6532)

## Summary of the Pull Request

This is another iteration on the Command Palette spec, from #5674. These were some ideas that were tossed around by @DHowett, @cinnamon-msft and myself, formalized here. I proposed this as an addendum to the original spec, since I think the first made sense atomically, and this only makes sense as a set of changes to the original. I didn't want to go hacking up the original doc to add this set of changes. 

**There are two proposals in this spec - they should be viewed as two atomic units. They can be accepted or rejected independently. I'm suggesting we approve both. They work _together_. I'm realizing now that this is worded confusingly, and it's on me to fix that.**

## PR Checklist
* [x] Another spec in the #2046 / #5400 saga
* [x] I work here
* [x] _is a doc_

> ## Abstract
> 
> This document is intended to serve as an addition to the [Command Palette Spec].
> While that spec is complete in it's own right, subsequent discussion revealed
> additional ways to improve the functionality and usability of the command
> palette. This document builds largely on the topics already introduced in the
> original spec, so readers should first familiarize themselves with that
> document.
> 
> One point of note from the original document was that the original specification
> was entirely too verbose when defining both keybindings and commands for
> actions. Consider, for instance, a user that wants to bind the action "duplicate
> the current pane". In that spec, they need to add both a keybinding and a
> command:
> 
> ```json
> {
>     "keybindings": [
>         { "keys": [ "ctrl+alt+t" ], "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" } },
>     ],
>     "commands": [
>         { "name": "Duplicate Pane", "action": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "icon": null },
>     ]
> }
> ```
> 
> These two entries are practically the same, except for two key differentiators:
> * the keybinding has a `keys` property, indicating which key chord activates the
>   action.
> * The command has a `name` property, indicating what name to display for the
>   command in the Command Palette.
> 
> What if the user didn't have to duplicate this action? What if the user could
> just add this action once, in their `keybindings` or `commands`, and have it
> work both as a keybinding AND a command?
>

* Optimize booleans (#6548)

<!-- 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
Many places in this codebase has an equality comparison to the boolean FALSE. This adds unneeded complexity as C and C++ has a NOT operand for use of these in if statements. This makes the code more readable in those areas.

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

<!-- 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
One boolean being compared to FALSE was only used once, with the boolean name being "b", so it is better off not existing at all.

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

* Replace std::map with std::unordered_map (#6640)

Replace std::map with std::unordered_map when the order doesn't matter
and hash functions are provided. Simple optimizations, but I expect the
performance should be strictly better, especially for
CodepointWidthDetector.hpp.

* Update _TerminalCursorPositionChanged to use ThrottledFunc (#6492)

* Update _TerminalCursorPositionChanged to use ThrottledFunc.
* Rename previous ThrottledFunc to ThrottledArgFunc because now
  ThrottledFunc is for functions that do not take an argument.
* Update ThrottledFunc and ThrottledArgFunc to accept a CoreDispatcher
  on which the function should be called for convenience.
* Don't use coroutines/winrt::fire_and_forget in
  ThrottledFunc/ThrottledArgFunc because they are too slow (see PR).

_AdjustCursorPosition went from 17% of samples to 3% in performance
testing.

* version: bump to 1.2 on master

* Add keybinding to rename tab (#6557)

<!-- 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
Add keybinding for renaming a tab
<!-- 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] Fulfills format requirements set by #6567 
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [X] Tests passed
* [X] Requires documentation to be updated
* [X] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #6567 and here (#6557)

This no longer c loses #6256, as the spec changed. 
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

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

* Revert "Skip ... analysis when the ... text is simple (6206)" (#6665)

This reverts commit 94eab6e391a099814ce8f9a08c8cccf9f588b7d1.

We'll reintroduce this again after making sure it plays nicely with
recycling and box drawing glyphs.

Fixes #6488
Fixes #6664

* Implement Shift+MultiClick Selection Expansion (#6322)

This pull request implements shift+double/triple click. Proper behavior
(as described in #4557) is to only expand one selection point, not both.

Adding the `bool targetStart` was a bit weird. I decided on this being
the cleanest approach though because I still want `PivotSelection` to be
its own helper function. Otherwise, the concept of "pivoting" gets kinda
messy.

## Validation Steps Performed
Manual testing as described on attached issue.
Tests were added for Shift+Click and pivoting the selection too.

Closes #4557

* Add `setTabColor` and `openTabColorPicker` actions (#6567)

## Summary of the Pull Request

Adds a pair of `ShortcutAction`s for setting the tab color.
* `setTabColor`: This changes the color of the current tab to the provided color, or can be used to clear the color.
* `openTabColorPicker`: This keybinding immediately activates the tab color picker for the currently focused tab.

## References

## PR Checklist
* [x] scratches my own itch
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/69

## Detailed Description of the Pull Request / Additional comments

## Validation Steps Performed
* hey look there are tests
* Tested with the following:
```json

        // { "command": "setTabColor", "keys": [ "alt+c" ] },
        { "keys": "ctrl+alt+c", "command": { "action": "setTabColor", "color": "#123456" } },
        { "keys": "alt+shift+c", "command": { "action": "setTabColor", "color": null} },
        { "keys": "alt+c", "command": "openTabColorPicker" },
```

* When we add a new tab in compact mode, re-enforce Compact mode (#6670)

This workaround was suggested by @chingucoding in
microsoft/microsoft-ui-xaml#2711

Fixes #6570

## References

microsoft/microsoft-ui-xaml#2711
#6570

## PR Checklist
* [x] Closes an issue
* [x] CLA
* [x] Tested
* [x] Docs not required
* [x] Schema not required

* Hardcode the paths to Windows PowerShell and CMD (#6684)

Occasionally, we get users with corrupt PATH environment variables: they
can't lauch PowerShell, because for some reason it's dropped off their
PATH. We also get users who have stray applications named
`powershell.exe` just lying around in random system directories.

We can combat both of these issues by simply hardcoding where we expect
PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR%
because apparently (according to Stack Overflow), SystemPath is
read-only and WINDIR isn't.

Refs #6039, #4390, #4228 (powershell was not found)
Refs #4682, Fixes #6082 (stray powershell.exe)

* Add support for the Command Palette (#6635)

## Summary of the Pull Request

![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif)


This adds a first iteration on the command palette. Notable missing features are:
* Commandline mode: This will be a follow-up PR, following the merge of #6537
* nested and iterable commands: These will additionally be a follow-up PR.

This is also additionally based off the addenda in #6532. 

This does not bind a key for the palette by default. That will be done when the above follow-ups are completed.

## References
* #2046 - The original command palette thread
* #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work 
* #5674 and #6532 - specs
* #6537 - related

## PR Checklist
* [x] Closes #2046
  - incidentally also closes #6645
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - delaying this until it's more polished.


## Detailed Description of the Pull Request / Additional comments

* There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`.

## Validation Steps Performed

* I've been playing with this for months.
* Tests
* Selfhost with the team

* Restore simple text runs, correct for crashes (#6695)

Restores the simple text run analysis and skipping of most of the
shaping/layout steps. Corrects one of the fast-path steps to ensure that
offsets and clusters are assigned.

## References
- Bug #6488 
- Bug #6664
- Simple run PR #6206 
- Simple run revert PR #6665
- Recycle glyph runs PR #6483

The "correction" functions, by which box drawing analysis is one of
them, is dependent on the steps coming before it properly assigning the
four main vectors of the text layout glyphs: indices, advances, offsets,
and clusters. When the fast path is identified by the code from #6206,
only two of those are fully updated: indices and advances. The offsets
doesn't tend to cause a problem because offsets are rarely used so
they're pretty much always 0 already (but this PR enforces that they're
zero for the simple/fast path.) The clusters, however, were not mapped
for the fast path. This showed itself in one of two ways:
1. Before the recycled runs PR #6483, the cluster map had a 0 in every
   field for the stock initialized vector.
2. After the recycled runs PR #6483, the cluster map had the previous
   run's mapping in it.

This meant that when we reached the steps where glyph runs were
potentially split during the correction phase for box drawing
characters, unexpected values were present to map the glyph indices to
clusters and were corrected, adjusted, or split in an unexpected
fashion. 

For instance, the index out of range bug could appear when the default 0
values appended to the end of the clusters vector were decremented down
to a negative value during the run splitter as the true DWrite cluster
mapper doesn't generate that sort of pattern in the slow path case
without also breaking the run itself.

The resolution here is therefore to ensure that all of the fields
related to glyph layout are populated even in the fast path. This
doesn't affect the slow path because that one always populated all
fields by asking DWrite to do it. The fast path just skips a bunch of
DWrite steps because it can implicitly identify patterns and save a
bunch of time.

I've also identified a few vectors that weren't cleared on reset/reuse
of the layout. I'm clearing those now so the `.resize()` operations
performed on them to get to the correct lengths will fill them with
fresh and empty values instead of hanging on to ones that may have been
from the previous. This should be OK memory perf wise because the act of
`.clear()` on a vector shouldn't free anything, just mark it invalid.
And doing `.resize()` from an empty one should just default construct
them into already allocated space (which ought to be super quick).

## Validation
* [x] Far.exe doesn't crash and looks fine
* [x] "\e[30;47m\u{2500} What \u{2500}\e[m" from #6488 appears
  appropriately antialiased
* [x] Validate the "\e[30;47m\u{2500} What \u{2500}\e[m" still works
  when `FillGeometry` is nerfed as a quick test that the runs are split
  correctly.
* [x] Put `u{fffd} into Powershell Core to make a replacement char in
  the output. Then press enter a few times and see that shrunken initial
  characters on random rows. Verify this is gone.

Closes #6668
Closes #6669

Co-Authored-By: Chester Liu <skyline75489@outlook.com>

* Update Cascadia Code to 2007.01 (#6721)

* Add support for OSC 52 (copy-to-clipboard) (#5823)

With this commit, terminal will be able to copy text to the system
clipboard by using OSC 52 MANIPULATE SELECTION DAATA.

We chose not to implement the clipboard querying functionality offered
by OSC 52, as sending the clipboard text to an application without the
user's knowledge or consent is an immense security hole.

We do not currently support the clipboard specifier Pc to specify which
clipboard buffer should be filled

# Base64 encoded `foo`
$ echo -en "\e]52;;Zm9v\a"

# Multiple lines
# Base64 encoded `foo\r\nbar`
$ echo -en "\e]52;;Zm9vDQpiYXI=\a"

Closes #2946.

* Replace old C headers (xxx.h) with modern ones (cxxx) (#5080)

* Improve conpty rendering of default colors in legacy apps (#6698)

Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.

One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.

Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.

So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).

And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values …
@Poopooracoocoo
Copy link

@Poopooracoocoo Poopooracoocoo commented Sep 25, 2020

Oh and right clicking on the caption buttons in the title bar doesn't open Sizer's menu, an app by Brianapps that works with the Office suite which appears to have a custom title bar.

@mdtauk
Copy link

@mdtauk mdtauk commented Dec 12, 2020

Ignoring the Rounded Window Border (that will probably come to Windows with the new "Sun Valley" UI refresh) Here is how I would imagine a more immersive Terminal could look.
image
image

Edit:
image
Example with scrolled content

So the Titlebar uses the Console background - the Tabs blend in with an active tab standing out - and the Window Controls adapting their colour to contrast well.

@desmap
Copy link

@desmap desmap commented Jan 4, 2021

Acrylic/transparency is turned off on Alt-Tab, both in the preview thumbs and in the actual window.

Is this here the right place to report and should I open a new issue?

@DHowett
Copy link
Member

@DHowett DHowett commented Jan 4, 2021

@desmap I believe that if you look in this thread and search in our historic issues, you will find an existing report for that behavior. 😄

@just1a-person
Copy link

@just1a-person just1a-person commented Feb 11, 2021

Can we change the title? The UI isn't that bad now?

@miniksa miniksa changed the title MEGA THREAD: Design is not complete, UI is not polished MEGA THREAD: Design still subject to change, UI is pretty okay though Feb 12, 2021
@ghost
Copy link

@ghost ghost commented Mar 1, 2021

Hi, I looked into some issues with the TabView and ways to fix them.

Currently, TabView is customized to remove all padding except for the left, which causes the top shadow and the rightmost tab corner to be cut.
tabs_125x

However, if the custom padding is removed, it will persist when the window is maximized. This is because the space is created by changing the height of the caption buttons and not that of the TabView.
This could be fixed by adding/removing a negative margin instead when maximizing/windowing respectively.

TabView has a 8px top padding by default, instead of the 4px used by Terminal. I would suggest using the default, as it looks more balanced and other tabbed apps have it like that as well.
tabapps

As seen above, the TabStrip shadow is discontinued to the right because the TabView doesn't span the entire window.
This could be fixed by moving the DragBar and caption buttons to the TabViewFooter, or having them float above.
tabs_shadow

@shaheedmalik
Copy link

@shaheedmalik shaheedmalik commented Mar 1, 2021

Hi, I looked into some issues with the TabView and ways to fix them.

Currently, TabView is customized to remove all padding except for the right, which causes the top shadow and the rightmost tab corner to be cut.
tabs_125x

However, if the custom padding is removed, it will persist when the window is maximized. This is because the space is created by changing the height of the caption buttons and not that of the TabView.
This could be fixed by adding/removing a negative margin instead when maximizing/windowing respectively.

TabView has a 8px top padding by default, instead of the 4px used by Terminal. I would suggest using the default, as it looks more balanced and other tabbed apps have it like that as well.
tabapps

As seen above, the TabStrip shadow is discontinued to the right because the TabView doesn't span the entire window.
This could be fixed by moving the DragBar and caption buttons to the TabViewFooter, or having them float above.
tabs_shadow

This is due to the Desktop Window Manager not correctly scaling windows properly. It isn't a glitch with the TabView. Microsoft Edge has this same problem with the tab spacing at the top of the tab. Other windows have this problem but because there usually no noticable elements there, most people miss it. It is the reason why the Minimize Restore, Close buttons appear off.

@ghost
Copy link

@ghost ghost commented Mar 1, 2021

Those issues are unrelated to the caption buttons looking off.
Currently, Terminal sets a custom padding in App.xaml, which if removed will solve the first problem.
<Thickness x:Key="TabViewHeaderPadding">8,0,0,0</Thickness>

The tab spacing is intentional, but Terminal should do it in a different way so that the shadow isn't cut.

Edit: The default TabView padding is 8,8,8,0, for reference.

@brendomaciel
Copy link

@brendomaciel brendomaciel commented Apr 9, 2021

I don't know if this is the right place to put this proposal, but here we goes:

image

What do you guys think about a more like Notepads app tab style?

I don't know why, but their acrylic works even with the unfocused window. Another detail is the fact that they put a little bit of extra personalization with the OS accent color in some places of the application (like tab border and menu icon color).

@DarthJahus
Copy link

@DarthJahus DarthJahus commented Apr 10, 2021

Can we have a visual indicator when Pause / Wait keyboard button is pressed? Maybe add it to the tab title : (paused) ; or add an optional status bar.

@r4dian
Copy link

@r4dian r4dian commented Apr 11, 2021

If Powerline/ohmyzsh/zpresto, (for example) adds a background on the right of the line, then once you hit the bottom of the window that background appears also in places it shouldn't (to repro, run a command with long output twice, with a similar prompt setup.)

Screenshot 2021-04-11 235044

@ghost
Copy link

@ghost ghost commented May 27, 2021

image

The acrylic NavigationView doesn't look that good with tabs.
I think it should either have the same background as the rest of the page, or there should be a header above it.

@ghost
Copy link

@ghost ghost commented Jun 8, 2021

image

I suggest having the search menu (Ctrl+Shift+F) be detached from the titlebar for a couple of reasons:

  • the new WinUI TabView style has a border at the bottom and the menu won't be seamlessly connected anymore
  • WinUI now tries to avoid having sharp corners at all
  • other apps with a similar menu have it being detached

Would something like this be good? It has an 8px margin at the top, like the Command Palette.
searchmenu

@ghost ghost mentioned this issue Sep 1, 2021
@Tropix126
Copy link

@Tropix126 Tropix126 commented Sep 7, 2021

I've thrown together this quick concept of what Terminal might look like with WinUI 2.6 controls and mica.
image

@Tropix126
Copy link

@Tropix126 Tropix126 commented Sep 8, 2021

image
Dark mode

@Tropix126
Copy link

@Tropix126 Tropix126 commented Sep 8, 2021

imageSettings

image About dialog + Command palette

@Tropix126
Copy link

@Tropix126 Tropix126 commented Sep 8, 2021

image
Finally, here's a concept for the find and replace flyout based on @gabrielconl 's idea

@hyperactiverobot
Copy link

@hyperactiverobot hyperactiverobot commented Sep 8, 2021

I've thrown together this quick concept of what Terminal might look like with WinUI 2.6 controls and mica.
image

Yes!!!!!!

@miniksa
Copy link
Member

@miniksa miniksa commented Sep 8, 2021

Thanks @Tropix126. We are trying to move to WinUI 2.6 so we can get their styling work, but we're currently blocked by microsoft/microsoft-ui-xaml#5435. I've engaged with the WinUI team internally to hopefully get us past this.

msftbot bot pushed a commit that referenced this issue Sep 9, 2021
Made some changes to the search box:
* Adjusted spacing inside the box
* Detached the search box from the titlebar (as explained [here](#1375 (comment)))
* The search box is now 8px further to the left, in case the scrollbar is always enabled
* Made some controls use default properties, so that they'll adjust nicely to the 2.6 styles

Other: the search box and command palette now use OverlayCornerRadius

Before/After:
![image](https://user-images.githubusercontent.com/84711285/131888377-513b9de4-a653-4086-9a67-8718c64dc75b.png)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet