* [contributing.md] add how to report security bugs
I think it's a good idea mentioning how to report vulnerabilities in contributing.md, by pointing them to SECURITY.md. This is useful in case people only read contributing.md but not security.md, and incorrectly believe that your team prefers discussing security issues on GitHub.
* Use full name of MSRC
As suggested by miniksa, change "MSRC" to "Microsoft Security Response Center (MSRC)"
* Edits doc section: Starting Windows Terminal
* Proposes using the search function to locate the app.
* Restructures as a procedure.
* Adds misc edits.
* Made step 1 more generic, rather than prescribing the search method.
* Added tip about shortcut for elevated app
[skip ci]
* Edits doc section `Installing Windows Terminal`
* Adds some light edits throughout.
* Adds link to `winver` documentation.
* Adds link to Microsoft Store listing
Updates procedure to link to https://aka.ms/install-terminal
This PR represents the start of the work on Cascading User + default settings, #754.
Cascading settings will be done in two parts:
* [ ] Layered Default+User settings (this PR)
* [ ] Dynamic Profile Generation (#2603).
Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master.
This PR covers adding one primary feature: the settings are now in two separate files:
* a static `defaults.json` that ships with the package (the "default settings")
* a `profiles.json` with the user's customizations (the "user settings)
User settings are _layered_ upon the settings in the defaults settings.
## References
Other things that might be related here:
* #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state
* #1398 - This might have honestly been solved by #2475
## PR Checklist
* [x] Closes#754
* [x] Closes#1378
* [x] Closes#2566
* [x] I work here
* [x] Tests added/passed
* [x] Requires documentation to be updated - it **ABSOLUTELY DOES**
## Detailed Description of the Pull Request / Additional comments
1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object.
2. Next, we add tests for layering properties like that.
3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings.
4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk.
5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values.
6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is.
7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything.
8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles.
## TODO:
* [x] Still need to make Alt+Click work on the settings button
* [x] Need to write some user documentation on how the new settings model works
* [x] Fix the pair of tests I broke (re: Duplicate profiles)
<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
* 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
* 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
* Fix a typo; Update the defaults to match #2378
* Tiny nits
* Some typos, PR nits
* Fix this broken defaults case
* Edits doc section `Configuring Windows Terminal`
* Converts into a procedure.
* Uses `⌵` character to replace the `down` UI element.
* Additional minor edit
Updates formatting, edits for brevity.
* Fixed json path
Added `8wekyb3d8bbwe` to file path.
* Amends user-docs procedure
Amends docs procedure for `Running a Different Shell`:
* Adds an overview sentence.
* Adds some light rephrasing.
* Proposes using the countersink arrow `⌵` to depict the `down` GUI element.
* Adds link to WSL installation guide
We were using a tag to trigger the bot for the verbose feedback hub response.
But...
1. We have run into several instances of the bot aggressively replying multiple times before the tag is removed.
2. We asked for a "comment contains" function in the bot and the Fabric Bot team obliged.
So I've changed it to `/duplicate` from the tag trigger and will remove the tag.
* Start working on drafting this spec
* Really add a LOT of notes
* More spec updates.
* Remove `hiddenProfiles` in favor of `profile.hidden`
* Add info on how layering will work
* add more powershell core info
* Finish remaining TODO sections
* Apply suggestions from code review
Fix simple typos
Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
* Lots of feedback from PR
* Try and make dynamic settings a bit clearer
* more clearly call out serializing only what's different from a default-
constructed `Profile`
* Add more goals
* add a blurb for user-default profile objects
* Add updates concerning dynamic profile generation (#1321)
* Add updates concerning dynamic profile generation
This is based on discussion with @dhowett-msft we had o*line. We're trying to
work through a way to prevent dynamic profiles from roaming to machines the
dynamic profiles might not exist on.
After writing this up, I'm not totally sure that it's a better design.
* Add some initial updates from discussion
* Pushing some updates here. I haven't given it a once over to ensure it's all consistent but it's worth reviewing @dhowett-msft
* Some minor updates from Dustin
* Fix a bunch of slightly more minor points in the spec
* Move "Profile Ordering" to "Future considerations"
* Add some notes on migrating profiles, GUID generation, de-duping profiles, and O R A N G E
* Fix the indenting here
* Update powershell core to be a dynamic profile, don't even mention other options.
* Remaining PR feedback
* Apply suggestions from code review
Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
* remove a dead comment
* Add a spec draft for Keybindings Arguments.
Specs #1142.
Just read the spec :)
* Apply suggestions from code review
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
* Include notes on reliability, security, and `Handle`ing Keybinding Args
* Add some extra details from review
* Split up ActionArgs and ActionEventArgs
* Clarify _not_ handling an action
* Add some notes on parsing args
* Add some future considerations on extensions
* Updating spec to remove the bulk of the `IActionArgs` and `IActionEventArgs` implementations, as they're redundant.
This seemed like it fit the style & depth of the other Niksa posts, so I'm proposing we add it here. We could always make a `Howett.md` if that seems more reasonable
### User Stories:
1. A user wants to be able to use the executable path as their starting title
- Does anyone want this?
2. A user wants to be able to set a custom starting title, but have that title be overridable
3. A user wants to be able to set an overridable starting title, different from the profile name
- Presumably someone will want this
4. A user totally wants to ignore the VT title and use something else
- This will make more sense in the post [#1320] "Support runtime variables in the custom user title" settings
### Solutions:
1. `name`, `startingTitle`, `tabTitle`
* a. `name` is only ever used as the profile name.
* b. If `startingTitle` isn't set, then the executable path is used
* c. If `startingTitle` is set, it's used as the initial title
* d. If `tabTitle` is set, it overrides the title from the terminal
* e. Current users of `tabTitle` need to manually update to the new behavior.
2. `name` as starting title, `tabTitle` as a different starting title
* a. `name` is used as the starting title and the profile name in the dropdown
* b. If `tabTitle` is set, we'll use that as the overridable starting title instead.
* c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
* d. Current users of `tabTitle` automatically get the new (different!) behavior.
* e. User Story 1 is impossible
- Does anyone want the behavior _ever_? Perhaps making that scenario impossible is good?
3. `name` unchanged, `tabTitle` as the starting title
* a. `name` is only ever used as the profile name.
* b. If `tabTitle` is set, we'll use that as the overridable starting title.
* c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
* d. Current users of `tabTitle` automatically get the new (different!) behavior.
4. `name` as starting title, `tabTitle` as different starting title, `suppressApplicationTitle` Boolean to force it to override
* a. `name`, `tabTitle` work as in Solution 2.
* b. When someone wants to be able to statically totally override that title (story 4), they can use `suppressApplicationTitle`
* c. `suppressApplicationTitle` name is WIP
* d. We'll add `suppressApplicationTitle` when someone complains
* e. If you really want story 1, use `tabTitle: c:\path\to\foo.exe` and `suppressApplicationTitle`.
[#1320]: https://github.com/microsoft/terminal/issues/1320
We've decided to pursue path 4.
* First draft of a spec for splitting off the existing VT52 escape sequences, and extending the VT52 support.
* Make the issue ID visible on GitHub.
* Added suggested mappings for the Graphics Mode character set.
* Add escape sequences for all the commands and clarify the use of the ESC < sequence when switching back to ANSI mode.
* Add details about the differing boundary rules of the VT100 CUP command and the VT52 Direct Cursor Address command.
* Specify the identifying sequence that the Identify command should return.
* Add details of the print commands.
* Add a list of keyboard sequences that are different in the VT52 mode, and make the description of the Keypad Mode commands a little clearer.
* Add a section describing the testing needed to cover the new functionality.
* Stop the crash with fonts by trying a few fallback/backup fonts if we can't find what was selected.
* Create fallback pattern for finding a font. Resolve and pass the locale name. Retrieve the font name while retrieving the font object. Use retrieved data in the _GetProposedFont methods instead of re-resolving it.
* Add details to schema about fallback. Finish comment explaining fallback pattern to doc comment on method.
* Implement base background image alignment settings
TerminalSettings now has two new properties:
* BackgroundImageHorizontalAlignment
* BackgroundImageVerticalAlignment
These properties are used in TermControl::_InitializeBackgroundBrush to specify the alignment for TermControl::_bgImageLayer.
This is a base commit that will split into two possible branches:
* Use one setting in profiles.json: "backgroundImageAlignment"
* Use two settings in profiles.json: "backgroundImageHorizontal/VerticalAlignment"
* Implement background image alignment profile setting
Implement background image alignment as one profile setting.
* This has the benefit of acting as a single setting when the user would likely want to change both horizontal and vertical alignment.
* HorizontalAlignment and VerticalAlignment are still stored as a tuple in Profile because they are an optional field. And thus, it would not make sense for one of the alignments to be left unused while the other is not.
* Cons are that the tuple signature is quite long, but it is only used in a small number of locations. The Serialize method is also a little mishapen with the nested switch statements. Empty lines have been added between base-level cases to improve readability.
* Fix capitalization typo for BackgroundImageStretchModeKey
In Profiles.cpp, the key for the image stretch mode json property had a lowercase 'i' in "Backgroundimage", not following proper UpperCamelCase.
The "i" has been capitalized and the two usages of the constant have been updated as well.
* Document Background Image settings
* Adds entries SettingsSchema.md for the original 3 backgroundImage settings in addition to the new backgroundImageAlignment setting.
* Fix setting capitalization error in UsingJsonSettings.md
* The background image example in UsingJsonSettings.md listing a backgroundImageStretchMode of "Fill" has been corrected to "fill".
Fixes#1949.
* Doc of stuff I've explained.
* add a few more
* archive fulltext of comments and link back to originals, attempt to make relative anchor links for jumping.
* Refactors TerminalApp into two projects:
- TerminalAppLib, which builds a .lib, and includes all the code
- TerminalApp, which builds a dll by linking the lib
* Adds a TerminalApp.Unit.Tests project
- Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation
- includes the ability to test types with XAML content using an appxmanifest
* Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR.
-------------------------
These are some previous commit messages. They may be helpful to future readers.
* Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042
* VS automatically did this for me
* This is a dead end
I tried including the idl-y things into the lib, but that way leads insanity
If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets
that ProjectReferences can have winmd's in them, so it won't be able to
compile any types from the referenced projects. If you instead try to manually
reference the types, you'll get duplicate types up the wazoo, which of course
is insane, since we're referencing them the _one_ time
* Yea just follow #1042 on github for status
So current state:
1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and
TerminalSettings, then mdmerge will complain about all the types from
TerminalSettings being defined twice. In this magic scenario, the
dependencies of TerminalControl are used directly for some reason:
```
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd.
```
2. If you don't add a `Reference` TerminalControl, then it'll complain about
being unable to find the type TitleChangedEventArgs, which is defined in
TerminalControl.
3. If you don't add a `Reference` TerminalSettings, then it'll complain about
being unable to find the type KeyChord and other types from
TerminalSettings. In this scenario, it doesn't recurse on the other
dependencies from TerminalControl for whatever reason.
4. If you instead try to add all 3 as a `ProjectReference`, then it'll
complain about being unable to find TitleChangedEventArgs, as in 2.
Presumably, it;ll have troubles with the other types too, as none of the 3
are actually included in the midlrt.rsp file.
5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as
a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration
Microsoft.UI.Xaml.Markup.XamlApplication`
6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND
MUX.Markup as a `Reference`, you'll get the same result as 3.
* what if we just don't idl
This seems to compile
* This compiles but I broke the MUX resources
look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that!
* lets do this
If I leave the MUX nuget out of the project, I'll get a compile error in
App.xaml:
```
...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls'
```
If I add it back to the project, it works
* Some cleanup from the previous commit
* This is busted again.
Doing a clean build didn't work.
A clean rebuild of the project, paired with some removal of dead code
revealed a problem with what I have so far.
TerminalAppLib depends on the generation of two headers,
`AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the
winrt types. They're needed to be able to compile the implementations.
Presumably that's not getting generated by the lib project, because the dll
project is the one to generate that file.
So we need to move the idl's to the lib project. This created maddness,
because of course the Duplicate Type thing. The solution to that is to
actually mark the winrt DLLs that we're chaining up through us as
```
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
```
This will prevent them from getting double-included.
This still doesn't work however, since
```
app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp'
error C3861: 'XamlMetaDataProvider': identifier not found
```
So we need to figure that out. The dll project is still generating the right
header, so lets look there.
* Move the xaml stuff to the lib
This compiles, but when we launch, we fail to load the tabviewcontrol
resources again. So that's not what you want. Why is it not included?
* It works again!
* Use the pri, xbf files from TerminalAppLib, not TerminalApp
* Manually make TerminalApp include a reference to TerminalAppLib's
TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to
TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the
TerminalApp project (it's expecting it to have a winmd)
* Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The
dll doesn't do any codegen anymore.
* Agressively clean up these files
* Clean up unnecessary includes in the dll pch.h
* This does NOT work.
The WindowsxamlManager call crashes. I'm thinking it has to do with activation
of winrt types from a dll.
Email out to @Austin-Lamb to see if he can assist
* This gets our cppwinrt types working, but xaml islands is still broken
* Split the tests apart, so they aren't insane
* These are the magic words to make xaml islands work
* All this witchcraft is necessary to make XAML+MUX work right
* Clean this up a bit and add comments
* Create an enormous doc explaining this madness
* Unsure how this got changed.
* Trying to get the CI build to work again.
This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false.
However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference.
* Update cppwinrt to the latest version - this fixes the MSBuild
* I still need to re-add the KeyModifiers checks from TermControl. I think
this update broke `operator&` for that enum.
* There needs to be some cleanup obviously
* The doc should be updated as well
* Clean up changes from cppwinrt update
* Try doing this, even though it seems wrong
* Lets try this (press x to doubt)
* Clean up vcxproj file, and remove appxmanifest change from previous commit
* Update to the latest TAEF release, maybe that'll work
* Let's try a prerelease version, shall we?
* Add notes about TAEF package, comment out tests
* Format the code
* Hopefully fix the arm64 and x86 builds
also a typo
* Fix PR nits
* Fix some bad merge conflicts
* Some cleanup from the merge
* Well I was close to getting the merge right
* I believe this will fix CI
* Apply suggestions from code review
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
* These definitely need to be fixed
* Try version detecting in the test
IDK if this will build, I'm letting the CI try while I clean rebuild locally
* Try blindly updating to the newest nuget version
* Revert "Try blindly updating to the newest nuget version"
This reverts commit b72bd9eb73.
* We're just going to see if these work in CI with this change
* Comment the tests back out. Windows Server 2019 is 10.0.17763.557
* Remove the nuget package
We don't need this package anymore now that we're hosting it
* Okay this _was_ important
* Added fontSize and acrylicOpacity changing tip
Added Terminal tip about changing the font size and acrylic opacity using keyboard shortcuts.
* Update index.md
* Propose banner at top of issue templates
Getting tired of obvious low quality issues and I want to provide the warning that we may start closing things without further explanation as our volume is too high to deal with junk issues.
* Add bot rule information too.
* Mark NTSTATUS, HRESULT, and wil::unique_ptr as inline code snippets
* Change encapsulate on line 14 to lower case to be consistent with the other rules
* Start working on adding support for panes
See #1000 for the panes megathread on remaining work.
The functionality will be there, but the keybinding won't be there, so people have to
opt-in to it.
Submitting first draft of spec template, and `contributing.md` outlining our guidance on how to engage with us, file issues, suggest features, submit changes, etc.
- "Windows Internal Library" got named "Windows Implementation Library" for its GH release
- Fixed the links to point to the files in the WIL GH instead of the local copies.
- Left the rest of this as general guidance to how we use it.
