Following up https://github.com/microsoft/terminal/pull/8586 by @Hegunumo,
fully remove the command dispatching logic from Command Palette.
Currently Command Palette might dispatch command in Tab Switcher mode.
This leads to several inconsistencies:
* Only the commands with the same key modifier as an ATS anchor will be issued
* This command will not close the TabSwitcher
(while commands issued from TerminalPage do).
Implementation details:
* Pass KeyMapping rather than binding to CommandPalette
* Use this mapping inside previewKeyDownHandler of ATS to detect
if previous tab or next tab bindings were engaged.
No need to handle Ctrl+Tab explicitly anymore -
it is handled as any other binding.
* Cleanup the logic in TerminalPage::_SelectNextTab
that checks if CommandPalette is visible.
It is not required anymore, as visible palette would intercept the call.
* Remove dependency of TerminalPage on AppLogic
that was introduced lately .
Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will
be responsible for all the Monarch/Peasant work that's been described in
#7240 & #8135.
This PR does _not_ implement the Monarch/Peasant architecture in any
significant way. The goal of this PR is to just to establish the project
layout, and the most basic connections. This should make reviewing the
actual meat of the implementation (in a later PR) easier. It will also
give us the opportunity to include some of the basic weird things we're
doing (with `CoRegisterClass`) in the Terminal _now_, and get them
selfhosted, before building on them too much.
This PR does have windows registering the `Monarch` class with COM. When
windows are created, they'll as the Monarch if they should create a new
window or not. In this PR, the Monarch will always reply "yes, please
make a new window".
Similar to other projects in our solution, we're adding 3 projects here:
* `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a
static lib.
* `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL,
for use in `WindowsTerminal.exe`.
* `Remoting.UnitTests.dll`: A unit test dll that links with the static
lib.
There are plenty of TODOs scattered about the code. Clearly, most of
this isn't implemented yet, but I do have more WIP branches. I'm using
[`projects/5`](https://github.com/microsoft/terminal/projects/5) as my
notation for TODOs that are too small for an issue, but are part of the
whole Process Model 2.0 work.
## References
* #5000 - this is the process model megathread
* #7240 - The process model 2.0 spec.
* #8135 - the window management spec. (please review me, I have 0/3
signoffs even after the discussion we had 😢)
* #8171 - the Monarch/peasant sample. (please review me, I have 1/2)
## PR Checklist
* [x] Closes nothing, this is just infrastructure
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
In dark mode (and high contrast mode), color animation of title bar
button uses wrong color. Cause of this issue is using invalid data in
`ColorAnimation`. I fixed this bug by changing `ColorAnimation` value
in XAML layout file.
According to a [forum post], `To` value of `ColorAnimation` must be
frozen. But original source code uses "color binding" which makes this
value dynamic. As a result, the value set by default is always used,
that means, light mode.
So I added new resource named `CaptionButtonStrokeColor` and
`CaptionButtonBackgroundColor` which has static color value.
In light mode and dark mode, I set `SystemBaseHighColor` in the color
resource. `SystemBaseHighColor` is the same as
`SystemControlForegroundBaseHighBrush.Color` which is originally used in
animation.
The background color animation happened to work correctly because its
value is the same between light mode and dark mode. But I also fixed
background color animation.
## Validation Steps Performed
There is no need to add new test with this fix.
- I changed the `theme` value in `settings.json` and confirmed that the
correct color values were used.
- I confirmed that it works correctly even if the Windows theme is
changed.
[forum post]: https://social.msdn.microsoft.com/Forums/vstudio/en-US/027c364f-5d75-424f-aafd-7fb76b10b676/templatebinding-on-storyboard?forum=wpfCloses#7314
This commit makes "Open in Windows Terminal" Context menu work again for
directory background even on system that OS fix is not applied.
This is a fallback solution to OS fixes mentioned in #6414.
While OS fix is on its way, we need a fallback that works on existing OS
versions.
The approach to this is: when no item is selected (nullptr for
IShellItemArray*), we use shell api to query the path of current active
Explorer window. A special case is handled for Windows Desktop. Once
we are able to obtain the path, we launch Windows Terminal with it.
## Validation Steps Performed
1. Right click on desktop to bring up the Context menu, pick "Open in
Windows Terminal", verify that a terminal is opened with correct
initial path.
2. Open a few File Explorer windows, pick any window, navigate to a
folder, click on "Background" to bring up the context menu, click
"Open in Windows Terminal" verify that a terminal is opened with
correct initial path.
Closes#6414
Performs a number of minor bugfixes related to the Settings UI:
- b5370a1 Dropdown bug:
- the dropdown would display the keybinding for the first
`openSettings` found. So it would accidentally present and bind the
one for the Settings UI.
- 91eb49e autogenerated name for opening Settings UI:
- the Settings UI keybinding would display "open settings file". This
was updated to say "Open Settings UI".
- 1cadbf4 Profile Page navigation crash:
- the selected item off of a MUX navigation view returns a MUX
NavViewItem (as opposed to WUX)
- dd2f3e5 Hookup delete for Profile page navigation:
- missed a spot where we were manually navigating to the Profile
page. So it wasn't hooked up properly
- 9fea6de Properly cast NavViewItem tags
- When we update the NavigationView's menu items, we were casting the
tags to `Model::Profile` instead of `Editor::ProfileViewModel`.
## References
#6800 - Settings UI epic
Fixes the following bug:
> - [ ] JSON change --> crash
> - open SUI --> open JSON --> edit retro effects in JSON --> save file --> cry because the app crashed
## Additional comments
This was a part of some manual testing I performed on the Settings UI.
More intricate bugs are being reported on #6800 and will be fixed in
their own PR.
Fix `TabPaletteItem` to hold only a weak reference to a tab.
This way we guarantee that the refcount of the closed tab
gets to 0 immediately
(and that command palette cannot "raise it from the dead").
While this seems a correct thing to do,
it is still not clear why the `FilteredCommand` itself
(the one holding the `TabPaletteItem`) doesn't get released
until the UI is refreshed.
There is an impact of not registering to PropertyChanged event:
if the tab title changes during Tab Switcher navigation
the Tab Switcher item won't be updated immediately
(the change will apply next time the Tab Switcher is open).
Due to this change we need to make sure that the tabs binding
in https://github.com/microsoft/terminal/pull/8427
doesn't break the title / icon update.
## Validation Steps Performed
* Manual testing
Closes#8651
This commit introduces direct shortcut dispatch to TerminalPage, which
allows it to respond to key bindings before the command palette.
This allows the user to use shortcuts from the command palette while
it's open.
Closes#6679
Looks like recent regression:
1. Every time the tab gains focus (e.g., upon tab switching) we trigger `TaskbarProgressChanged`
2. This call results in `HideIcon` call
3. This call resets the value of Icon even if hide=false
4. This triggers reload of the image resulting in blinking
Introduces the following UI controls to the ColorSchemes page:
- "Add new" button
- next to dropdown selector
- adds a new color scheme named ("Color Scheme #" where # is the number of color schemes you have)
- "Rename" Button
- next to the selector
- replaces the ComboBox with a TextBox and the accept/cancel buttons appear
- "Delete" button
- bottom of the page
- opens flyout, when confirmed, deletes the current color scheme and selects another one
This also adds a Delete button to the Profiles page. The Hide checkbox was moved above the Delete button.
## References
#1564 - Settings UI
#6800 - Settings UI Completion Epic
## Detailed Description of the Pull Request / Additional comments
**Color Schemes:**
- Deleting a color scheme selects another one from the list available
- Rename replaces the combobox with a textbox to allow editing
- The Add New button creates a new color scheme named "Color Scheme X" where X is the number of schemes defined
- In-box color schemes cannot be deleted
**Profile:**
- Deleting a profile selects another one from the list available
- the rename button does not exist (yet), because it needs a modification to the NavigationView's Header Template
- The delete button is disabled for in-box profiles (CMD and Windows Powershell) and dynamic profiles
## Validation Steps Performed
**Color Schemes - Add New**
✅ Creates a new color scheme named "Color Scheme X" (X being the number of color schemes)
✅ The new color scheme can be renamed/deleted/modified
**Color Schemes - Rename**
✅ You cannot rename an in-box color scheme
✅ The rename button has a tooltip
✅ Clicking the rename button replaces the combobox with a textbox
✅ Accept --> changes name
✅ Cancel --> does not change the name
✅ accepting/cancelling the rename operation updates the combo box appropriately
**Color Schemes - Delete**
✅ Clicking delete produces a flyout to confirm deletion
✅ Deleting a color scheme removes it from the list and select the one under it
✅ Deleting the last color scheme selects the last available color scheme after it's deleted
✅ In-box color schemes have the delete button disabled, and a disclaimer appears next to it
**Profile- Delete**
✅ Base layer presents a disclaimer at the top, and hides the delete button
✅ Dynamic and in-box profiles disable the delete button and show the appropriate disclaimer next to the disabled button
✅ Clicking delete produces a flyout to confirm deletion
✅ Regular profiles have a delete button that is styled appropriately
✅ Clicking the delete profile button opens a content dialog. Confirmation deletes the profile and navigates to the profile indexed under it (deleting the last one redirects to the last one)
## Demo
Refer to this post [here](https://github.com/microsoft/terminal/pull/8403#issuecomment-747545651.
Confirmation flyout demo: https://github.com/microsoft/terminal/pull/8403#issuecomment-747657842
<!-- 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
The tab tooltip is no longer empty when it was toggle zoomed.
<!-- 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#8199
* [ ] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
I was looking at conhost/OpenConsole and noticed it was being pretty
inefficient with allocations due to some usages of std::deque and
std::vector that didn't need to be done quite that way.
So this uses std::vector for the TextBuffer's storage of ROW objects,
which allows one allocation to contiguously reserve space for all the
ROWs - on Desktop this is 9001 ROW objects which means it saves 9000
allocations that the std::deque would have done. Plus it has the
benefit of increasing locality of the ROW objects since deque is going
to chase pointers more often with its data structure.
Then, within each ROW there are CharRow and ATTR_ROW objects that use
std::vector today. This changes them to use Boost's small_vector, which
is a variation of vector that allows for the so-called "small string
optimization." Since we know the typical size of these vectors, we can
pre-reserve the right number of elements directly in the
CharRow/ATTR_ROW instances, avoiding any heap allocations at all for
constructing these objects.
There are a ton of variations on this "small_vector" concept out there
in the world - this one in Boost, LLVM has one called SmallVector,
Electronic Arts' STL has a small_vector, Facebook's folly library has
one...there are a silly number of these out there. But Boost seems like
it's by far the easiest to consume in terms of integration into this
repo, the CI/CD pipeline, licensing, and stuff like that, so I went with
the boost version.
In terms of numbers, I measured the startup path of OpenConsole.exe on
my dev box for Release x64 configuration. My box is an i7-6700k @ 4
Ghz, with 32 GB RAM, not that I think machine config matters much here:
| | Allocation count | Allocated bytes | CPU usage (ms) |
| ------ | ------------------- | ------------------ | -------------- |
| Before | 29,461 | 4,984,640 | 103 |
| After | 2,459 (-91%) | 4,853,931 (-2.6%) | 96 (-7%) |
Along the way, I also fixed a dynamic initializer I happened to spot in
the registry code, and updated some docs.
## Validation Steps Performed
- Ran "runut", "runft" and "runuia" locally and confirmed results are
the same as the main branch
- Profiled the before/after numbers in the Visual Studio profiler, for
the numbers shown in the table
Co-authored-by: Austin Lamb <austinl@microsoft.com>
This commit adds a [progress ring] to the tab header when we receive an
OSC 9 sequence.
Adds an event handler in `Tab.cpp` for the event we raise when we get a
request to set the taskbar state/progress. This event handler updates
the tab header with the active control's state/progress.
When we want to show the progress ring, we hide the tab icon and place
the progress ring over it.
[progress ring]: https://docs.microsoft.com/en-us/uwp/api/Microsoft.UI.Xaml.Controls.ProgressRing?view=winui-2.4
References #6700
This commit introduces another optional text block in palette that will
be shown in the command line mode (above the history). This text block
will either contain a list of parsed command lines or a description why
the parsing failed
Closes#8344Closes#7284
Co-authored-by: mrange <marten_range@hotmail.com>
I loved the pixel shaders in #7058, but that PR needed a bit of polish
to be ready for ingestion. This PR is almost _exactly_ that PR, with
some small changes.
* It adds a new pre-profile setting `"experimental.pixelShaderPath"`,
which lets the user set a pixel shader to use with the Terminal.
- CHANGED FROM #7058: It does _not_ add any built-in shaders.
- CHANGED FROM #7058: it will _override_
`experimental.retroTerminalEffect`
* It adds a bunch of sample shaders in `samples/shaders`. Included:
- A NOP shader as a base to build from.
- An "invert" shader that inverts the colors, as a simple example
- An "grayscale" shader that converts all colors to grayscale, as a
simple example
- An "raster bars" shader that draws some colored bars on the screen
with a drop shadow, as a more involved example
- The original retro terminal effects, as a more involved example
- It also includes a broken shader, as an example of what heppens
when the shader fails to compile
- CHANGED FROM #7058: It does _not_ add the "retroII" shader we were
all worried about.
* When a shader fails to be found or fails to compile, we'll display an
error dialog to the user with a relevant error message.
- CHANGED FROM #7058: Originally, #7058 would display "error bars"
on the screen. I've removed that, and had the Terminal disable the
shader entirely then.
* Renames the `toggleRetroEffect` action to `toggleShaderEffect`.
(`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This
action will turn the shader OR the retro effects on/off.
`toggleShaderEffect` works the way you'd expect it to, but the mental
math on _how_ is a little weird. The logic is basically:
```
useShader = shaderEffectsEnabled ?
(pixelShaderProvided ?
pixelShader :
(retroEffectEnabled ?
retroEffect : null
)
) :
null
```
and `toggleShaderEffect` toggles `shaderEffectsEnabled`.
* If you've got both a shader and retro enabled, `toggleShaderEffect`
will toggle between the shader on/off.
* If you've got a shader and retro disabled, `toggleShaderEffect` will
toggle between the shader on/off.
References #6191
References #7058Closes#7013Closes#3930 "Add setting to retro terminal shader to control blur
radius, color"
Closes#3929 "Add setting to retro terminal shader to enable drawing
scanlines"
- At this point, just roll your own version of the shader.
There are two issue with copy to clipboard when block is selected:
* We don't add new lines for lines that were wrapped
* We remove trailing whitespaces which is not intuitive in block selection.
Fixed the copy logic to always add newlines and not to remove
whitespaces when block is selected.
Even if shift is pressed!
## Detailed Description of the Pull Request / Additional comments
* Added optional parameter to `TextBuffer::GetText`
that allows to apply formatting (includeCRLF / trimming)
to lines that were wrapped
* Changed `Terminal::RetrieveSelectedTextFromBuffer`
to apply the following parameters when block is selected:
* includeCRLF = true
* trimTrailingWhitespaces = false
* apply the formatting above to all rows, including the ones
that were wrapped
## Validation Steps Performed
* Manual tests for both block and standard selection
* Copy with both right-click and command
* Added UT
Closes#6740
This changes the keyboard warning from a dialog to an `InfoBar`, which
we just got in MUX 2.5. Some users were unhappy that we'd always display
the dialog. We learned from the input team that this service _should_
always be enabled. We're also learing from users that they don't always
want it enabled.
We're working with the Input team to help us figure out how this service
can be disabled _and the Terminal work just fine_. They're confident
that it _shouldn't_. For 99% of our users, they're right. So we don't
want to get rid of the dialog entirely, we want to understand how this
is possible. While we wait, let's make the message less aggressive.
This is instead of making a `iKnowWhatImDoingDisableTheKeyboardWarning`
setting to disable the dialog. Props to @cornem for suggesting the less
aggressive solution.
## Validation Steps Performed
Tested manually, but by forcing the message to always display. Disabling
the service requires two full reboots, and _ain't nobody got time for
that_.
Closes#8228Closes#4448, for now
<!-- 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
It is maybe not the best way since I had to get all the cases for key handling so I just created for each of them. As a result the code get longer(not optimized). Most difficult thing was Next tab and Previous tab I just could not solve it.
### 9 commands that couldn't enabled > <
1. Increase font size -> could not find VirtualKey for "-"
2. Decrease font size -> could not find VirtualKey for "+"
3. Split pane, split:horizontal -> could not find VirtualKey for "-"
4. Split pane, split:vertical -> could not find VirtualKey for "+"
5. Open default settings -> could not find VirtualKey for ","
6. Open settings file -> could not find VirtualKey for ","
7. Open new tab dropdown -> could not resolve keybindings
8. Next tab -> could not resolve keybindings
9. Previous tab -> could not resolve keybindings
<!-- 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#6679
* [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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
This commit iontroduces another `target` to the `openSettings` binding:
`settingsUI`. It opens the settings UI introduced in the previous
commit.
Closes#1564Closes#8048 (PR)
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Leon Liang <lelian@microsoft.com>
This commit introduces the terminal settings editor (to wit: the
Settings UI) as a standalone project. This project, and this commit, is
the result of two and a half months of work.
TSE started as a hackathon project in the Microsoft 2020 Hackathon, and
from there it's grown to be a bona-fide graphical settings editor.
There is a lot of xaml data binding in here, a number of views and a
number of view models, and a bunch of paradigms that we've been
reviewing and testing out and designing and refining.
Specified in #6720, #8269
Follow-up work in #6800Closes#1564Closes#8048 (PR)
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com>
Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com>
Co-authored-by: John Grandle <jograndl@microsoft.com>
Co-authored-by: xerootg <xerootg@users.noreply.github.com>
Co-authored-by: Scott <sarmiger1@gmail.com>
Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com>
Co-authored-by: Leon Liang <lelian@microsoft.com>
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
This commit is an amalgamation of some of the TSM changes in PR #8048.
It:
* Introduces CascadiaSettings.CreateNewProfile to add a new profile
* Introduces CascadiaSettings.ProfileDefaults, which returns the
"defaults" object as a profile
* Fixes the font weight deserializer to work on uint16_ts
* Fixes a property getter in ColorScheme to not be a property getter
* Fixes a reserialization error with default profiles
* Sets a default icon for all profiles (to the C:\ Segoe MDL2 icon)
This PR defines a series of `NOSOMETHING` macros in PCHs, in order to
prevent `windows.h` from bringing a lot of rarely used things into the
project.
Theoretically this should make PCH generation and overall complication
faster, but I didn't really benchmark the speed.
Another benefit would be reducing the symbol noises caused by
`windows.h`.
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/7916
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Upon tab close the tabview is responsible to issue tab selection for the next active tab.
However this doesn't happen when tabview is hidden.
There was a special treatment for this scenario for full screen mode.
Added the same treatment to focus mode (as the tabview is not visible in this case as well).
## Validation Steps Performed
Manual tests
Adds a "move to previous pane" and "move to next pane" keybinding, which
navigates to the last/first focused pane
We assign pane IDs on creation and maintain a vector of active pane IDs
in MRU order. Navigating panes by MRU then requires specifying which
pane ID we want to focus.
From our offline discussion (thanks @zadjii-msft for the concise
description):
> For the record, the full spec I'm imagining is:
>
> { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } },
>
> and order defaults to mru, and useSwitcher will default to true, when
> there is a switcher. So
>
> { command": { "action": "focusNextPane" } },
> { command": { "action": "focusNextPane", "order": "mru" } },
>
> these are the same action. (but right now we don't support the order
> param)
>
> Then there'll be another PR for "focusPane(target=id)"
>
> Then a third PR for "focus(Next|Prev)Pane(order=inOrder)"
> for the record, I prefer this approach over the "one action to rule
> them all" version with both target and order/direction as params,
> because I don't like the confusion of what happens if there's both
> target and order/direction provided.
References #1000Closes#2871
I added `enum class` to one thing and decided that that was quite enough
before disabling the `enum class` warning.
Looks like 16.8 made more map/vector operations noexcept, so we have to
re-annotate to remain compliant.
There's a handful of small changes in these updates:
The Win32 Toolkit is now built with CFG (I think), and
the VCRT forwarders are now the (second) non-RC version.
First step towards #8415:
* Introduce `PaletteItem` and derive from it to provide native support
for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`,
`CommandLinePaltteItem`)
* Remove business logic behind PaletteItem from palette (aka dispatch
commands and preview tabs externally)
So the implementation is somewhat dirty.
The ideas was nice - add lostFocusHandler
However it broke few things:
* In the TabSwitcher the ListItem must be focusable since otherwise
the SingleSelectionMode behavior breaks.
To address this I had to put the lostFocusHandler on the items as well
* When you click the flyout, the palette loses focus,
which makes the terminal page to set the focus on the tab, closing the flyout.
To address this I had to ensure the tab won't get focused once the flyout is open.
In addition, flyout should fix the focus before opening,
otherwise alt+tab will put a focus on a tab row rather than on tab
* I also had to close the palette if the tab order changes.
To prevent inconsistencies.
Closes#8355
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This PR adds shortcut action so that users can scroll.
I used `UINT16_MAX` for `rowsToScroll`.
<!-- 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#7542
* [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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Have you ever wanted to debug the Terminal, but weren't sure which of
your Terminal windows was the one you needed to attach to? Now you don't
need to worry! Simply execute the `breakIntoDebugger` action, and the
Terminal will `DebugBreak()` for you!
This requires that the user has set `"debugFeatures": true`
Validated by adding a command:
{
"command": "breakIntoDebugger",
"keys": "ctrl+alt+shift+f1",
"name": "DebugBreak()"
},
...and verifying that it pops open the post-mortem debugger (windbg).
This commit moves us to the Xaml prerelease (201202003) that is
equivalent to public stable release 2.5.
Remember, we need to use prereleases for some silly reason.
There were some minor annoyances with the WPF projects.
1. WpfTerminalTestNetCore was in an unnecessary same-named subdirectory
2. The build started throwing deprecation warnings because `netcoreapp3.0` is not LTS and is going away.
I was about to add `SetAnsiMode`/`ResetAnsiMode` for `SM` and `RM` when I
realized that we probably don't need yet another enum of mode types, set and
reset functions, and a mode helper for ANSI standard modes when we already have
one for DEC Private modes.
This commit:
1. Changes the enum `PrivateModeParams` to just be `ModeParams`
2. Differentiates ANSI Standard modes (IRM, KAM, SRM, ...) from DEC
Private modes (DECCOLM, DECCKM, ...) using a flag bit set in the enum
value.
3. Introduces a helper class for constructing these values much like
`VTID`. That helper takes a bitmask and applies it to an input to
produce the final enum value.
4. Dispatches all mode set/reset through a common Set/Reset and
`_ModeHelper` that uses the existing enum values.
[1] These modes are in separate namespaces with some overlap. We want to
differentiate them at dispatch time to ensure that `\e[2h` and `\e[?2h` are
given different treatment, and ensure that `\e[1000h` doesn't activate xterm
mouse mode.
Fixes#8457.
This PR improves the clipboard handling logic of "drag and drop" in
TermControl, making it more useful and less likely to crash.
* Added support for two more categories of content, `ApplicationLink`
and `WebLink`.
* Reordered the ifs, making `StorageItem` the last clause. With WT being
a text-oriented application, I think we can safely assume that the
content being pasted is likely to be text/links.
* Catch possible exceptions during
`e.DataView().GetStorageItemsAsync()`.
Closes#7804
`backgroundImageAlignment` is exposed as 1 setting in the JSON, but
stored as two separate settings (`HorizontalAlignment` and
`VerticalAlignment`). This PR introduces `ConvergedAlignment` as a flag
enum that can be a combination of horizontal and vertical Alignments.
TSM now solely uses this `ConvergedAlignment`, and TerminalSettings
performs a conversion from this new enum to the traditional
`HorizontalAlignment` and `VerticalAlignment` for consumption.
## Validation Steps Performed
Manually tested changing the `backgroundImageAlignment` in my
settings.json and checking if the image updated appropriately.
Show a validation warning when someone sets a `setColorScheme` action
with an invalid scheme
In the setting validation phase, scan all commands for all the "set
color scheme" actions, and check each of them has a valid scheme. If any
of them has an invalid scheme name, raise a warning. Do not check
iterable commands that will be expanded to valid color schemes.
## Validation Steps Performed
- Added tests to LocalTests_SettingsModel
- Manual tests, add commands to settings.json with invalid color scheme
and check the warning pops up. Try simple and nested commands.
Closes#7221
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/8421
* [x] CLA signed.
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
Skip further computations if:
* The list is empty
* No item is selected and we press "up" key
(we do want to handle "down" key for CommandLineMode)
## Validation Steps Performed
* Manual testing + UT
The Settings UI exposes the `profiles.defaults` (PD) object. Today, we
remove PD if there's nothing in it. However, that causes problems with
the Settings UI, because we have no `Profile` object to bind to
(resulting in a crash). Rather than making the Settings UI create a PD,
and link it in the inheritance tree, it's much easier to just _always_
create and link the PD object.
## References
#1564 - Settings UI (fixes a crash for this)
#7923 - Introduces inheritance
## PR Checklist
* [X] Tests added/passed
## Validation Steps Performed
* [x] repro steps for crash in Settings UI (copied changes over to that
branch for testing)
* [x] tests passed
This fixes the issue with the settings UI where clicking the browse
buttons would cause an exception to be thrown when we tried to display a
picker without an originating HWND.
It turns out that pickers need a hosting/parent window, and Xaml Islands
doesn't furnish us with a CoreWindow that's set up for that use case.
Alas!
Raymond Chen's [blog post on the matter] suggests that we should
hand the HWND off through some classic COM interface. To do that
properly, Terminal's various components need to implement that interface
and propagate the HWND down where it's needed.
Thanks to a [Xaml compiler issue], we can't actually do that. To work
around that, we've begged and borrowed different methods for pushing
HWNDs around:
1. Using IInitializeWithWindow in secret
2. A member that takes a uint64
3. An interface that offers a function that will "wire up" the HWND.
I chose (1) because AppHost can implement IInitializeWithWindow, but
TerminalPage cannot. We're just pretending that TerminalPage _can_.
I chose (2) because none of the Xaml types in TerminalSettingsEditor can
implement the interface thanks to the aforementioned compiler issue, but
we don't have an escape hatch like AppHost that lives in the same module
and can help us do the propagation.
I chose (3) because I didn't want to commit the same sin as (2) _seven
times_ for every different type of settings page that exists. (3) is
backed by "IHostedInWindow", and anybody who knows they have to use
IInitializeWithWindow to tie an HWND to an object can call
IHostedInWindow.TryPropagateHostingWindow() on that object.
House of cards.
[Xaml compiler issue]: https://github.com/microsoft/microsoft-ui-xaml/issues/3331
[blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413
(cherry picked from commit f9fc9861a1)
If we try set a very long title, "rename box" UI changes max height,
corrupting the layout. There are several ways to fix it, e.g. by
limiting the MaxHeight (e.g. by binding it to the actual height of the
title bar).
However, I went for the most straightforward approach - truncating. I
don't think we should allow long titles (though it can be a nice hidden
storage 😊)
I considered to truncate it to the tab header width, but we can actually
see more data in tab-switcher, so I simply went for a hard-coded value
which should be large enough.
If this approach makes sense we need to consider updating the
documentation.
Closes#8428
Fix for #8365
Adds a `_renameCancelled` bool that determines whether we raise the event for a title change. We do this because the lost focus handler for the rename box will be called _both_ when the renamer is dismissed by clicking somewhere else and by pressing enter/escape. So, the lost focus handler needs to conditionally raise the event.
Closes#8365
## Summary of the Pull Request
Introduces a new command called `moveTab`
This command has a single mandatory argument with values of `forward` and `backward`
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/3593
* [x] CLA signed.
* [x] Tests added/passed
* [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198
* [x] Schema updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Went for the straightforward solution of moving the tab and the tabViewItem.
## Validation Steps Performed
* Manual testing
Many include statements use forward slashes, while others use backwards
slashes. This is inconsistent formatting. For this reason, I changed the
backward slashes to forward slashes since that is the standard.
## Summary of the Pull Request
Add a history to command palette in the command line mode.
Few considerations/limitations
1. In-memory, 10 entries hard-coded
2. MRU
3. List rather than set
4. The user needs explicitly select command from the history
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/8296
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] I've discussed this with core contributors already.
## Validation Steps Performed
* Manual testing
The CloseWarningDialog is now "awaitable"/async, as suggested in PR #7871.
As opening the dialog is async, the flag can be reset in the same
method. This way the flag operations occur in the same method. The
event handlers of the buttons became obsolete and are removed.
## Validation Steps Performed
Tested manually.
* Add a tabColor parameter to the `new-tab` and `split-panes` command
* Add --tabColor to the command line, to allow bootstrapping with tabs
of different colors
Add another field to NewTerminalArgs. Use this field to set
StartingTabColor in Terminal. This color gets overridden by the color
defined by the profile / VT, however can be overridden with the color
picker.
Since the color is the property of the Terminal, when defined for the
tab this color is associated only with the first pane/terminal of the
tab. Additional panes will not inherit this color (to prevent advanced
resolution, where we need to resolve between the inherited color and the
one specified for the pane).
## Validation Steps Performed
* UT for parameters parsing
* Running system with several tabs of different colors.
* Adding custom actions with colors
* Performing operations like split pane, duplicate and so on
Closes#8075
The terminal taskbar icon can now flash when the BEL sequence is
emitted, to let the user know something needs their attention.
The `BellStyle` setting can now be set to `audible`, `visual` or both or
none. When the pane receives a BEL event and the `bellStyle` includes
`visual`, we bubble the event up all the way to `AppHost` to handle
flashing the taskbar.
Closes#1608
This commit implements the OSC 9;4 sequence per the [ConEmu style].
| sequence | description |
| ------------ | ------------ |
| `ESC ] 9 ; 4 ; st ; pr ST` | Set progress state on taskbar and tab. |
| | When `st` is: |
| | |
| | `0`: remove progress. |
| | `1`: set progress value to `pr` (number, 0-100). |
| | `2`: set the taskbar to the "Error" state |
| | `3`: set the taskbar to the "Indeterminate" state |
| | `4`: set the taskbar to the "Warning" state |
We've also extended this with:
* st 3: set indeterminate state
* st 4: set paused state
We handle multiple tabs sending the sequence by using the the last focused
control's taskbar state/progress.
Upon receiving the sequence in `TerminalApi`, we send an event that gets caught
by `TerminalPage`. `TerminalPage` then fires another event that gets caught by
`AppHost` and that's where we set the taskbar progress.
Closes#3004
[ConEmu style]: https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
Currently when implicit tab command is specified (i.e., we have
parameters for new-tab, but don't have the explicit subcommand name) we
fallback to parsing the entire arg list as new tab command.
However, if we also have a launch profile (or anything else that might in
the future belong to the upper scope) it is passed as a parameter to the
new tab command, failing the parsing.
The idea behind my solution is to run the parser as a prefix command -
i.e., as long as we succeed to parse [options] / [subcommand] we will
parse them (populating the fields like a launch mode), but once we will
discover something unfamiliar, like profile, we will know that the
prefix is over and will handle the remaining suffix as a new tab
command.
## Validation Steps Performed
* UT added
* Manual run of different options
Closes#7318
<!-- 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 sets the tab close button color to match the tab text color.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#8046
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#8046
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] 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: #8046
<!-- 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
This sets the tab close button color to match the tab text color.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Test light theme white tab mouse hover effect:
Test dark theme white tab mouse hover effect:
## Summary of the Pull Request
This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated.
`CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents.
#### Limitations:
- all of the color schemes are serialized regardless of them coming from defaults.json or settings.json
- keybindings/actions are copied/pasted
## References
#1564 - Settings UI
TSM Specs (#6904 and #7876)
## PR Checklist
* [x] Tests added/passed
Fixes the clear button to clear the typed command not clickable in the
command palette.
- From the primary investigation it looked like the `TextBlock` element
introduced in #7935 was somehow blocking (appearing on top of) the
clear button.
- It was also blocking the command palette input field from being able
to access which was preventing the text in the input field from being
selected and the cursor would still show as `pointer` cursor instead
of a `text selection` cursor
- Adding `HorizontalAlignment="Left"` property to the above-mentioned
`TextBlock` element fixed the issue.
## Validation Steps Performed
- Created the Dev build for `x64` in Visual Studio and verified the
functionality manually.
Closes#8220
Until now, we relied on WM_SIZING to ensure that the island is not
downsized below minimal allowed dimensions. However, on some occasions
WM_WINDOWPOSCHANGED, e.g. when anchoring a window to the top/bottom of
the screen. This message will use dimensions obtained from
WM_GETMINMAXINFO. Until now we didn't override this value, falling back
to the defaults. As a result we got an inconsistent behavior (at least
when attaching the anchor).
I added logic very similar to the one we use in IslandWindow::_OnSizing
to the MINMAXINFO handler: snap the client area, add non client
exclusive are, consider DPI along the computation.
## Validation Steps Performed
* Manual testing of minimizing, maximizing, resizing, attaching
different anchors, etc.
Closes#8026
There are two code paths for Ctrl+Tab and for everything else:
Ctrl + Tab is working perfectly
* On the first tab navigation TerminalPage::_SelectNextTab resets the
tab commands, and since palette is not visible selects the relevant
tab index
* On the second navigation Ctrl+Tab is intercepted by
CommandPalette::_previewKeyDownHandler and everything works fine
But with custom binding things are screwed:
* On the first tab navigation TerminalPage::_SelectNextTab resets the
tab commands, and since palette is not visible selects the relevant
tab index
* On the second navigation keys are not intercepted and thus
TerminalPage::_SelectNextTab is called again. It resets the commands,
but now since the palette is visible we simply invoke
CommandPalette::SelectNextItem. Which in turn misbehaves because no
item is selected.
The approach for the solution is not to reset anything if the command
palette is already open.
## Validation Steps Performed
* Manual testing of both custom and non-custom bindings with different
amount of tabs.
Closes#8247
Display a warning message when the DirectX renderer resolves a font that
isn't the one you selected to warn that it couldn't be found.
Also I wrote the dialog event chain out of `TermControl` to be reusable
in the future for other messages the control might want to tell a host
about and various levels.
## Validation Steps Performed
- Manual validation, setting bad font name, fixing font name with
`settings.json`.
Closes#1017
Some UTs crash with access violation, that occurs during pane animation.
The reason for this is a race, upon which the pane is closed (set to
nullptr) before the parent is animated. Added a simple check against
null. Doubt it can happen in production, yet worth taking care!
The JsonUtils changes in #8018 revealed that we need more robust,
configurable optional handling. We learned that there's a class of
values that was previously underrepresented in our API: _strings that
have an explicit empty value_.
The Settings model supports starting directory, icon, background image
et al values that are empty. That emptiness _overrides_ a value set in a
lower layer, so it is not sufficient to represent the empty value for
any one of those fields as an unset optional.
There are a couple other settings for which we've implemented a
hand-rolled option type (for roughly the same reason): foreground,
background, any color fields that override values from the color scheme
_or_ the lower layer profile.
These requirements are best fulfilled by better optional support in
JsonUtils. Where the library would originally detect known types of
optional and pre-filter them out during `GetValue` and `SetValue`, it
will now defer to another conversion trait.
This commit introduces a helper conversion trait and an "option oracle".
The conversion trait will use the option oracle to detect emptiness,
generate empty option values, and read values out of option types. In so
doing, the trait is insulated from the implementation details of any
specific option type.
Any special logic for handling JSON null and option types has been
stripped from GetValue. Due to this, there is an express change in
behavior for some converters:
* `GetValue<T>(jsonNull)` where `T` is **not** an option type[1] has
been upgraded from a silent no-op to an exception.
Further, I took the opportunity to replace NullableSetting with
std::optional<std::optional<T>>, which accurately represents "setting
that the user might explicitly clear". I've added a test to
JsonUtilsTests to make sure it can serialize/deserialize double
optionals the way we expect it to.
Tests (Local, Unit for TerminalApp/SettingsModel):
Summary: Total=140, Passed=140, Failed=0, Blocked=0, Not Run=0, Skipped=0
[1]: Explicitly, if `T` is not an option type _and the converter does
not support null_.
I am still not sure what is the full set of scenarios that the problem
might occur, but for me it occurred for an "old" cloud shell account,
and didn't reproduce since I have reconfigured it. These behavior might
be explained by the fact that "preferred shell type" did not exist in
the API originally and thus was not set. In such case, Terminal
succeeds to retrieve to the settings but then crashes when reading the
missing field. To fix it, I handle the case where the field is missing
and fallback to PowerShell.
## Validation Steps Performed
* Tested manually, only once.
Closes#7056
In introduced a bug in #8185, due to which Command Palette sorts items
alphabetically in the tab switcher mode. This PR fixes it.
Validation:
Created tabs with different names and verified that the MRU order is
preserved
Closes#8185
By adding these target Inputs/Outputs to TestHostApp's AfterBuild, we
can ensure that new versions of the test libraries are properly
detected. No longer will we have to delete them from disk and rebuild
TestHostApp and hope that it picks up the latest test binaries.
Oh, and I turned on a couple other optimizations (hard links, skipping
unchanged files) that were really just low-hanging fruit.
* Created a ViewModel class in the Command Palette called
FilteredCommand, aggregating the Command, the filter and the
highlighted presentation of the command name
* This ListView of the filtered commands is bound to the vector of
FilteredCommands
* Introduced HighlightedTextControl user control with HighlightedText
view model
* Added this control to the ListView Item's grid
* Bound the FilteredCommand's highlighted command name to the user
control
## Validation Steps Performed
* UT for matching algorithm
* Only manual tests
* Searching in CommandLine, SwitchTab and Nested Command modes
* Checking for bot matching an non matching filters
* Dogfooding
Closes#6646
## Summary of the Pull Request
Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string:
* `true`, `"mru"`: Use the tab switcher with MRU tab switching
* `"inOrder"`: Use the tab switcher, with in-order tab switching
* `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order.
This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread.
## References
* #7952 introduced MRU tab switching
## PR Checklist
* [x] Closes#8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task
* [x] I work here
* [x] Tests added/passed - YOU BET THEY WERE
* [ ] Requires documentation to be updated
## Validation Steps Performed
I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting.
I also _ran the test_ I added.
This commit adds functionality so that users can move back from sub menu
whenever they want. As a result, users no longer have to close command
palette and open it again to get all commands again.
Closes#7910
## Summary of the Pull Request
When we get a serialization error, we "catch" it in `AppLogic` and only
`LoadDefaults()`. Since `LoadDefaults()` doesn't perform a full
validation of `CascadiaSettings`, we need to manually update our list of
active profiles (similar to how we manually resolve the default
profile).
## Validation Steps Performed
Repro steps fixed:
1. add deserialization error to settings.json (i.e. "fontWeight": "wumbo")
2. launch WT
3. verify that dropdown is populated with active profiles
Closes#8146
## Summary of the Pull Request
With this PR, the Terminal will check to make sure the "Touch, Keyboard and Handwriting Panel Service" is enabled at startup. If it isn't, then the Terminal won't be able to receive keyboard input (see #4448 and the 20 linked issues to that one).
## References
* See #4448 for more details
## PR Checklist
* [x] Closes#7886
* [ ] Should this make #4448 not-open as well?
* [x] I work here
* [n/a] Tests added/passed
* [x] Docs: https://github.com/MicrosoftDocs/terminal/pull/168
## Validation Steps Performed
I manually set the service to "Disabled", restarted the machine, verified the dialog opens (and that I'm unable to type in the Terminal), then re-set the service to automatic and rebooted, and the dialog doesn't appear.
In preparation for the Settings UI, we needed to make some changes to
Tab to abstract out shared, common functionality between different types
of tab. This is the result of that work. All code references to the
settings have been removed or reverted.
Contains changes from #8053, #7802.
The messages below only make sense in the context of the Settings UI,
which this pull request does not bring in. They do, however, provide
valuable information.
From #7802 (@leonMSFT):
> This PR's goal was to add an option to the `OpenSettings` keybinding to
> open the Settings UI in a tab. In order to implement that, a couple of
> changes had to be made to `Tab`, specifically:
>
> - Introduce a tab interface named `ITab`
> - Create/Rename two new Tab classes that implement `ITab` called
> `SettingsTab` and `TerminalTab`
>
From #8053:
> `TerminalTab` and `SettingsTab` share some implementation details. The
> close submenu introduced in #7728 is a good example of functionality
> that is consistent across all tabs. This PR transforms `ITab` from an
> interface, into an [unsealed runtime class] to de-duplicate some
> functionality. Most of the logic from `SettingsTab` was moved there
> because I expect the default behavior of a tab to resemble the
> `SettingsTab` over a `TerminalTab`.
>
> ## References
> Verified that Close submenu work was transferred over (#7728, #7961, #8010).
>
> ## Validation Steps Performed
> Check close submenu on first/last tab when multiple tabs are open.
>
> Closes#7969
>
> [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Leon Liang <lelian@microsoft.com>
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
<!-- 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
In the focus mode the top border disappears upon resize. While this behavior is expected in the maximized / full screen mode, it should not happen in the focus mode.
<!-- 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 https://github.com/microsoft/terminal/issues/7012
* [x] CLA signed
* [ ] Tests added/passed - nope, only manual testing
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] 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
_GetTopBorderHeight method returns 0 when maximized or no title bar is visible. However the existence of top border has nothing to do with whether the title bar is visible. We want to leave the border as long as the window is not in some form of maximizing (maximized / full screen)
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Manual - dragging, resizing, maximizing both in focus and non focus modes + full screen testing
<!-- 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
<!-- 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 https://github.com/microsoft/terminal/issues/7996
* [x] CLA signed.
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] 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
Currently the value of AlwaysOnTop is read by the AppHost from AppLogic that takes this value from the root TerminalPage. However at this stage neither AppLogic nor TerminalPage are initialized, and thus the return value is always false.
This PR introduces a "GetInitialAlwaysOnTop" method to AppLogic that returns a value that is configured in the settings.
In addition, the TerminalPage creation was fixed to read the configuration value upon creation (and not just after settings reload).
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
* Only manual testing
* Starting the system with both initial value set to true and false
* Verifying that dynamic toggling on / off is not affected
<!-- 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
A second close command (middle click on taskbar preview) overrides the warning dialog and closes the application.
<!-- 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#7451
* [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
When a close command is invoked (middle click on taskbar preview or 'X' button), a new flag is set. When the user wants to close again (this time only via the taskbar preview, as the 'X' button is disabled), the application is closed. If the user cancels the dialog, the flag is reset to prevent accidental closing on a subsequent close command.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
I am developing with a [Windows 10 virtual machine](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/) provided by Microsoft. I tested manually. I considered the 'X' button, middle click on taskbar preview, and Alt+F4. Only a middle click on the taskbar preview does override the dialog.
Fire and forget on the hyperlink handler inside the TermControl.
## PR Checklist
* [x] Closes#7994
* [x] Tested manually
* [x] Hi, I work here.
## Detailed Description of the Pull Request / Additional comments
In `TermControl`, `_HyperlinkHandler` is called by
`_PointerPressedHandler` which has taken a write lock for all its
friends. However, `_HyperlinkHandler` downstreams to `ShellExecute`
which can pump the message queue looking for something. That pumping of
the queue can trigger messages that also want the write lock to update
state. They get stuck. Everything hangs.
`_HyperlinkHandler` really only needs read lock and really only for as
long as it takes to fill up its parameters before it's invoked... but
the simpler and more contained solution is to just fire and forget the
rest of the method that causes the deadlock to a continuation at the
tail of the dispatcher queue so `_PointerPressedHandler` can complete
and naturally drop the write lock.
## Validation Steps Performed
- Launched `main` manually on my box and clicked the hyperlink that is
detected when Powershell starts and it froze.
- Launched this change manually on my box and clicked the hyperlink that
is detected when Powershell starts and it did not freeze.
This pull request is the initial implementation of hyperlink auto
detection
Overall design:
- Upon startup, TerminalCore gives the TextBuffer some patterns it
should know about
- Whenever something in the viewport changes (i.e. text
output/scrolling), TerminalControl tells TerminalCore (through a
throttled function for performance) to retrieve the visible pattern
locations from the TextBuffer
- When the renderer encounters a region that is associated with a
pattern, it paints that region differently
References #5001Closes#574
## Summary of the Pull Request
This PR replaces `CascadiaSettings::_profiles` with...
- `_allProfiles`: the list of all available profiles in the settings model (i.e. settings.json, dynamic profiles, etc...)
- `_activeProfiles`: the list of all non-hidden profiles (used for the new tab dropdown)
## References
#8018: maintaining a list of all profiles allows us to serialize hidden profiles
#1564: Settings UI can link to `AllProfiles()` instead of `ActiveProfiles()` to expose hidden profiles
## PR Checklist
* [x] Closes#4139
* [x] Tests added/passed
## Validation Steps Performed
Deploy and testing succeeded
C++/WinRT added a feature where it will detect a mismatch in some of its
build flags.
Because we build XAML projects and non-XAML projects, and try to link
them together in static libraries, we need those flags to always match.
C++/WinRT only respects this flag when `DEBUG` is set, so our CI missed
this.
With thanks to @carlos-zamora for letting me build/test/commit this on
his computer.
This commit introduces 8 more variants of the .ICO file, embeds the
right ones into WindowsTerminal.exe, and adds code that will select the
most appropriate icon at runtime.
Since we're a Centennial application, the "application" icon inside our
package isn't used by the shell for the taskbar thumbnails or the
Alt-Tab window.
To quote J. Tippet,
> I believe there are two possible fixes:
>
> 1. Fix the OS shell to prefer the MRT icon instead of preferring the
> win32 icon
> 2. Add alternate versions of /res/terminal.ico
> The 1st fix is clearly better, since it benefits any hybrid app. But
> the 2nd fix is much easier, since it'd just take about an hour to gin up
> a new .ico file and hack the .RC file to refer to it when building the
> preview flavor.
... and to quote Michael Ratanapintha,
> Basically, if your MSIX-packaged desktop app's image resources are
> separate files or even separate MSIX packages, they may be loaded by
> MRT. If they're embedded in the .exe, they're the old-fashioned Win32
> resources Mr. Tippet is referring to.
This is the "2nd fix."
Fixes#6777
Co-authored-by: Jeffrey Tippet <jtippet@ntdev.microsoft.com>
This commit fixes our longstanding build artifact output issues and
finally unifies all C++ project output into bin/ and obj/.
In light of that, I've removed NoOutputRedirection.
I've also updated WTU and U8U16Test to use our common build props and
fixed any warnings/compilation errors that popped out.
I validated this change by running repeated incremental builds after
changing individual .cpp files in many of our C++/WinRT projects.
While not explicitly permitted, a wide range of software (including
Windows' own touch keyboard) sets the `wScan` member of the `KEYBDINPUT`
structure to 0, resulting in `scanCode` being 0 as well. In these
situations we'll now use the `vkey` to get a `scanCode`.
Validation
----------
* AutoHotkey
* Use a keyboard layout with `AltGr` key
* Execute the following script:
```ahk
#NoEnv
#Warn
SendMode Input
SetWorkingDir %A_ScriptDir%
<^>!8::SendInput {Raw}»
```
* Press `AltGr+8` while the Terminal is in the foreground
* Ensure » is being echoed ✔️
* PowerToys
* Add a `Ctrl+I -> ↑ (up arrow)` keyboard shortcut
* Press `Ctrl+I` while the Terminal is in the foreground
* Ensure the shell history is being navigated backwards ✔️
* Windows Touch Keyboard
* Right-click or tap and hold the taskbar and select "Show touch
keyboard" button
* Open touch keyboard
* Ensure keyboard works like a regular keyboard ✔️
* Ensure unicode characters are echoed on the Terminal as well (except
for Emojis) ✔️Closes#7438Closes#7495Closes#7843
## Summary of the Pull Request
Introduces `IInheritable` as an interface that helps move cascading settings into the Terminal Settings Model. `GlobalAppSettings` and `Profile` both are now `IInheritable`. `CascadiaSettings` was updated to `CreateChild()` for globals and each profile when we are loading the JSON data.
IInheritable does most of the heavy lifting. It introduces a two new macros and the interface. The macros help implement the fallback functionality for nullable and non-nullable settings.
## References
#7876 - Spec Addendum
#6904 - TSM Spec
#1564 - Settings UI
#7876 - `Copy()` needs to be updated to include _parent
Close the tab context menu when clicking on the title bar
## Detailed Description of the Pull Request / Additional comments
Following #2438, hide the tabs context menu on `TerminalPage::TitlebarClicked()`.
We don't know which of the tabs is showing the context menu, do it on all tabs.
## Validation Steps Performed
Open the context menu from any tab, click on title bar and see the context menu disappear.
Closes#7988
We are getting some watson crash reports that the terminal is attempting
to resize to `(0, 0)`. This change makes it so that we prevent such
resizing and if so, throw an exception before we reach native code.
This commit adds resizing checks that prevent resizing the terminal WPF
control to a size of `(0, 0)`
- The number of lines to move upon scroll up scroll down can be defined
in ScrollUp and ScrollDown commands (parameter is called
"rowsToScroll").
- If the number are not provided, use the system default (the one we are
using for mouse scrolls), rather than 1 line.
## Validation Steps Performed
* Manual testing
* Added custom bindings for scroll commands with different values,
verified they and the default appear and behave as expected
* Checked that invalid values are not allowed
Closes#5078
This PR resolves an issue I observed in
Microsoft.Terminal.Wpf.TerminalControl.CalculateMargins(). Specifically,
on line 194 in the project. In this example, the line: `height =
controlSize.Height - (this.TerminalRendererSize.Height /
dpiScale.DpiScaleX);` is associating the height margin with
dpiScale.DpiScaleX instead of dpiScale.DpiScaleY. This PR changes the
association to DpiScaleY.
Closes#8038
<!-- 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)? -->
Adds the color slider to the tab color picker
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#7948
* [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.~
* [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: #7948
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
*Not required*
We wrap the call to `_WriteSettings` in
`CascadiaSettingsSerialization.cpp` in a try/catch block, and if we
catch an error we append a warning telling the user to check the
permissions on their settings file.
Closes#7727
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)
<!-- 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
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*.
