## Summary of the Pull Request
Enables the user to provide arbitrary argument values to shortcut actions through a new `args` member of keybindings. For some keybindings, like `NewTabWithProfile<N>`, we previously needed 9 different `ShortcutAction`s, one for each value of `Index`. If a user wanted to have a `NewTabWithProfile11` keybinding, that was simply impossible. Now that the args are in their own separate json object, each binding can accept any number of arbitrary argument values.
So instead of:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": "newTabProfile0", "keys": ["ctrl+shift+1"] },
{ "command": "newTabProfile1", "keys": ["ctrl+shift+2"] },
{ "command": "newTabProfile2", "keys": ["ctrl+shift+3"] },
{ "command": "newTabProfile3", "keys": ["ctrl+shift+4"] },
```
We can now use:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": { "action": "newTab", "index": 0 }, "keys": ["ctrl+shift+1"] },
{ "command": { "action": "newTab", "index": 1 }, "keys": ["ctrl+shift+2"] },
{ "command": { "action": "newTab", "index": 2 }, "keys": ["ctrl+shift+3"] },
```
Initially, this does seem more verbose. However, for cases where there are multiple args, or there's a large range of values for the args, this will quickly become a more powerful system of expressing keybindings.
The "legacy" keybindings are _left in_ in this PR. They have helper methods to generate appropriate `IActionArgs` values. Prior to releasing 1.0, I think we should remove them, if only to remove some code bloat.
## References
See [the spec](https://github.com/microsoft/terminal/blob/master/doc/specs/%231142%20-%20Keybinding%20Arguments.md) for more details.
This is part two of the implementation, part one was #2446
## PR Checklist
* [x] Closes#1142
* [x] I work here
* [x] Tests added/passed
* [x] Schema updated
## Validation Steps Performed
* Ran Tests
* Removed the legacy keybindings from the `defaults.json`, everything still works
* Tried leaving the legacy keybingings in my `profiles.json`, everything still works.
-------------------------------------------------
* this is a start, but there's a weird linker bug if I take the SetKeybinding(ShortcutAction, KeyChord) implementation out, which I don't totally understand
* a good old-fashioned clean will fix that right up
* all these things work
* hey this actually _functionally_ works
* Mostly cleanup and completion of implementation
* Hey I bet we could just make NewTab the handler for NewTabWithProfile
* Start writing tests for Keybinding args
* Add tests
* Revert a bad sln change, and clean out dead code
* Change to include "command" as a single object
This is a change to make @dhowett-msft happy. Changes the args to be a part
of the "command" object, as opposed to an object on their own.
EX:
```jsonc
// Old style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": { "action": "switchToTab", "index": 0 }, "keys": ["ctrl+alt+1"] },
// new style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": "switchToTab", "args": { "index": 0 } "keys": ["ctrl+alt+1"] },
```
* schemas are hard yo
* Fix the build?
* wonder why my -Wall settings are different than CI...
* this makes me hate things
* Comments from PR
* Add a `Direction::None`
* LOAD BEARING
* add some GH ids to TODOs
* add a comment
* PR nits from carlos
<!-- 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 introduces a setting to both Profiles and ColorSchemes called <code>selectionBackground</code> that allows you to change the selection background color to what's specified. If <code>selectionBackground</code> isn't set in either the profile or color scheme, it'll default to what it was before - white.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#3326
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [x] Requires documentation to be updated
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Added selectionBackground to existing profile and colorscheme tests.
- Verified that the color does change to what I expect it to be when I add "selectionBackground" to either/both a profile and a color scheme.
<hr>
* adding selectionBackground to ColorScheme and TerminalSettings
* Changing PaintSelection inside the renderers to take a SelectionBackground COLORREF
* changes to conhost and terminal renderdata, and to terminal settings and core
* IT WORKS
* modification of unit tests, json schemas, reordering of functions
* more movement
* changed a couple of unit tests to add selectionBackground, added the setting to schemas, also added the optional setting to profiles
* default selection background should be slightly offwhite like the default foreground is
* reverting changes to .sln
* cleaning up
* adding comment
* oops
* added clangformat to my vs hehe
* moving selectionBackground to IControlSettings and removing from ICoreSettings
* trying to figure out why the WHOLE FILE LOOKS LIKE ITS CHANGED
* here it goes again
* pls
* adding default foreground as the default for selection background in dx
* Create a doc for adding common third-party tools
Maybe it would be helpful to have a comprehensive guide on adding some common third-party tools as profiles.
* add some additional tools from PR
* Add a note on using WSL paths to documentation
Co-Authored-By: greg904 <56923875+greg904@users.noreply.github.com>
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
## Summary of the Pull Request
Enables the `toggleFullscreen` action to be able to enter fullscreen mode, bound by default to <kbd>alt+enter</kbd>.
The action is bubbled up to the WindowsTerminal (Win32) layer, where the window resizes itself to take the entire size of the monitor.
This largely reuses code from conhost. Conhost already had a fullscreen mode, so I figured I might as well re-use that.
## References
Unfortunately there are still very thin borders around the window when the NonClientIslandWindow is fullscreened. I think I know where the problem is. However, that area of code is about to get a massive overhaul with #3064, so I didn't want to necessarily make it worse right now.
A follow up should be filed to add support for "Always show / reveal / never show tabs in fullscreen mode". Currently, the only mode is "never show tabs".
Additionally, some of this code (particularily re:drawing the nonclient area) could be re-used for #2238.
## PR Checklist
* [x] Closes#531, #3411
* [x] I work here
* [n/a] Tests added/passed 😭
* [x] Requires documentation to be updated
## Validation Steps Performed
* Manually tested both the NonClientIslandWindow and the IslandWindow.
* Cherry-pick commit 8e56bfe
* Don't draw the tab strip when maximized
(cherry picked from commit bac4be7c0f3ed1cdcd4f9ae8980fc98103538613)
* Fix the vista window flash for the NCIW
(cherry picked from commit 7d3a18a893c02bd2ed75026f2aac52e20321a1cf)
* Some code cleanup for review
(cherry picked from commit 9e22b7730bba426adcbfd9e7025f192dbf8efb32)
* A tad bit more notes and cleanup
* Update schema, docs
* Most of the PR comments
* I'm not sure this actually works, so I'm committing it to revert it and check
* Update some comments that were lost.
* Fix a build break?
* oh no
* [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.
