MouseInput was directly asking user32 about the state of the mouse buttons,
which was somewhat of a layering violation. This commit makes all callers
have to pass the mouse state in themselves.
Closes#4869
This PR adds the `togglePaneZoom` action, which can be used to make a
pane expand to fill the entire contents of the window. A tab that
contains a zoomed pane will have a magnifying glass icon prepended
to its title. Any attempts to manage panes with one zoomed will force
the zoomed pane back to normal size.
VALIDATION
Zoomed in and out a bunch. Tried closing panes while zoomed. Tried
splitting panes while zoomed. Etc.
Closes#996
This PR adds support for per-profile tab colors, in accordance with
#7134. This adds a single `tabColor` property, that when set, specifies
the background color for profile's tab. This color can be overridden by
the color picker, and clearing the color with the color picker will
revert to this default color set for the tab.
* Full theming is covered in #3327 & #5772
Validation: Played with setting this color, both on launch and via
hot-reload
Specified in #7134Closes#1337
## Summary of the Pull Request
Move `ICoreSettings` and `IControlSettings` from the TerminalSettings project to the TerminalCore and TerminalControl projects respectively. Also entirely removes the TerminalSettings project.
The purpose of these interfaces is unchanged. `ICoreSettings` is used to instantiate a terminal. `IControlSettings` (which requires an `ICoreSettings`) is used to instantiate a UWP terminal control.
## References
Closes#7140
Related Epic: #885
Related Spec: #6904
## PR Checklist
* [X] Closes#7140
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~
## Detailed Description of the Pull Request / Additional comments
A lot of the work here was having to deal with winmd files across all of these projects. The TerminalCore project now outputs a Microsoft.Terminal.TerminalControl.winmd. Some magic happens in TerminalControl.vcxproj to get this to work properly.
## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.
## Summary of the Pull Request
Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter.
* `closeOtherTabs`: Close tabs other than `index`
* `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right")
## References
* This PR is being made to unblock @RahulRavishankar in #1912
## PR Checklist
* [x] I work here
* [ ] Tests added/passed
* [x] Requires documentation to be updated
* [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action
* [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided
## Validation Steps Performed
* _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_
* _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_
* _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_
* _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_
- This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
Up until #4999 we deferred all key events to the character event handler
for which `ToUnicodeEx` returned a valid character and alternatively
those who aren't a special key combination as listed in
`TerminalInput`'s implementation.
Since #4999 we started acknowledging/handling all key events no matter
whether they're actually a known key combination. Given non-ASCII inputs
the Win32 `SendInput()` method generates certain sequences that aren't
recognizable combinations though and if they're handled by the key event
handler no follow up character event is sent containing the unicode
character.
This PR adds another condition and defers all key events without scan
code (i.e. those not representable by the current keyboard layout) to
the character event handler.
I'm absolutely not certain that this PR doesn't have a negative effect
on other kinds of inputs.
Is it common for key events to not contain a scan code? I personally
haven't seen it happen before AutoHotKey/SendInput.
Before this PR is merged it'd be nice to have a good testing plan in
place in order to ensure nothing breaks.
## Validation Steps Performed
Remapped `AltGr+8` to `»` using AutoHotKey using `<^>!8::SendInput {Raw}»`.
Ensured `»` is printed if `AltGr+8` is pressed.
Closes#7064Closes#7120
I found this while crawling through conhost's WindowIo. Mouse wheel
events come in in screen coordinates, unlike literally every other mouse
event.
The WPF control was doing it wrong.
This pull request fixes capture and event generation in VT mouse mode
for both conhost and terminal.
Fixes#6401.
[1/3] Terminal: clamp mouse events to the viewport, don't throw them away
gnome-terminal (at least) sends mouse events whose x/y are at the
extreme ends of the buffer when a drag starts inside the terminal and
then exits it.
We would previously discard any mouse events that exited the borders of
the viewport. Now we will keep emitting events where X/Y=0/w/h.
[2/3] conhost: clamp VT mouse to viewport, capture pointer
This is the same as (1), but for conhost. conhost wasn't already
capturing the pointer when VT mouse mode was in use. By capturing, we
ensure that events that happen outside the screen still result in events
sent to an application (like a release after a drag)
[3/3] wpf: capture the pointer when VT mouse is enabled
This is the same as (2), but for the WPF control. Clamping is handled
in TerminalCore in (1), so we didn't need to do it in WPF.
Move TerminalSettings object from TerminalSettings project
(Microsoft.Terminal.Settings) to TerminalApp project. `TerminalSettings`
specifically operates as a bridge that exposes any necessary information
to a TerminalControl.
Closes#7139
Related Epic: #885
Related Spec: #6904
## PR Checklist
* [X] Closes#7139
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~
## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.
Add some user research to determine what the average number of characters a user types before executing a cmdpal action.
This might need to be modified when it merges with #6732
Updates TAEF to 10.57.200731005-develop
## PR Checklist
* [x] Helps #6992 by bringing `wttlog.dll` along with the rest of TAEF.
* [x] I work here.
* [x] Automated tests in CI
* [x] No doc/schema update necessary (checked for docs in this repo)
* [x] Am core contributor.
When we added support for win32 input mode, we neglected to pass
`ENHANCED_KEY` through the two surfaces that would generate events. This
broke arrow keys in much the same way was #2397, but in a different
layer.
While I was working on the WPF control, I took a moment to refactor the
message cracking out into a helper. It's a lot easier on the eyes than
four lines of bit shifting repeated three times.
Fixes#7074
Allows splitting pane (with default settings) by holding down ALT and pressing the new tab button ('+')
## PR Checklist
* [X] Closes#6757
* [X] Works here.
* [X] Manual test (below)
* [X] Is core contributor.
## More detailed description
Pretty much exactly the code added in #5928 (all credit to @carlos-zamora), but put at the new tab button event binding
## Validation steps
Seems to work - holding ALT while pressing '+' opens a pane instead of a tab. Holding ALT while starting up terminal for the first time does not seem to affect the behaviour.
We've been trying to improve the copy/paste experience with the terminal
in Visual Studio. Once of our problematic scenarios is when the terminal
is connected to a remote environment and the user attempts to
copy/paste. This gets forwarded to the remote shell that copy/paste into
the remote clipboard instead of the local one.
So we opted to add ctrl+shift+c/v to the terminal and need access to the
selected text via the terminal control
VALIDATION
Tested with Visual Studio integrated terminal
* send alt/F10 through the control
We were not listening for WM_SYSKEY{UP,DOWN}
* extract the actual scancode during WM_CHAR, not the bitfield
We were accidentally sending some of the additional keypress data in with
the character event in Win32 Input Mode
* set default fg/bg to campbell
The WPF control starts up in PowerShell blue even though it's not typically used
in PowerShell blue.
* don't rely on the font to determine wideness
This is a cross-port of #2928 to the WPF control
* deterministic shutdown
In testing, I saw a handful of crashes on teardown because we were not shutting
down the render thread properly.
* don't pass 10 for the font weight ...
When Cascadia Code is set, it just looks silly.
* trigger render when selection is cleared, do it under lock
Fixes#6966.
Original notes from @M-Pixel:
> Console applications assume that backgrounds are black, and that
> `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This
> assumption is accounted for by all color schemes in `defaults.json`,
> except for the Solarized themes.
>
> The Solarized Dark theme, in particular, makes `-Parameters` invisible
> against the background in PowerShell, which is obviously an unacceptable
> usability flaw.
>
> This change makes `black` and `background` to the same (which is common
> throughout the color schemes), and makes `brightBlack` (`DarkGray` in
> .NET) lighter than black (which is obviously more correct given the
> meanings of those words).
Out of the box, we ship a pretty bad behavior.
If I look at all of the existing shipped color schemes--and that
includes things like Tango and One Half--we are universally following a
`background` == `black` rule.
If I consult gnome-terminal or xterm, they do the same thing; Xterm by
default, gnome-terminal for solarized. The background generally matches
color index `0` across all their **dark** schemes. Konsole and
lxterminal disagree and map background to `0 intense` for Solarized.
I want to put our Solarized schemes on a deprecation path, but
unfortunately we still need to ship _something_ for users who we're
going to strand on them.
I'm going to have to swallow my bitter and say that yes, we should
probably just change the index mapping and go with something that works
right out of the box while we figure out how to do perceptual color
nudging and eventually remove bad defaults (like Solarized).
From #6618.
Fixes#4047.
Closes#6618.
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
By default, the memory order on atomics is `seq_cst`. This is a relatively expensive ordering and it shows in situations where we're rapidly signaling a consumer to pick up something from a producer. I've instead attempted to switch these to `release` (producer) and `acquire` (consumer) to improve the performance of these signals.
## Validation Steps Performed
- Run `time cat big.txt` and `time cat ls.txt` under VS Performance Profiler.
## PR Checklist
* [x] Closes perf itch
* [x] I work here
* [x] Manual test
* [x] Documentation irrelevant.
* [x] Schema irrelevant.
* [x] Am core contributor.
## Summary of the Pull Request
Text can have various attributes, such as "bold", "italic", "underlined", etc. The TextAttribute class embodies this. It has methods to set/query these attributes.
This change tweaks a few of the method names to make them match. I.e. for an imaginary text property "Foo", we should have methods along the lines of:
```
IsFoo
SetFoo(bool isFoo)
```
And variations should match: we should have "Foo" and "OverFoo", not "Fooey" and "OverFoo".
I chose to standardize on the adjective form, since that's what we are closest to already. The attributes I attacked here are:
SetItalic**s** --> SetItalic
SetUnderline --> SetUnderline**d**
SetOverline --> SetOverline**d**
("italic" is an adjective; "italics" is a plural noun, representing letters or words in an italic typeface)
And I also added methods for "DoublyUnderlined" for good measure.
I stopped short of renaming the GraphicsOptions enum values to match, too; but I'd be willing to do that in a follow-up change if people wanted it.
## Validation Steps Performed
It builds, and tests still pass.
This pull request converts the following JSON deserializers to use the
new JSON deserializer pattern:
* Profile
* Command
* ColorScheme
* Action/Args
* GlobalSettings
* CascadiaSettingsSerialization
This is the completion of a long-term JSON refactoring that makes our
parser and deserializer more type-safe and robust. We're finally able to
get rid of all our manual enum conversion code and unify JSON conversion
around _types_ instead of around _keys_.
I've introduced another file filled with template specializations,
TerminalSettingsSerializationHelpers.h, which comprises a single unit
that holds all of the JSON deserializers (and eventually serializers)
for every type that comes from TerminalApp or TerminalSettings.
I've also moved some types out of Profile and GlobalAppSettings into a
new SettingsTypes.h to improve settings locality.
This does to some extent constitute a breaking change for already-broken
settings. Instead of parsing "successfully" (where invalid values are
null or 0 or unknown or unset), deserialization will now fail when
there's a type mismatch. Because of that, some tests had to be removed.
While I was on a refactoring spree, I removed a number of helpless
helpers, like GetWstringFromJson (which converted a u8 string to an
hstring to make a wstring out of its data pointer :|) and
_ConvertJsonToBool.
In the future, we can make the error types more robust and give them
position and type information such that a conformant application can
display rich error information ("line 3 column 3, I expected a string,
you gave me an integer").
Closes#2550.
The command palette is a ListView of commands. As you type into the
search box, commands are added or removed from the ListView. Currently,
each update is done by completely clearing the backing list, then adding
back any items that should be displayed. However, this defeats the
ListView's built-in animations: upon every keystroke, ListView displays
its list-clearing animation, then animates the insertion of every item
that wasn't deleted. This results in noticeable flickering.
This PR changes the update logic so that it updates the list using
(roughly) the minimum number of Insert and Remove calls, so the ListView
makes smoother transitions as you type.
I implemented it by keeping the existing code that builds the filtered
list, but I changed it to build into a scratch list. Then I grafted on
a generic delta algorithm to make the real list look like the scratch
list.
To verify the delta algorithm, I tested all 360,000 permutations of
pairs of up to 5 element lists in a toy C# app.
## Validation
I'm not sure if my screen capture tool really caught all the flickering
here, but the screencasts below should give a rough idea of the
difference. (All the flickering was becoming a nuisance while I was
testing out the HC changes.)
See the images in #6939 for more info.
Co-authored-by: Jeffrey Tippet <jtippet@microsoft.com>
We were using std::basic_string_view as a stand-in for std::span so that
we could change over all at once when C++20 dropped with full span
support. That day's not here yet, but as of 54a7fce3e we're using GSL 3,
whose span is C++20-compliant.
This commit replaces every instance of basic_string_view that was not
referring to an actual string with a span of the appropriate type.
I moved the `const` qualifier into span's `T` because while
`basic_string_view.at()` returns `const T&`, `span.at()` returns `T&`
(without the const). I wanted to maintain the invariant that members of
the span were immutable.
* Mechanical Changes
* `sv.at(x)` -> `gsl::at(sp, x)`
* `sv.c{begin,end}` -> `sp.{begin,end}` (span's iterators are const)
I had to replace a `std::basic_string<>` with a `std::vector<>` in
ConImeInfo, and I chose to replace a manual array walk in
ScreenInfoUiaProviderBase with a ranged-for. Please review those
specifically.
This will almost certainly cause a code size regression in Windows
because I'm blowing out all the PGO counts. Whoops.
Related: #3956, #975.
This PR adds support for always on top mode, via two mechanisms:
* The global setting `alwaysOnTop`. When set to true, the window will be
created in the "topmost" group of windows. Changing this value will
hot-reload whether the window is in the topmost group.
* The action `toggleAlwaysOnTop`, which will toggle the `alwaysOnTop`
property at runtime.
## Detailed Description of the Pull Request / Additional comments
All "topmost" windows maintain an internal z-ordering relative to one
another, but they're all always above all other "non-topmost" windows.
So multiple Windows Terminal windows which are both `alwaysOnTop` will
maintain a z-order relative to one another, but they'll all be on top of
all other windows.
## Validation Steps Performed
Toggled always on top mode, both in the settings and also at runtime,
and verified that it largely did what I expected.
Closes#3038
This adds `nt`, `sp`, and `ft` as aliases for `new-tab`, `split-pane`,
and `focus-tab`, respectively. These do exactly the same thing as their
long for counterparts, but are just shorter, for those of us who type
slower than a fifth grader 👀
Now you can do
```
wt nt cmd.exe /k #work 15 ; sp cmd.exe /k #work 15 ; sp cmd.exe /k
media-commandline ; nt powershell dev\\symbols.ps1 ; nt -p \"Ubuntu\" ;
nt -p \"Ubuntu\" ; ft -t 0
```
instead of
```
new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ;
split-pane cmd.exe /k media-commandline ; new-tab powershell
dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"Ubuntu\" ;
focus-tab -t 0
```
The pattern I'm using here is that each of these subcommands now has a
little helper lambda that actually sets up the subcommand with the
required arguments, and we just call that lambda twice, once for the
long-form of the command, and again for the short.
I imagine that in the future, we won't necessarily have short-forms for
every subcommands, so if there are future conflicts we'd have to figure
that out pre-emptively, but these all seem like they'll need a short
form.
Closes#5466
GSL 3, the next major version of GSL after the one we're using, replaced
their local implementation of `span` with one that more closely mimics
C++20's span. Unfortunately, that is a breaking change for all of GSL's
consumers.
This commit updates our use of span to comply with the new changes in
GSL 3.
Chief among those breaking changes is:
* `span::at` no longer exists; I replaced many instances of `span::at`
with `gsl::at(x)`
* `span::size_type` has finally given up on `ptrdiff_t` and become
`size_t` like all other containers
While I was here, I also made the following mechanical replacements:
* In some of our "early standardized" code, we used std::optional's
`has_value` and `value` back-to-back. Each `value` incurs an
additional presence test.
* Change: `x.value().member` -> `x->member` (`optional::operator->`
skips the presence test)
* Change: `x.value()` -> `*x` (as above)
* GSL 3 uses `size_t` for `size_type`.
* Change: `gsl::narrow<size_t>(x.size())` -> `x.size()`
* Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()`
during span construction
I also replaced two instances of `x[x.size() - 1]` with `x.back()` and
one instance of a manual array walk (for comparison) with a direct
comparison.
NOTE: Span comparison and `make_span` are not part of the C++20 span
library.
Fixes#6251
This parameter was added as a workaround for our fast trackpad
scrolling. Since that was fixed before 1.0 shipped, in #4554, it has
been largely vestigial. There is no reason for us to keep it around any
longer.
It was also the only "logic" in TerminalSettings, which is otherwise a
library that only transits data between two other libraries.
I have not removed it from the schema, as I do not want to mark folks'
settings files invalid to a strict schema parser.
While I was in the area, I added support for "scroll one screen at a
time" (which is represented by the API returning WHEEL_PAGESCROLL),
fixing #5610. We were also storing it in an int (whoops) instead of a
uint.
Fixes#5610
## Summary of the Pull Request
This PR adds support for the `SGR 2` escape sequence, which enables the
ANSI _faint_ graphic rendition attribute. When a character is output
with this attribute set, it uses a dimmer version of the active
foreground color.
## PR Checklist
* [x] Closes#6703
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #6703
## Detailed Description of the Pull Request / Additional comments
There was already an `ExtendedAttributes::Faint` flag in the
`TextAttribute` class, but I needed to add `SetFaint` and `IsFaint`
methods to access that flag, and update the `SetGraphicsRendition`
methods of the two dispatchers to set the attribute on receipt of the
`SGR 2` sequence. I also had to update the existing `SGR 22` handler to
reset _Faint_ in addition to _Bold_, since they share the same reset
sequence. For that reason, I thought it a good idea to change the name
of the `SGR 22` enum to `NotBoldOrFaint`.
For the purpose of rendering, I've updated the
`TextAttribute::CalculateRgbColors` method to return a dimmer version of
the foreground color when the _Faint_ attribute is set. This is simply
achieved by dividing each color component by two, which produces a
reasonable effect without being too complicated. Note that the _Faint_
effect is applied before _Reverse Video_, so if the output it reversed,
it's the background that will be faint.
The only other complication was the update of the `Xterm256Engine` in
the VT renderer. As mentioned above, _Bold_ and _Faint_ share the same
reset sequence, so to forward that state over conpty we have to go
through a slightly more complicated process than with other attributes.
We first check whether either attribute needs to be turned off to send
the reset sequence, and then check if the individual attributes need to
be turned on again.
## Validation
I've extended the existing SGR unit tests to cover the new attribute in
the `AdapterTest`, the `ScreenBufferTests`, and the `VtRendererTest`,
and added a test to confirm the color calculations when _Faint_ is set
in the `TextAttributeTests`.
I've also done a bunch of manual testing with all the different VT color
types and confirmed that our output is comparable to most other
terminals.
## Summary of the Pull Request
Add support for "focus" mode, which only displays the actual terminal content, no tabs or titlebar. The edges of the window are draggable to resize, but the window can't be moved in borderless mode.
The window looks _slightly_ different bewteen different values for `showTabsInTitlebar`, because switching between the `NonClientIslandWindow` and the `IslandWindow` is _hard_.
`showTabsInTitlebar` | Preview
-- | --
`true` | 
`false` | 
## PR Checklist
* [x] Closes#2238
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
* **KNOWN ISSUE**: Upon resizing the NCIW, the top frame margin disappears, making that border disappear entirely. 6356aaf has a bunch of WIP work for me trying to fix that, but I couldn't get it quite right.
## Validation Steps Performed
* Toggled between focus and fullscreen a _bunch_ in both modes.
This commit updates JsonUtilsNew to support winrt
`Windows::Foundation::IReference<T>` as an option type, and cleans up the
optional support code by removing the optional overload on
`GetValue(...)`. Instead of using an overload with a partial
specialization, we're using a constexpr if with a type trait to
determine option-type-ness.
In addition, Carlos reported an issue with deriving from `FlagMapper`
(itself templated) and referring to the base type's members without
fully qualifying them. To make derivation easier, `EnumMapper` and
`FlagMapper` now provide `BaseEnumMapper` and `BaseFlagMapper` type
aliases.
I've taken the opportunity to add a `winrt::hstring` conversion
trait.
Lastly, in casual use, I found out that I'd written the til::color
converter wrong: it supports color strings of length 7 (`#rrggbb`) and
length 4 (`#rgb`). I mistyped (and failed to test) support for 4-length
color strings by pretending they were only 3 characters long.
## References
Merged JsonUtils changes from #6004 and #6590.
## PR Checklist
* [x] Unblocks aforementioned PRs
* [x] cla
* [x] Tests added/passed
* [x] Documentation N/A
* [x] Schema N/A
* [x] Kid tested, mother approved.
Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows
Terminal as Administrator. This is caused by the app execution alias and
the actual targeted executable not having the same name.
In addition, PowerShell has an issue detecting app execution aliases as
GUI/TUI applications. When you run wt from PowerShell, the shell will
wait for WT to exit before returning to the prompt. Having a shim that
immediately re-executes WindowsTerminal and then returns handily knocks
this issue out (as the process that PS was waiting for exits
immediately.)
This could cause a regression for anybody who tries to capture the PID
of wt.exe. Our process tree is not an API, and we have offered no
consistency guarantee on it.
VALIDATION
----------
Tested manual launch in a number of different scenarios:
* [x] start menu "wtd"
* [x] start menu tile
* [x] powertoys run
* [x] powertoys run ctrl+shift (admin)
* [x] powershell inbox, "core"
* [x] cmd
* [x] run dialog
* [x] run dialog ctrl+shift (admin)
* [x] run from a lnk with window mode=maximized
Fixes#4645 (PowerShell waits for wt)
Fixes#6625 (Can't launch as admin using C-S-enter)
This is a refactoring of the renderer color calculations to simplify the
implementation, and to make it easier to support additional
color-altering rendition attributes in the future (e.g. _faint_ and
_conceal_).
## References
* This is a followup to PRs #3817 and #6809, which introduced additional
complexity in the color calculations, and which suggested the need for
refactoring.
## Detailed Description of the Pull Request / Additional comments
When we added support for `DECSCNM`, that required the foreground and
background color lookup methods to be able to return the opposite of
what was requested when the reversed mode was set. That made those
methods unnecessarily complicated, and I thought we could simplify them
considerably just by combining the calculations into a single method
that derived both colors at the same time.
And since both conhost and Windows Terminal needed to perform the same
calculations, it also made sense to move that functionality into the
`TextAttribute` class, where it could easily be shared.
In general this way of doing things is a bit more efficient. However, it
does result in some unnecessary work when only one of the colors is
required, as is the case for the gridline painter. So to make that less
of an issue, I've reordered the gridline code a bit so it at least
avoids looking up the colors when no gridlines are needed.
## Validation Steps Performed
Because of the API changes, quite a lot of the unit tests had to be
updated. For example instead of verifying colors with two separate calls
to `LookupForegroundColor` and `LookupBackgroundColor`, that's now
achieved with a single `LookupAttributeColors` call, comparing against a
pair of values. The specifics of the tests haven't changed though, and
they're all still working as expected.
I've also manually confirmed that the various color sequences and
rendition attributes are rendering correctly with the new refactoring.
## Summary of the Pull Request
This PR adds full support for the `DECSCNM` reverse screen mode in the Windows Terminal to align with the implementation in conhost.
## References
* The conhost implementation of `DECSCNM` was in PR #3817.
* WT originally inherited that functionality via the colors being passed through, but that behaviour was lost in PR #6506.
## PR Checklist
* [x] Closes#6622
* [x] CLA signed.
* [ ] 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.
* [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: #6622
## Detailed Description of the Pull Request / Additional comments
The `AdaptDispatch::SetScreenMode` now checks if it's in conpty mode and simply returns false to force a pass-through of the mode change. And the `TerminalDispatch` now has its own `SetScreenMode` implementation that tracks any changes to the reversed state, and triggers a redraw in the renderer.
To make the renderer work, we just needed to update the `GetForegroundColor` and `GetBackgroundColor` methods of the terminal's `IRenderData` implementation to check the reversed state, and switch the colors being calculated, the same way the `LookupForegroundColor` and `LookupBackgroundColor` methods work in the conhost `Settings` class.
## Validation Steps Performed
I've manually tested the `DECSCNM` functionality for Windows Terminal in Vttest, and also with some of my own test scripts.
## Summary of the Pull Request
Updates the Terminal's scroll response to new output. The Terminal will not automatically scroll if...
- a selection is active, or
- the viewport is at the bottom of the scroll history
## References
#2529 - Spec
#3863 - Implementation
## PR Checklist
* [X] Closes#980
* [X] Closes#3863
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Updates the `_scrollOffset` value properly in TerminalCore when the cursor moves. We calculate a new `_scrollOffset` based on if we are circling the buffer and how far below the mutable bottom is.
We specifically check for if a selection is active and if the viewport is at the bottom, then use that as a condition for deciding if we should update `_scrollOffset` to the new calculated value or 0 (the bottom of the scroll history).
## Validation Steps Performed
Manual testing. Though I should add automated tests.
- [X] new output
- [X] new output when circling
- [X] new output when circling and viewport is at the top
The main change in 16.7 is the separation of `AppContainerApplication`
into `WindowsStoreApp` and `WindowsAppContainer`. There's been a bit of
interest in splitting packaging away from containment, and this is the
first step in that direction.
We're a somewhat unique application, but as WinUI3 becomes more
prevalent we will become _less_ unique.
Some of these things, I've looked at and wondered how they ever worked.
## PR Checklist
* [x] Closes nothing
## Validation Steps Performed
Built locally and in CI. Tested the generated package with the package tester. Built on 16.6 and seen that it still seems to work.
This PR enables `ApplicationHighContrastAdjustment::None`. Doing this
disables a set of mitigations in XAML designed to band-aid apps that
were never explicitly designed for High Contrast (HC) modes. Terminal
now has full control of and responsibility for its appearance in HC
mode. This allows Terminal to look a lot better.
On paper, we should be able to set `HighContrastAdjustment="None"` on
the `<Application>` element. But that doesn't have any effect. I don't
know if this is a bug in `<Toolkit:XamlApplication>` or somewhere else.
So instead I set the property in codebehind, which is not as ideal, but
does at least work. I'd love to a way to move this into App.xaml.
The Find box had a couple stray styles to override the ToggleButton's
foreground color. With backplating removed, these styles became
actively harmful (white foreground on highlight color background), so I
just removed them. The built-in style for ToggleButton is perfect
as-is.
Closes#5360
WinUI's `Margin` and `Padding` work very similarly. `Margin` distances
ourselves from our parent. Whereas `Padding` distances our children from
ourselves.
Terminal's `padding` setting is actually implemented by defining
`Margin` on the SwapChainPanel. This means that the "padding" that is
created is actually belongs to SwapChainPanel's parent: Grid (not to be
confused with its parent, "RootGrid").
When a user clicks on the padded area, input goes to Grid. But there's a
twist: you can't actually hit Grid. To be able to hit Grid, you can't
just set IsHitTestVisible. You need to set it's Visibility to Visible,
and it's Background to Transparent (not null) [2].
## Validation Steps Performed
- [X] Start a selection from the padding area
- [X] Click on a SearchBox if one is available
- The SearchBox gets first dibs on the hit test so none gets through
to the SwapChainPanel
## References
[1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.ishittestvisible
[2] https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/events-and-routed-events-overview#hit-testing-and-input-eventsCloses#5626
## Summary of the Pull Request
Pretty straightforward. Logs three scenarios:
* The user opened the command palette (and which mode it was opened in)
* The user ran a command from the palette
* The user dismissed the palette without running an action.
We discussed this in team sync yesterday.
## PR Checklist
* [x] I work here
* [n/a] Requires documentation to be updated
See: https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.200609001
> ### Notable Changes:
>
> Resize tab view items only once the pointer has left the TabViewItem strip (microsoft/microsoft-ui-xaml#2569)
> Align TabView visuals with Edge (microsoft/microsoft-ui-xaml#2201)
> Fix background of MenuFlyout in white high contrast (microsoft/microsoft-ui-xaml#2446)
> TabView: Make TabViewItem consume the TabViewItemHeaderForeground theme resource (microsoft/microsoft-ui-xaml#2348)
> TabView: Add tooltips to its scrolling buttons. (microsoft/microsoft-ui-xaml#2369)
* [x] Related to #5360 (@jtippet confirms that this alone does not close it.)
* [x] I work here
## Summary of the Pull Request
In the wake of #6635, a couple things got missed in merges:
* `toggleRetroEffect` didn't get into the schema, nor did `renameTab` or
`commandPalette`.
* `toggleRetroEffect` also didn't get a name
Furthermore, I thought it might be a good idea to start sticking
commands into `bindings` even without `keys`. So I tried doing that for
`opentabColorPicker` and `toggleRetroEffect`, and found immediately that
the labels for the key chord still appear even when the text is empty.
So I added some XAML magic to hide those when the text is empty.
## References
* #6762
* #6691
* #6557
* #6635
## PR Checklist
* [x] Closes#6762
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
* See also: https://docs.microsoft.com/en-us/windows/uwp/data-binding/data-binding-quickstart#formatting-or-converting-data-values-for-display
- make sure to switch to C++/WinRT at the top!
## Validation Steps Performed
Removed all my manual actions, ran the Terminal:
Update colors of our custom NewTab button to match MUX's TabView button
MUX has a NewTab button, but Terminal uses a homemade lookalike. The
version in Terminal doesn't use the same brush color resources as MUX's
button, so it looks very slightly different. This PR updates Terminal's
button to use the exact same colors that MUX uses. I literally copied
these brush names out of MUX source code.
## References
This is the color version of the layout fix#6766
This is a prerequisite for fixing #5360
## Detailed Description of the Pull Request / Additional comments
The real reason that this matters is that once you flip on
`ApplicationHighContrastAdjustment::None`, the existing colors will not
work at all. The existing brushes are themed to black foreground on a
black background when High Contrast (HC) Black theme is enabled. The
only thing that's saving you is
`ApplicationHighContrastAdjustment::Auto` is automatically backplating
the glyphs on the buttons, which (by design) hides the fact that the
colors are poor. The backplates are those ugly squares inside the
buttons on the HC themes.
Before I can push a PR that disables automatic backplating (set
`ApplicationHighContrastAdjustment` to `None`), we'll need to select
better brushes that work in HC mode. MUX has already selected brushes
that work great in all modes, so it just makes sense to use their
brushes.
The one very subtle difference here is that, for non-HC themes, the
glyph's foreground has a bit more contrast when the button is in
hovered/pressed states. Again this slight difference hardly matters
now, but using the correct brushes will become critical when we try to
remove the HC backplating.
Closes#6812
## Summary of the Pull Request
Let's try and figure out just how many people are actually using Solarized. I emailed @DHowett about this a week ago, but otherwise we don't really have any other tasks for this.
## PR Checklist
* [x] I work here
* [n/a] Requires documentation to be updated
The MUX TabView control has a uniquely-shaped [+] button. TerminalApp
doesn't use it: instead, it has a SplitView button that is styled to
look like MUX's official button. However, it doesn't get the button's
shape right. This PR updates TerminalApp's custom button to look more
like MUX's.
The difference is that MUX only rounds the top two corners, and it uses
a bigger radius. Without matching MUX's radius, the upper-left corner
of the button makes an awkward asymmetric divot with the abutting tab.
There's also a spot in the lower-left corner that just looks like
someone accidentally spilled a few pixels on the floor.
Current appearance before this PR:
New appearance with this PR:
Most important deltas highlighted with red circles:
Note that this PR does *not* attempt to fix the colors. The colors are
also just slightly different from what MUX uses. I'll save that for a
separate PR, since all those screenshots would clutter this up this PR.
## Summary of the Pull Request
This PR adds support for the `SGR 53` and `SGR 55` escapes sequences,
which enable and disable the ANSI _overline_ graphic rendition
attribute, the equivalent of the console character attribute
`COMMON_LVB_GRID_HORIZONTAL`. When a character is output with this
attribute set, a horizontal line is rendered at the top of the character
cell.
## PR Checklist
* [x] Closes#6000
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
To start with, I added `SetOverline` and `IsOverlined` methods to the
`TextAttribute` class, to set and get the legacy
`COMMON_LVB_GRID_HORIZONTAL` attribute. Technically there was already an
`IsTopHorizontalDisplayed` method, but I thought it more readable to add
a separate `IsOverlined` as an alias for that.
Then it was just a matter of adding calls to set and reset the attribute
in response to the `SGR 53` and `SGR 55` sequences in the
`SetGraphicsRendition` methods of the two dispatchers. The actual
rendering was already taken care of by the `PaintBufferGridLines` method
in the rendering engines.
The only other change required was to update the `_UpdateExtendedAttrs`
method in the `Xterm256Engine` of the VT renderer, to ensure the
attribute state would be forwarded to the Windows Terminal over conpty.
## Validation Steps Performed
I've extended the existing SGR unit tests to cover the new attribute in
the `AdapterTest`, the `OutputEngineTest`, and the `VtRendererTest`.
I've also manually tested the `SGR 53` and `SGR 55` sequences to confirm
that they do actually render (or remove) an overline on the characters
being output.
The VT reset operations `RIS` and `DECSTR` are implemented as a series
of steps, each of which could potentially fail. Currently these
operations abort as soon as an error is detected, which is particularly
problematic in conpty mode, where some steps deliberately "fail" to
indicate that they need to be "passed through" to the conpty client. As
a result, the reset won't be fully executed. This PR changes that
behaviour, so the error state is recorded for any failures, but the
subsequent steps are still run.
Originally the structure of these operations was of the form:
bool success = DoSomething();
if (success)
{
success = DoSomethingElse();
}
But I've now changed the code so it looks more like this:
bool success = DoSomething();
success = DoSomethingElse() && success;
This means that every one of the steps should execute, regardless of
whether previous steps were successful, but the final _success_ state
will only be true if none of the steps has failed.
While this is only really an issue in the conhost code, I've updated
both the `AdaptDispatch` and `TerminalDispatch` classes, since I thought
it would be best to have them in sync, and in general this seems like a
better way to handle multi-step operations anyway.
VALIDATION
I've manually tested the `RIS` escape sequence (`\ec`) in the Windows
Terminal, and confirmed that it now correctly resets the cursor
position, which it wasn't doing before.
Closes#6545
Pretty straightforward. `toggleRetroEffect` will work to toggle the
retro terminal effect on/off.
* Made possible by contributions from #6551, _and viewers like you_
