0df02343f1
_**This PR targets the #2515 PR**_. It does that for the sake of diffing. When this PR and #2515 are both ready, I'll merge #2515 first, then change the target of this branch, and merge this one. <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR adds support for "dynamic profiles", in accordance with the [Cascading Settings Spec](https://github.com/microsoft/terminal/blob/master/doc/cascadia/Cascading-Default-Settings.md#dynamic-profiles). Currently, we have three types of default profiles that fit the category of dynamic profile generators. These are profiles that we want to create on behalf of the user, but require runtime information to be able to create correctly. Because they require runtime information, we can't ship a static version of these profiles as a part of `defaults.json`. These three profile generators are: * The Powershell Core generator * The WSL Distro generator * The Azure Cloud Shell generator <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #754 * [x] I work here * [x] look at all these **Tests** * [x] Requires documentation to be updated - This is done as part of the parent PR <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments We want to be able to enable the user to edit dynamic profiles that are generated from DPGs. When dynamic profiles are added, we'll add entries for them to the user's `profiles.json`. We do this _without re-serializing_ the settings. Instead, we insert a partial serialization for the profile into the user's settings. ### Remaining TODOs: * Make sure that dynamic profiles appear in the right place in the order of profiles -> #2722 * [x] don't serialize the `colorTable` key for dynamic profiles. * [x] re-parse the user settings string if we've changed it. * Handle changing the default profile to pwsh if it exists on first launch, or file a follow-up issue -> #2721 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Start dynamically creating profiles * Give the inbox generators a namespace and generally hack this a lot less * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * Serialize the source key * Make the Azure cloud shell a dynamic profile * Make the built-in namespaces public * Add a mechanism for quick-diffing a profile This will be used to generate the json snippets for dynamically generated profiles. * Generate partial serializations of dynamic profiles _not_ in the user settings * Start writing tests for generating dyn profiles * dyn profiles generate GUIDs based on _source * we won't run DPGs when they'd disabled? * Add more DPG tests - TestDontRunDisabledGenerators * Don't layer profiles with a source that's also different * Add another test, DoLayerUserProfilesOnDynamicsWhenSourceMatches * Actually insert new dynamic profiles into the file * Minor cleanup of `Profile::ShouldBeLayered` * Migrate legacy profiles gracefully * using namespace winrt::Windows::UI::Xaml; * _Only_ layer dynamic profiles from user settings, never create * Write a test for migrating dynamic profiles * Comments for dayssssss * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Don't layer a profile if the json doesn't have a GUID * Fix a test I unfixed * get rid of extraneous bois{}; * Piles of PR feedback * Collection of PR nits * PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * In-den-taition! * Some typos, PR nits * Fix this broken defaults case * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * PR nits |
||
|---|---|---|
| .github | ||
| .nuget | ||
| build | ||
| dep | ||
| doc | ||
| pkg/appx | ||
| res | ||
| samples | ||
| src | ||
| tools | ||
| .clang-format | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .vsconfig | ||
| CODE_OF_CONDUCT.md | ||
| common.openconsole.props | ||
| consolegit2gitfilters.json | ||
| dirs | ||
| LICENSE | ||
| NOTICE.md | ||
| NuGet.Config | ||
| OpenConsole.sln | ||
| README.md | ||
| SECURITY.md | ||
Welcome!
This repository contains the source code for:
- Windows Terminal
- The Windows console host (
conhost.exe) - Components shared between the two projects
- ColorTool
- Sample projects that show how to consume the Windows Console APIs
Other related repositories include:
Installation
(Note: in order to run the Windows Terminal, you'll need to be running at least Windows build 18362 or higher.)
Microsoft Store
Download the Microsoft Terminal free from the Microsoft Store and it'll be continuously updated. Or, feel free to side-load releases from GitHub, but note they won't auto-update.
Chocolatey (Unofficial)
Download and upgrade the Windows Terminal from Chocolatey.
To install Windows Terminal, run the following command from the command line or from PowerShell:
choco install microsoft-windows-terminal
To upgrade Windows Terminal, run the following command from the command line or from PowerShell:
choco upgrade microsoft-windows-terminal
If you have any issues when installing/upgrading the package please go to the package page and follow the Chocolatey triage process
Build Status
| Project | Build Status |
|---|---|
| Terminal | |
| ColorTool |
Terminal & Console Overview
Please take a few minutes to review the overview below before diving into the code:
Windows Terminal
Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more.
The Terminal will also need to meet our goals and measures to ensure it remains fast, and efficient, and doesn't consume vast amounts of memory or power.
The Windows console host
The Windows console host, conhost.exe, is Windows' original command-line user experience. It implements Windows' command-line infrastructure, and is responsible for hosting the Windows Console API, input engine, rendering engine, and user preferences. The console host code in this repository is the actual source from which the conhost.exe in Windows itself is built.
Console's primary goal is to remain backwards-compatible with existing console subsystem applications.
Since assuming ownership of the Windows command-line in 2014, the team has added several new features to the Console, including window transparency, line-based selection, support for ANSI / Virtual Terminal sequences, 24-bit color, a Pseudoconsole ("ConPTY"), and more.
However, because the Console's primary goal is to maintain backward compatibility, we've been unable to add many of the features the community has been asking for, and which we've been wanting to add for the last several years--like tabs!
These limitations led us to create the new Windows Terminal.
Shared Components
While overhauling the Console, we've modernized its codebase considerably. We've cleanly separated logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient STL containers, and made the code simpler and safer by using Microsoft's WIL header library.
This overhaul work resulted in the creation of several key components that would be useful for any terminal implementation on Windows, including a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, and a VT parser/emitter.
Building a new terminal
When we started building the new terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by sticking with C++ and sharing the aforementioned modernized components, placing them atop the modern Windows application platform and UI framework.
Further, we realized that this would allow us to build the terminal's renderer and input stack as a reusable Windows UI control that others can incorporate into their applications.
FAQ
Where can I download Windows Terminal?
The Windows Terminal preview can be downloaded from the Microsoft Store.
https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701
I built and ran the new Terminal, but I just get a blank window app!
Make sure you are building for your computer's architecture. If your box has a 64-bit Windows, change your Solution Platform to x64.
To check your OS architecture go to Settings -> System -> About (or Win+X -> System) and under Device specifications check for the System type.
I built and ran the new Terminal, but it looks just like the old console! What gives?
Firstly, make sure you're building & deploying CascadiaPackage in Visual Studio, NOT Host.EXE. OpenConsole.exe is just conhost.exe, the same old console you know and love. opencon.cmd will launch openconsole.exe, and unfortunately, openterm.cmd is currently broken.
Secondly, try pressing Ctrl + T. The tabs are hidden when you only have one tab by default. In the future, the UI will be dramatically different, but for now, the defaults are supposed to look like the console defaults.
I tried running WindowsTerminal.exe and it crashes!
- Don't try to run it unpackaged. Make sure to build & deploy
CascadiaPackagefrom Visual Studio, and run the Windows Terminal (Dev Build) app. - Make sure you're on the right version of Windows. You'll need to be on Insider's builds, or wait for the 1903 release, as the Windows Terminal REQUIRES features from the latest Windows release.
Getting Started
Debugging
- To debug in VS, right click on CascadiaPackage (from VS Solution Explorer) and go to properties, in the Debug menu, change "Application process" and "Background task process" to "Native Only".
Contributing
We are excited to work alongside you, our amazing community, to build and enhance Windows Terminal!
We ask that before you start work on a feature that you would like to contribute, please read our Contributor's Guide. We will be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort.
👉 Remember! Your contributions may be incorporated into future versions of Windows! Because of this, all pull requests will be subject to the same level of scrutiny for quality, coding standards, performance, globalization, accessibility, and compatibility as those of our internal contributors.
⚠ Note: The Command-Line Team is actively working out of this repository and will be periodically re-structuring the code to make it easier to comprehend, navigate, build, test, and contribute to, so DO expect significant changes to code layout on a regular basis.
Documentation
All documentation is located in the ./doc folder. If you would like to contribute to the documentation, please submit a pull request.
Communicating with the Team
The easiest way to communicate with the team is via GitHub issues. Please file new issues, feature requests and suggestions, but DO search for similar open/closed pre-existing issues before you do.
Please help us keep this repository clean, inclusive, and fun! We will not tolerate any abusive, rude, disrespectful or inappropriate behavior. Read our Code of Conduct for more details.
If you would like to ask a question that you feel doesn't warrant an issue (yet), please reach out to us via Twitter:
-
Rich Turner, Program Manager: @richturn_ms
-
Dustin Howett, Engineering Lead: @dhowett
-
Michael Niksa, Senior Developer: @michaelniksa
-
Kayla Cinnamon, Program Manager (especially for UX issues): @cinnamon_msft
Developer Guidance
Build Prerequisites
-
You must be running Windows 1903 (build >= 10.0.18362.0) or above in order to run Windows Terminal.
-
You must have the 1903 SDK (build 10.0.18362.0) installed.
-
You must have at least VS 2019 installed.
-
You must install the following Workloads via the VS Installer. Opening the solution will prompt you to install missing components automatically.
- Desktop Development with C++
- Universal Windows Platform Development
- The following Individual Components
- C++ (v142) Universal Windows Platform Tools
-
You must also enable Developer Mode in the Windows Settings app to locally install and run the Terminal app.
Building the Code
This repository uses git submodules for some of its dependencies. To make sure submodules are restored or updated, be sure to run the following prior to building:
git submodule update --init --recursive
OpenConsole.sln may be built from within Visual Studio or from the command-line using MSBuild. To build from the command line, find your shell below.
PowerShell
Import-Module .\tools\OpenConsole.psm1
Set-MsBuildDevEnvironment
Invoke-OpenConsoleBuild
CMD
.\tools\razzle.cmd
bcz
We've provided a set of convenience scripts as well as README in the /tools directory to help automate the process of building and running tests.
Coding Guidance
Please review these brief docs below relating to our coding standards etc.
👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or make some new ones!)
This is a work in progress as we learn what we'll need to provide people in order to be effective contributors to our project.
- Coding Style
- Code Organization
- Exceptions in our legacy codebase
- Helpful smart pointers and macros for interfacing with Windows in WIL
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.