Our last build failed because it tried to pass "10621.0" off as a
uint64. I didn't know it had to be a single number... so let's use the
3-component equivalent (which would have been 1.24.260303001)
This also moves the Ukrainian Preview release notes to Stable (which
wouldn't happen automatically) and updates them thanks to Serhii.
Co-authored-by: Serhii Pustovit <light.feel@gmail.com>
When a new command is added or an existing command's name is changed,
make sure we update the top-level command list so that it appears there
when the user navigates back to the actions page
## Detailed Description of the Pull Request / Additional comments
Added a new `_CommandListDirty` flag to the `ActionsViewModel`. When a
new command is added or a command's name is changed the flag is set.
When navigating to the top-level actions page, we regenerate the
`_CommandList` if the flag is set.
## Validation Steps Performed
Adding a new command or updating a command's name is now reflected
correctly when navigating back to the actions page.
This only gates VT-driven clipboard writes (OSC 52), not
user-initiated copy.
Closes#19051
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
This PR introduces `compatibility.ambiguousWidth` as a **global**
compatibility setting (`narrow` default, `wide` optional).
The default remains `narrow`.
Why global-only in this PR:
- Width detection is currently process-wide (`CodepointWidthDetector`
singleton).
- True profile-level ambiguous-width behavior would require broader
architectural changes and is intentionally deferred to a follow-up
design/PR.
What this PR guarantees:
- Terminal-side handling is consistent end-to-end for the selected
ambiguous-width policy (rendering path + ConPTY/host propagation).
Known limitation:
- Some client applications (for example PSReadLine/readline-based apps)
may still compute character widths independently.
- In such cases, cursor movement or Backspace behavior can differ from
visual cell width even when terminal-side policy is consistent.
This is a compatibility/readability trade-off feature:
- `narrow`: prioritize cross-application compatibility.
- `wide`: prioritize readability with many CJK fonts.
Closes#153Closes#370
Refs #2928
Refs #2049, #2066, #2375, #900, #5910, #5914
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
## Summary of the Pull Request
Fixes a bug where a partially visible URL would not be detected. This is
fixed by expanding the search space by 1 viewport height in both
directions.
The `_patternIntervalTree` now operates in the absolute-buffer space as
opposed to the viewport-relative space. It's a bit of an annoying
change, but the alternative would be to keep track of the offset used by
the method above, which I find more annoying, personally. As a part of
this change, I made it a bit more clear when something is
viewport-relative vs buffer-absolute.
Regarding mark mode hyperlink navigation, now that everything is in the
absolute-buffer space, I'm able to fix some of the issues in #13854. I
removed `_selectionIsTargetingUrl` and fixed/validated navigating to
hyperlinks that are partially visible.
## Validation Steps Performed
Detects URL that is...
✅ fully visible
✅ partially cropped off the top
✅ partially cropped off the bottom
✅ Above scenarios work with mark mode hyperlink navigation
✅Tests added
Closes#18177Closes#13854
## Summary
Fixes tab row losing acrylic material when window is unfocused, even
when "Allow acrylic material in unfocused windows" is enabled.
## References
Fixes#19544
## Changes
Modified `_updateThemeColors()` in `TerminalPage.cpp` to check both
window focus state and `EnableUnfocusedAcrylic` setting.
## Testing
- Verified acrylic persists when window loses focus (with setting
enabled)
- Verified acrylic removed when setting disabled (expected behavior)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
This pull request resolves a longstanding issue (which probably nobody
but me cared about :P) where gridlines and underlines did not change
color to match the selection or search highlight foreground.
During brush preparation, we stash the underline color; during line
rendering we store it in a third bitmap and during rendering in each
backend we read the colors out of the appropriate bitmap.
The gridlines come from the foreground bitmap and the underlines from
the new underline bitmap.
I've updated each instance of append*Line to break the line-to-render up
by color span.
We are, therefore, no longer passing the stroke color in each gridline
payload.
The original console renderer supports painting the gridlines in
different colors for each half of a 2-cell glyph. That functionality no
longer works in Atlas. To fix it, we would need to move underline _span_
preparation into PaintBufferLine (so that we could apply the right
colors to the bitmap mid-cell.)
Known Issues
------------
- D2D only; dotted lines which are broken by a highlight have doubled
dots (because we draw them as individual line segments and without a
global geometry like curly lines.)
- Atlas (all); grid line colors can no longer change in the middle of
a 2-cell glyph.
Tested By
---------
RenderingTests
## Summary of the Pull Request
Cleans up GenerateSettingsIndex.ps1 by addressing the feedback Dustin
left in #19519
## Validation Steps Performed
✅ SUI search works
## Summary of the Pull Request
There is an issue where clicking an item (with the mouse) from the auto
suggest box's dropdown would fail on the first try, but the dropdown
gets reopened automatically and clicking an item after that works. This
is because `AutoSuggestBox` has `UpdateTextOnSelect` defaulted to
`True`, but we also have a `SuggestionChosen` handler that effectively
does the same thing, and the two were conflicting. This commit fixes
that by removing our `SuggestionChosen` handler.
## Verification steps performed
Selecting an item from the dropdown with mouse works on first try.
Keyboard flow continues to work as expected.
## Summary of the Pull Request
Consolidates the navigation functions in `MainPage` for the settings UI.
This involved:
- combining all separate `_Navigate()` functions into one big one
- deduplicating `SettingsNav().SelectedItem()` calls
- removing the unnecessary variable for a crumb (just inline creation
and registration)
- removing the `elementToFocus` staging behavior for color schemes and
profile sub pages
## References and Relevant Issues
Builds off the work done in #19519 and #19831
## Validation Steps Performed
Navigate to...
✅ simple top-level pages: Startup, Interaction, Appearance, Rendering,
Compatibility, Add profile
✅ Color schemes and subpages
✅ Actions, subpages
✅ New Tab Menu and folder subpages
✅ Extensions, subpages, and profile/scheme navigation
✅ defaults profile and subpages
✅ specific profile and subpages
Also tested discarding changes on these pages.
✅ search still works and navigates to the correct element
## PR Checklist
Closes#19866
Only respond to any search changes in the command palette if the command
palette is visible. Without this check, a previewable action's preview
can appear after the command palette is closed.
## Validation Steps Performed
Preview no longer appears after the command palette is closed
## PR Checklist
Closes#18737
## Summary of the Pull Request
Adds search functionality to the settings UI. This is added to an
`AutoSuggestBox` in the main `NavigationView`. Invoking a result
navigates to the proper location in the settings UI and focuses the
setting, when possible.
## References and Relevant Issues
Based on https://github.com/microsoft/PowerToys/pull/41285
## Detailed Description of the Pull Request / Additional comments
- tools/GenerateSettingsIndex.ps1: parses all the XAML files in the
settings UI for SettingsContainers and builds a search index from them
- XAML changes: ensures all SettingContainer objects have an `x:Name` so
that we can navigate to them and bring them into view.
- TerminalSettingsEditor/Utils.h: implements `BringIntoViewWhenLoaded()`
which navigates to the relevant part of the UI. This is called in
`OnNavigatedTo()` for each page.
- fzf was moved out of TerminalApp so that TerminalSettingsEditor can
access it
- There's a few main components to searching, all of it is in
`MainPage`:
- `MainPage::_UpdateSearchIndex()`|`SearchIndex::Reset()`: loads the
search index generated by `GenerateSettingsIndex.ps1`; provides
additional localization, if needed
- `MainPage::SettingsSearchBox_TextChanged`:
- detect that text changed in the search box
- perform the actual search in `SearchIndex::SearchAsync()`. This is a
HEFTY async function that can be cancelled. It needs a lot of context
passed in to expand the search index appropriately (i.e. build awareness
of "PowerShell" profile and generate results appropriately). This is
also where fzf is used to perform weighted matching.
- the weighted matching itself is pretty complicated, but all the
associated bonus weights are at the top of SearchIndex.cpp.
- `SettingsSearchBox_QuerySubmitted`: extract the search index metadata
and call the correct `_Navigate()` function
## Validation Steps Performed
Search for...
- settings that don't change at runtime:
- [x] global settings
- [x] settings in profile.defaults
- [x] "add new profile" page
- settings that may change at runtime:
- [x] settings in a profile
- [x] individual color schemes
- [x] actions (main actions page + edit action subpage)
- [x] new tab menu folders
- [x] extensions
- misc. corner cases:
- [x] terminal chat (blocked in indexing script; requires minor changes
in feature branch)
- [x] settings in appearance objects
To test fzf matching and weighted results, I specifically tested these
scenarios:
- "PowerShell" --> prioritize the PowerShell profile page(s)
- "font size" --> prioritize profile defaults entry
- "font size powershell" --> prioritize PowerShell > font size
## PR Checklist
Closes#12949
## Follow-ups
- search by JSON key: need a way to add JSON keys to index entries.
`GetSearchableFields()` should make the rest pretty easy.
- search by keywords: need to define keywords. `GetSearchableFields()`
should make the rest pretty easy.
## Summary of the Pull Request
Pretty straightforward. Does exactly what it says on the tin.
## Validation Steps Performed
Pasting works when broadcast input is enabled...
✅ paste w/ mouse
✅ paste w/ keyboard (untouched)
Closes#18821
This pull request removes the feature flag blocking Atlas from being
built into conhost, and introduces a new one preventing Atlas from using
_custom shaders_ in conhost.
This prevents us from taking a new dependency on `d3dcompiler_47.dll`.
It also adds all the build rules necessary to link Atlas in properly.
It is worth noting that Atlas does not work in WinPE, because there's no
DXGI/D2D or anything of note.
- `SetThreadpoolTimer` is equivalent in every way to
`SetThreadpoolTimerEx` for our use case (we throw away the return value)
- `SetThreadDescription` is optional
This essentially rewrites `TerminalInput` from scratch.
There's significant overlap between what kind of information
the Kitty protocol needs from the OS and our existing code.
The rewrite allows us to share large parts of the implementation.
Closes#11509
## Validation Steps Performed
* `kitten show-key -m kitty` ✅
* US Intern. " + ' produces `\'` ✅
* Hebrew base keys produce Unicode ✅
* Hebrew AltGr combinations produce Unicode ✅
* French AltGr+Space produces U+00A0 ✅
* German AltGr+Decimals produce []{}... ✅
- Actions page: entries now stretch across the screen horizontally (to a
max of 1000) to be consistent with other settings pages
- Edit action page:
- `Keybindings` and `Additional arguments` are now top-aligned headers
- All arg templates now also stretch across the screen horizontally to
match how expanders look in the rest of the settings UI
## Validation Steps Performed
Everything still works. Screenshots below.
Similar to the `FontFaceBox`, show all the available shortcut actions
when the user clicks the `ShortcutActionBox`, and filter the results
based on the user's search query
We do not have good test coverage for the `WindowsInbox` build.
- ClipboardTest regressed with #19511
- DECRQCRA tests were not written for WindowsInbox
- FTCS marks tests were not written for WindowsInbox
After this PR:
Summary: Total=7182, Passed=7160, Failed=3, Blocked=0, Not Run=0,
Skipped=19
The 3 failing tests are in the integrity level FT, and they fail because
they expect to be run in an empty console window (the test reads buffer
output starting from 0, 0.)
fmt 11.4 -> 12.1
cmark 0.30 -> 0.31
CLI11 2.4 -> 2.6
This commit retains the addition of `FMT_PEDANTIC` so that we remain
compliant with Microsoft's security requirements.
Replaces usage of `NavigateToXArgs` in the `TerminalSettingsEditor` with
`NavigateToPageArgs`. They all did pretty much the same thing anyways.
Refs #19826
Refs #19519
The maintainers of jsoncpp chose to decline
open-source-parsers/jsoncpp#1154 until they make a new major release.
We are not burdened by that requirement.
Closes#10887
Refs #19834
## Summary of the Pull Request
Fixes a memory leak for `IHostedInWindow` in the TerminalSettingsEditor.
The memory leak occurs from `MainPage` creating an object that stores
reference to back to `MainPage` as `IHostedInWindow`. With `IconPicker`
specifically, the cycle would look like `MainPage` --> `NewTabMenu` -->
`IconPicker` --> `MainPage`.
I've audited uses of `IHostedInWindow` in the TerminalSettingsEditor and
replaced them as weak references. I also checked areas that
`WindowRoot()` was called and added a null-check for safety.
## Validation Steps Performed
Verified `MainPage` and `NewTabMenu` dtors are called when the settings
UI closes from...
✅ Launch page (base case - it doesn't have an `IHostedInWindow`)
✅ New Tab Menu page
## Summary of the Pull Request
This PR pulls out the icon picker used in Profiles_Base.xaml to be its
own control. Then it's reused as a way to set an icon on folders in the
new tab menu.
As a part of pulling out the icon picker into its own control, some
minor code-health polish was added (i.e. lazy loading icon types and
built in icons).
The new tab menu didn't have a `NavigateToPageArgs`, so I took the
declaration from #19519 and moved it here. I chose to do that instead of
creating a `NavigateToNewTabMenuArgs` since that's more strict and it
would be removed as a part of #19519 anyways.
Aside from that, the PR is pretty straightforward.
## References and Relevant Issues
Part of #18281
## Validation Steps Performed
- Profile icon picker
- [x] set none
- [x] set built-in icon
- [x] set emoji
- [x] set file
- [x] loads icons properly (for all of the scenarios above)
- New tab menu folder icon picker
- [x] set none
- [x] set built-in icon
- [x] set emoji
- [x] set file
- [x] loads icons properly (for all of the scenarios above)
Two main changes:
- the build was failing for ARM64 because the build agents run out of
memory downloading artifacts; this is a known issue that nobody cares to
fix (and it pertains to using the x64 emulated agent host on native
arm64 machines)
- deleting the PDBs shrinks the build output by 2500MB :P
- we had to switch to a new type of identity for publishing nuget
packages to our cross-org feed
I've verified that we get counts _and_ can even produce final PGO count
packages for both architectures!