## 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
You know how much I hate squirreling away information on objects we have
to pass halfway across the universe just to get back.
In this case, `StartingTitle` will always be the name of the profile. We
only used ProfileName in places where we _needed a Title_, so this makes
it much more obvious what we're doing.
## Summary of the Pull Request
Fixes a bug where copying and coloring selected text would be off by
one. This was introduced in #18106 when selection was updated to be
stored as an exclusive range. `Selection::_RegenerateSelectionSpans()`
was updated then, but copying text and coloring selection didn't rely on
selection spans.
Copying text relies on `GetSelectionAnchors()`. This function has now
been updated to increment the bottom-right point of the selection. This
way, `GetTextSpans()` operates on the expected _exclusive_ range.
Coloring selection relies on `TextBuffer::SearchText()`,
`TextBuffer::GetTextRects` and `GetSelectionSpans()`. Both
`Selection::ColorSelection()` were updated to use `rect` over
`inclusive_rect` to emphasize that they are exclusive ranges. Converting
between the two improves clarity and fixes the bug.
## References and Relevant Issues
Introduced in #18106
## Validation Steps Performed
Copying text works in the following scenarios:
✅ single line, left-to-right and right-to-left
✅ multi-line, diagonal directions
✅ block selection
Coloring text works in the following scenarios:
✅ctrl+# --> color instance
✅ctrl+shift+# --> color all instances
Closes#19053
Fixes a few issues with some telemetry events:
- The macro is organized as such: `TraceLoggingX(value, argName,
[argDescription])`. A few args had a description set on the spot where
the name should be. I added a name for a few of these.
- `TraceLoggingBool` --> `TraceLoggingInt32` for `themeChoice` (we
shouldn't be casting the evaluated int as a bool; it loses some of the
data we care about)
- improves the description for `themeChoice` to include information
about the legacy values
Checked through all our telemetry events and all of the args have a
proper name set. We tend to use `TraceLoggingValue` too which
automatically figures out the type that's being used, so that's also
handled.
`IsOn` is the blinker on/off state, which `IsVisible`
is the actual cursor visibility on/off state.
## Validation Steps Performed
* Run bash/zsh in WSL
* (Repeatedly) Quickly scroll right and press A-Z
* Scrolls to the left ✅
Automatically generates an "SSH" folder in the new tab menu that
contains all profiles generated by the SSH profile generator. This
folder is created if the SSH generator created some profiles and the
folder hasn't been created before. Detecting if the folder was generated
is done via the new `bool ApplicationState::SSHFolderGenerated`. The
logic is similar to `SettingsLoader::DisableDeletedProfiles()`.
Found a bug on new tab menu's folder inlining feature where we were
counting the number of raw entries to determine whether to inline or
not. Since the folder only contained the match profiles entry, this bug
made it so that the profile entries would always be inlined. The fix was
very simple: count the number of _resolved_ entries instead of the raw
entries. This can be pulled into its own PR and serviced, if desired.
## References and Relevant Issues
#18814#14042
## Validation Steps Performed
✅ Existing users get an SSH folder if profiles were generated
## PR Checklist
Closes#19043
Due to an unexpected decision on behalf of the Azure Artifacts folks,
the default view for a feed with upstream sources reports all packages,
even if they are not actually populated into the feed.
This results in (uncontrolled) 401 errors whenever a new package appears
upstream, because the feed tells our users and our build system that it
is available, but fails when the download actually begins because it is
not allowed to "write" the upstream version to the feed.
Windows 11 uses some additional signals to determine what the user cares
about and give it a bit of a QoS boost. One of those signals is whether
it is associated with a window that is in the foreground or which has
input focus.
Association today takes two forms:
- Process has a window which is in the foreground or which has input
focus
- Process has a *parent* that meets the above criterion.
Console applications that are spawned "inside" terminal by handoff do
not fall into either bucket. They don't have a window. Their parent is
`dllhost` or `explorer`, who is definitely not in focus.
We are piloting a new API that allows us to associate those processes
with Terminal's window.
When Terminal is in focus, it will attach every process from the active
tab to its QoS group. This means that whatever is running in that tab
is put into the "foreground" bucket, and everything running in other
background tabs is not.
When Terminal is out of focus, it attaches every process to its QoS
group. This ensures that they all go into the "background" bucket
together, following the window.
This extends our current behavior in conhost to scroll to the
cursor position when typing. This is especially relevant in WSL,
where this won't happen at all, otherwise.
Closes#18073
Closes MSFT:49027268
This reverts commit c55aca508beadebc080b0c76b7322de80a294968
because it is unaware of the VT state and may inject the DSR CPR
while e.g. a DCS is going on.
Reopens#18725
* Moves clipboard writing from `ControlCore` to `TerminalPage`.
This requires adding a bunch of event types and logic.
This is technically not needed anymore after changing the
direction of this PR, but I kept it because it's better.
* Add a `WarnAboutMultiLinePaste` enum to differentiate between
"paste without warning always/never/if-bracketed-paste-disabled".
Closes#13014
Closes https://github.com/microsoft/edit/issues/279
## Validation Steps Performed
* Launch Microsoft Edit and copy text with a trailing newline
* Paste it with Ctrl+Shift+V
* It's pasted as it was copied ✅
* Changing the setting to "always" always warns ✅
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
