We believed that this would fix an issue on Windows 10, where the volume
mixer would forget Windows Terminal after every relaunch. It turns out
that it does not.
Still, this code is much more concise and doesn't require yet another
WinRT object. Story of our lives.
Refs #17733
## Summary of the Pull Request
Targets #20010
Adds another `bellStyle` flag option. This sends a windows toast
notification to the user when a BEL is encountered
- [X] Closes#18605
- [ ] Documentation updated
Heavily based on #19936
Co-authored by @zadjii-msft
This adds support for OSC 7 which is the same as OSC 9;9 but using
file URIs. As per the previous discussion in #8214, the problem is
that WSL shells emit URIs that can't work because the hostname in
the URI translates to an UNC path with an non-existing hostname.
In my opinion this doesn't deter the fact though that OSC 7 works
just fine for a native Windows application.
In the future we should consider trying to detect WSL file URIs
and translating it to the `--cd` argument for `wsl.exe`.
All of the heavy lifting for parsing the URI is done by
`PathCreateFromUrlW`. It just had to be plugged into the OSC 9;9 code.
Closes#3158
## Validation Steps Performed
* Launch fish-shell in WSL
* Duplicate tab works ✅
* (And because it doesn't work without using
`IsValidDirectory` I know that OSC 7 works ✅)
Previously, launching an unelevated session after an elevated one would
delete the latter's persisted buffers, and vice versa of course. Also,
elevated buffers didn't have an ACL forbidding access to unelevated
users. That's also fixed now.
Closes#19526
## Validation Steps Performed
* Unelevated/elevated WT doesn't erase each other's buffers ✅
* Old buffers named `buffer_` are renamed to `elevated_` if needed ✅
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
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!
In #16172, we removed the propagation of the profile down into the
Terminal Pane Content.
It was holding on to the profile from the _old_ settings model (😱).
This also broke background image hot reload.
This pull request broadly rewrites how we handle all media resources in
the Terminal settings model.
## What is a media resource?
A media resource is any JSON property that refers to a file on disk,
including:
- `icon` on profile
- `backgroundImage` on profile (appearance)
- `pixelShaderPath` and `pixelShaderImagePath` on profile (appearance)
- `icon` on command and the new tab menu entries
The last two bullet points were newly discovered during the course of
this work.
## Description of Changes
In every place the settings model used to store a string for a media
path, it now stores an `IMediaResource`.
A media resource must be _resolved_ before it's used. When resolved, it
can report whether it is `Ok` (found, valid) and what the final
normalized path was.
This allows the settings model to apply some new behaviors.
One of those new behaviors is resolving media paths _relative to the
JSON file that referred to them._ This means fragments and user settings
can now contain _local_ images, pixel shaders and more and refer to them
by filename.
Relative path support requires us to track the path from which every
media resource "container" was read[^2]. For "big" objects like Profile,
we track it directly in the object and for each layer. This means that
fragments **updating** a profile pass their relative base path into the
mix. For some of the entries such as those in `newTabMenu`, we just wing
it (#19191). For everything that is recursively owned by a parent that
has a path (say each Command inside an ActionMap), we pass it in from
the parent during media resolution.
During resolution, we now track _exactly which layer_ an icon,
background image, or pixel shader path came from and read the "base
path" from only that layer. The base path is not inherited.
Another new behavior is in the handling of web and other URLs.
Canonical and a few other WSL distributors had to resort to web URLs for
icons because we did not support loading them from the package. Julia
tried to use `ms-appx://JuliaPackageNameHere/path/to/icon` for the same
reason. Neither was intended, and of the two the second _should_ have
worked but never could[^1].
For both `http(s?)` URLs and `ms-appx://` URLs which specify a package
name, we now strip everything except the filename. As an example...
If my fragment specifies `https://example.net/assets/foo.ico`, and my
fragment was loaded from `C:\Fragments`, Terminal will look *only* at
`C:\Fragments\foo.ico`.
This works today for Julia (they put their icon in the fragment folder
hoping that one day we would support this.) It will require some work
from existing WSL distributors.
I'm told that this is similar to how XML schema documents work.
Now, icons are special. They support _Emoji_ and _Segoe Icons_. This PR
adds an early pass to avoid resolving anything that looks like an
emoji.
This PR intentionally expands the heuristic definition of an emoji. It
used to only cover 1-2 code unit emoji, which prevented the use of any
emoji more complicated than "man in business suite levitating."
An icon path will now be considered an emoji or symbol icon if it is
composed of a single grapheme cluster (as measured by ICU.)
This is not perfect, as it errs on the side of allowing too many
things... but each of those things is technically a single grapheme
cluster and is a perfectly legal FontIcon ;)
Profile icons are _even more special_ than icons. They have an
additional fallback behavior which we had to preserve. When a profile
icon fails validation, or is expressly set to `null`, we fall back to
the EXE specified in the command line.
Because we do this fallback during resolution, _and the icon may be
inherited by any higher profile,_ we can only resolve it against the
commandline at the same level as the failed or nulled icon.
Therefore, if you specify `icon: null` in your `defaults` profile, it
will only ever resolve to `cmd.exe` for any profile that inherits it
(unless you change `defaults.commandline`).
This change expands support for the magic keywords `desktopWallpaper`
and `none` to all media paths (yes, even `pixelShaderPath`... but also,
`pixelShaderImagePath`!) It also expands support for _environment
variables_ to all of those places. Yes, we had like forty different
handlers for different types of string path. They are now uniform.
## Resource Validation
Media resources which are not found are "rejected". If a rejected
resource lives in _user_ settings, we will generate a warning and
display it.
In the future, we could detect this in the Settings UI and display a
warning inline.
## Surprises
I learned that `Windows.Foundation.Uri` parses file paths into `file://`
URIs, but does not offer you a way to get the original file path back
out. If you pass `C:\hello world`, _`Uri.Path`_ will return
`/C:/hello%20world`. I kid you not.
As a workaround, we bail out of URL handling if the `:` is too close to
the start (indicating an absolute file path).
## Testing
I added a narow test hook in the media resource resolver, which is
removed completely by link-time code generation. It is a real joy.
The test cases are all new and hopefully comprehensive.
Closes#19075Closes#16295Closes#10359 (except it doesn't support fonts)
Supersedes #16949 somewhat (`WT_SETTINGS_DIR`)
Refs #18679
Refs #19215 (future work)
Refs #19201 (future work)
Refs #19191 (future work)
[^1]: Handling a `ms-appx` path requires us to _add their package to our
dependency graph_ for the entire duration during which the resource will
be used. For us, that could be any time (like opening the command
palette for the first time!)
[^2]: We don't bother tracking where the defaults came from, because we
control everything about them.
This will prevent Terminal from erroneously selecting a hidden (deleted,
disabled or otherwise) profile of the same name during restoration and
subsequently using the wrong settings.
I am not certain why we used the name at all!
Closes#19105
If `persistedWindowLayout` is enabled, we now persist the window layout
every few minutes (excluding the text buffer).
This was done by adding a `SafeDispatcherTimer` to the `WindowEmperor`
that calls `PersistState()` every 5 minutes. For `BuildStartupKind`, I
split up `Persist` into `PersistAll` and `PersistLayout`. This way, we
go through all the same code flow that `Persist` had except for
specifically serializing the buffer.
## Validation Steps Performed
✅ (with the timer set to 3 seconds) create a window layout and ensure
the layout is restored after forcefully stopping Terminal (aka
simulating a "crash")
Closes#18838
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.
#17333 introduced a regression: While it fixes a recursion *into*
`Pane::Close()` that doesn't fix the recursion outside of it.
In this case, `Close()` raises the `Closed` event which results
in another tab being closed because it's bound to `_RemoveTab`.
The recursion is now obvious, because I made the entire process
synchronous. Previously, it would (hopefully) just be scheduled
after the pane and its content are already gone.
The issue can be fixed by moving the recursion check from
`Pane::Close()` to `TerminalTab::Shutdown()` but I felt like
it would better to fix the issue a bit more thoroughly.
`IPaneContent` can raise a `CloseRequested` event to indicate it wants
to be closed. However, that also contained recursion, because the
content would call its own `Close()` to raise the event, which the
tab catches, calls `Close()` on the `Pane` which calls `Close()` on
the content which raises the event again and so on. That's what was
fixed in #17333 among others. We can do this better by not raising
the event from `IPaneContent::Close()`. Instead, that method will now
be exclusively called by `Pane`. The `CloseRequested` event will now
truly be just a request and nothing more. Furthermore, the ownership
of the event handling was moved from the `TerminalTab` to the `Pane`.
To make all of this a bit simpler and more robust, two new methods
were added to `Pane`: `_takePaneContent` and `_setPaneContent`.
These methods ensure that `Close()` is called on the content,
that the event handlers are always added and revoked
and that the ownership transfers cleanly between panes.
## Validation Steps Performed
* Open 3 tabs, close the middle one ✅
* Open 3 vertical panes, close the middle one ✅
* Drag tabs with multiple panes between windows ✅
This changes `NewTabArgs`, `SplitPaneArgs`, and `NewWindowArgs` to
accept a `INewContentArgs`, rather than just a `NewTerminalArgs`. This
allows a couple things:
* Users can open arbitrary types of panes with the existing `splitPane`,
`newWindow` actions, just by passing `"type": "scartchpad"` (for
example). This is a lot more flexible than re-defining different
`"openScratchpad"`, `"openTasksPane"`, etc, etc actions for every kind
of pane.
* This allows us to use the existing machinery of session restore to
also restore non-terminal panes.
The `type` property was added to `newTab`, `splitPane`, `newWindow`.
When omitted, we still just treat the json as a blob of NewTerminalArgs.
There's not actually any other kinds of `INewContentArgs` in this PR
(other than the placeholder `GenericContentArgs`). In
[`dev/migrie/fhl/md-pane`](https://github.com/microsoft/terminal/compare/dev/migrie/f/tasks-pane...dev/migrie/fhl/md-pane),
I have a type of pane that would LOVE to add some args here. So that's
forward-thinking.
There's really just two stealth types of pane for now: `settings`, and
`scratchpad`. Those I DON'T have as constants or anything in this PR.
They probably should be? Though, I suspect around the time of the tasks
& MD panes, I'll come up with whatever structure I actually want them to
take.
### future considerations here
* In the future, this should allow extensions to say "I know how to host
`foo` content", for 3p content.
* The `wt` CLI args were not yet updated to also accept `--type` yet.
There's no reason we couldn't easily do that.
* I considered adding `ICanHasCommandline` to allow arbitrary content to
generate a `wt` commandline-serializable string. Punted on that for now.
## other PRs
* #16170
* #16171
* #16172
* #16895
* #16914 <-- you are here
Closes#17014
As @lhecker noted in the #16172 review, `UpdateTerminalSettings` is
wacky. We can just pass the cache in at the start, then reset it and
reuse it in `UpdateSettings`. One fewer `try_as`!
... technically. We still won't let it actually _be_ a pane, but now it
acts like one. It's hosted in a `SettingsPaneContent`. There's no more
`SettingsTab`. It totally _can_ be in a pane (but don't?)
## Validation Steps Performed
* Still opens the settings
* Only opens a single settings tab, or re-activates the existing one
* Session restores!
* Updates the title of the tab appropriately
* I previously _did_ use the scratchpad action to open the settings in a
pane, and that worked.
## Related PRs
* #16170
* #16171
* #16172 <-- you are here
* #16895
Refs #997Closes#8452
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 ✅
Instead of `Pane` hosting a `TermControl` directly, it now hosts an
`IPaneContent`. This is an abstraction between the TermControl and the
pane itself, to allow for arbitrary implementations of `IPaneContent`,
with things that might not be terminals.
## References and Relevant Issues
* #997
* #1000
## Detailed Description of the Pull Request / Additional comments
This PR by itself doesn't do much. It's just a refactoring.
- It doesn't actually add any other types of pane content.
- It overall just tries to move code whenever possible, with as little
refactoring as possible. There are some patterns from before that don't
super scale well to other types of pane content (think: the `xyzChanged`
events on `IPaneContent`).
- There's a few remaining places where Pane is explicitly checking if
its content is a terminal. We probably shouldn't, but meh
There are two follow-up PRs to this PR:
* #16171
* #16172
In addition, there's more work to be done after these merge:
* TODO! issue number for "Replace `IPaneContent::xyzChanged` with
`PropertyChanged` events"
* TODO! issue number for "Re-write state restoration so panes don't
produce `NewTerminalArgs`"
## Validation Steps Performed
* It still launches
* It still works
* Broadcasting still works
* The weird restart connection thing from #16001 still works
## PR Checklist
- [x] Closes#997
## other PRs
* #16170 <-- you are here
* #16171
* #16172
