Windows Terminal

Build 2020

Windows Terminal 1.0

We are incredibly proud to announce the release of Windows Terminal 1.0! Windows Terminal has come a long way since its announcement at Microsoft Build 2019. You can download Windows Terminal from the Microsoft Store or from the GitHub releases page. Windows Terminal will have monthly updates, starting in July 2020.
https://devblogs.microsoft.com/commandline/windows-terminal-1-0/

The new Windows Terminal and the original Windows console host, all in the same place!
https://github.com/microsoft/terminal
9,672 forks.
105,219 stars.
1,781 open issues.

Recent commits:

Reject OSC titles longer than 1000 characters, like xterm (#20839)I know that this seems short, but like. One thousand characters. In atitle.Xterm (which I checked at version 398) rejects requests to set a titlethis long _outright,_ and does not truncate or elide any part of it.Closes #20838, GitHub
Prevent repeated alt buffer sequences from using the wrong size (#20825)`UseAlternateScreenBuffer` set the size of the new alt buffer from`_mutableViewport` (from the main buffer). Resizing while the alt bufferwas open and requesting it again (which is already somewhat strange andshould be a no-op…) would use the old size.Closes #20820, GitHub
Fix several scrollbar issues in conhost (#20824)- Closes #19585, by always tracking the main buffer for scrollbar state, instead of letting `SIF_DISABLENOSCROLL` track it implicitly- Optimized scrollbar state on startup by setting its visibility eagerly- Fixed a transient full-height thumb on return from the alt bufferAnd a real zinger (decade old bug, basically):- Fixed a bug where the alt buffer doesn't resize if its size matches the main buffer (technically unrelated to scrollbars), GitHub
ci: run the Any CPU, WPF, ConPTY and MSIX bundle builds in CI (#20835), GitHub
Rewrite HwndTerminal to build on ControlInteractivity and -Core (#20812)This pull request replaces all of HwndTerminal, which used to be a thinlayer on top of TerminalCore.lib, with a new implementation that relieson the Interactivity and Core layers in TerminalControl.lib.We used to spend a lot of time reimplementing interactivity componentsfor HwndTerminal or–if I'm being honest–letting it rot and nevergiving it the improvements the rest of the application got.Among those improvements:- Automatic scrolling finally works (as of #20710)- Selection works the same way as it does in Terminal proper (starts on the half-cell, uses an exclusive range)- Consistent double- and triple-click behavior without having to reimplement word- and line-wise expansion- Scroll wheel behavior- Shift+Click to suppress VT mouse mode- Scrolling and focus handling move down into the Win32 message loop from WPFThis pull request seeks to get HwndTerminal back to where it was (plusthe things we naturally get from switching over). In the future, we canmore easily add:- title reporting (surprised we didn't have this)- clickable URLs- automatic copy-to-clipboard- right-click menu support- DTTERM window manipulation- shaders- Ctrl+Scroll zoomImplementation Details———————-The WPF control is backed by a flat "C" API, which takes in a `void*`and does some stuff to it. We call that a `PTERM`. References to "FlatC" in this commit body describe the body of work below WPF.X-macros are used to fill out the definintions of every C API and bridgeit to a properly typed C++ member function. Ugh. No more crap where wesplit the implementation into half C export and half C++ member.ControlCore and ControlInteractivity require something that looks likeTerminalSettings. The WPF control only supports the most basic settings,in `struct TerminalTheme`, and so I've added a bridge WinRT type toadapt TerminalTheme toIXxxSettings. Most of the values it returns are our "defaults", and someof them are overridden.Core requires an `ITerminalConnection`, but the WPF API uses a pair of"write output" and "send input" callbacks. Flat C provides anITerminalConnection that bridges those callbacks. It does notcommunicate connection state or anything else. Resizing is probablygoing to be a problem.Core requires a dispatcher queue to ensure that some operations happenon the UI thread. I have stubbed out an implementation of`IDispatcherQueue` that calls a couple function pointers with a contextpointer; the WPF code hooks up to that and bridges it into the WPFdispatcher. Yes, the Core's dispatcher queue _is_ the WPF main UIthread. It has to be, otherwise we'll explode the first time we try toupdate the scroll bar. Prep work was done in #20713.To make the above easier, I removed all use of DispatcherTimer (see#20711). Attempts to use it will almost certainly cause the WPF controlto implode.Core needed to be taught a couple tricks to start up targeting an HWNDinstead of a composition handle. See #20722 for more.Refs #20710Refs #20711Refs #20713Refs #20722Required #20721Refs #20745Related to #6999, GitHub

Was this post helpful?

Let us know if you liked the post. That’s the only way we can improve.

Linux Shtuff

Build 2020

Windows Terminal 1.0

Was this post helpful?

Leave a Reply Cancel reply

Recent Posts

Archives

Meta