Our build pipeline was originally set up such that we could take any
binaries from the Terminal build and seamlessly re-package them with the
release or preview livery. My initial plan was to stamp a stable and
preview build at the same time, out of the same bits, to make ring
promotion easier.
I've never done that. For the last five releases, we've just re-cut a
new stable build along with the new preview build, usually because we
want to backport some fixes to stable.
This commit introduces preprocessor defines, detectable through CL and
RC, for any project that wants them. Right now, that's just going to be
WindowsTerminal.vcxproj (since it hosts the icons and the app entry
point). This list may be extended to include wt (the shim executable)
and the shell extension at some future date.
This will greatly simplify the logic in #7971, as we'll no longer need
to detect if we're dev or preview at runtime. It may also simplify the
logic in the shell extension for determining whether we're Dev or not.
## Summary of the Pull Request
Fixes the bug where `exit`ing inside a closed pane would leave the Terminal blank.
Additionally, removes `Tab::GetRootElement` and replaces it with the _observable_ `Tab::Content`. This should be more resilient in the future.
Also adds some tests, though admittedly not for this exact scenario. This scenario requires a cooperating TerminalConnection that I can drive for the sake of testing, and _ain't nobody got time for that_.
## References
* Introduced in #6989
## PR Checklist
* [x] Closes#7252
* [x] I work here
* [x] Tests added/passed 🎉
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From notes I had left in `Tab.cpp` while I was working on this:
```
OKAY I see what's happening here the ActivePaneChanged Handler in TerminalPage
doesn't re-attach the tab content to the tree, it just updates the title of the
window.
So when the pane is `exit`ed, the pane's control is removed and re-attached to
the parent grid, which _isn't in the XAML tree_. And no one can go tell the
TerminalPage that it needs to re set up the tab content again.
The Page _manually_ does this in a few places, when various pane actions are
about to take place, it'll unzoom. It would be way easier if the Tab could just
manage the content of the page.
Or if the Tab just had a Content that was observable, that when that changed,
the page would auto readjust. That does sound like a LOT of work though.
```
## Validation Steps Performed
Opened panes, closed panes, exited panes, zoomed panes, moved focus between panes, panes, panes, panes
## Summary of the Pull Request
Just deleting an unnecessary call to `_UpdateCommandsForPalette`
**Note:** This only fixes slowdown when opening/closing a tab, but not upon first startup (we still need to call `_UpdateCommandsForPalette` there
## References
Fixes the slowdown described in #7820 for opening and closing tabs, but doesn't improve startup time dramatically.
## Validation Steps Performed
Tested with ~100 profiles in my settings file
This PR changes the ATS display order to _always_ be in most recently
used (MRU) order. I chose not to give ATS the option to be displayed
in-order because that order is better served through the traditional
left-right TabRow switching.
_Note_: `TabSearch` will stay in-order.
This means that users can only choose one order or another in their
`nextTab/prevTab` bindings. Setting `useTabSwitcher` to true will make
nT/pT open the ATS in MRU order. If it's set to false, the ATS won't
open and nT/pT will simply go left and right on the TabRow.
I'm open to getting rid of the global and making ATS its own keybinding,
but for now I figured I would keep the current behavior and open the PR
to get eyes on the code that doesn't have anything to do with the
settings.
Closes#973
Let's assume the user has bound the dead key ^ to a sendInput command
that sends "b". If the user presses the two keys ^a it'll produce "bâ",
despite us marking the key event as handled. We can use `ToUnicodeEx`
to clear such dead keys from the keyboard state and should make use of
that for keybindings. Unfortunately `SetKeyboardState` cannot be used
for this purpose as it doesn't clear the dead key state.
Validation
* Enabled a German keyboard layout
* Added the following two keybindings:
{ "command": { "action": "sendInput", "input": "x" }, "keys": "q" },
{ "command": { "action": "sendInput", "input": "b" }, "keys": "^" }
* Pressed the following keys → ensured that the given text is printed:
* q → x
* ´ → nothing
* a → á
* ^ → b
* a → a (previously this would print: â)
* ´ → nothing
* ^ → b
* a → a (unfortunately we cannot specifically clear only ^)
Closes#5784
Fix for crash occurring when splitting a pane, due to tab context menu created multiple times.
## References
#7728
## PR Checklist
* [x] Closes#7941
* [x] CLA signed.
## Detailed Description of the Pull Request / Additional comments
When splitting panes the `Tab::Initialize` function is called again. This rebuilt the context menu from scratch and appended the existing Close... sub-menu items to a new parent, thus causing the crash.
It is not necessary to re-create the context menu every time you split panes, it can be created only once.
## Validation Steps Performed
Manual verification:
- Play with the context menu, the Close... submenu is functioning
- Split panes (ALT + New tab), no crash occurs and context menu still functioning
## Summary of the Pull Request
This implements the `Copy` function for `CascadiaSettings`. Copy performs a deep copy of a `CascadiaSettings` object. This is needed for data binding in the Terminal Settings Editor.
The `Copy` function was basically implemented in every settings model object. This was mostly just repetitive work.
## References
#7667 - TSM
#1564 - Settings UI
## PR Checklist
* [X] Tests added/passed
It turns out that we missed part of the OSC 8 spec which indicated that
_hyperlinks with the same ID but different URIs are logically distinct._
> Character cells that have the same target URI and the same nonempty id
> are always underlined together on mouseover.
> The same id is only used for connecting character cells whose URIs is
> also the same. Character cells pointing to different URIs should never
> be underlined together when hovering over.
This pull request fixes that oversight by appending the (hashed) URI to
the generated ID.
When Terminal receives one of these links over ConPTY, it will hash the
URL a second time and therefore append a second hashed ID. This is taken
as an acceptable cost.
Fixes#7698
VsCode uses `>` as its "prefix" for the equivalent of their "action
mode". This PR aligns the Terminal with their logic here.
We have to be tricky - if we use the `>` in the actual input as the
indicator for action mode, we can't display any placeholder text in the
input to tell users to type a command. This wasn't an issue for the
commandline mode previously, because we'd stick the "prompt" in the "no
matches text" space. However, we can't do that for action mode. Instead,
we'll stick a floating text block over the input box, and when the
user's in action mode, we'll manually place a `>` into that space. When
the user backspaces the `>`, we'll remove it from that block, and switch
into commandline mode.
## Validation Steps Performed
Played with the cmdpal in lots of different modes, this finally feels
good
Closes#7736
Adds a new setting, `bellStyle`, to be able to disable the audible bell
added in #7679. Currently, this setting accepts two values:
* `audible`: play a noise on a bell
* `none`: Don't play a noise.
In the future, we can add a `"bellStyle": "visible"` for flashing the
Terminal instead of making a noise on bell.
## Validation Steps Performed
Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of
triggering a bell. I set the setting to `none`, and presto, the bell
stopped.
Closes#2360
This PR introduces a pair of classes for managing VT parameters that
automatically handle range checking and default fallback values, so the
individual operations don't have to do that validation themselves. In
addition to simplifying the code, this fixes a few cases where we were
mishandling missing or extraneous parameters, and adds support for
parameter sequences on commands that couldn't previously handle them.
This PR also sets a limit on the number of parameters allowed, to help
thwart DoS memory consumption attacks.
## References
* The new parameter class also introduces the concept of an
omitted/default parameter which is not necessarily zero, which is a
prerequisite for addressing issue #4417.
## Detailed Description of the Pull Request / Additional comments
There are two new classes provide by this PR: a `VTParameter` class,
similar in function to a `std::optional<size_t>`, which holds an
individual parameter (which may be an omitted/default value); and a
`VTParameters` class, similar in function to `gsl:span<VTParameter>`,
which holds a sequence of those parameters.
Where `VTParameter` differs from `std::optional` is with the inclusion
of two cast operators. There is a `size_t` cast that interprets omitted
and zero values as 1 (the expected behaviour for most numeric
parameters). And there is a generic cast, for use with the enum
parameter types, which interprets omitted values as 0 (the expected
behaviour for most selective parameters).
The advantage of `VTParameters` class is that it has an `at` method that
can never fail - out of range values simply return the a default
`VTParameter` instance (this is standard behaviour in VT terminals). It
also has a `size` method that will always return a minimum count of 1,
since an empty parameter list is typically the equivalent of a single
"default" parameter, so this guarantees you'll get at least one value
when iterating over the list with `size()`.
For cases where we just need to call the same dispatch method for every
parameter, there is a helper `for_each` method, which repeatedly calls a
given predicate function with each value in the sequence. It also
collates the returned success values to determine the overall result of
the sequence. As with the `size` method, this will always make at least
one call, so it correctly handles empty sequences.
With those two classes in place, we could get rid of all the parameter
validation and default handling code in the `OutputStateMachineEngine`.
We now just use the `VTParameters::at` method to grab a parameter and
typically pass it straight to the appropriate dispatch method, letting
the cast operators automatically handle the assignment of default
values. Occasionally we might need a `value_or` call to specify a
non-standard default value, but those cases are fairly rare.
In some case the `OutputStateMachineEngine` was also checking whether
parameters values were in range, but for the most part this shouldn't
have been necessary, since that is something the dispatch classes would
already have been doing themselves (in the few cases that they weren't,
I've now updated them to do so).
I've also updated the `InputStateMachineEngine` in a similar way to the
`OutputStateMachineEngine`, getting rid of a few of the parameter
extraction methods, and simplifying other parts of the implementation.
It's not as clean a replacement as the output engine, but there are
still benefits in using the new classes.
## Validation Steps Performed
For the most part I haven't had to alter existing tests other than
accounting for changes to the API. There were a couple of tests I needed
to drop because they were checking for failure cases which shouldn't
have been failing (unexpected parameters should never be an error), or
testing output engine validation that is no longer handled at that
level.
I've added a few new tests to cover operations that take sequences of
selective parameters (`ED`, `EL`, `TBC`, `SM`, and `RM`). And I've
extended the cursor movement tests to make sure those operations can
handle extraneous parameters that weren't expected. I've also added a
test to verify that the state machine will correctly ignore parameters
beyond the maximum 32 parameter count limit.
I've also manual confirmed that the various test cases given in issues
#2101 are now working as expected.
Closes#2101
## Summary of the Pull Request
Added watch on desktopImagePath to check when the path equals "DesktopWallpaper"
If it does equal "DesktopWallpaper" it replaces the path with a path to the desktop's wallpaper
*I am a student and this is my first pull request for Terminal so please give feedback no matter how small. It's the best way I can learn.
## PR Checklist
* [X] Closes#7295
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [?] Tests added/passed
* [X] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: https://github.com/MicrosoftDocs/terminal/pull/155
* [?] Schema updated. (Not sure if this is needed, also not sure where this would be)
* [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: #7295 (Have only talked with the people on the issue, which I don't think has any core contributors)
## Detailed Description of the Pull Request / Additional comments
I am using SystemParametersInfo for SPI_GETDESKWALLPAPER which puts the path into a WCHAR and that is then inserted as the BackgroundImagePath.
I do not think an additional test would add value. The SPI_GETDESKTOPWALLPAPER uses the computers local wallpaper path and puts it into a WCHAR, which then I feed into BackgroundImagePath() as it's new path. I don't think there adds value in making a static path of the desktop background and testing that, given that static tests are already done for "BackgroundImage()".
## Validation Steps Performed
(Manual Validation - Test False Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "<some random img path>"] under profiles->defaults
3. Verified terminal's background is not the desktops wallpaper.
(Manual Validation - Test True Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults
3. Verified the background image matches the desktop background image.
(Manual Validation - Multiple Tabs True Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults
3. Verified the background image matches the desktop background image.
4. Opened new tabs
5. Verified the background image matches the desktop background image for each tab.
<!-- 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 a "Close..." option to the tab context menu, with nested entries to close tabs to the right and close other tabs (actions already available)
![immagine](https://user-images.githubusercontent.com/1140981/94178005-c7e03600-fe9a-11ea-9f87-c6f4895d4cf3.png)
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#1912
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#5524
* [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
First contribution 🙂
Tried to follow some suggestions from https://github.com/microsoft/terminal/issues/1912#issuecomment-667079311
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted
as `RR/GG/BB` instead of `0R/0G/0B`
* Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The
behaviour of 12 bit variants is to repeat the first digit at the end,
e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`.
* Add support for `#` formats. We are following the rules of
[XParseColor] by interpreting `#RGB` as `R000G000B000`.
* Add support for XOrg app color names, which are supported by xterm, VTE
and many other terminal emulators.
* Multi-parameter OSC 4 is now supported.
* The chaining of OSC 10-12 is not yet supported. But the parameter
validation is relaxed by parsing the parameters as multi-params but
only use the first one, which means `\e]10;rgb:R/G/B;` and
`\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color
correctly. This fixes some of the issues mentioned in #942 but not
all of them.
[XParseColor]: https://linux.die.net/man/3/xparsecolorCloses#3715
This commit introduces two new launch modes: focus and maximizedFocus.
* Focused mode, behaves like a default mode, but with the Focus Mode
enabled.
* Maximized focused mode, behaves like a Maximized mode, but with the
Focus Mode enabled.
There two ways to invoke these new modes:
* In the settings file: you set the "launchMode" to either "focus" or
"maximizedFocus"
* In the command line options, you can path -f / --focus, which is
mutually exclusive with the --fullscreen, but can be combined with the
--maximized:
* Passing -f / --focus will launch the terminal in the "focus" mode
* Passing -fM / --focus --maximized will launch the terminal in the
"maximizedFocus" mode
This should resolve a relevant part in the command line arguments
mega-thread #4632Closes#7124Closes#7825Closes#7875
Took this as an easy starter. The method IslandWindow::SetAlwaysOnTop is
triggered once terminal settings are reloaded (in
TerminalPage::_RefreshUIForSettingsReload flow). This method calls
SetWindowPos without SWP_NOACTIVATE. As a result the window gets
activated, the focus is set and the cursor starts blinking.
Added SWP_NOACTIVATE in all SetWindowPos calls from IslandWindow and
NoClientIslandWindow (where it was missing). Please let me know if this
is an overkill - it is not required to fix the issue, however seems a
good practice, that might help if we decide to apply more settings
immediately.
## Validation Steps Performed
* Only manual testing - please guide me to the relevant UT framework, if
exists.
* Trying to reproduce this with VS attached doesn't work - the window
gets the focus in any case.
* Tested as a standalone application, by modifying different settings
(and comparing the results before and after the fix).
* Checked with Spy++ that no WM_ACTIVATE / WM_SETFOCUS is thrown upon
settings modification
* Applied terminal resizing, toggling full screen and focus mode to
check no regression was introduced.
Closes#7571
Adds a tooltip to the new tab button and menu to let the user know
that holding alt will open a new pane instead.
Fixes#7851
Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
Adds the ability to manually handle the terminal renderer resizing
events by allowing different render size and WPF control size. This is
done by adding an `AutoFill` property to the control that prevents the
renderer from automatically resizing and tells the WPF control to fill
in the extra space with the terminal background as shown below:
This PR adds the following:
- Helper method in the DX engine to convert character viewports into
pixel viewports
- `AutoFill` property that prevents automatic resizing of the renderer
- Tweaks and fixes that automatically fill in the empty space if
`AutoFill` is set to false
- Fixes resizing methods and streamlines their codepath
## Validation Steps Performed
Manual validation with the Visual Studio Integrated Terminal tool
window.
This pull request introduces (a very, very stripped-down copy of) the
WIL fallback error reporter.
It emits error records, usually immediately before the application
implodes, into the event stream.
This should improve diagnosability of issues that take Terminal down,
and allow us to give out a .wprp file to gather traces from users.
This is not going to be our plan of record for Universal going forward.
This updates the Universal configuration to 1) match non-universal and 2) switch to local applications
## Summary of the Pull Request
Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source.
This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist.
## References
Based on #7667
## PR Checklist
* [X] Closes#7784
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] Schema updated.
## Validation Steps Performed
Deploy succeeded.
#7796 and #7667 were being implemented concurrently. As a part of #7667, Command was moved from TermApp to TSM. This just applies that change to a line we missed in #7796 and fixes the build break.
## Summary of the Pull Request
![preview-ats-000](https://user-images.githubusercontent.com/18356694/94801728-18302a00-03ac-11eb-851d-760b92ebb46f.gif)
This PR enables the ATS to display the active tab as the user navigates the tab switcher. We do this by dispatching the tab switch actions as the user navigates the menu, and manually _not_ focusing the new tab when the tab switcher is open.
## References
* #6732 - original tab switcher PR
* #6689 - That's a more involved, generic version of this, but this PR will be enough to stop most of the complaints hopefully
## PR Checklist
* [x] Closes#7409
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Opened tabs, tabbed through the menu, verified that it did what I'd expect
Introduces a new TerminalSettingsModel (TSM) project. This project is
responsible for (de)serializing and exposing Windows Terminal's settings
as WinRT objects.
## References
#885: TSM epic
#1564: Settings UI is dependent on this for data binding and settings access
#6904: TSM Spec
In the process of ripping out TSM from TerminalApp, a few other changes
were made to make this possible:
1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was
moved to `CascadiaSettings`
- These are defined as static functions. They also no longer check if
`AppLogic::Current()` is nullptr.
2. `enum LaunchMode` was moved from TerminalApp to TSM
3. `AzureConnectionType` and `TelnetConnectionType` were moved from the
profile generators to their respective TerminalConnections
4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are
exposed as `hstring` instead of `std::filesystem::path`
5. `Command::ExpandCommands()` was exposed via the IDL
- This required some of the warnings to be saved to an `IVector`
instead of `std::vector`, among some other small changes.
6. The localization resources had to be split into two halves.
- Resource file linked in init.cpp. Verified at runtime thanks to the
StaticResourceLoader.
7. Added constructors to some `ActionArgs`
8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to
`JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp.
A large amount of work includes moving to the new namespace
(`TerminalApp` --> `Microsoft::Terminal::Settings::Model`).
Fixing the tests had its own complications. Testing required us to split
up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a
non-local test variant can be found in #7743.
Closes#885
This commit makes the Windows Terminal play an audible sound when the
`BEL` control character is output.
The `BEL` control was already being forwarded through conpty, so it was
just a matter of hooking up the `WarningBell` dispatch method to
actually play a sound. I've used the `PlaySound` API to output the sound
configured for the "Critical Stop" system event (aka _SystemHand_),
since that is the sound used in conhost.
## Validation
I've manually confirmed that the terminal produces the expected sound
when executing `echo ^G` in a cmd shell, or `printf "\a"` in a WSL bash
shell.
References:
* There is a separate issue (#1608) to deal with configuring the `BEL`
to trigger visual forms of notification.
* There is also an issue (#2360) requesting an option to disable the
`BEL`.
Closes#4046
The WAP packaging project is sensitive to including applications that it
thinks are UWPs. The changes we made to separate WindowsStoreApp and
WindowsAppContainer weren't comprehensive enough to convince WAP that we
were not still UWPs.
Because of that, it would run sub-builds of each of these projects (and
all their dependencies) with an additional `GenerateAppxPackageOnBuild`
property set. The existence of this property caused MSBuild to think the
projects needed to be built *again*.
DestListLogoUri cannot handle paths that are separated with / unless
they're actually URLs. We have to guess somewhat whether something is a
file path and if it appears to be one, normalize it.
Fixes#7706
This PR adds support for the _blink_ graphic rendition attribute. When a
character is output with this attribute set, it "blinks" at a regular
interval, by cycling its color between the normal rendition and a dimmer
shade of that color.
The majority of the blinking mechanism is encapsulated in a new
`BlinkingState` class, which is shared between the Terminal and Conhost
implementations. This class keeps track of the position in the blinking
cycle, which determines whether characters are rendered as normal or
faint.
In Windows Terminal, the state is stored in the `Terminal` class, and in
Conhost it's stored in the `CONSOLE_INFORMATION` class. In both cases,
the `IsBlinkingFaint` method is used to determine the current blinking
rendition, and that is passed on as a parameter to the
`TextAttribute::CalculateRgbColors` method when these classes are
looking up attribute colors.
Prior to calculating the colors, the current attribute is also passed to
the `RecordBlinkingUsage` method, which keeps track of whether there are
actually any blink attributes in use. This is used to determine whether
the screen needs to be refreshed when the blinking cycle toggles between
the normal and faint renditions.
The refresh itself is handled by the `ToggleBlinkingRendition` method,
which is triggered by a timer. In Conhost this is just piggybacking on
the existing cursor blink timer, but in Windows Terminal it needs to
have its own separate timer, since the cursor timer is reset whenever a
key is pressed, which is not something we want for attribute blinking.
Although the `ToggleBlinkingRendition` is called at the same rate as the
cursor blinking, we actually only want the cells to blink at half that
frequency. We thus have a counter that cycles through four phases, and
blinking is rendered as faint for two of those four. Then every two
cycles - when the state changes - a redraw is triggered, but only if
there are actually blinking attributes in use (as previously recorded).
As mentioned earlier, the blinking frequency is based on the cursor
blink rate, so that means it'll automatically be disabled if a user has
set their cursor blink rate to none. It can also be disabled by turning
off the _Show animations in Windows_ option. In Conhost these settings
take effect immediately, but in Windows Terminal they only apply when a
new tab is opened.
This PR also adds partial support for the `SGR 6` _rapid blink_
attribute. This is not used by DEC terminals, but was defined in the
ECMA/ANSI standards. It's not widely supported, but many terminals just
it implement it as an alias for the regular `SGR 5` blink attribute, so
that's what I've done here too.
## Validation Steps Performed
I've checked the _Graphic rendition test pattern_ in Vttest, and
compared our representation of the blink attribute to that of an actual
DEC VT220 terminal as seen on [YouTube]. With the right color scheme
it's a reasonably close match.
[YouTube]: https://www.youtube.com/watch?v=03Pz5AmxbE4&t=1m55sCloses#7388
Currently, `CommandPalette` creates and maintains the `SwitchToTab`
commands used for the ATS. When `Command` goes into the
TerminalSettingsModel, the palette won't be able to access `Command`'s
implementation type, making it difficult for `CommandPalette` to tell
`Command` to listen to `Tab` for changes.
This PR changes the relationship up so `Tab` now manages its
`SwitchToTab` command, and `CommandPalette` just plops the command from
`Tab` into its list.
Add `ToJson()` to the `ConversionTrait`s in JsonUtils. This can be used
to serialize settings objects into JSON.
As a proof of concept, `ToJson` and `UpdateJson` were added to
`ColorScheme`.
Getters and setters for members and colors in the color table were added
and polished.
## References
#1564 - Settings UI
`ColorScheme` is a particularly easy example of serialization because it
has _no fallback_.
Added a few tests for JSON serializers.
## Summary of the Pull Request
This fixes a typo in the `HyperlinkIdConsistency` unit test which was causing that test to fail. It was mistakenly using a `/` instead of `\` for the string terminator sequences.
## References
The test initially worked because of a bug in the state machine parser, but that bug was recently fixed in PR #7340.
## PR Checklist
* [x] Closes#7654
* [x] CLA signed.
* [x] Tests passed
* [ ] Documentation updated.
* [ ] 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.
## Validation Steps Performed
I've run the test again and it now passes.
`KeyMapping` was introduced to break up `AppKeyBindings`. `KeyMapping`
records the keybindings from the JSON and lets you query them.
`AppKeyBindings` now just holds a `ShortcutActionDispatcher` to run
actions, and a `KeyMapping` to record/query your existing keybindings.
This refactor allows `KeyMapping` to be moved to the
TerminalSettingsModel, and `ShortcutActionDispatcher` and
`AppKeyBindings` will stay in TerminalApp.
`AppKeyBindings` had to be passed down to a terminal via
`TerminalSettings`. Since each settings object had its own
responsibility to update/create a `TerminalSettings` object, I moved all
of that logic to `TerminalSettings`. This helps with the
TerminalSettingsModel refactor, and makes the construction of
`TerminalSettings` a bit cleaner and more centralized.
## References
#885 - this is all in preparation for the TerminalSettingsModel
## Validation Steps Performed
- [x] Tests passed
- [X] Deployment succeeded
Now that CascadiaSettings is a WinRT object, we need to update the error
handling a bit. Making it a WinRT object limits our errors to be
hresults. So we moved all the error handling down a layer to when we
load the settings object.
- Warnings encountered during validation are saved to `Warnings()`.
- Errors encountered during validation are saved to `GetLoadingError()`.
- Deserialization errors (mainly from JsonUtils) are saved to
`GetDeserializationErrorMessage()`.
## References
#7141 - CascadiaSettings is a settings object
#885 - this makes ripping out CascadiaSettings into
TerminalSettingsModel much easier
## Validation Steps Performed
* [x] Tests passed
- [x] Deployment succeeded
- tested with invalid JSON (deserialization error)
- tested with missing DefaultProfile (validation error)
If a user clicks a link that is either invalid (cannot be parsed) or has
a scheme we do not support (like file or mailto (for now)), we open up a
dialog box telling them the issue.
References #5001
- Render hyperlinks with a dashed underline
- Render hovered hyperlinks with a solid underline
- Show URI tooltip on hover
TermControl now has a canvas that contains a tiny border to which a
tooltip is attached. When we hover over hyperlinked text, we move the
border to the mouse location and update the tooltip content with the
URI.
Introduced a new underline type (HyperlinkUnderline), supports rendering
for it, and uses it to render hyperlinks. HyperlinkUnderline is usually
a dashed underline, but when a link is hovered, all text with the same
hyperlink ID is rendered with a solid underline.
References #5001
This commit leverages C++/WinRT's final_release [extension point] to
pull the final destruction of ConptyConnection off onto a background
thread.
We've been seeing some deadlocks during teardown where the output thread
(holding the last owning reference to the connection) was trying to
destruct the threadpool wait while the threadpool wait was
simultaneously running its callback and waiting for the output thread to
terminate. It turns out that trying to release a threadpool wait while
it's running a callback that's blocked on you will absolutely result in
a deadlock.
Fixes#7392.
[extension point]: https://devblogs.microsoft.com/oldnewthing/20191018-00/?p=103010
CascadiaSettings is now a WinRT object in the TerminalApp project.
## References
#7141 - CascadiaSettings is a settings object
#885 - this new settings object will be moved to a new TerminalSettingsModel project
This one _looks_ big, but most of it is really just propagating the
changes to the tests. In fact, you can probably save yourself some time
because the tests were about an hour of Find&Replace.
`CascadiaSettings::GetCurrentAppSettings()` was only being used in
Pane.cpp. So I ripped out the 3 lines of code and stuffed them in there.
Follow-up work:
- There's a few places in AppLogic where I `get_self` to be able to get
the warnings out. This will go away in the next PR (wrapping up #885)
## Validation Steps Performed
- [x] Tests passed
- [X] Deployment succeeded
Closes#7141
By setting the jumplist entries to launch `WindowsTerminal.exe` out of
the package root, we've inadvertently made WindowsTerminalDev emit jump
list entries that launch the _unpackaged_ version of Terminal.
We can fix this by copying the code from the shell extension that
determines which version of the executable to launch -- wt, wtd or
WindowsTerminal -- depending on the context under which it was invoked.
Fixes#7554
This PR is about the behavior of DECSCUSR. This PR changes the meaning
of DECSCUSR 0 to restore the cursor style back to user default. This
differs from what VT spec says but it’s used in popular terminal
emulators like iTerm2 and VTE-based ones. See #1604.
Another change is that for parameter greater than 6, DECSCUSR should be
ignored, instead of restoring the cursor to legacy. This PR fixes it.
See #7382.
Fixes#1604.