## 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.
## 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
The original intent with dynamic profiles was that they could be
uninstalled but that Terminal would remember your settings in case they
ever came back.
After we implemented dynamic profile _deletion_, however, we
accidentally made it so that saving your settings after a dynamic
profile disappeared scoured it from the planet _forever_ (since we
remembered that we generated it, but now it was no longer in the
settings file).
This pull request implements:
- Tracking for orphaned dynamic profiles
- A new settings page for the profile that explains what happened
- Badging on the Navigation Menu indicating which profiles are orphaned
and which are hidden
Closes#14061Closes#11510
Refs #13916
Refs #9997
This adds a basic policy check for DisabledProfileSources, so that
organizations can easily disable certain profiles like the Azure one.
Closes#17964
## Validation Steps Performed
* Add a policy to disable Azure under HKCU. Disabled ✅
* Add a policy to disable nothing under HKLM. Enabled ✅
(...because it overrides the HKCU setting.)
## Summary of the Pull Request
Adds a global Compatibility page to the settings UI. This page exposes
several existing settings and introduces a few new settings:
- compatibility.allowHeadless
- compatibility.isolatedMode
- compatibility.textMeasurement
- debugFeatures
This also adds a Terminal subpage for profiles in the settings UI. This
page includes:
- suppressApplicationTitle
- compatibility.input.forceVT
- compatibility.allowDECRQCRA
- answerbackMessage
Several smaller changes were accomplished as a part of this PR:
- `experimental.input.forceVT` was renamed to
`compatibility.input.forceVT`
- introduced the `compatibility.allowDECRQCRA` setting
- updated the schema for these new settings and
`compatibility.allowHeadless` (which was missing)
- add `Feature_DebugModeUI` feature flag to control if debug features
should be shown in the SUI
Verified accessible via Accessibility Insights
A part of #10000Closes#16672
Adds functionality throughout the settings model to keep track of which
settings have been set.
There are two entry points:
- AppLogic.cpp: this is where we perform a settings reload by loading
the JSON
- MainPage.cpp: this is where the Save button is clicked in the settings
UI
Both of these entry points call into
`CascadiaSettings::LogSettingChanges()` where we aggregate the list of
changes (specifically, _which_ settings changed, not _what_ their value
is).
Just about all of the settings model objects now have a
`LogSettingChanges(std::set& changes, std::string_view context)` on
them.
- `changes` is where we aggregate all of the changes to. In it being a
set, we don't need to worry about duplicates and can do things like
iterate across all of the profiles.
- `context` prepends a string to the setting. This'll allow us to better
identify where a setting was changes (i.e. "global.X" are global
settings). We also use this to distinguish between settings set in the
~base layer~ profile defaults vs individual profiles.
The change log in each object is modified via two ways:
- `LayerJson()` changes: this is useful for detecting JSON changes! All
we're doing is checking if the setting has a value (due to inheritance,
just about everything is an optional here!). If the value is set, we add
the json key to the change log
- `INHERITABLE_SETTING_WITH_LOGGING` in IInheritable.h: we already use
this macro to define getters and setters. This new macro updates the
setter to check if the value was set to something different. If so, log
it!
Other notes:
- We're not distinguishing between `defaultAppearance` and
`unfocusedAppearance`
- We are distinguishing between `profileDefaults` and `profile` (any
other profile)
- New Tab Menu Customization:
- we really just care about the entry types. Handled in
`GlobalAppSettings`
- Font:
- We still have support for legacy values here. We still want to track
them, but just use the modern keys.
- `Theme`:
- We don't do inheritance here, so we have to approach it differently.
During the JSON load, we log each setting. However, we don't have
`LayerJson`! So instead, do the work in `CascadiaSettings` and store the
changes there. Note that we don't track any changes made via setters.
This is fine for now since themes aren't even in the settings UI, so we
wouldn't get much use out of it anyways.
- Actions:
- Actions are weird because we can have nested and iterable actions too,
but `ActionsAndArgs` as a whole add a ton of functionality. I handled it
over in `Command::LogSettingChanges` and we generally just serialize it
to JSON to get the keys. It's a lot easier than dealing with the object
model.
Epic: #10000
Auto-Save (ish): #12424
This PR clones `winrt::fire_and_forget` and replaces the uncaught
exception handler with one that logs instead of terminating.
My hope is that this removes one source of random crashes.
## Validation Steps Performed
I added a `THROW_HR` to `TermControl::UpdateControlSettings`
before and after the suspension point and ensured the application
won't crash anymore.
We got some new icons for Developer Command Prompt and Developer
PowerShell from our friends over on Visual Studio!
This pull request includes them in the package, and fixes up the VS
dynamic profiles to reset any icons that matched the old paths.
This may be a minor breaking change for user settings, but we're making
the assumption that if they didn't change their VS profile icons from
the defaults, they probably want to follow us to the new defaults.
To prevent anything like this from happening again, we're going to stop
serializing icons for stub profiles.
I've also included a VS version of the PowerShell "black" icon which is
currently unused, but can be used in the future for PS7+-based VS Dev
Shell.
Closes#17627
Between fmt 7.1.3 and 11.0.2 a lot has happened. `wchar_t` support is
now more limited and implicit conversions don't work anymore.
Furthermore, even the non-`FMT_COMPILE` API is now compile-time checked
and so it fails to work in our UI code which passes `hstring` format
strings which aren't implicitly convertible to the expected type.
`fmt::runtime` was introduced for this but it also fails to work for
`hstring` parameters. To solve this, a new `RS_fmt` macro was added
to abstract the added `std::wstring_view` casting away.
Finally, some additional changes to reduce `stringstream` usage
have been made, whenever `format_to`, etc., is available.
This mostly affects `ActionArgs.cpp`.
Closes#16000
## Validation Steps Performed
* Compiles ✅
* Settings page opens ✅
* Every single place that called `read_file_as_utf8_string_if_exists`
would immediately do a `.value_or(std::string{})`.
As such, the function now returns a string directly.
* There was just one caller to `read_file_as_utf8_string`
and it only cared about files that are non-empty.
As such, the specialization got removed.
Both of these make sense to me, as in practice there's seldom
a difference between an empty file and a non-existent one.
## Validation Steps Performed
* Compiles ✅
* Starts ✅
* Deleting the `settings.json` contents triggers a reload ✅
As outlined in #16816, refactor `ActionMap` to use the new action IDs
added in #16904
## Validation steps performed
- [x] Legacy style commands are parsed correctly (and rewritten to the
new format)
- [x] Actions are still layered correctly and their IDs can be used to
'overwrite' actions in earlier layers
- [x] Keybindings that refer to an ID defined in another layer work
correctly
- [x] User-defined actions without an ID have one generated for them
(and their settings file is edited with it)
- [x] Schema updated
Refs #16816Closes#17133
We will no longer serialize IDs that we generated for the user.
This change is being made so that we can release user action IDs at the
same time as the features that require them!
Validation: Generated IDs do not get written to the json, user-made IDs
still do
Closes#17109
As laid out in #16816, adds an `ID` field to `Command`.
**This first PR only adds IDs for built-in commands in defaults, and
generates IDs for user-created commands that don't define an ID.** Also
note that for now we **will not** be allowing IDs for iterable/nested
commands.
The follow-up PR is where we will actually use the IDs by referring to
commands with them.
Refs #16816
## Validation Steps Performed
User-created commands in the settings file get rewritten with generated
IDs
This changeset allows Windows Terminal to dump its buffer contents as
UTF-16LE VT text onto disk and restore it later. This functionality is
enabled whenever `persistedWindowLayout` is being used.
Closes#961Closes#16741
## Validation Steps Performed
* Open multiple windows with multiple tabs and restart the app
Everything's restored ✅
* Reopen a tab with output from `RenderingTests.exe`
Everything's restored ✅
* Closing tabs and windows with Ctrl+W deletes their buffer dumps ✅
* Closing tabs doesn't create buffer dumps ✅
## Summary of the Pull Request
As outlined in #16816 , adding `OriginTag` to `Command` is one of the
prerequisites to implementing Action IDs. This PR does that.
## Validation Steps Performed
Actions/Commands still get parsed and work
## PR Checklist
- [ ] Closes #xxx
- [ ] 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 (if necessary)
More prerequisite work for Action IDs - turns out if we add the action
IDs to the actions defined in `defaults.json` the string ends up being
too large and the compiler complains about it. Use a `.rc` file for
`defaults.json` instead and also for `enableColorSelection.json` +
`userDefaults.json`.
Up until now, we have treated inbox, fragment and user color schemes the
same: we load them all into one big map and when we save the settings
file we write them *all* out. It's been a big annoyance pretty much
forever.
In addition to cluttering the user's settings file, it prevents us from
making changes to the stock color schemes (like to change the cursor
color, or to adjust the colors in Tango Dark, or what have you) because
they're already copied in full in the user settings. It also means that
we need some special UI affordances for color schemes that you are
allowed to view but not to delete or rename.
We also have a funny hardcoded list of color scheme names and we use
that to determine whether they're "inbox" for UI purposes.
Because of all that, we are hesitant to add *more* color schemes to the
default set.
This pull request resolves all of those issues at once.
It:
- Adds an "origin" to color schemes indicating where they're from
(Inbox, Fragment, User, ...)
- Replaces the Edit UI with a much simpler version that pretty much only
has a "duplicate this color scheme to start editing it" button
- Deletes color schemes that we consider to be equivalent to inbox ones;
this allows us to finally disentangle the user's preferences from the
terminal's.
- Migrates all user settings that referred to schemes they may have
modified (even implicitly!) to their modified versions.
The equivalence check intentionally leaves out the cursor and selection
colors, so that we have the freedom to change them in the future.
The Origin is part of a new interface, `ISettingsModelObject`, which we
can use in the future for things like Themes and Actions.
Surprisingly easier than I thought this would be. ActionMap already
supports layering (from defaults.json), so this basically re-uses a lot
of that for fun and profit.
The trickiest bits:
* In `SettingsLoader::_parseFragment`, I'm constructing a fake, empty
JSON object, and taking _only_ the actions out from the fragment, and
stuffing them into this temp json. Then, I parse that as a globals
object, and set _that_ as the parent to the user settings file. That
results in _only_ the actions from the fragment being parsed before the
user's actions.
* In that same method, I'm also explicitly preventing the ActionMap (et
al.) from parsing `keys` from these actions. We don't want fragments to
be able to say "ctrl+f is clear buffer" or something like that. This
required a bit of annoying plumbing.
Closes#16063
Tests added.
Docs need to be updated.
This contains all the parts of #16598 that aren't specific to session
restore, but are required for the code in #16598:
* Adds new GUID<>String functions that remove the `{}` brackets.
* Adds `SessionId` to the `ITerminalConnection` interface.
* Flush the `ApplicationState` before we terminate the process.
* Not monitoring `state.json` for changes is important as it prevents
disturbing the session state while session persistence is ongoing.
That's because when `ApplicationState` flushes to disk, the FS
monitor will be triggered and reload the `ApplicationState` again.
This PR is a few things:
* part the first: Convert the `compatibility.reloadEnvironmentVariables`
setting to a per-profile one.
* The settings should migrate it from the user's old global place to the
new one.
* We also added it to "Profile>Advanced" while I was here.
* Adds a new pair of commandline flags to `new-tab` and `split-pane`:
`--inheritEnvironment` / `--reloadEnvironment`
* On `wt` launch, bundle the entire environment that `wt` was spawned
with, and put it into the `Remoting.CommandlineArgs`, and give them to
the monarch (and ultimately, down to `TerminalPage` with the
`AppCommandlineArgs`). DO THIS ALWAYS.
* As a part of this, we’ll default to _reloading_ if there’s no explicit
commandline set, and _inheriting_ if there is.
* For example, `wt -- cmd` would inherit, and `wt -p “Command Prompt”`
would reload.[^1]
* This is a little wacky, but we’re trying to separate out the
intentions here:
* `wt -- cmd` feels like “I want to run cmd.exe (in a terminal tab)”.
That feels like the user would _like_ environment variables from the
calling process. They’re doing something more manual, so they get more
refined control over it.
* `wt` (or `wt -p “Command Prompt”`) is more like, “I want to run the
Terminal (or, my Command Prompt profile) using whatever the Terminal
would normally do”. So that feels more like a situation where it should
just reload by default. (Of course, this will respect their settings
here)
## References and Relevant Issues
https://github.com/microsoft/terminal/issues/15496#issuecomment-1692450231
has more notes.
## Detailed Description of the Pull Request / Additional comments
This is so VERY much plumbing. I'll try to leave comments in the
interesting parts.
## PR Checklist
- [x] This is not _all_ of #15496. We're also going to do a `-E foo=bar`
arg on top of this.
- [x] Tests added/passed
- [x] Schema updated
[^1]: In both these cases, plus the `environment` setting, of course.
* `[[nodiscard]]` and `[[maybe_unused]]` must come before `virtual` and
`static` qualifiers
* We were calling the jsoncpp constructors directly (again) as functions
(again)
* Some of our preprocessor `#endif` lines were quite messed up
(`-Winvalid-token`)
* One of our test projects was using somebody else's `precomp.h`
Related to #14871
Obviously, icons are all wrong. Color is about right but they need CAN
icons.
I'll leave that as an exercise for @DHowett to generate the right ones
as a follow-up.
Related to #774
Switch the schema depending on the branding we're being built for
Ever since we started writing the entire settings file out ourselves,
we've had the opportunity to control which schema it uses.
This is a quality-of-life improvement for Preview users, and might make
life easier for Dev users as well.
For Debug builds, it even switches over to a local `file://` path to
the schema in the source directory!
Closes#6601
The ability to build and run Terminal as a UWP application was removed
in #12119. We left some of its vestiges around, but now there is no need
for them.
This is a minimal version of the requests for #14858. In that thread we
discussed FULL reverting the default themes to the old ones. In later
discussion, we decided _meh_, let's just ship the legacy themes too, so
it's easy to go back if you should choose. The default still remains the
sane `dark`, but the `legacy*` themes are all right there, and given the
same special treatment as the other inbox themes.
Closes#14858Closes#14844
This pull request implements portable mode for Windows Terminal, which
will make side by side deployment of different versions generally more
feasible.
Portable mode was specified in #15032.
There are three broad categories of changes in this PR:
1. Changes to settings loading.
2. A new indicator in the settings UI plus a link to the portable mode
docs.
3. A new application display name, `Terminal (Portable)`, which users
will hopefully include in their bug reports.
It's surprisingly small for how big a deal it is!
Related to #15034Closes#1386
## Summary
_In the days of old, the windows were sundered, each with its own
process, like the scattered stars in the sky. But a new age hath dawned,
for all windows now reside within a single process, like the bright gems
of a single crown._
_And lo, there came the `WindowEmperor`, a new lord to rule over the
global state, wielding the power of hotkeys and the beacon of the
notification icon. The `WindowManager` was cast aside, no longer needed
to seek out other processes or determine the `Monarch`._
_Should the `WindowEmperor` determine that a new window shall be raised,
it shall set forth a new thread, born from the ether, to govern this new
realm. On the main thread shall reside a message loop, charged with the
weighty task of preserving the global state, guarded by hotkeys and the
beacon of the notification icon._
_Each window doth live on its own thread, each guarded by the new
`WindowThread`, a knightly champion to hold the `TerminalWindow`,
`AppHost`, and `IslandWindow` in its grasp. And so the windows shall run
free, no longer burdened by their former ways._
All windows are now in a single process, rather than in one process per
window. We'll add a new `WindowEmperor` class to manage global state
such as hotkeys and the notification icon. The `WindowManager` has been
streamlined and no longer needs to connect to other processes or
determine a new `Monarch`. Each window will run on its own thread, using
the new `WindowThread` class to encapsulate the thread and manage the
`TerminalWindow`, `AppHost`, and `IslandWindow`.
* Related to #5000
* Related to #1256
## Windows Terminal Process Model 3.0
Everything is now one process. All the windows for a single Terminal
instance live in a singular Terminal process. When a new terminal
process launches, it will still attempt to communicate with an existing
one. If it finds one, it'll pass the commandline to that process and
exit. Otherwise, it'll become the "monarch" and create a new window.
We'll introduce a new abstraction here, called the `WindowEmperor`.
`Monarch` & `Peasant` will still remain, for facilitating cross-window
communication. The Emperor will allow us to have a single dedicated
class for all global state, and will now always represent the "monarch"
(rather than our previously established non-deterministic monarchy to
elevate a random peasant to the role of monarch). We still need to do a
very minimal amount of x-proc calls. Namely, one right on startup, to
see if another `Terminal.exe` was already running. If we find one, then
we toss our commandline at it and bail. If we don't, then we need to
`CoRegister` the Monarch still, to prepare for subsequent launches to
send commands to us.
`WindowManager` takes the most changes here. It had a ton of logic to
redundantly attempt to connect to other monarchs of other processes, or
elect a new one. It doesn't need to do any of that anymore, which is a
pretty dramatic change to that class.
This creates the opportunity to move some lifetime management around.
We've played silly games in the past trying to have individual windows
determine if they're the singular monarch for global state.
`IslandWindow`s no longer need to track things like global hotkeys or
the notification icon. The emperor can do that - there's only ever one
emperor. It can also own a singular copy of the settings model, and hand
out references to each other thread.
Each window lives on separate threads. We'll need to separately
initialize XAML islands for each thread. This is totally fine, and
actually supported these days. We'll use a new class called
`WindowThread` to encapsulate one of these threads. It'll be responsible
for owning the `TerminalWindow`, `AppHost` and `IslandWindow` for a
single thread.
This introduces new classes of bugs we'll need to worry about. It's now
easier than ever to have "wrong thread" bugs when interacting with any
XAML object from another thread. A good case in point - we used to stash
a `static` `Brush` in `Pane`, for the color of the borders. We can't do
that anymore! The first window will end up stashing a brush from its
thread. So now when a second window starts, the app explodes, because
the panes of that window try to draw their borders using a brush from
the wrong thread.
_Another fun change_: The keybinding labels of the command palette.
`TerminalPage` is the thing that ends up expanding iterable `Command`s.
It does this largely with copies - it makes a new `map`, a new `vector`,
copies the `Command`s over, and does the work there before setting up
the cmdpal.
Except, it's not making a copy of the `Command`s, it's making a copy of
the `vector`, with winrt objects all pointing at the `Command` objects
that are ultimately owned by `CascadiaSettings`.
This doesn't matter if there's only one `TerminalPage` - we'll only ever
do that once. However, now there are many Pages, on different threads.
That causes one `TerminalPage` to end up expanding the subcommands of a
`Command` while another `TerminalPage` is ALSO iterating on those
subcommands.
_Emperor message window_: The Emperor will have its own HWND, that's
entirely unrelated to any terminal window. This window is a
`HWND_MESSAGE` window, which specifically cannot be visible, but is
useful for getting messages. We'll use that to handle the notification
icon and global hotkeys. This alleviates the need for the IslandWindow
to raise events for the tray icon up to the AppHost to handle them. Less
plumbing=more good.
### Class ownership diagram
_pretend that I know UML for a second_:
```mermaid
classDiagram
direction LR
class Monarch
class Peasant
class Emperor
class WindowThread
class AppHost
Monarch "1" --o "*" Peasant: Tracks
Emperor --* "1" AppLogic:
Monarch <..> "1" Emperor
Peasant "1" .. "1" WindowThread
Emperor "1" --o "*" WindowThread: Tracks
WindowThread --* AppHost
AppHost --* IslandWindow
AppHost --* TerminalWindow
TerminalWindow --* TerminalPage
```
* There's still only one `Monarch`. One for the Terminal process.
* There's still many `Peasant`s, one per window.
* The `Monarch` is no longer associated with a window. It's associated
with the `Emperor`, who maintains _all_ the Terminal windows (but is not
associated with any particular window)
* It may be relevant to note: As far as the `Remoting` dll is concerned,
it doesn't care if monarchs and peasants are associated with windows or
not. Prior to this PR, _yes_, the Monarch was in fact associated with a
specific window (which was also associated with a window). Now, the
monarch is associated with the Emperor, who isn't technically any of the
windows.
* The `Emperor` owns the `App` (and by extension, the single `AppLogic`
instance).
* Each Terminal window lives on its own thread, owed by a `WindowThread`
object.
* There's still one `AppHost`, one `IslandWindow`, one `TerminalWindow`
& `TerminalPage` per window.
* `AppLogic` hands out references to its settings to each
`TerminalWindow` as they're created.
### Isolated Mode
This was a bit of a tiny brainstorm Dustin and I discussed. This is a
new setting introduced as an escape watch from the "one process to rule
them all" model. Technically, the Terminal already did something like
this if it couldn't find a `Monarch`, though, we were never really sure
if that hit. This just adds a setting to manually enable this mode.
In isolated mode, we always instantiate a Monarch instance locally,
without attempting to use the `CoRegister`-ed one, and we _never_
register one. This prevents the Terminal from talking with other
windows.
* Global hotkeys won't work right
* Trying to run commandlines in other windows (`wt -w foo`) won't work
* Every window will be its own process again
* Tray icon behavior is left undefined for now.
* Tab tearout straight-up won't work.
### A diagram about settings
This helps explain how settings changes get propagated
```mermaid
sequenceDiagram
participant Emperor
participant AppLogic
participant AppHost
participant TerminalWindow
participant TerminalPage
Note Right of AppLogic: AL::ReloadSettings
AppLogic ->> Emperor: raise SettingsChanged
Note left of Emperor: E::...GlobalHotkeys
Note left of Emperor: E::...NotificationIcon
AppLogic ->> TerminalWindow: raise SettingsChanged<br>(to each window)
AppLogic ->> TerminalWindow:
AppLogic ->> TerminalWindow:
Note right of TerminalWindow: TW::UpdateSettingsHandler
Note right of TerminalWindow: TW::UpdateSettings
TerminalWindow ->> TerminalPage: SetSettings
TerminalWindow ->> AppHost: raise SettingsChanged
Note right of AppHost: AH::_HandleSettingsChanged
```
* `lld-link` is more strict about the casing of keywords in `.def` files
* `[[nodiscard]]` must come before `virtual` and `static` qualifiers
* `precomp.h` is never to be included with `<>`
* We were calling the jsoncpp constructors directly (oops) as functions
(oops)
* ClipboardTests constructed `KeyEvent`s by copy instead of directly
* While we can `await` a `Dispatcher`, it's clearer to add `resume_foreground`
This is a rather trivial changeset. Now that these two are present in the
`std` namespace there's no reason for us to continue using the `gsl` ones.
Additionally this ensures future compatibility with other 3rd party libraries.
Implements an initial version of #1571 as it has been specified, the
only big thing missing now is the possibility to add actions, which
depends on #6899.
Further upcoming spec tracked in #12584
Implemented according to [instructions by @zadjii-msft]. Mostly
relatively straightforward, but some notable details:
- In accordance with the spec, the counting/indexing of profiles is
based on their index in the json (so the index of the profile, not of
the entry in the menu).
- Resolving a profile name to an actual profile is done in a similar
fashion as how currently the `DefaultProfile` field is populated: the
`CascadiaSettings` constructor now has an extra `_resolve` function
that will iterate over all entries and resolve the names to instances;
this same function will compute all profile sets (the set of all
profiles from source "x", and the set of all remaining profiles)
- ~Fun~ fact: I spent two whole afternoons and evenings trying to add 2
classes (which turned out to be a trivial `.vcxproj` error), and then
managed to finish the entire rest of it in another afternoon and
evening...
## Validation Steps Performed
A lot of manual testing; as mentioned above I was not able to run any
tests so I could not add them for now. However, the logic is not too
tricky so it should be relatively safe.
Closes#1571
[instructions by @zadjii-msft]: https://github.com/microsoft/terminal/issues/1571#issuecomment-1184851000
This PR adds a new dynamic profile generator which creates profiles to
quickly connect to detected SSH hosts.
This PR adds a new `SshHostGenerator` inbox dynamic profile generator.
When run, it looks for an install of our
[Win32-OpenSSH](https://github.com/PowerShell/Win32-OpenSSH) client app
`ssh.exe` in all of the (official) places it gets installed. If the exe
is found, the generator then looks for and parses both the user and
system OpenSSH config files for valid SSH hosts. Each host is then
converted into a profiles to call `ssh.exe` and connect to those hosts.
VALIDATION
Installed OpenSSH, configured host for alt.org NetHack server, connected
and played some NetHack from the created profile.
* [x] When OpenSSH is not installed, don't add profiles
* [x] Detected when installed via Optional Features (installs in
`System32\OpenSSH`, added to PATH)
* [x] Detected when installed via the 32-Bit OpenSSH MSI from GitHub
(installs in `Program Files (x86)\OpenSSH`, not added to PATH)
* [x] Detected when installed via the 64-Bit OpenSSH MSI from GitHub
(installs in `Program Files\OpenSSH`, not added to PATH)
* [x] Detected when installed via `winget install
Microsoft.OpenSSH.Beta` (uses MSI from GitHub)
* [x] With `"disabledProfileSources": ["Windows.Terminal.SSH"]` the
profiles are not generated
Closes#9031
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
Closes https://github.com/microsoft/terminal/issues/9031
Upgrades check-spelling to v0.0.21
The command to apply changes should now work on Windows (it requires
Perl, but I believe that's more or less present most of the time, and it
should walk you through the rest of the required tools).
There are a bunch of new features, the most important here are probably
being able to update the metadata from Windows. (If it doesn't work,
please @ me).
Also, candidate.patterns will automatically suggest patterns. You can
see them in patterns.txt, e.g.:
```
# Automatically suggested patterns
# hit-count: 3831 file-count: 582
# IServiceProvider
\bI(?=(?:[A-Z][a-z]{2,})+\b)
```
The metadata bits (the hit count/file count) don't have to be retained
(I hope they'll be useful in deciding whether/or not to add a pattern,
i.e. "how applicable is it?"), the comment hinting at what the pattern
does is probably worth retaining.
We've been using more or less this version for a while internally
(including talk-to-bot, and, I do have a pattern that could be used to
let people use that in forks, but, I'm going to skip that for now).
This weekend, I did some cleanup for `act` (to run check-spelling
locally), and some minor polish.
You can see the runs I made in
https://github.com/check-spelling/terminal/actions
After this commit a user may specify fractional font sizes.
Support was only implemented for AtlasEngine however.
DxEngine continues to use rounded (integer) font sizes.
Closes#6678
## Validation Steps Performed
* Install a bitmap font that requires fractional font sizes
(e.g. Terminus TTF, https://files.ax86.net/terminus-ttf/)
* Set font size to something integer (e.g. 14pt)
Glyphs are blurry ✅
* Set font size to something fractional (e.g. 13.5pt)
Glyphs are crisp ✅
With AtlasEngine being enabled by default in 1.16 Preview it would look weird
if the `useAtlasEngine` option would still be called "experimental".
Additionally we're interested in how many users opt out of useAtlasEngine,
indicating major issues that would require us to disable it by default again.
Related to #13936
## Validation Steps Performed
* Toggling `useAtlasEngine` works as expected ✅
* Observe new event with TVPP ✅
## Summary of the Pull Request
As described in #9583, this change implements the legacy conhost "EnableColorSelection" feature.
## Detailed Description of the Pull Request / Additional comments
@zadjii-msft was super nice and provided the outline/plumbing (WinRT classes and such) as a hackathon-type project (thank you!)--a "SelectionColor" runtimeclass, a ColorSelection method on the ControlCore runtimeclass, associated plumbing through the layers; plus the action-and-args plumbing to allow hooking up a basic "ColorSelection" action, which allows you to put actions in your settings JSON like so:
```json
{
"command":
{
"action": "experimental.colorSelection",
"foreground": "#0f3"
},
"keys": "alt+4"
},
```
On top of that foundation, I added a couple of things:
* The ability to specify indexes for colors, in addition to RGB and RRGGBB colors.
- It's a bit hacky, because there are some conversions that fight against sneaking an "I'm an index" flag in the alpha channel.
* A new "matchMode" parameter on the action, allowing you to say if you want to only color the current selection ("0") or all matches ("1").
- I made it an int, because I'd like to enable at least one other "match mode" later, but it requires me/someone to fix up search.cpp to handle regex first.
- Search used an old UIA "ColorSelection" method which was previously `E_NOTIMPL`, but is now wired up. Don't know what/if anything else uses this.
* An uber-toggle setting, "EnableColorSelection", which allows you to set a single `bool` in your settings JSON, to light up all the keybindings you would expect from the legacy "EnableColorSelection" feature:
- alt+[0..9]: color foreground
- alt+shift+[0..9]: color foreground, all matches
- ctrl+[0..9]: color background
- ctrl+shift+[0..9]: color background, all matches
* A few of the actions cannot be properly invoked via their keybindings, due to #13124. `*!*` But they work if you do them from the command palette.
* If you have "`EnableColorSelection : true`" in your settings JSON, but then specify a different action in your JSON that uses the same key binding as a color selection keybinding, your custom one wins, which I think is the right thing.
* I fixed what I think was a bug in search.cpp, which also affected the legacy EnableColorSelection feature: due to a non-inclusive coordinate comparison, you were not allowed to color a single character; but I see no reason why that should be disallowed. Now you can make all your `X`s red if you like.
"Soft" spots:
* I was a bit surprised at some of the helpers I had to provide in textBuffer.cpp. Perhaps there are existing methods that I didn't find?
* Localization? Because there are so many (40!) actions, I went to some trouble to try to provide nice command/arg descriptions. But I don't know how localization works…
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#9583
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed *(what would be the right place to add tests for this?)*
* [ ] 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. *(is this needed?)*
* [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: #xxx
## Validation Steps Performed
Just manual testing.
This commit stores a hash of the `settings.json` file in `ApplicationState`
with which we can detect whether the settings contents actually changed.
Since I only use a small 64-bit hash as opposed to SHA2 for instance,
I'm taking the last write time of the file into account as well.
This allows us to skip calling `UpdateJumplist` at least the majority of app
launches which hopefully improves launch performance on devices with slower IO.
Part of #5907.
## Validation Steps Performed
* Delete some profiles (see above), save settings, tasks are gone ✅
FYI For some (...) inexplicable reason, shell task lists are preserved forever
even if msix applications are uninstalled, etc. So to test whether tasks are
properly written on first app launch we have to delete some profiles/tasks
first, otherwise we can't see whether they're actually written later.
* Now exit Windows Terminal, delete `settings.json` and relaunch
* All tasks are back ✅
* With a debugger, ensure that `CascadiaSettings::WriteSettingsToDisk`
generates the same hash that `LoadAll` reads. ✅
The main fix here is for the caption button colors. If you had a dark OS/app theme, and a light titlebar, we'd end up with light glyphs, so the caption buttons would be impossible to find.
There's also a pile of nits from #12992 in here. Probably enough to close#13456 out, but I'll let Dustin be the judge.
Filing today, to get in for 1.16 selfhost (@DHowett)
##### ⚠️ targeting 1.15
## Summary of the Pull Request
Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties:
* enabling Mica as the window backdrop
* changing the tab row color (read: changing the titelbar color)
These represent the most important asks of theming in the Terminal. The properties added in this PR are:
* Theme color variants:
- `"#rrggbb"` or `"#aarrggbb"`
- `"accent"`
- `"terminalBackground"`
* Properties (_listed here in dot notation, but implemented as sub-objects_)
- `tabRow.background`: accepts a ThemeColor (above)
- `window.applicationTheme`: accepts one of `{"system", "light", "dark"}`
- `window.useMica`: accepts a boolean, defaults to false.
## References
* As first described in #3327
* spec'd in #12530
## PR Checklist
* [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code.
* **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509.
* [x] Closes#1963
* [x] Closes#3774
* [x] Closes#12939
* [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - **SURE DOES**
## Detailed Description of the Pull Request / Additional comments
### --> GO READ #12530 <--
Seriously.
These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there.
They don't layer. You'll need to define your own themes.
Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0.
The sub objects have some gnarly macros to generate a lot of the serialization code for you.
### TODOs
* [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround.
* [x] Make sure `terminalBackground` & the SUI result in something sensible
* [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"`
* [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then.
## Validation Steps Performed
This is the blob I've been testing with:
<details>
```jsonc
// "useAcrylicInTabRow": true,
"theme": "my dark",
// "theme": "Edge",
"theme": "orangey",
"theme": "WHITE",
// "theme": "terminal",
"themes": [
{
"name": "my dark",
"window": {
"applicationTheme": "dark",
"useMica": true,
},
"tabRow": {
"background": "#00000000",
},
},
{
"name": "Edge",
"tabRow": { "background": "accent" },
"window": { "applicationTheme": "system" }
},
{
"name": "orangey",
"window": {
"applicationTheme": "light",
"useMica": true,
},
"tabRow": {
"background": "#ff8800",
},
},
{
"name": "WHITE",
"window": {
"applicationTheme": "dark",
"useMica": true,
},
"tabRow": {
"background": "#FFFFFF",
},
},
{
"name": "terminal",
"window": {
"applicationTheme": "dark",
"useMica": false,
},
"tabRow": {
"background": "terminalBackground",
},
},
]
```
</details>
Windows Terminal Preview gets existing settings from Release build if
Preview settings are empty
This ensures that when settings are empty or not existent, we check if
we're currently in a preview build and if we are, we attempt to grab
settings from the Release build's setting path instead. We tested it
manually by changing settings in Release build and confirming that
changes migrated to Preview when settings are empty or not existent.
Additionally, we tested that settings.json of the running build changed.
We also ran existing TAEF testing locally and it passed.
In LoadAll() function in
src\cascadia\TerminalSettingsModel\CascadiaSettingsSerialization.cpp, we
first checked if the settings file us empty/exists via settingsString.
If it does not and we are in the Preview build, we try loading the
Release build's settings. We created modified versions of
CascadiaSettings::_settingsPath() and GetBaseSettingsPath() to get the
path for the Release build's settings. If the Release build settings do
exist and firstTimeSetup is true, we set it to settingsString so it can
be written to disk via WriteSettingsToDisk(). Note that currently we
hardcode the path of the Release build. This pull request was worked on
with @Dannihu01.
## Validation Steps Performed Test1: Setting to firstTimeSetup is true
and loading settings.json from WT release when release exists -> Result:
settings.json AND GUI reflected WT release’s settings
Test2: Setting to firstTimeSetup is true and loading settings.json from
WT release when release doesn’t exist -> Result: settings.json AND GUI
reflected DEFAULT settings
Test3: (After running Test1) Setting to firstTimeSetup is false and
seeing if current settings.json matches WT release. (See if it doesn’t
change) -> Result: settings.json AND GUI reflected WT release’s settings
Closes#6855
Co-authored-by: Danniell Hu <dannihu@umich.edu>
If we want to make Windows Terminal the default terminal under Windows,
we'll have to make conhost "handoff" incoming connections by default.
But this poses a problem: How can the seldomly updated conhost know
whether the routinely updated Windows Terminal version is actually willing
to accept such handoffs by default (it might be unwilling due to bugs, etc.)?
This commit solves the issue by introducing:
* A marker interface (`IDefaultTerminalMarker`): If it exists,
Windows Terminal indicates its willingness to accept the handoff.
* Turning the all-0 GUID from being synonymous for conhost,
to being synonymous for "Let Windows decide". Without this we wouldn't
be able to differentiate between users who consciously chose conhost
as their default terminal, vs. users who want the standard behavior.
## Validation Steps Performed
Testing fallback behavior:
* Install "Terminal" 1.13
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Launching `cmd.exe` launches as a conhost window ✅
(because "Terminal" 1.13 lacks the marker interface)
* Open properties page in `conhost.exe`
"Let Windows decide" is select by default ✅
* Changing the selection writes the new value ✅
Testing the new behavior:
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Use `CLSID_WindowsTerminalConsoleDev` and `CLSID_WindowsTerminalTerminalDev`
for the initialization of `TerminalDelegationPair`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Deploy the "Terminal Dev" package
* Launching `cmd.exe` launches "Terminal Dev" ✅
(because "Terminal Dev" has the marker interface)
* Open the settings tab
"Let Windows decide" is select by default ✅
* Changing the selection and saving writes the new value ✅
#4015 requires sweeping changes in order to allow a migration of our buffer
coordinates from `int16_t` to `int32_t`. This commit reduces the size of
future commits by using type inference wherever possible, dropping the
need to manually adjust types throughout the project later.
As an added bonus this commit standardizes the alignment of cv qualifiers
to be always left of the type (e.g. `const T&` instead of `T const&`).
The migration to type inference with `auto` was mostly done
using JetBrains Resharper with some manual intervention and the
standardization of cv qualifier alignment using clang-format 14.
## References
This is preparation work for #4015.
## Validation Steps Performed
* Tests pass ✅
#12149 introduced a bug where `ClearCommandline()` is called on any user
profile containing the non-canonical strings "cmd.exe" or "powershell.exe"
in the "commandline" field. If you happen to have set the "commandline"
field in your `profiles.defaults`, this will cause these user profiles
to adopt the base layer command-line instead of the defaults layer one.
This commit fixes the issue, by checking the command-line after the call
to `ClearCommandline()` and ensuring it's the expected string.
Additionally this moves the migration logic to `SettingsLoader` as this allows
us to write the fixed settings to disk, if any fixed had to be applied.
## PR Checklist
* [x] Closes#12842
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* The modified unit test fails without these changes ✅
* The modified unit test succeeds with these changes ✅
* Setting `profiles.defaults.commandline` to "pwsh.exe" and setting
my "...\\powershell.exe" profile to use just "powershell.exe" as
the `commandline`, doesn't cause it to use "pwsh.exe" ✅
The fixed settings are written to settings.json ✅
After this commit we only set the default fields of a profile - primarily the
name field - as late as possible, after layering has already completed.
This ensures that we pick up any modifications from fragments.
## PR Checklist
* [x] Closes#12520
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Add a fragment at
`%LocalAppData%\Microsoft\Windows Terminal\Fragments\Fragment\fragment.json`
with
`{"profiles":[{"updates":"{61c54bbd-c2c6-5271-96e7-009a87ff44bf}","name":"NewName"}]}`
* Windows PowerShell profile is created with the name "NewName" in settings.json ✅
This commit fixes a stray exception during settings loading,
caused by a failure to obtain the app's extension catalog.
## PR Checklist
* [x] Closes#12305
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
I'm unable to replicate the issue. ❌
However an error log was provided in #12305 with which
the function causing the exception could be determined.
## Summary of the Pull Request
This makes it so that the settings.json backups are no longer created when the user saves their settings via the Settings UI.
Closes#11703
In previous releases, we had the commandlines for the Command Prompt and PowerShell profiles unqualified, as `cmd.exe` and `powershell.exe`. This was bad - theoretically, that would have preferred the cmd that was in the CWD over the one in System32. Or, something could insert itself into the path, and you'd end up with a malicious `cmd.exe` before the real one.
In #11437, we made sure that the `userDefaults` are initiated with the fully qualified paths. However, that didn't fix the issue for folks who already had settings files.
In an effort to better prevent this kind of badness, if we see a profile _with a default profile guid_, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one.
* Related to #11437
* [x] fixes#12126
* [x] Tests added
