Some minor styling tweaks to the about page.
- Tweaking the spacing of the version-checking / update available text.
- Wrapping the hyperlinkbuttons in a StackPanel so it's easier to set a
negative margin so they are visually aligned with the version / title
text.
Closes#18994
It's the fzf algorithm!
Repurposed work from #16586
- I think the fzf algo fits here where it optimizes to find the optimal
match based on consecutive chars and word boundaries.
- There are some edge cases where a match with a small gap could get a
higher score than a match of consecutive chars when the match with a
gap has other bonuses (FirstChar * Boundary Bonus). This can be
adjusted by adjusting the bonuses or removing them if needed.
- From reading the thread in #6693 it looked like you guys were leaning
towards something like the fzf algo.
- License file is now updated in
https://github.com/nvim-telescope/telescope-fzf-native.nvim repository
- https://github.com/nvim-telescope/telescope-fzf-native.nvim/pull/148
- https://github.com/junegunn/fzf/issues/4310
- Removed the following from the original implementation to minimize
complexity and the size of the PR. (Let me know if any of these should
be added back).
- Query expressions "$:StartsWith ^:EndsWith |:Or !:Not etc"
- Slab to avoid allocating the scoring matrix. This felt like overkill
for the number of items in the command pallete.
- Fallback to V1 algorithm for very long strings. I want to say that the
command palette won't have strings this long.
- Added the logic from GH#9941 that copies pattern and text chars to
string for comparision with lstrcmpi
- It does this twice now which isn't great...
Closes#6693
---------
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Skips rendering LRI, RLI, FSI, and PDI "glyphs" in the terminal.
Does not implement BIDI/RTL; that is out of scope, see #538. This is
just a hotfix to stop spamming the console with undesired character
printouts. Once BIDI support is implemented, this change will (maybe?)
no longer be necessary.
Fixes#16574.
This pull request adds an Extensions page to the Settings UI, which lets
you enable/disable extensions and see how they affect your settings
(i.e. adding/modifying profiles and adding color schemes). This page is
specifically designed for fragment extensions and dynamic profile
generators, but can be expanded on in the future as we develop a more
advanced extensions model.
App extensions extract the name and icon from the extension package and
display it in the UI. Dynamic profile generators extract the name and
icon from the generator and display it in the UI. We prefer to use the
display name for breadcrumbs when possible.
A "NEW" badge was added to the Extensions page's `NavigationViewItem` to
highlight that it's new. It goes away once the user visits it.
## Detailed Description of the Pull Request / Additional comments
- Settings Model changes:
- `FragmentSettings` represents a parsed json fragment extension.
- `FragmentProfileEntry` and `FragmentColorSchemeEntry` are used to
track profiles and color schemes added/modified
- `ExtensionPackage` bundles the `FragmentSettings` together. This is
how we represent multiple JSON files in one extension.
- `IDynamicProfileGenerator` exposes a `DisplayName` and `Icon`
- `ExtensionPackage`s created from app extensions extract the
`DisplayName` and `Icon` from the extension
- `ApplicationState` is used to track which badges have been dismissed
and prevent them from appearing again
- a `std::unordered_set` is used to keep track of the dismissed badges,
but we only expose a get and append function via the IDL to interact
with it
- Editor changes - view models:
- `ExtensionsViewModel` operates as the main view model for the page.
- `FragmentProfileViewModel` and `FragmentColorSchemeViewModel` are used
to reference specific components of fragments. They also provide support
for navigating to the linked profile or color scheme via the settings
UI!
- `ExtensionPackageViewModel` is a VM for a group of extensions exposed
by a single source. This is mainly needed because a single source can
have multiple JSON fragments in it. This is used for the navigators on
the main page. Can be extended to provide additional information (i.e.
package logo, package name, etc.)
- `CurrentExtensionPackage` is used to track which extension package is
currently in view, if applicable (similar to how the new tab menu page
works)
- Editor changes - views:
- `Extensions.xaml` uses _a lot_ of data templates. These are reused in
`ItemsControl`s to display extension components.
- `ExtensionPackageTemplateSelector` is used to display
`ExtensionPackage`s with metadata vs simple ones that just have a source
(i.e. Git)
- Added a `NewInfoBadge` style that is just an InfoBadge with "New" in
it instead of a number or an icon. Based on
https://github.com/microsoft/PowerToys/pull/36939
- The visibility is bound to a `get` call to the `ApplicationState`
conducted via the `ExtensionsPageViewModel`. The VM is also responsible
for updating the state.
- Lazy loading extension objects
- Since most instances of Terminal won't actually open the settings UI,
it doesn't make sense to create all the extension objects upon startup.
Instead, we defer creating those objects until the user actually
navigates to the Extensions page. This is most of the work that happened
in `CascadiaSettingsSerialization.cpp`. The `SettingsLoader` can be used
specifically to load and create the extension objects.
## Validation Steps
✅ Keyboard navigation feels right
✅ Screen reader reads all info on screen properly
✅ Accessibility Insights FastPass found no issues
✅ "Discard changes" retains subpage, but removes any changes
✅ Extensions page nav item displays a badge if page hasn't been visited
✅ The badge is dismissed when the user visits the page
## Follow-ups
- Streamline a process for adding extensions from the new page
- Long-term, we can reuse the InfoBadge system and make the following
minor changes:
- `SettingContainer`: display the badge and add logic to read/write
`ApplicationState` appropriately (similarly to above)
- `XPageViewModel`:
- count all the badges that will be displayed and expose/bind that to
`InfoBadge.Value`
- If a whole page is new, we can just style the badge using the
`NewInfoBadge` style
Looks like there's a new VS version on the build agents. This just goes
through and fixes any issues they found.
There's still a COMPILER CRASH though.
## Summary of the Pull Request
Adds branding and distribution metadata to the following telemetry
events:
- ActionDispatched (branding only)
- JsonSettingsChanged
- UISettingsChanged
- SessionBecameInteractive
Also removes the settings logger output from the debugger and some
leftover debugging functions.
Adds a label to the XSettingsChanged settings value to make it easier to
read on the backend.
Once an application has returned from handling `WM_ENDSESSION`
the OS may kill the app at any point. This means we must
persist our state while inside the message handler.
Closes#17179
## Validation Steps Performed
Honestly, none. It's a race condition in the first place.
## Motivation
The motivation is that Windows users are more accustomed to working with
GUI Menus using a mouse, unlike Linux users.
## Summary of the Pull Request
added split pane with profile or duplicate up/down/left/right context
menus as submenu
added swap panes up/down/left/right context menus as submenu
added toggle pane zoom context menu
added close other panes context menu
## References :
- Relevant Issues : (#18137)
## Type of change :
- [x] New feature
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Applies some localization fixes for the regex strings and
Settings_ResetApplicationState.HelpText.
Also renames the `_validateX()` functions to
`_validateAndPopulateXRegex()` for clarity.
This works around a bug in WinUI where it creates a single context
menu/flyout for text elements per thread, not per `XamlRoot`, similar to
many other areas. Since the `XamlRoot` cannot change after creation,
this means that once you've opened the flyout, you're locked into that
window (= XAML root) forever. You can't open the flyout in another
window and once you've closed that window, you can't open it anywhere at
all.
Closes#18599
## Validation Steps Performed
* Flies out right click in the
* About dialog ✅
* Search dialog ✅
* Word delimiters setting ✅
* Launch size setting ✅
* Across two windows ✅
If `persistedWindowLayout` is enabled, we now persist the window layout
every few minutes (excluding the text buffer).
This was done by adding a `SafeDispatcherTimer` to the `WindowEmperor`
that calls `PersistState()` every 5 minutes. For `BuildStartupKind`, I
split up `Persist` into `PersistAll` and `PersistLayout`. This way, we
go through all the same code flow that `Persist` had except for
specifically serializing the buffer.
## Validation Steps Performed
✅ (with the timer set to 3 seconds) create a window layout and ensure
the layout is restored after forcefully stopping Terminal (aka
simulating a "crash")
Closes#18838
## Summary of the Pull Request
Adds the ability to reset the settings.json file and application state
via the Settings UI. Since these are destructive operations, the
destructive styling is applied, as well as a confirmation prompt
notifying the user that this occurs immediately.
## Validation Steps Performed
✅ "reset settings" results in the correct contents for settings.json and
state.json
✅ "reset cache" results in the correct contents for state.json
Closes#947
## Summary of the Pull Request
Adds logic such that local snippets from .wt.json files are imported not
only at the current directory, but also in the parent directories.
## References and Relevant Issues
Spec:
https://github.com/microsoft/terminal/blob/main/doc/specs/%231595%20-%20Suggestions%20UI/Snippets.md
## Validation Steps Performed
`D:\test\.wt.json`: contains `Hello --> hello (parent)`
`D:\test\inner_dir\.wt.json`: contains `Hello --> hello`
- In `D:\test\`...
- ✅ `Hello` command outputs `hello (parent)`
- ✅ commands from `inner_dir` not shown
- In `D:\test\inner_dir\`...
- ✅ `Hello` command outputs `hello`
- ✅ commands from `D:\test` are shown
## PR Checklist
Closes#17805
## Summary of the Pull Request
Updates the New Tab Menu's Match Profiles entry to support regex instead
of doing a direct match. Also adds validation to ensure the regex is
valid. Updated the UI to help make it more clear that this supports
regexes and even added a link to some helpful docs.
## Validation Steps Performed
✅ Invalid regex displays a warning
✅ Valid regex works nicely
✅ profile matcher with source=`Windows.Terminal.VisualStudio` still
works as expected
## PR Checklist
Closes#18553
I finally realized the missing piece.
We need to clear the state array unconditionally,
as otherwise it won't get cleared. Duh.
Closes#18584
## Validation Steps Performed
* Craft a state.json with a layout
* Launch Terminal while the feature is disabled
* state.json is cleaned up on exit ✅
AdaptDispatch has a TODO item indicating that we should *not* consider a
row wrapped until we write into the cell beyond it. We actually do have
that logic (it even refers to it!), but we still set the wrap flag when
we fill the final column.
We never removed it because it broke the old VT rendering-based ConPTY
implementation.
Now that VtEngine is gone, so can be this code and this strange
workaround for a problem nobody was quite sure what was.
This will fix, hopefully, the last of our exact line length write wrap
issues. tmux users can finally rejoice.
Closes#8976Closes#15602
Went through the settings UI and checked which other setting containers
were missing a preview. Here's the list:
- starting directory
- tab title
- background image
- answerback message
- bell style
Adding them was fairly straightforward. Tried to reuse existing
resources when possible. The general pattern was to add a
"Current<Setting>" or "<Setting>Preview" getter that just created the
human-readable format of the setting.
## Validation Steps Performed
✅ value is shown (including special values!)
✅ each of these work with a screen reader
Closes#18576
The `SGR 1` VT attribute can either be interpreted as a brighter color,
or as a bolder font, depending on the _Intense text style_ setting.
However, the concept of brightness only applies to the eight standard
ANSI colors, so when `SGR 1` is configured as _bright_, it has no effect
on the ITU T.416 colors (RGB and the 256 index colors).
To address that, we now interpret `SGR 1` as a bolder font when applied
to ITU colors, regardless of whether the _Intense text style_ option is
set to bold or not.
Note that this only applies to the Atlas render engine, since the GDI
engine doesn't support bold fonts.
## Validation Steps Performed
I've manually tested `SGR 1` applied to different color formats with the
_Intense text style_ option set to _None_, and confirmed that the text
is now rendered with a bold font for ITU colors, but not for ANSI/AIX
colors.
Closes#18284
This fixes#18877, by iteratively checking to see if a line is wrapped
and moving up or down accordingly.
**Current behavior:** When a user triple-clicks on a line that’s
visually wrapped by the terminal, only the single physical row that was
clicked gets selected.
**Expected behavior:** A triple-click like in xterm, should select the
entire logical line including all of its wrapped segments, from the true
start through its true end, regardless of where the wrap occurred.
**Why it matters:** Logical line selection is what users expect when
they’re trying to grab one command or output block in full. Limiting the
selection to just the current physical row can lead to copy/paste
mistakes and a confusing experience whenever a long line wraps.
## Validation Steps Performed
I ran the existing tests using `Invoke-OpenConsoleTests` and they were
passing and I was also able to test the build on my machine. I added a
test case as well
## PR Checklist
Closes#18877
This fixes two issues in the WPF terminal control:
- The emoji picker and other IME candidate windows didn't show up in the
right place
- Submitting an emoji via the emoji picker would result in two win32
input mode events with a VK of 65535 and the surrogate pair halves.
I am not sure I did the right thing with the thread TSF handle...
According to the documentation, the final character of an SGR mouse
report is meant to be `M` for a button press and `m` for a button
release. However it isn't clear what the final character should be for
motion events, and we were using an `m` if there weren't any buttons
held down at the time, while all other terminals used an `M`, regardless
of the button state.
This PR updates our implementation to match what everyone else is doing,
since our interpretation of the spec was causing problems for some apps.
## Validation Steps Performed
I've manually tested the new behavior in Vttest, and confirmed that our
mouse reports now match Xterm more closely, and I've tested with v0.42.0
of Zellij, which was previous glitching badly in Windows Terminal, but
now works correctly.
I've also updated our unit tests for the SGR mouse mode to reflect the
correct report format.
Closes#18712
When calculating the initial terminal window size, we weren't taking
into account the line height and cell width settings, so the resulting
number of rows and columns didn't match the requested launch size.
Verification:
Manually verified that the window is now correctly sized when using a
custom line height and cell width.
Closes#18582
This PR fixes two cases where image content wasn't correctly erased when
overwritten.
1. When legacy console APIs fill an area of the buffer using a starting
coordinate and a length, the affected area could potentially wrap over
multiple rows, but we were only erasing the overwritten image content on
the first affected row.
2. When copying an area of the buffer with text content over another
area that contained image content, the image in the target area would
sometimes not be erased, because we ignored the `_eraseCells` return
value which indicated that the image slice needed to be removed.
## References and Relevant Issues
The original code was from the Sixel implementation in PR #17421.
## Validation Steps Performed
I've manually verified that these two cases are now working as expected.
## PR Checklist
- [x] Closes#18568
This requires us to delay-sign the assembly with a public key (the snk
file), and then later submit it for strong naming. This is separate from
code signing, and has to take place before it.
The snk file does not contain any private key material.
This cannot merge until we are approved to use this new signing "key
code".
We used to cherry-pick every commit that had even one card in "To Cherry
Pick", even if it was also referenced by a card in "Rejected" or even
"To Consider".
Now we will warn and skip those commits.
I took this opportunity to add a bit of an object model for servicing
cards as well as prettify the output.
That allowed us to add a list of cards that were ignored due to having
no commits, and display little icons for each type of card.
`RenderSettings` already stores `DECSCNM` (reversed screen),
so it only makes sense to also store DECSET 2026 there.
## Validation Steps Performed
* Same as in #18826✅
Wanted to learn how the bot works, so I went ahead cleaned up the bot
rules a bit. List of changes:
- added a description for each rule (and move it to the top of the rule)
- added all the "Area-" labels and sorted
The conhost v2 rewrite from a decade ago introduced a race condition:
Previously, we would acquire and hold the global console lock while
servicing
a console API call. If the call cannot be completed a wait task is
enqueued,
while the lock is held. The v2 rewrite then split the project up into a
"server" and "host" component (which remain to this day). The "host"
would
hold the console lock, while the "server" was responsible for enqueueing
wait
tasks _outside of the console lock_. Without any form of
synchronization,
any operations on the waiter list would then of course introduce a race
condition. In conhost this primarily meant keyboard/mouse input, because
that
runs on the separate Win32 window thread. For Windows Terminal it
primarily
meant the VT input thread.
I do not know why this issue is so extremely noticeable specifically
when we
respond to DSC CPR requests, but I'm also not surprised: I suspect that
the
overall performance issues that conhost had for a long time, meant that
most
things it did were slower than allocating the wait task.
Now that both conhost and Windows Terminal became orders of magnitudes
faster
over the last few years, it probably just so happens that the DSC CPR
request
takes almost exactly as many cycles to complete as allocating the wait
task
does, hence perfectly reproducing the race condition.
There's also a slight chance that this is actually a regression from my
ConPTY
rewrite #17510, but I fail to see what that would be. Regardless of
that,
I'm 100% certain though, that this is a bug that has existed in v0.1.
Closes#18117Closes#18800
## Validation Steps Performed
* See repro in #18800. In other words:
* Continuously emit DSC CPR sequences
* ...read the response from stdin
* ...and print the response to stdout
* Doesn't deadlock randomly anymore ✅
* Feature & Unit tests ✅
The "open JSON" button in the settings UI wasn't working when invoked
via accessibility tools (specifically Narrator in scan mode and Voice
Access). For some reason, in those scenarios, neither the `Tapped` or
`KeyDown` event were hit!
This PR adds the logic to open the json file via the `ItemInvoked` event
instead. The `Tapped` and `KeyDown` handlers were removed to prevent a
redundant `OpenJson` event being raised.
Additionally, `SelectsOnInvoked` was set to `False` on the "open JSON"
nav item. This prevents the selection pill from moving to the nav item,
which feels more correct.
## Validation Steps Performed
The following scenarios are confirmed to open the JSON
✅ Mouse click
✅ Keyboard (Spacebar and Enter)
✅ Voice Access
✅ Narrator in scan mode
For all of these (except Voice Access), I've confirmed that holding the
Alt button while invoking the JSON button opens defaults.json.
Closes#18770Closes#12003
This PR adds a new policy definition to the ADMX templates for settings
the default Terminal application in Windows.
> [!Note]
> This PR does not change any code of Windows, Console Host or Windows
Terminal. It only adds the definition for a new policy to the templates.
I got the registry values form the documentation and by testing the
values.
The policy is only available as user policy because the registry values
have to be in HKCU.
The Policy is implemented as preference (not inside the Policy key) and
therefore keeps it's value on removing (not configured) it. You can see
this in `gpedit.msc` on the policy symbol and the hint in the
description.
Closes#18302
Refs #18303
