We need to act like a ConPTY just a little earlier in startup. My relevant notes start here: https://github.com/microsoft/terminal/issues/15245#issuecomment-1536150388.
Basically, we'd create the first screen buffer with 9001 rows, because it would be created _before_ VtIo would be in a state to say "yes, we're a conpty". Then, if a CLI app emits an entire screenful of text _before_ the terminal has a chance to resize the conpty, then the conpty will explode during `_DoLineFeed`. That method is absolutely not expecting the buffer to get resized (and the old text buffer deallocated).
Instead, this will treat the console as in ConPty mode as soon as `VtIo::Initialize` is called (this is during `ConsoleCreateIoThread`, which is right at the end of `ConsoleEstablishHandoff`, which is before the API server starts to process the client connect message). THEORETICALLY, `VtIo` could `Initialize` then fail to create objects in `CreateIoHandlers` (which is what we used to treat as the moment that we were in conpty mode). However, if we do fail out of `CreateIoHandlers`, then the console itself will fail to start up, and just die. So I don't think that's needed.
This fixes#15245. I think this is PROBABLY also the solution to #14512, but I'm not gonna explicitly mark closed. We'll loop back on it.
Oklab by Björn Ottosson is a color space that has less irregularities
than the CIELAB color space used for ΔE2000. The distance metric for
Oklab (ΔEOK) is defined by CSS4 as the simple euclidian distance.
This allows us to drastically simplify the code needed to determine
a color that has enough contrast. The new implementation still lacks
proper gamut mapping, but that's another and less important issue.
I also made it so that text with the dim attribute gets adjusted just
like regular text, since this is an accessibility feature after all.
The new code is so much faster than the old code (12-125x) that I
dropped any caching code we had. While this increases the CPU overhead
when printing lots of indexed colors, the code is way less complex now.
"Increases" in this case however means something in the order of 15-60ns
per color change (as measured on my CPU). It's possible to further
improve the performance using explicit SIMD instructions, but I've
left that as a future improvement, since that will make the code quite
a bit more verbose and I didn't want to hinder the initial review.
Finally, these new routines are also used for ensuring that the
AtlasEngine cursors remains visible at all times.
Closes#9610
## Validation Steps Performed
* When `adjustIndistinguishableColors` is enabled
colors are distinguishable ✅
* An inverted cursor on top of a `#7f7f7f` foreground & background
is still visible ✅
* A colored cursor on top of a background with identical color
is still visible ✅
* Cursors on a transparent background are visible ✅
This commit makes a few changes to avoid bugs, but they basically boil
down to: When we scroll by an entire viewport worth of content, we must
ensure that the scroll offset is 0, because otherwise the scroll rect
(that's basically the viewport, but excluding the scroll offset) will
end up being empty, which the `Present1` API chokes on. This commit
avoids this situation by shuffling around some code to first calculate
the dirty rows, _then_ check if it affects all of them and in that case
sets the scroll offset to 0, and only then finally actually does any
scrolling if there's still something to scroll.
## Validation Steps Performed
* Start pwsh
* Zoom in twice with Ctrl+Scrollwheel
* Print a few viewports worth of text
* Press Ctrl+L
* No errors ✅
Get the locale from `GetUserDefaultLocaleName` and pass it to
DirectWrite's `GetGlyphs` / `GetGlyphPlacements`.
This change is very important for some fonts, which heavily depend on
the locl table, like Source Han Sans for instance.
Closes#13685
## Validation Steps Performed
* Set font to Cascadia Code
* Set locale to "pl-PL"
* Type "Ć"
* The acute is less angled and almost vertical ✅
## Summary of the Pull Request
This was a fever dream I had last July. What if, instead of `WINRT_PROPERTY` magic macros everywhere, we had actual templated versions you could debug into.
So instead of
```c++
WINRT_PROPERTY(bool, Deleted, false);
WINRT_PROPERTY(OriginTag, Origin, OriginTag::None);
WINRT_PROPERTY(guid, Updates);
```
you'd do
```c++
til::property<bool> Deleted{ false };
til::property<OriginTag> Origin{ OriginTag::None };
til::property<guid> Updates;
```
.... and then I just kinda kept doing that. So I did that for `til::event`.
**AND THEN LAST WEEK**
Raymond Chen was like: ["this is a good idea"](https://devblogs.microsoft.com/oldnewthing/20230317-00/?p=107946)
So here it is.
## Validation Steps Performed
Added some simple tests.
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
`IDWriteFontSetBuilder` is super expensive (~40ms of CPU for building a
single font set on a high-end CPU from ~2021). Let's avoid the cost,
by only constructing it if Cascadia Code is actually missing.
To not overcomplicate the code and to support any additional fonts we
might ship in the future, I'm not checking for the font name, and
instead I just construct the font set whenever any font is missing.
Part of #5907
## Validation Steps Performed
* Breakpoints in FontCache aren't hit ✅
* App doesn't crash ✅
This MR introduces `activeOnly ` for the `showCloseButton` theme option
causing the close button only to appear on the active tab.
This is more or less following the approach explained here
https://github.com/orgs/microsoft/projects/686/views/2?pane=issue&itemId=19775774
which indeed just works 😄 .
You notice when switching theme the close buttons is back on all tabs
again as well.
Closes#13672
I didn't check specific unit tests for this. I hope by making this MR
the pipeline will show if I broke something. Or just let me know if you
want me to add something specific for this.
## Summary of the Pull Request
When the screen is resized in ConHost via a VT escape sequence, the
active text attributes could end up being corrupted if they were set to
something that the legacy console APIs didn't support (e.g. RGB colors).
This PR fixes that issue.
## Detailed Description of the Pull Request / Additional comments
The way a resize is implemented is by retrieving the buffer information
with `GetConsoleScreenBufferInfoEx`, updating the size fields, and then
writing the data back out again with `SetConsoleScreenBufferInfoEx`.
However, this also results in the active attributes being updated via
the `wAttributes` field, and that's only capable of representing legacy
console attributes.
We address this by saving the full `TextAttribute` value before it gets
corrupted in the `SetConsoleScreenBufferInfoEx` call, and then restore
it again afterwards.
## Validation Steps Performed
I've added a unit test to verify the attributes are correctly preserved
for all VT resize operations, and I've also manually confirmed the test
case in #2540 is now working as expected.
## PR Checklist
- [x] Closes#2540
- [x] Tests added/passed
- [ ] Documentation updated
- [ ] Schema updated (if necessary)
Basically, just make sure that we register our `SettingsChanged` handler
in `TerminalWindow` _after_ `TerminalWindow` is actually ready to handle
it. _duh_.
Closes#15209
If you were really fast, and closed one window, and then tried to drag
the only tab out of the last remaining window, the Terminal could
explode. It'd attempt to restore the previous window state, and explode.
Easy way to stop this (also, be more robust): just don't attempt to
restore windows during tear-out. That's obvious.
This is a part of #14957
A resurrection of the original nested "Close" menu from #7728. We
discovered that nested flyouts crash in #8238. Those are fixed now
though! So we can bring this back.
This also includes the "Close Pane" item from #15198.
Adds an action for immediately restarting the connection. I suspect
most folks that wanted #3726 will be happy just with the
<kbd>enter</kbd> solution from #14060, but this will work without having
to `exit` the client. Just, relaunch whatever the commandline is. Easy
peasy.
Closes#3726.
Obsoletes #14549
A different take on #14548.
> We didn't love that a connection could transition back in the state
diagram, from Closed -> Start. That felt wrong. To remedy this, we're
going to allow the ControlCore to...
ASK the app to restart its connection. This is a much more sensible
approach, than leaving the ConnectionInfo in the core and having the
core do the restart itself. That's mental.
Cleanup from #14060Closes#14327
Obsoletes #14548
This PR gives the atlas engine an attempt to retry a couple operations
where it asks for debug flags when we're in debug mode. If you don't
have the Graphics debugger and GPU profiler for DirectX installed, then
these calls will fail, and we end up blowing up the renderer. Instead,
just try again.
Originally, I actually thought I had hit #14082, but after sorting this
out, it was just #14316.
closes#14316
Adds support to jump list generation for icon paths that include an
indirect reference e.g. `c:\windows\system32\shell32.dll,214`
If given a path that has an indirect icon reference parse the path into
component parts `filePath` and `iconIndex` and use
`IShellLinkW::SetIconLocation` to set the Icon for the entry. Otherwise
do what we always do.
This PR also introduces `til::to_int`, which is based on `til::to_ulong`
and supports signed integers.
## Validation Steps Performed
Icons were visible in the jump list and in terminal next to the
profiles.
Closes#15205
## Summary of the Pull Request
Adding a 'Close Pane' menu item in the context menu.
## References and Relevant Issues
#13580
## Detailed Description of the Pull Request / Additional comments
If a user decides to split a tab to create multiple panes through the
context menu, they should be able to then close the pane via the context
menu too. This PR introduces a new context menu item, 'Close Pane', that
only appears when a user has 2 or more panes in a tab. When a user
clicks close pane, the _active_pane will be closed.
## Validation Steps Performed
As it's my first PR, I still need to understand how to go through the
testing suite.
## PR Checklist
- [x] Closes#13580
- [ ] 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)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
This is an update of our Primary Device Attributes report, which better
indicates the feature extensions that we now support.
## Detailed Description of the Pull Request / Additional comments
This first parameter of the response is 61, representing a conformance
level of 1. The subsequent parameters identify the supported feature
extensions.
1 = 132 column mode
6 = Selective erase
7 = Soft fonts
22 = Color text
23 = Greek character sets
24 = Turkish character sets
28 = Rectangular area operations
32 = Text macros
42 = ISO Latin-2 character set
Most of these features are handled entirely within `AdaptDispatch`, so
they apply to all clients. However, 132 column mode is only supported by
ConHost, so we don't report that for conpty clients.
And note that soft fonts won't necessarily work in all conpty clients,
but we don't have an easy way of determining that, so we just report
soft font support for everyone.
## Validation Steps Performed
I've manually verified that the `DA1` report is returning the expected
response in Vttest, both from ConHost and Windows Terminal.
I've also updated the `DeviceAttributesTests` in the adapter tests to
account for the new expected response.
Closes#14491
This adds support for XTerm's "bracketed paste" mode in ConHost. When
enabled, any pasted text is bracketed with a pair of escape sequences,
which lets the receiving application know that the content was pasted
rather than typed.
## References and Relevant Issues
Bracketed paste mode was added to Windows Terminal in PR #9034.
Adding it to ConHost ticks one more item off the list in #13408.
## Detailed Description of the Pull Request / Additional comments
This only applies when VT input mode is enabled, since that is the way
Windows Terminal currently works.
When it comes to filtering, though, the only change I've made is to
filter out the escape character, and only when bracketed mode is
enabled. That's necessary to prevent any attempts to bypass the
bracketing, but I didn't want to mess with the expected behavior for
legacy apps if bracketed mode is disabled.
## Validation Steps Performed
Manually tested in bash with `bind 'set enable-bracketed-paste on'` and
confirmed that pasted content is now buffered, instead of being executed
immediately.
Also tested in VIM, and confirmed that you can now paste preformatted
code without the autoindent breaking the formatting.
Closes#395
This is practically a from scratch rewrite of AtlasEngine.
The initial approach used a very classic monospace text renderer, where
the viewport is subdivided into cells and each cell is assigned one
glyph texture, just like how real terminals used to work.
While we knew that it would have problems with overly large glyphs,
like those found in less often used languages, we didn't expect the
absolutely massive number of fonts that this approach would break.
For one, the assumption that monospace fonts are actually mostly
monospace has turned out to be a complete lie and we can't force users
to use better designed fonts. But more importantly, we can't just
design an entire Unicode fallback font collection from scratch where
every major glyph is monospace either. This is especially problematic
for vertical overhangs which are extremely difficult to handle in a
way that outperforms the much simpler alternative approach:
Just implementing a bog-standard, modern, quad-based text renderer.
Such an approach is both, less code and runs faster due to a less
complex CPU-side. The text shaping engine (in our case DirectWrite)
has to resolve text into glyph indices anyways, so using them directly
for text rendering allows reduces the effort of turning it back into
text ranges and hashing those. It's memory overhead is also reduced,
because we can now break up long ligatures into their individual glyphs.
Especially on AMD APUs I found this approach to run much faster.
A list of issues I think are either obsolete (and could be closed)
or resolved with this PR in combination with #14255:
Closes#6864Closes#6974Closes#8993Closes#9940Closes#10128Closes#12537Closes#13064Closes#13527Closes#13662Closes#13700Closes#13989Closes#14022Closes#14057Closes#14094Closes#14098Closes#14117Closes#14533Closes#14877
## PR Checklist
* Enabling software rendering enables D2D mode ✅
* Both D2D and D3D:
* Background appears correctly ✅✅
* Text appears correctly
* Cascadia Code Regular ✅✅
* Cascadia Code Bold ✅✅
* Cascadia Code Italic ✅✅
* Cascadia Code block chars leave (almost) no gaps ✅✅
* Terminus TTF at 13.5pt leaves no gaps between block chars ✅✅
* ``"`u{e0b2}`u{e0b0}"`` in Fira Code Nerd Font forms a square ✅✅
* Cursor appears correctly
* Legacy small/medium/large ✅✅
* Vertical bar ✅✅
* Underscore ✅✅
* Empty box ✅✅
* Full box ✅✅
* Double underscore ✅✅
* Changing the cursor color works ✅✅
* Selection appears correctly ✅✅
* Scrolling in various manners always renders correctly ✅✅
* Changing the text antialising mode works ✅✅
* Semi-transparent backgrounds work ✅✅
* Scroll-zooming the font size works ✅✅
* Double-size characters work ✅✅
* Resizing while text is printing works ✅✅
* DWM `+Heatmap_ShowDirtyRegions` shows that only the cursor
region is dirty when it's blinking ✅✅
* D2D
* Margins are filled with background color ❌
They're filled with the neighboring's cell background color for
convenience, as D2D doesn't support `D3D11_TEXTURE_ADDRESS_BORDER`
* D3D
* Margins are filled with background color ✅
* Soft fonts work ✅
* Custom shaders enable continous redraw if time constant is used ✅
* Retro shader appears correctly ✅
* Resizing while a custom shader is running works ✅
The AppInitialized latency metric logs how long the application needs
to initialize the UI. 5b434dc broke this metric, because it was now
executing the code outside of the `Initialized` callback.
It's the difference between a "latency" of ~50ms and ~350ms.
As an added bonus it moves the `_ApplyStartupTaskStateChange` task
into the `Initialized` callback as well, because why not.
## Validation Steps Performed
* Breakpoint into "AppInitialized" - latency is now correct ✅
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
## Summary of the Pull Request
There are certain escape sequences that use the `VTParameters::subspan`
method to access a subsection of the provided parameter list. When the
parameter list is empty, that `subspan` call can end up using an offset
that is out of range, which causes the terminal to crash. This PR stops
that from happening by clamping the offset so it's in range.
## References and Relevant Issues
This bug effected the `DECCARA` and `DECRARA` operations introduced in
PR #14285, and the `DECPS` operation introduced in PR #13208.
## Validation Steps Performed
I've manually confirmed that the sequences mentioned above are no longer
crashing when executed with an empty parameter list, and I've added a
little unit test that checks `VTParameters::subspan` method is returning
the expected results when passed an offset that is out of range.
## PR Checklist
- [x] Closes#15234
- [x] Tests added/passed
- [ ] Documentation updated
- [ ] Schema updated (if necessary)
We had a report in a mail thread that someone's Terminal windows were
getting created hidden, and never showing themselves.
As a theory, I'm guessing that dwFlags didn't say that we should
actually use `wShowWindow`. So, to be more correct, let's actually obey
that.
I'm gonna send this package to them to see if it fixes them.
Related to #14957.
Likely regressed in #13838.
This bug causes AtlasEngine to render buffer contents with an incorrect
`cellCount`, which may either cause it to draw the contents only
partially, or potentially access the TextBuffer contents out of bounds.
`EnablePainting` sets the `_viewport` to the current viewport for some
unfortunate (and quite buggy/incorrect) caching purposes, which causes
`_CheckViewportAndScroll()` to think that the viewport hasn't changed
in the new window. We can ensure `_CheckViewportAndScroll()` works
by also setting `_forceUpdateViewport` to `true`.
Part of #14957
## PR Checklist
* Tear out a tab from a smaller window to a larger window
* Renderer contents adept to the larger window size ✅
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
It seemed dangerous to just have places all over Pane where we
manipulate the whole cadre of TermControl events. Seemed ripe for a
copypasta error. This moves that around, so there's only two methods for
messing with the TermControl callbacks: `_setupControlEvents` and
`_removeControlEvents`.
Closes: nothing. This was an off-the-cuff commit that seemed valuable.
Original bug report #15049
Relates to feature #1571
MenuFlyoutSubItem, when collapsing from profile selection, move focus
back to the titlebar.
An extra Closing event handler is needed to keep focus on the command
shell.
Closes#15049
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.
See
https://github.com/microsoft/terminal/issues/14957#issuecomment-1520522722.
I think there's a race here that lets the WindowEmperor muck around with
the window after it's done, but before we remove it from our list of
threads.
This _should_ remove the thread from the list, _then_ null out the
AppHost, then flush the XAML queue, preventing the A/V.
Closes MSFT:43995981
Adds a "Select command" and a "Select output" entry to the right-click
context menu when the user has shell integration enabled. This lets the
user quickly right-click on a command and select the entire commandline
or all of its output.
This was a "I'm waiting for reviews" sorta idea. Seemed like a
reasonable combination of features. Related to #13445, #11000.
Tested manually.
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
`WINRT_LEAN_AND_MEAN` removes a bunch of less often used parts of the
C++/WinRT headers:
- `std::hash` specializations for every object
- `operator <<(ostream)` overloads for any `IStringable`
- Interface producers for interfaces that are marked "exclusive"
There's only one place where we were using even one of these.
Enabling this saves us (optimistically) 30 seconds of build time on the
CI agents and shrinks our largest PCH (TerminalApp, x64, Debug) by about
150MiB.
It's not huge, but it's not nothing.
Just changing the Theme also doesn't seem to work by itself - there
seems to be a way for the tab to set the deselected foreground onto
itself as it becomes selected. If the mouse isn't over the tab, that can
result in mismatched fg/bg's
Regressed around #15078Closes#15184
Default to XamlRoot when unable to find a focused object in
DirectKeyEvents
This may not be the most appropriate "fix" for this. Certainly open to
criticism and feedback. We are trapping the alt+space key chord on the
win32 side and forwarding it to the xaml side. There we try to find a
focused object by walking the xaml tree. If we are unable to find a
focused object we return false and do nothing. I suspect that the area
that has focus that prevents this from working normally is on the win32
side. Since we want to handle the system menu anyway and are explicitly
trapping that key combo and forwarding it on I thought this was the best
approach. If we cant find a focused object default to the xaml root.
## Validation Steps Performed
System menu opens as it should.
Closes#14397
Set the padding to the default TabViewHeaderPadding (8,0,0,0), but with
-1 on the bottom. This prevents a small 1px gap that can appear on 150%
scale displays between the tab item and the content. The 1 on top helps
keep
the tab the correct relative height within the tab row.
Regressed in #15078
See also MSFT:40692364
Add automation heading level 1 to fix the about dialog by adding an
automation property.
Allows screen reader to pick up that this is a heading and read
properly.
Closes#11912
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
## Summary of the Pull Request
Add an infobar warning when a non-monospaced font is selected.
## References and Relevant Issues
#13389
## Detailed Description of the Pull Request / Additional comments
I initially had the `IsOpen` property of the infobar bound to the
`ShowAllFonts` checkbox property. However, I felt we could do better by
adding a property for it since there was already a method defined to
inspect whether the selected font was in the `MonoSpaceFontList`.
## Validation Steps Performed
Warning shows up when a non-monospaced font is selected either globally
or on individual profiles. All existing tests continue to pass.
<img width="868" alt="image"
src="https://user-images.githubusercontent.com/2086722/232594214-cd42397b-ce9d-499c-aa73-3feaa45e850e.png">
## PR Checklist
- [x] Closes#13389
- [x] 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)
Adds two new commands, `selectOutput` and `selectCommand`. These don't
do much without shell integration enabled, unfortunately. If you do
enable it, however, you can use these commands to quickly navigate the
history to select whole commands (or their output).
Some sample JSON:
```json
{ "keys": "ctrl+shift+<", "command": { "action": "selectCommand", "direction": "prev" } },
{ "keys": "ctrl+shift+>", "command": { "action": "selectCommand", "direction": "next" } },
{ "keys": "ctrl+shift+[", "command": { "action": "selectOutput", "direction": "prev" } },
{ "keys": "ctrl+shift+]", "command": { "action": "selectOutput", "direction": "next" } },
```
**Demo gifs** in
https://github.com/microsoft/terminal/issues/4588#issuecomment-1352042789closes#4588
Tested manually.
<details>
<summary>CMD.exe user? It's dangerous to go alone! Take this.</summary>
Surely, there's a simpler way to do it, this is adapted from my own
script.
```cmd
prompt $e]133;D$e\$e]133;A$e\$e\$e]9;9;$P$e\$e[30;107m[$T]$e[97;46m$g$P$e[36;49m$g$e[0m$e[K$_$e[0m$e[94m%username%$e[0m@$e[32m%computername%$e[0m$G$e]133;B$e\
```
</details>
This fixes 3 sources for animations:
* `TabView`'s `EntranceThemeTransition` causes tabs to slowly slide in
from the bottom. Removing the transition requires you to override the
entire list of transitions obviously, which is a global change. Nice.
Am I glad I don't need to deal with the complexity of CSS. /s
* `TabBase`, `SettingsTab` and `TerminalTab` were using a lot of
coroutines with `resume_foreground` even though almost none of the
functions are called from background tabs in the first place. This
caused us to miss the initial XAML drawing pass, which resulted in
animations when the tab icons would asynchronously pop into existence.
It also appears as if `resume_foreground`, etc. have a very high CPU
cost attached, which surprises me absolutely not at all given WinRT.
The improvement is difficult to quantify because the run to run
variation is very high. But it seems like this shaves about 10% off
of the ~500ms startup delay on my PC depending on how you measure it.
Part of #5907
## PR Checklist
* It starts when it should ✅
* It doesn't "exit" when it shouldn't ✅
(Scrolling, Settings reload, Bell `\a`, Progress `\e]9;4;2;80\e\\`)
This sets `x:Load` to `false` for the two elements.
On my system, with Windows Defender disabled, this reduces CPU
usage by 15ms and the visual delay during launch by 40ms.
Part of #5907
## Validation Steps Performed
* Ctrl+Shift+P opens command palette ✅
* Context menu opens command palette ✅
* Context menu opens about dialog ✅
`WM_ACTIVATE` is sent on window creation, whereas `WM_SHOWWINDOW` is
sent when the window is shown. Before we call `Peasant::ActivateWindow`
in the `WM_ACTIVATE` handler, we try to get the virtual desktop GUID of
our window, but since it's not shown yet during startup, there's also
no GUID that can be retrieved. This results in an error log message and
an all 0 GUID to be sent via `Peasant::ActivateWindow`.
The GUID of the window that actually spawned on the other hand is never
reported until the first time you reactivate it again, leading to a
number of subtle bugs around window activity.
Additionally, this commit fixes a race condition and pointer unsafety,
by pulling all relevant member variables onto the coroutine's stack,
before it yields itself to a background thread.
## Validation Steps Performed
- Set a trace breakpoint on `_peasantNotifyActivateWindow`
- GUID is non-zero ✅
## Summary of the Pull Request
Add subtext that lets the user know why Always show tabs is not
toggleable in SUI. Also adds some additional information to the comment
for this value that points to the Globals_ShowTitlebar.Header setting.
## References and Relevant Issues
#13984
## Detailed Description of the Pull Request / Additional comments
Simple updates to the resources that add some additional helpful
information for the user.
## Validation Steps Performed
Verified the updates show in the SUI and that they render correctly.
## PR Checklist
- [ ] Closes#13984
- [ ] 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)
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Original description, pre-process model v3:
> This is just the `SHOWDEFAULT` bit from #12979. This seems to also
work now, but I'm PR'ing it separately so it can be a separate revert
from #13811, if it is problematic.
More accurately:
This PR enables terminal windows to use the `wShowCmd` from the
STARTUPINFO passed to `windowsterminal.exe` to set the initial
visibility of the window. We can't just use `SW_SHOWDEFAULT`, because
all the windows are running in the initial process! After the first
window, the subsequent ones would ignore any params passed to their
originating `windowsterminal.exe` processes. To mitigate, we pass that
`wShowCmd` info from the source process, to the actual running terminal
process. That accounts for most of the delta here.
Closes#9053
This doesn't do the same for defterm-initiated connections. This is
because we don't need to! Defterm very explicitly rejects handoff for
minimized console apps. This is probably for the best! I put an attempt
in 66f8b25ec before I forgot that it was filtered long before the
Terminal. NOT doing this for /min saves us all sorts of "what happens if
`start /min cmd` tries to glom?" or "what if someone does `start /min
cmd && start /max cmd` and they glom together?".
<hr>
Also closes#15193, which was introduced as a part of this.
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
Mike Griese
Leonard Hecker
kovdu
Ben Constable
James Holderness
James Pack
joadoumie
Kevin Kostrzewa
Dustin L. Howett
