Render SGR1 as bold in 256 and true colors, where "bold is intense" is
not applicable.
Implemented by creating 2 extra fonts: bold for 1 and bold italic for 1
+ 3.
No non-trivial changes, just extensions.
LOGFONT also supports Underline and StrikeOut, but they seem to be
already covered by other means, so no combinatorial explosion of fonts
expected.
Refs #18919
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
## Summary of the Pull Request
Update the WinGet CNF package search to match that of the updated
PowerShell WinGet CNF module. Now, we'll only search for matching
commands instead of by name and moniker.
## References and Relevant Issues
https://github.com/microsoft/winget-command-not-found/pull/29
## Validation Steps Performed
✅ In CMD, type "vim" and vim packages are suggested
## Summary of the Pull Request
Turns out that the `"TabViewItemHeaderBackground"` resource should be
set to the _selected_ color instead of the _deselected_ color.
In 1.22, (pre-#18109) we actually didn't set this resource. But we do
actually need it for high contrast mode! (verified)
## Validation Steps Performed
✅ High contrast mode looks right
✅ "Snazzy" theme from bug report looks right
## PR Checklist
Closes#19343
Apparently, `GetModuleFileNameW` returns exactly the path (or prefix, in
case of a DLL) passed to `CreateProcess` casing and all. Since we were
using it to generate the uniquing hash for Portable and Unpackaged
instances, this meant that `C:\Terminal\wt` and `C:\TeRmInAl\wt` were
considered different instances. Whoops.
Using `QueryFullProcessImageNameW` instead results in canonicalization.
Maybe the kernel does it. I don't know. What I do know is that it works
more correctly.
(`Query...` goes through the kernel, while `GetModule...` goes through
the loader. Interesting!)
Closes#19253
## Summary of the Pull Request
When we introduced action IDs, we separated "commands" from
"keybindings", and introduced fixup logic to rewrite the legacy-style
command blocks into the new version. However we don't do any ID logic
for nested and iterable commands, so make sure we don't inform the
loader for fixups in those cases.
## Validation Steps Performed
We no longer repeatedly attempt to fixup the settings file when we see a
`"keys"` entry in a nested/iterable command block
## PR Checklist
- [x] Closes#18736
## Summary of the Pull Request
Fixes a couple of minor issues in the settings schema which can result
in erroneous settings validation failures.
## References and Relevant Issues
None
## Detailed Description of the Pull Request / Additional comments
- `answerbackMessage`
Permit `null` type (corresponds to the default value).
- `compatibility.input.forceVT`
Add missing setting (previously was `experimental.input.forceVT`).
- `rendering.graphicsAPI`
Add missing `automatic` enumeration value.
- Mark several settings as deprecated using the same format and direct
the user to the updated settings to use.
## Validation Steps Performed
Tested updated schema against configuration with above settings present.
## PR Checklist
- [X] Schema updated (if necessary)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
If the progress state hasn't been set for more than 200ms, we shouldn't
even bother flickering the old state.
This prevents applications from making the tab (and the taskbar icon)
flicker.
We were reviewing #19394 and decided that the _original_ behavior before
Leonard's throttling fix was somewhat unfortunate as well. An
application that sets an indeterminate state for 10ms and then clears it
shouldn't be able to make any part of the application flicker, fast _or_
slow.
Removing the leading fire time from the throttled function ensures that
it will only fire once every 200ms, and only with the state most
recently set. It will not debounce (so setting the progress every 150ms
will not prevent it from updating.)
Closes#19394
The previous fix in #19296 moved the _destruction_ of AppHost into the
tail end after we manipulate the `_windows` vector; however, it kept the
part which calls into XAML (`Close`) before the `erase`. I suspect that
we still had some reentrancy issues, where we cached an iterator before
the list was modified by another window close event.
That is:
```mermaid
sequenceDiagram
Emperor->>Emperor: Close Window
Emperor->>+AppHost: Close (a)
AppHost->>XAML: Close
XAML-->>Emperor: pump loop
Emperor->>Emperor: Close Window
Emperor->>+AppHost: Close (b)
AppHost->>XAML: Close
XAML-->>Emperor: pump loop
AppHost->>-Emperor: Closed
Emperor->>Emperor: erase(b)
AppHost->>-Emperor: Closed
Emperor->>Emperor: erase(a)
```
Moving the `Close()` to after the `erase` ensures that there are no
cached iterators that survive beyond XAML pumping the message loop.
Fixes 8d41ace3
## Summary of the Pull Request
Adds the tab color profile setting to the settings UI. It's positioned
next to the tab title at the root of the profile page.
The new component uses a nullable color picker control to allow the user
to pick a color. The null color is represented as "Use theme color".
The tricky part is evaluating the `ThemeColor` for `null` (aka "use
theme color"). Since the value is dependent on the active theme, it can
be any of the following values:
- theme.tab.background...
- explicit color
- accent color
- terminal background color
- (if no theme.tab.background is defined) theme.window.applicationTheme
- light --> #F9F9F9
- dark --> #282828
- default --> one of the above two values depending on the application
theme
The above light/dark values were acquired by using the color picker on
the tab when in light/dark theme.
## Validation Steps Performed
✅ accessible value is read out
✅ explicit tab color set
- tab color is null, so we fall back to...
- ✅ theme.tab.background: explicit color, accent color, terminal
background color
- ✅ theme.window.applicationTheme (and no theme.tab.background defined):
light, dark, default (aka not defined)
- ✅ updates when theme is changed locally and via JSON
## PR Checklist
Closes part of #18318
This will allow us to publish vpacks without making the build fail
waiting for us to *merge* those vpacks into Windows. It also gives us
better control over when and where the vpack update gets merged.
Goal: Remove `CursorBlinker`.
Problem: Spooky action at a distance via `Cursor::HasMoved`.
Solution: Moved all the a11y event raising into `_stream.cpp` and pray
for the best.
Goal: Prevent node.js from tanking conhost performance via MSAA (WHY).
Problem: `ServiceLocator`.
Solution: Unserviced the locator. Debounced event raising. Performance
increased by >10x.
Problem 2: Lots of files changed.
This PR is a prerequisite for #19330
## Validation Steps Performed
Ran NVDA with and without UIA enabled and with different delays. ✅
Some of the other settings fixups require there to be a valid
NewTabMenu, rather than just a temporary object. Since the resolving all
the menu entries after loading already forces the user to have a
`newTabMenu`, let's just codify it as a real fixup.
I've moved the SSH folder fixup after the settings fixup because it
relies on there being a NTM.
I decided not to make this fixup write back to the user's settings.
There are a couple reasons for this, all of which are flimsy.
- There are a number of tests that test fixup behavior, especially those
around actions, which would need to be updated for this new mandatory
key. I did not think it proper to add `newTabMenu` to ten unrelated
tests that only contain actions (for example.)
- We actually don't currently have mandatory keys. But this one was
always being added anyway, in a later phase...
- It's consistent with the existing behavior.
Closes#19356
This adds support for horizontal mouse wheel events (`WM_MOUSEHWHEEL`).
With this change, applications running in the terminal can now receive
and respond to horizontal scroll inputs from the mouse/trackpad.
Closes#19245Closes#10329
Fixes the terminal profile jsonschema to allow for null in the id. This
is to match the current implementation when disabling a built in default
keybind.
I do not like this.
## Validation Steps Performed
* Enable close buttons on tabs
* Open a tab
* Close the tab with middle click
* Open a tab
* Right click the tab
* Tab doesn't close, Menu opens ✅
Implements reflection to the various ActionArg types in the settings
model, which allows these structs to provide information about
themselves (i.e. what args they contain and what types they are). This
is necessary as a pre-requisite for the Settings Editor to display and
modify these arg values.
## Detailed Description of the Pull Request / Additional comments
* The `IActionArgs` interface now has additional methods:
* Get the number of args
* Get/Set an arg at a specific index
* Get a vector of arg descriptions; the arg description contains:
* name of the arg
* type of the arg
* whether the arg is required
* a tag, this is to cover special cases (for example the ColorScheme
argument is technically of type "string", but only allows specific
values)
* All the macros in `ActionArgsMagic` have been updated to support the
new interface
* `ActionMap` has been updated to support adding/editing/deleting
actions and keybindings from outside the SettingsModel
* It also handles ID change requests for commands
* EnumMappings have been added to various ActionArg enums that weren't
there before
## Validation Steps Performed
Bug bashed in conjunction with #18917
The idea with IControlSettings (and friends) was always that a consumer
of the terminal control could implement it in whatever way they pleased.
Windows Terminal (the application) was intended to be only one
consumer. It has a whole JSON settings model. Nobody wants to think
about JSON at the Terminal Control level. We could have an "adapter" in
TerminalApp, which spoke Terminal JSON Settings on one side and Terminal
Control on the other side.
That worked until we added the settings editor. The settings editor
needed to display a control, and that control's settings needed to be
based on the JSON settings. Oops. We took the expedient route of moving
the adapter into TerminalSettingsModel itself, and poking a bunch of
holes in it so that TerminalApp and TerminalSettingsEditor could tweak
it as needed.
Later, we doubled down on the control settings interface by having every
Terminal Control _make its own ControlSettings_ when we were going to do
the multi-process model. This reduced the number of IPC round trips for
every settings query to 0. Later we built color scheme previewing on top
of that--adding structs to carry color schemes and stuff which was
already in the Appearance config. Sheesh. Layers and layers and layers.
This pull request moves it back into its own library and strips it from
the surface of TerminalSettingsModel. It also deletes `ControlSettings`
and `struct CoreScheme`. That library is called
`TerminalSettingsAppAdapterLib`, and it contains a hidden WinRT
_implements_ type rather than a full-fledged activatable `runtimeclass`.
It also implements one-level inheritance on its own rather than using
IInheritable.
It adheres to the following principles:
- The control will never modify its settings in a way that is visible to
the control's consumer; therefore, none of the properties have setters
- The settings should never contain things of interest only to the
Application that the Application uses to communicate data _back to
itself_ (see `ProfileName`, removed in 68b723c and `KeyBindings`,
removed in fa09141). This generalizes to "we should never store stuff
in an unrelated object passed between layers solely for the purpose of
getting it back".
I made a few changes to the settings interface, including introducing a
new `ICoreScheme` interface that _only_ contains color scheme info. This
is designed to support the Preview/Set color scheme actions, which no
longer work by _app backing up the scheme and restoring it later._ All
of that machinery lives inside TermControl/ControlCore now.
`ICoreScheme` no longer supports `GetColorAtIndex`; you must read all 16
colors at the same time. I am not sorry. Every consumer did that
already, so now we have 15 fewer COM calls for every color scheme.
The new TerminalSettings is mostly consumed via
`com_ptr<TerminalSettings>`, so a bunch of `.` (projected) accesses had
to turn into `->` (com_ptr dereferencing) accesses.
I also realized, in the course of this work, that the old
TerminalSettings contained a partial hand-written reimplementation of
_every setting_ in `ControlProperties`. Every contributor had to add
every new setting to both places--why? I can't figure it out. I'm using
ControlProperties comprehensively now. I propagated any setting whose
default value was different from that in ControlProperties back to
ControlProperties.
This is part X in a series of pull requests that will remove all mention
of Microsoft.Terminal.Control and Microsoft.Terminal.Core from the
settings model. Once that is done, the settings model can consume _only_
the base WinRT types and build very early and test more easily.
Previewing is fun. I introduced a new place to stash an entire color
table on ControlCore, which we use to save the "active" colors while we
temporarily overwrite them. SetColorScheme is _also_ fun. We now have a
slot for overriding only the focused color scheme on ControlCore. It's
fine. It's clearer than "back up the focused appearance, overwrite the
focused appearance, create a child of the user's settings and apply the
color scheme to it, etc.".
There is a bug/design choice in color scheme overriding, which may or
may not matter: overlaying a color scheme on a terminal with an
unfocused appearance which _does not_ have its own color scheme will
result in the previously-deleted overridden focused color scheme peeking
through when the terminal is not focused.
I also got rid of our only in-product use of
`Terminal::CreateFromSettings` which required us to set `InitialRows`
and `InitialCols` on the incoming settings object (see core tenet 2).
Refs #19261
Refs #19314
Refs #19254
For some reason, we went real hard on an architecture where the settings
object contained the key bindings handler for the terminal. To make this
work, we had to wind it through tons of layers: `TermControl`,
`ControlInteractivity`, `ControlCore` (which saved it on
`ControlSettings`), `ControlSettings`. Of course, because we have no
clear delineation of concerns at the App layer this required us to put
the bindings into the Settings Cache[^1].
Well, `TermControl` used `ControlCore` to get the Settings, to get the
Bindings, to dispatch keys.
Yes, `TermControl` stored `IKeyBindings` down three layers _only to fish
it back out and use it itself._
There is one place in the application where `TermControl`s are hooked up
to their owners. Instead of passing the key bindings dispatcher in
through nine hundred layers, we can just set it once--definitively!--
there.
[^1]: This was the last thing that made the settings cache
page-specific...
tl;dr: ~Apphost() may pump the message loop.
That's no bueno. See comments in the diff.
Additionally, this PR enables `_assertIsMainThread` in
release to trace down mysterious crashes in those builds.
tl;dr: Open/CloseClipboard are surprisingly not thread-safe.
## Validation Steps Performed
* Copy a large amount of text (>1MB)
* Run `edit.exe`
* Press and hold Ctrl+Shift+V
* Doesn't crash ✅
I legitimately cannot figure out how I forgot this. Bell should support
all the same validation as other media resources! Technically this means
you can set `bellSound` to `desktopWallpaper`, but... we'll pretend that
makes sense.
I reworked the viewmodel to be a little more sensible. It no longer
requires somebody else to check that its files exist. The settings UI
now also displays `File not found` in the _preview_ for the bell if it
is a single file which failed validation!
Test Impact: The LocalTests do not call `Initialize(HWND)`, so we would
fail on launch.
Also, we have `Create()` and `Initialize()` and `event Initialized` (the
last of which is not called from either of the first two...)
Reflect inbox changes to `onecore/windows/core/console/open`.
* eed3a6fa5 Merged PR 13076689: Update managed TAEF tests that exist in
GE branches to use the new publishing locations of TAEF's managed
reference binaries.
* 718d7d02d Merged PR 12483430: build console* with clang
Somebody internal is trying to build the console with Clang (which is
cool).
---------
Co-authored-by: Dragos Sambotin <dragoss@microsoft.com>
Co-authored-by: Phil Deets <pdeets@microsoft.com>
Interesting changes in this update:
- better support for `REFIID,IUnknown**` in `capture`
- `LOAD_LIBRARY_SEARCH_DEFAULT_DIRS` for all SxS DLL loading
- `get_self` reading from classic COM interfaces (rather than WinRT
ones)
- better incremental builds by ignoring stale winmd files (see
microsoft/cppwinrt#1404)
- some ability to mix c++17 and c++20 static libraries
- better codegen for `consume` methods
This version of C++/WinRT is better about propagating `protected`
fields from the metadata into the C++ projections. This required
us to switch to the `I...Protected` interfaces for some things
we are _technically_ not allowed access to. We also had some
`overridable` (protected!) members of our own that needed undec-
oration.
The unfocused appearance section in the settings UI looks a little off.
Specifically, the header was too large (larger than the breadcrumbs!)
and the button was weirdly aligned.
This PR reduces the size of the header and creates a style in
CommonResources that manages it. This is the only place it's used, for
now. A vertical alignment was added to the "create appearance" and
"delete appearance" buttons to make them look better. The top margin of
the "Text" header was also removed so that there isn't an awkward gap in
the unfocused appearance section (the 32 that was there was moved to the
bottom of the control preview so that that area remains unaffected.)
Follow-up from #19001
## Summary of the Pull Request
Adds a telemetry provider to the Terminal.Settings.Editor project as
well as new telemetry events to track traffic through the settings UI.
Specifically, the following events were added:
- `NavigatedToPage`: Event emitted when the user navigates to a page in
the settings UI
- Has a `PageId` parameter that includes the identifier of the page that
was navigated to
- (conditionally added when PageId = `page.editColorScheme`)
`SchemeName` parameter tracks the name of the color scheme that's being
edited
- conditionally added when PageId = `page.extensions`:
- `ExtensionPackageCount`: The number of extension packages displayed
- `ProfilesModifiedCount`: The number of profiles modified by enabled
extensions
- `ProfilesAddedCount`: The number of profiles added by enabled
extensions
- `ColorSchemesAddedCount`: The number of color schemes added by enabled
extensions
- conditionally added when PageId = `page.extensions.extensionView`:
- `FragmentSource`: The source of the fragment included in this
extension package
- `FragmentCount`: The number of fragments included in this extension
package
- `Enabled`: The enabled status of the extension
- (conditionally added when PageID = `page.newTabMenu`) if the page is
representing a folder view
- conditionally added when PageID = `page.profile.*`:
- `IsProfileDefaults`: if the modified profile is the profile.defaults
object
- `ProfileGuid`: the guid of the profile that was navigated to
- `ProfileSource`: the source of the profile that was navigated to
- conditionally added when PageID = `page.profile` (aka the base profile
page):
- `Orphaned`: tracks if the profile was orphaned
- `Hidden`: tracks if the profile is hidden
- (conditionally added when PageID = `page.profile.appearance`)
`HasBackgroundImage`: `if the profile has a background image defined`
- (conditionally added when PageID = `page.profile.appearance`)
`HasUnfocusedAppearance`: `if the profile has an unfocused appearance
defined`
- `AddNewProfile`: Event emitted when the user adds a new profile
`IsExtensionView` parameter tracks if the page is representing a view of
an extension
- Has a `Type` parameter that represents the type of the creation method
(i.e. empty profile, duplicate)
- `ResetApplicationState`: Event emitted when the user resets their
application state (via the UI)
- `ResetToDefaultSettings`: Event emitted when the user resets their
settings to their default value (via the UI)
- `OpenJson`: Event emitted when the user clicks the Open JSON button in
the settings UI
- Has a `SettingsTarget` parameter that represents the target settings
file (i.e. settings.json vs defaults.json)
- `CreateUnfocusedAppearance`: Event emitted when the user creates an
unfocused appearance for a profile
- `IsProfileDefaults`: if the modified profile is the profile.defaults
object
- `ProfileGuid`: the guid of the profile that was navigated to
- `ProfileSource`: the source of the profile that was navigated to
- `DeleteProfile`: Event emitted when the user deletes a profile
- also includes `ProfileGuid`, `ProfileSource`, `Orphaned` from the
`NavigatedToPage` section above
The page ids can be reused later as a serialized reference to the page.
We already use the one for the extensions page for the "new" badge.
The Name, Source, and Commandline profile settings should not be allowed
to be set on the Profiles.Defaults object. This just enforces that by
clearing them (as is done with Guid).
These profile settings are omitted from the settings UI's profile
defaults page.
Closes#19202
