maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/doc/cascadia/profiles.schema.json

1635 lines
61 KiB
JSON
Raw Normal View History

Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
{
Prepare for the primary branch name to change to main (#7985)
2020-10-22 02:29:36 +02:00
"$id": "https://github.com/microsoft/terminal/blob/main/doc/cascadia/profiles.schema.json",
Update profiles schema to draft 2020-12 (#10280) Update profiles schema to draft 2020-12 because as mentioned in https://github.com/microsoft/vscode/issues/98724#issuecomment-786502628, OpenAPI Specification 3.1 defines using JSON Schema 2020-12 and VS Code already has early implementation around it. Basically, this just gets rid of the following error shown by VS Code when editing the settings.json file ``` Draft 2019-09 schemas are not yet fully supported. ``` ## PR Checklist * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated.
2021-06-05 01:41:44 +02:00
"$schema": "https://json-schema.org/draft/2020-12/schema#",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"title": "Microsoft's Windows Terminal Settings Profile Schema",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"definitions": {
Accept String value for Keybindings's Keys (#4714) ## Summary of the Pull Request `keys` in `keybindings` now accepts a string value. This assumes that you wanted a keychord of size 1. The schema and user docs were properly updated too. This means that the following keybinding is now accepted in your profiles.json: ```json { "command": "copy", "keys": "ctrl+c" } ``` as opposed to... ```json { "command": "copy", "keys": [ "ctrl+c" ] } ``` ## PR Checklist * [X] Closes #4713 * [X] CLA signed. * [X] Tests added/passed * [X] Requires documentation to be updated ## Validation Steps Performed - [X] tested the new schema - [X] added test
2020-02-27 21:53:31 +01:00
"KeyChordSegment": {
Add support for the `win` key in keybindings (#9783) ## Summary of the Pull Request Does what it says on the can. People can now use `win` in a keybinding to indicate that the chord needs <kbd>win</kbd>. ## References * Done for #653 * See also #8888 ## PR Checklist * [x] Closes #3184 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments For the record, I hate this. But it's great for quake mode, so _meh_. There's shockingly more win keys claimed then you think - many more than the shortcut guide even shows. * `win+b`: Focus the tray? * `win+t`: Focus the taskbar * `win+p`: Project... * `win+c`: The powertoys color picker * `win+v`: cloud clipboard So the list of valid combos is vanishingly small. It's all about that <kbd>win+~</kbd> ## Validation Steps Performed Bound ```json { "keys": [ "win+`" ], "command": "commandPalette" }, ``` and yea, it works as expected
2021-04-15 18:52:28 +02:00
"pattern": "^(?<modifier>(?<mod1>ctrl|alt|shift|win)(?:\\+(?<mod2>ctrl|alt|shift|win)(?<!\\k<mod1>))?(?:\\+(?<mod3>ctrl|alt|shift|win)(?<!\\k<mod1>|\\k<mod2>))?(?:\\+(?<mod4>ctrl|alt|shift|win)(?<!\\k<mod1>|\\k<mod2>|\\k<mod3>))?\\+)?(?<key>[^\\s+]|app|menu|backspace|tab|enter|esc|escape|space|pgup|pageup|pgdn|pagedown|end|home|left|up|right|down|insert|delete|(?<!shift.+)(?:numpad_?[0-9]|numpad_(?:period|decimal))|numpad_(?:multiply|plus|add|minus|subtract|divide)|f[1-9]|f1[0-9]|f2[0-4]|plus)$",
Improve keybinding JSON schema (#3904) The pattern regex now correctly disallows keybindings consisting of only modifiers, modifiers not separated by "+", and unknown keys. Certain shift+numpad combinations are also not allowed. The description lists allowed key names in tabular format (assuming the client renders \t correctly).
2020-03-24 23:06:23 +01:00
"type": "string",
Add support for the `win` key in keybindings (#9783) ## Summary of the Pull Request Does what it says on the can. People can now use `win` in a keybinding to indicate that the chord needs <kbd>win</kbd>. ## References * Done for #653 * See also #8888 ## PR Checklist * [x] Closes #3184 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments For the record, I hate this. But it's great for quake mode, so _meh_. There's shockingly more win keys claimed then you think - many more than the shortcut guide even shows. * `win+b`: Focus the tray? * `win+t`: Focus the taskbar * `win+p`: Project... * `win+c`: The powertoys color picker * `win+v`: cloud clipboard So the list of valid combos is vanishingly small. It's all about that <kbd>win+~</kbd> ## Validation Steps Performed Bound ```json { "keys": [ "win+`" ], "command": "commandPalette" }, ``` and yea, it works as expected
2021-04-15 18:52:28 +02:00
"description": "The string should fit the format \"[ctrl+][alt+][shift+][win+]<keyName>\", where each modifier is optional, separated by + symbols, and keyName is either one of the names listed in the table below, or any single key character. The string should be written in full lowercase.\napp, menu\tMENU key\nbackspace\tBACKSPACE key\ntab\tTAB key\nenter\tENTER key\nesc, escape\tESC key\nspace\tSPACEBAR\npgup, pageup\tPAGE UP key\npgdn, pagedown\tPAGE DOWN key\nend\tEND key\nhome\tHOME key\nleft\tLEFT ARROW key\nup\tUP ARROW key\nright\tRIGHT ARROW key\ndown\tDOWN ARROW key\ninsert\tINS key\ndelete\tDEL key\nnumpad_0-numpad_9, numpad0-numpad9\tNumeric keypad keys 0 to 9. Can't be combined with the shift modifier.\nnumpad_multiply\tNumeric keypad MULTIPLY key (*)\nnumpad_plus, numpad_add\tNumeric keypad ADD key (+)\nnumpad_minus, numpad_subtract\tNumeric keypad SUBTRACT key (-)\nnumpad_period, numpad_decimal\tNumeric keypad DECIMAL key (.). Can't be combined with the shift modifier.\nnumpad_divide\tNumeric keypad DIVIDE key (/)\nf1-f24\tF1 to F24 function keys\nplus\tADD key (+)"
Accept String value for Keybindings's Keys (#4714) ## Summary of the Pull Request `keys` in `keybindings` now accepts a string value. This assumes that you wanted a keychord of size 1. The schema and user docs were properly updated too. This means that the following keybinding is now accepted in your profiles.json: ```json { "command": "copy", "keys": "ctrl+c" } ``` as opposed to... ```json { "command": "copy", "keys": [ "ctrl+c" ] } ``` ## PR Checklist * [X] Closes #4713 * [X] CLA signed. * [X] Tests added/passed * [X] Requires documentation to be updated ## Validation Steps Performed - [X] tested the new schema - [X] added test
2020-02-27 21:53:31 +01:00
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"Color": {
"default": "#",
"pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$",
Add "format : color" to Schema color items (#3530) Enables VS Code to recognize color-typed settings and show a color decorator in the editor.
2019-11-20 23:55:36 +01:00
"type": "string",
"format": "color"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
},
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"Coordinates": {
"pattern": "^(-?\\d+)?(,\\s?(-?\\d+)?)?$",
"type": "string"
},
doc: add `disabledProfileSources` to the schema (#5549)
2020-04-25 00:15:27 +02:00
"DynamicProfileSource": {
"enum": [
"Windows.Terminal.Wsl",
"Windows.Terminal.Azure",
"Windows.Terminal.PowershellCore"
],
"type": "string"
},
Add a setting to configure the audible bell (#7793) Adds a new setting, `bellStyle`, to be able to disable the audible bell added in #7679. Currently, this setting accepts two values: * `audible`: play a noise on a bell * `none`: Don't play a noise. In the future, we can add a `"bellStyle": "visible"` for flashing the Terminal instead of making a noise on bell. ## Validation Steps Performed Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of triggering a bell. I set the setting to `none`, and presto, the bell stopped. Closes #2360
2020-10-16 00:27:27 +02:00
"BellStyle": {
Add a setting to flash the taskbar when the terminal emits BEL (#8215) The terminal taskbar icon can now flash when the BEL sequence is emitted, to let the user know something needs their attention. The `BellStyle` setting can now be set to `audible`, `visual` or both or none. When the pane receives a BEL event and the `bellStyle` includes `visual`, we bubble the event up all the way to `AppHost` to handle flashing the taskbar. Closes #1608
2020-11-18 23:55:10 +01:00
"oneOf": [
{
"type": "boolean"
},
{
"type": "array",
"items": {
"type": "string",
"enum": [
"audible",
Add a setting to flash the pane when BEL is emitted (#9270) <!-- 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 Adds a new bellStyle called `window`. When `window` is set and a BEL is emitted, we flash the pane that emitted it. Additionally, changes bellStyle in the SUI to a list of checkboxes instead of radio buttons, to match bellStyle being a flag-enum. Deprecates 'BellStyle::Visual' in the schema, but still allows it to be set in the json (it maps to `Window | Taskbar`) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #6700 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed GIF in Teams
2021-05-25 00:51:03 +02:00
"window",
"taskbar"
Add a setting to flash the taskbar when the terminal emits BEL (#8215) The terminal taskbar icon can now flash when the BEL sequence is emitted, to let the user know something needs their attention. The `BellStyle` setting can now be set to `audible`, `visual` or both or none. When the pane receives a BEL event and the `bellStyle` includes `visual`, we bubble the event up all the way to `AppHost` to handle flashing the taskbar. Closes #1608
2020-11-18 23:55:10 +01:00
]
}
},
{
"type": "string",
"enum": [
"audible",
Add a setting to flash the pane when BEL is emitted (#9270) <!-- 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 Adds a new bellStyle called `window`. When `window` is set and a BEL is emitted, we flash the pane that emitted it. Additionally, changes bellStyle in the SUI to a list of checkboxes instead of radio buttons, to match bellStyle being a flag-enum. Deprecates 'BellStyle::Visual' in the schema, but still allows it to be set in the json (it maps to `Window | Taskbar`) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #6700 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed GIF in Teams
2021-05-25 00:51:03 +02:00
"taskbar",
"window",
Add a setting to flash the taskbar when the terminal emits BEL (#8215) The terminal taskbar icon can now flash when the BEL sequence is emitted, to let the user know something needs their attention. The `BellStyle` setting can now be set to `audible`, `visual` or both or none. When the pane receives a BEL event and the `bellStyle` includes `visual`, we bubble the event up all the way to `AppHost` to handle flashing the taskbar. Closes #1608
2020-11-18 23:55:10 +01:00
"all",
"none"
]
}
]
Add a setting to configure the audible bell (#7793) Adds a new setting, `bellStyle`, to be able to disable the audible bell added in #7679. Currently, this setting accepts two values: * `audible`: play a noise on a bell * `none`: Don't play a noise. In the future, we can add a `"bellStyle": "visible"` for flashing the Terminal instead of making a noise on bell. ## Validation Steps Performed Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of triggering a bell. I set the setting to `none`, and presto, the bell stopped. Closes #2360
2020-10-16 00:27:27 +02:00
},
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
"AppearanceConfig": {
"properties": {
"colorScheme": {
"description": "The name of a color scheme to use when unfocused.",
"type": "string"
},
"foreground": {
"$ref": "#/definitions/Color",
"default": "#cccccc",
"description": "Sets the text color when unfocused. Overrides \"foreground\" from the color scheme. Uses hex color format: \"#rrggbb\".",
"type": ["string", "null"]
},
"background": {
"$ref": "#/definitions/Color",
"default": "#0c0c0c",
"description": "Sets the background color of the text when unfocused. Overrides \"background\" from the color scheme. Uses hex color format: \"#rrggbb\".",
"type": ["string", "null"]
},
"selectionBackground": {
"oneOf": [
{"$ref": "#/definitions/Color"},
{ "type": "null" }
],
"description": "Sets the background color of selected text when unfocused. Overrides selectionBackground set in the color scheme. Uses hex color format: \"#rrggbb\"."
},
"cursorColor": {
"oneOf": [
{ "$ref": "#/definitions/Color" },
{"type": "null"}
],
"description": "Sets the color of the cursor when unfocused. Overrides the cursor color from the color scheme. Uses hex color format: \"#rrggbb\"."
},
"cursorShape": {
"default": "bar",
"description": "Sets the shape of the cursor when unfocused. Possible values:\n -\"bar\" ( ┃, default )\n -\"doubleUnderscore\" ( ‗ )\n -\"emptyBox\" ( ▯ )\n -\"filledBox\" ( █ )\n -\"underscore\" ( ▁ )\n -\"vintage\" ( ▃ )",
"enum": [
"bar",
"doubleUnderscore",
"emptyBox",
"filledBox",
"underscore",
"vintage"
],
"type": "string"
},
"cursorHeight": {
"description": "Sets the percentage height of the cursor (when unfocused) starting from the bottom. Only works when cursorShape is set to \"vintage\". Accepts values from 1-100.",
"maximum": 100,
"minimum": 1,
"type": ["integer","null"],
"default": 25
},
"backgroundImage": {
"description": "Sets the file location of the image to draw over the window background when unfocused.",
"oneOf": [
{
"type": ["string", null]
},
{
"enum": [
"desktopWallpaper"
]
}
],
"type": [ "string", "null" ]
},
"backgroundImageOpacity": {
"default": 1.0,
"description": "Sets the transparency of the background image when unfocused. Accepts floating point values from 0-1.",
"maximum": 1.0,
"minimum": 0.0,
"type": "number"
},
"backgroundImageStretchMode": {
"default": "uniformToFill",
"description": "Sets how the background image is resized to fill the window when unfocused.",
"enum": [
"fill",
"none",
"uniform",
"uniformToFill"
],
"type": "string"
},
"backgroundImageAlignment": {
"default": "center",
"enum": [
"bottom",
"bottomLeft",
"bottomRight",
"center",
"left",
"right",
"top",
"topLeft",
"topRight"
],
"description": "Sets how the background image aligns to the boundaries of the window when unfocused. Possible values: \"center\", \"left\", \"top\", \"right\", \"bottom\", \"topLeft\", \"topRight\", \"bottomLeft\", \"bottomRight\"",
"type": "string"
},
"experimental.retroTerminalEffect": {
"description": "When set to true, enable retro terminal effects when unfocused. This is an experimental feature, and its continued existence is not guaranteed.",
"type": "boolean"
},
"experimental.pixelShaderPath": {
"description": "Use to set a path to a pixel shader to use with the Terminal when unfocused. Overrides `experimental.retroTerminalEffect`. This is an experimental feature, and its continued existence is not guaranteed.",
"type": "string"
}
},
"type": "object"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"ProfileGuid": {
"default": "{}",
"pattern": "^\\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}\\}$",
"type": "string"
},
Introduce IconConverter (#7830) ## Summary of the Pull Request Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source. This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist. ## References Based on #7667 ## PR Checklist * [X] Closes #7784 * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. ## Validation Steps Performed Deploy succeeded.
2020-10-08 20:29:04 +02:00
"Icon": {
"description": "Image file location or an emoji to be used as an icon. Displays within the tab, the dropdown menu, and jumplist.",
"type": [
"string",
"null"
]
},
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"ShortcutActionName": {
"enum": [
Remove a heap of legacy settings deserialization (#5190) This commit removes support for: * legacy keybindings of all types * `colorScheme.colors`, as an array * A `globals` object in the root of the settings file * `profile.colorTable` and `profile.colorscheme` (the rare v0.1 all-lowercase variety) Fixes #4091. Fixes #1069.
2020-03-31 22:58:28 +02:00
"adjustFontSize",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"closeOtherTabs",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"closePane",
"closeTab",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"closeTabsAfter",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"closeWindow",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"commandPalette",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"copy",
"duplicateTab",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"find",
Add `findNext`, `findPrev` actions (#8917) This PR is a resurrection of #8522. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new action for navigating to the next & previous search results. These actions are unbound by default. These actions can be used from directly within the search dialog also, to immediately navigate the results. Furthermore, if you have a search started, and close the search box, then press this keybinding, _it will still perform the search_. So you can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep searching new results. Neat! If you dispatch the action on the key down, then dismiss a selection on a key up, we'll end up immediately destroying the selection when you release the bound key. That's annoying. It also bothers @carlos-zamora in #3758. However, I _think_ we can just only dismiss the selection on a key up. I _think_ that's fine. It _seems_ fine so far. We've got an entire release cycle to futz with it. ## Validation Steps Performed I've played with it all day and it seems _crisp_. Closes #7695 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
"findMatch",
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
2021-05-21 23:55:57 +02:00
"focusPane",
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"globalSummon",
Add identifyWindow(s?) to the schema (#9726) Fixes #9721.
2021-04-06 21:11:29 +02:00
"identifyWindow",
"identifyWindows",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"moveFocus",
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-25 23:09:27 +01:00
"moveTab",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"newTab",
Add support for the `newWindow` action (#9208) Finally implements the `newWindow` action. It does so by `ShellExecute`ing `wt.exe` with commandline args corresponding to the ones that would create the same `NewTerminalArgs`. This works with #8898 and #9118 to allow new windows (even with `windowingBehavior: useExisting`) This is taken from my auto-elevate branch, hence the references to elevation References #5000 References projects/5 References #8898 References #9118 Closes #1051
2021-02-20 00:51:30 +01:00
"newWindow",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"nextTab",
"openNewTabDropdown",
"openSettings",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"openTabColorPicker",
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 18:00:04 +02:00
"openWindowRenamer",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"paste",
"prevTab",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"renameTab",
Add `openTabRenamer` action (#7462) Adds a `ShortcutAction` to allow editing the tab title via the TextBox (just like double-clicking the tab, but triggered from a key binding or command palette). * This implements "scenario 3" outlined in zadjii-msft's comment: https://github.com/microsoft/terminal/pull/6557#issuecomment-646153274 * The `openTabRenamer` action name is taken from the discussion in this PR: https://github.com/microsoft/terminal/pull/6567#issuecomment-646319010 Related to #6256 (but doesn't address pane renaming)
2020-10-28 20:36:30 +01:00
"openTabRenamer",
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"quakeMode",
Reset font size key bindings (#3505) ## Summary of the Pull Request This PR implements resetFontSize keybindings, with default keybindings `ctrl+0`. ## PR Checklist * [x] Closes #3319 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Validation Steps Performed Tested manually. ----------------------------------------- * Add resetFontSize keybindings (#3319) * update doc files * Refactor AdjustFontSize & ResetFontSize to use _SetFontSize (#3319) * Ran clang-format on TermControl * Fix function usage change
2019-11-25 18:35:10 +01:00
"resetFontSize",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"resizePane",
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 18:00:04 +02:00
"renameWindow",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"scrollDown",
"scrollDownPage",
"scrollUp",
"scrollUpPage",
Add `scrollToTop` and `scrollToBottom` actions to JSON schema (#8923) Closes #8992.
2021-01-28 18:38:06 +01:00
"scrollToBottom",
"scrollToTop",
Fixed #3799: Introduce sendInput command (#7249) ## Summary of the Pull Request This PR enables users to send arbitrary text input to the shell via a keybinding. ## PR Checklist * [x] Closes #3799 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #3799 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed Added the following keybindings: ```json { "keys": "p", "command": { "action": "sendInput", "input": "foobar" } }, { "keys": "q", "command": { "action": "sendInput", "input": "\u001b[A" } }, ``` Ensured that when pressing <kbd>P</kbd> "foobar" is echoed to the shell and when pressing <kbd>Q</kbd> the shell history is being navigated backwards.
2020-08-12 15:46:53 +02:00
"sendInput",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"setColorScheme",
"setTabColor",
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
"splitPane",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"switchToTab",
Provide global setting to use ATS for nextTab and prevTab (#7321) <!-- 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 splits the anchored and unanchored tab switcher into two. The anchored tab switcher is now baked into `nextTab`/`prevTab`, and the unanchored tab switcher command is just named `tabSearch`. `tabSearch` takes no arguments. To reflect this distinction, `CommandPalette.cpp` now refers to one as `TabSwitchMode` and the other as `TabSearchMode`. I've added a global setting named `useTabSwitcher` (name up for debate) that makes the Terminal use the anchored tab switcher experience for `nextTab` and `prevTab`. I've also given the control the ability to detect <kbd>Alt</kbd> KeyUp events and to dispatch keybinding events. By listening for keybindings, the ATS can react to `nextTab`/`prevTab` invocations for navigation in addition to listening for <kbd>tab</kbd> and the arrow keys. Closes #7178 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] CLA signed. * [x] Documentation updates: microsoftdocs/terminal#107 * [x] Schema updated.
2020-08-21 17:39:40 +02:00
"tabSearch",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"toggleAlwaysOnTop",
Add support for focus mode (#6804) ## Summary of the Pull Request Add support for "focus" mode, which only displays the actual terminal content, no tabs or titlebar. The edges of the window are draggable to resize, but the window can't be moved in borderless mode. The window looks _slightly_ different bewteen different values for `showTabsInTitlebar`, because switching between the `NonClientIslandWindow` and the `IslandWindow` is _hard_. `showTabsInTitlebar` | Preview -- | -- `true` | ![image](https://user-images.githubusercontent.com/18356694/86639069-f5090080-bf9d-11ea-8b29-fb1e479a078d.png) `false` | ![image](https://user-images.githubusercontent.com/18356694/86639094-fafee180-bf9d-11ea-8fc0-6804234a5113.png) ## PR Checklist * [x] Closes #2238 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * **KNOWN ISSUE**: Upon resizing the NCIW, the top frame margin disappears, making that border disappear entirely. 6356aaf has a bunch of WIP work for me trying to fix that, but I couldn't get it quite right. ## Validation Steps Performed * Toggled between focus and fullscreen a _bunch_ in both modes.
2020-07-13 19:40:20 +02:00
"toggleFocusMode",
Add find action to keybinding commands in Settings Profile Schema (#4219)
2020-01-14 21:26:30 +01:00
"toggleFullscreen",
Add `togglePaneZoom` to schema, defaults, and sort action names (#7346) #6989 forgot to add `togglePaneZoom` to the schema, so this does that. WHILE I'M HERE: * The action names in the schema and the actual source were both in _random_ order, so I sorted them alphabetically. * I also added an unbound `togglePaneZoom` command to defaults.json, so users can use that command from the cmdpal w/o binding it manually.
2020-08-20 03:02:10 +02:00
"togglePaneZoom",
Introduce read-only panes (#8867) ## Summary of the Pull Request Introduces read-only panes. When pane is marked as read-only: 1. Attempt to provide user input results in a warning 2. Attempt to close pane - shows dialog 3. Attempt to close hosting tab shows dialog 4. The hosting tab has no close button ## PR Checklist * [x] Closes #6981 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated - not yet. * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments 1. The readonly logic implemented in `TermControl` (and prevents any send input) 2. Special handling is required to allow key-bindings 3. The "close-readonly" protections are in TerminalPage. 4. The indication that the pane is readonly is done using lock glyph 5. The indication that the tab contains readonly pane is done by hiding the close button of the tab 6. The readonly mode is enabled by keyboard shortcut (the followup might add this to the context menu) ## Validation Steps Performed
2021-02-08 19:03:55 +01:00
"toggleReadOnlyMode",
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
"toggleShaderEffects",
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537) ## Summary of the Pull Request Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_. ## References * Related to #4472 * Related to #5400 - I need this for the commandline mode of the Command Palette * Related to #5970 ## PR Checklist * [x] Closes oh, there's not actually an issue for this. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - yes it does ## Detailed Description of the Pull Request / Additional comments One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again. We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up. This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out. This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized. ## Validation Steps Performed This was what the json blob I was using for testing evolved into ```json { "command": { "action":"wt", "commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0", }, "keys": ["ctrl+shift+n"] } ``` I also added some tests. # TODO * [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process? - Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
"wt",
Add `null`, `unbound` to schema for keybindings (#5221) ## Summary of the Pull Request Add `null`, `unbound` to schema for keybindings ## PR Checklist * [x] Closes #4751 * [x] I work here * [n/a] Tests added/passed * [x] Requires documentation to be updated
2020-04-02 21:43:46 +02:00
"unbound"
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
],
"type": "string"
},
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"FocusDirection": {
"enum": [
"left",
"right",
"up",
"down",
"previous"
],
"type": "string"
},
"ResizeDirection": {
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"enum": [
"left",
"right",
"up",
"down"
],
"type": "string"
},
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-25 23:09:27 +01:00
"MoveTabDirection": {
"enum": [
"forward",
"backward"
],
"type": "string"
},
Add `findNext`, `findPrev` actions (#8917) This PR is a resurrection of #8522. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new action for navigating to the next & previous search results. These actions are unbound by default. These actions can be used from directly within the search dialog also, to immediately navigate the results. Furthermore, if you have a search started, and close the search box, then press this keybinding, _it will still perform the search_. So you can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep searching new results. Neat! If you dispatch the action on the key down, then dismiss a selection on a key up, we'll end up immediately destroying the selection when you release the bound key. That's annoying. It also bothers @carlos-zamora in #3758. However, I _think_ we can just only dismiss the selection on a key up. I _think_ that's fine. It _seems_ fine so far. We've got an entire release cycle to futz with it. ## Validation Steps Performed I've played with it all day and it seems _crisp_. Closes #7695 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
"FindMatchDirection": {
"enum": [
"next",
"prev"
],
"type": "string"
},
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
"SplitState": {
"enum": [
"vertical",
schema: add support for "auto" split value (#4249)
2020-01-15 20:55:13 +01:00
"horizontal",
"auto"
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
],
"type": "string"
},
Add copyFormatting keybinding arg and array support (#6004) Adds array support for the existing `copyFormatting` global setting. This allows users to define which formats they would specifically like to be copied. A boolean value is still accepted and is translated to the following: - `false` --> `"none"` or `[]` - `true` --> `"all"` or `["html", "rtf"]` This also adds `copyFormatting` as a keybinding arg for `copy`. As with the global setting, a boolean value and array value is accepted. CopyFormat is a WinRT enum where each accepted format is a flag. Currently accepted formats include `html`, and `rtf`. A boolean value is accepted and converted. `true` is a conjunction of all the formats. `false` only includes plain text. For the global setting, `null` is not accepted. We already have a default value from before so no worries there. For the keybinding arg, `null` (the default value) means that we just do what the global arg says to do. Overall, the `copyFormatting` keybinding arg is an override of the global setting **when using that keybinding**. References #5212 - Spec for formatted copying References #2690 - disable html copy Validated behavior with every combination of values below: - `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` } - `copyFormatting` copy arg: { `null`, `true`, `false`, `[]`, `[, "html"]`} Closes #4191 Closes #5262
2020-08-15 03:02:24 +02:00
"CopyFormat": {
"oneOf": [
{
"type": "boolean"
},
{
"type": "array",
"items": {
"type": "string",
"enum": [
"html",
"rtf"
]
}
},
{
"type": "string",
"enum": [
"html",
"rtf",
"all",
"none"
]
}
]
},
Advanced Tab Switcher (#6732) ![TabSwitchingv2](https://user-images.githubusercontent.com/57155886/88237962-5505d500-cc35-11ea-8384-d91699155067.gif) ## Summary of the Pull Request This PR adds the Advanced Tab Switcher (ATS) to Terminal. It'll work similarly to VSCode's tab switcher. Because this implementation rides off a lot of the Command Palette's XAML code, it'll look just like the Command Palette, and also have support for tab title search. ## References #3753 - ATS Spec Closes #1502
2020-08-11 16:03:12 +02:00
"AnchorKey": {
"enum": [
"ctrl",
"alt",
"shift"
],
"type": "string"
},
Add launchMode parameter to ToggleCommandPalette action (#8382) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8322 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated - https://github.com/MicrosoftDocs/terminal/pull/202 * [x] Schema updated. * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Added an optional launchMode parameter to "commandPalette" command. The values of the launchMode are either "action" (default) or "command line". ## Validation Steps Performed * Manual tests
2020-12-03 17:15:31 +01:00
"CommandPaletteLaunchMode": {
"enum": [
"action",
"commandLine"
],
"type": "string"
},
Add support for new panes with specifc profiles and other settings overrides (#3825) ## Summary of the Pull Request This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added: * `profile` * `commandline` * `tabTitle` * `startingDirectory` `profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default. `commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607. With this PR, you can make bindings like the following: ```json { "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } }, { "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } }, { "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } }, { "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } }, { "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } }, { "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } }, { "keys": ["ctrl+g"], "command": { "action": "newTab" } }, { "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } }, { "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } }, { "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } } ``` ## References This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments. ## PR Checklist * [x] Closes #998 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated ## Validation Steps Performed There are tests 🎉 Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
"NewTerminalArgs": {
"properties": {
"commandline": {
"description": "A commandline to use instead of the profile's",
"type": "string"
},
"tabTitle": {
"description": "An initial tabTitle to use instead of the profile's",
"type": "string"
},
"startingDirectory": {
"description": "A startingDirectory to use instead of the profile's",
"type": "string"
},
"profile": {
"description": "Either the GUID or name of a profile to use, instead of launching the default",
"type": "string"
},
"index": {
"type": "integer",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "The index of the profile in the new tab dropdown (starting at 0)"
Add support for setting tabColor on the command line (#8102) * Add a tabColor parameter to the `new-tab` and `split-panes` command * Add --tabColor to the command line, to allow bootstrapping with tabs of different colors Add another field to NewTerminalArgs. Use this field to set StartingTabColor in Terminal. This color gets overridden by the color defined by the profile / VT, however can be overridden with the color picker. Since the color is the property of the Terminal, when defined for the tab this color is associated only with the first pane/terminal of the tab. Additional panes will not inherit this color (to prevent advanced resolution, where we need to resolve between the inherited color and the one specified for the pane). ## Validation Steps Performed * UT for parameters parsing * Running system with several tabs of different colors. * Adding custom actions with colors * Performing operations like split pane, duplicate and so on Closes #8075
2020-11-20 05:36:18 +01:00
},
"tabColor": {
"$ref": "#/definitions/Color",
"default": null,
"description": "If provided, will set the tab's color to the given value"
Allow configuring suppressApplicationTitle in new tab/pane/window commands (#9392) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9345 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated - not yet, will be once conceptually approved * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Introduce optional `suppressApplicationTitle` in to `NewTerminalArgs`. When set (either to true or false) overrides profile configuration. Introduce `--suppressApplicationTitle` flag to command line arguments. When provided for sub=command, sets the value in the relevant `NewTerminalArgs` to `true`
2021-03-08 16:23:50 +01:00
},
"suppressApplicationTitle": {
"type": "boolean",
"default": "false",
"description": "When set to true, tabTitle overrides the default title of the tab and any title change messages from the application will be suppressed. When set to false, tabTitle behaves as normal"
Add a `--colorScheme` param to `new-tab`, `split-pane` (#9602) This is entirely self-serving. In my go-to config, I like having some of the panes for a given profile in a different color scheme. This will let a user pass `--colorScheme <scheme name>` to manually override the scheme for that profile. Neat!
2021-03-29 22:04:39 +02:00
},
"colorScheme": {
"description": "The name of a color scheme to use, instead of the one specified by the profile",
"type": "string"
Add support for new panes with specifc profiles and other settings overrides (#3825) ## Summary of the Pull Request This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added: * `profile` * `commandline` * `tabTitle` * `startingDirectory` `profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default. `commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607. With this PR, you can make bindings like the following: ```json { "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } }, { "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } }, { "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } }, { "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } }, { "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } }, { "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } }, { "keys": ["ctrl+g"], "command": { "action": "newTab" } }, { "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } }, { "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } }, { "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } } ``` ## References This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments. ## PR Checklist * [x] Closes #998 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated ## Validation Steps Performed There are tests 🎉 Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
}
},
"type": "object"
},
Allow overriding tab switcher mode on command level (#9507) ## Summary of the Pull Request Currently, when the MRU is enabled we lose the keybinding allowing us to go forward/backward (aka right/left in LTR) in the tab view. To fix that, this PR introduces "tabSwitcherMode" optional parameter to the prevTab / nextTab commands. If it is not provided the global setting will be used. So if you want to go to adjacent tabs, even if MRU is enabled on the system level you can use: ``` { "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"} ``` or even ``` {"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"} ``` if you don't want tab switcher to show up <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9330 * [x] CLA signed. * [x] Tests added/passed * [ ] Documentation updated - not yet. Waiting for approval. * [x] Schema updated. * [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
"SwitchToAdjacentTabArgs" : {
"oneOf": [
{ "type": "null" },
{
"enum": [
"mru",
"inOrder",
"disabled"
],
"type": "string"
}
]
},
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"ShortcutAction": {
"properties": {
"action": {
"description": "The action to execute",
"$ref": "#/definitions/ShortcutActionName"
}
},
"required": [
"action"
],
"type": "object"
},
Remove a heap of legacy settings deserialization (#5190) This commit removes support for: * legacy keybindings of all types * `colorScheme.colors`, as an array * A `globals` object in the root of the settings file * `profile.colorTable` and `profile.colorscheme` (the rare v0.1 all-lowercase variety) Fixes #4091. Fixes #1069.
2020-03-31 22:58:28 +02:00
"AdjustFontSizeAction": {
"description": "Arguments corresponding to an Adjust Font Size Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "adjustFontSize" },
"delta": {
"type": "integer",
"default": 0,
"description": "How much to change the current font point size"
}
}
}
],
"required": [ "delta" ]
},
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"CopyAction": {
"description": "Arguments corresponding to a Copy Text Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "copy" },
Rename copy keybinding arg (#5216) ## Summary of the Pull Request `TrimWhitespace` is misleading. So it is now renamed as 'singleLine'. If true, it comes out as a single line! That makes more sense! ## PR Checklist * [X] Closes #3824 ## Validation Steps Performed Attempted the keybinding with both settings (and none set). Attempted mouse copy with and without shift.
2020-04-03 01:10:28 +02:00
"singleLine": {
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"type": "boolean",
Rename copy keybinding arg (#5216) ## Summary of the Pull Request `TrimWhitespace` is misleading. So it is now renamed as 'singleLine'. If true, it comes out as a single line! That makes more sense! ## PR Checklist * [X] Closes #3824 ## Validation Steps Performed Attempted the keybinding with both settings (and none set). Attempted mouse copy with and without shift.
2020-04-03 01:10:28 +02:00
"default": false,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "If true, the copied content will be copied as a single line (even if there are hard line breaks present in the text). If false, newlines persist from the selected text."
Add copyFormatting keybinding arg and array support (#6004) Adds array support for the existing `copyFormatting` global setting. This allows users to define which formats they would specifically like to be copied. A boolean value is still accepted and is translated to the following: - `false` --> `"none"` or `[]` - `true` --> `"all"` or `["html", "rtf"]` This also adds `copyFormatting` as a keybinding arg for `copy`. As with the global setting, a boolean value and array value is accepted. CopyFormat is a WinRT enum where each accepted format is a flag. Currently accepted formats include `html`, and `rtf`. A boolean value is accepted and converted. `true` is a conjunction of all the formats. `false` only includes plain text. For the global setting, `null` is not accepted. We already have a default value from before so no worries there. For the keybinding arg, `null` (the default value) means that we just do what the global arg says to do. Overall, the `copyFormatting` keybinding arg is an override of the global setting **when using that keybinding**. References #5212 - Spec for formatted copying References #2690 - disable html copy Validated behavior with every combination of values below: - `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` } - `copyFormatting` copy arg: { `null`, `true`, `false`, `[]`, `[, "html"]`} Closes #4191 Closes #5262
2020-08-15 03:02:24 +02:00
},
"copyFormatting": {
"default": null,
"description": "When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. An array of specific formats can also be used. Supported array values include `html` and `rtf`. Plain text is always copied. Not setting this value inherits the behavior of the `copyFormatting` global setting.",
"oneOf": [
{
"$ref": "#/definitions/CopyFormat"
},
{
"type": "null"
}
]
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
}
}
}
]
},
"NewTabAction": {
"description": "Arguments corresponding to a New Tab Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
Add support for new panes with specifc profiles and other settings overrides (#3825) ## Summary of the Pull Request This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added: * `profile` * `commandline` * `tabTitle` * `startingDirectory` `profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default. `commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607. With this PR, you can make bindings like the following: ```json { "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } }, { "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } }, { "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } }, { "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } }, { "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } }, { "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } }, { "keys": ["ctrl+g"], "command": { "action": "newTab" } }, { "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } }, { "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } }, { "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } } ``` ## References This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments. ## PR Checklist * [x] Closes #998 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated ## Validation Steps Performed There are tests 🎉 Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
{ "$ref": "#/definitions/NewTerminalArgs" },
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
{
"properties": {
Add support for new panes with specifc profiles and other settings overrides (#3825) ## Summary of the Pull Request This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added: * `profile` * `commandline` * `tabTitle` * `startingDirectory` `profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default. `commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607. With this PR, you can make bindings like the following: ```json { "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } }, { "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } }, { "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } }, { "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } }, { "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } }, { "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } }, { "keys": ["ctrl+g"], "command": { "action": "newTab" } }, { "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } }, { "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } }, { "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } } ``` ## References This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments. ## PR Checklist * [x] Closes #998 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated ## Validation Steps Performed There are tests 🎉 Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
"action": { "type":"string", "pattern": "newTab" }
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
}
}
]
},
"SwitchToTabAction": {
"description": "Arguments corresponding to a Switch To Tab Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "switchToTab" },
"index": {
"type": "integer",
"default": 0,
"description": "Which tab to switch to, with the first being 0"
}
}
}
],
"required": [ "index" ]
},
"MoveFocusAction": {
"description": "Arguments corresponding to a Move Focus Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "moveFocus" },
"direction": {
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"$ref": "#/definitions/FocusDirection",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"default": "left",
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"description": "The direction to move focus in, between panes. Direction can be 'previous' to move to the most recently used pane."
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
}
}
}
],
"required": [ "direction" ]
},
"ResizePaneAction": {
"description": "Arguments corresponding to a Resize Pane Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "resizePane" },
"direction": {
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"$ref": "#/definitions/ResizeDirection",
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"default": "left",
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"description": "The direction to move the pane separator in."
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
}
}
}
],
"required": [ "direction" ]
},
Fixed #3799: Introduce sendInput command (#7249) ## Summary of the Pull Request This PR enables users to send arbitrary text input to the shell via a keybinding. ## PR Checklist * [x] Closes #3799 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #3799 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed Added the following keybindings: ```json { "keys": "p", "command": { "action": "sendInput", "input": "foobar" } }, { "keys": "q", "command": { "action": "sendInput", "input": "\u001b[A" } }, ``` Ensured that when pressing <kbd>P</kbd> "foobar" is echoed to the shell and when pressing <kbd>Q</kbd> the shell history is being navigated backwards.
2020-08-12 15:46:53 +02:00
"SendInputAction": {
"description": "Arguments corresponding to a Send Input Action",
"allOf": [
{
"$ref": "#/definitions/ShortcutAction"
},
{
"properties": {
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"action": { "type": "string", "pattern": "sendInput" },
Fixed #3799: Introduce sendInput command (#7249) ## Summary of the Pull Request This PR enables users to send arbitrary text input to the shell via a keybinding. ## PR Checklist * [x] Closes #3799 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #3799 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed Added the following keybindings: ```json { "keys": "p", "command": { "action": "sendInput", "input": "foobar" } }, { "keys": "q", "command": { "action": "sendInput", "input": "\u001b[A" } }, ``` Ensured that when pressing <kbd>P</kbd> "foobar" is echoed to the shell and when pressing <kbd>Q</kbd> the shell history is being navigated backwards.
2020-08-12 15:46:53 +02:00
"input": {
"type": "string",
"default": "",
"description": "The text input to feed into the shell. ANSI escape sequences may be used. Escape codes like \\x1b must be written as \\u001b."
}
}
}
],
"required": [ "input" ]
},
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
"SplitPaneAction": {
"description": "Arguments corresponding to a Split Pane Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
Add support for new panes with specifc profiles and other settings overrides (#3825) ## Summary of the Pull Request This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added: * `profile` * `commandline` * `tabTitle` * `startingDirectory` `profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default. `commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607. With this PR, you can make bindings like the following: ```json { "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } }, { "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } }, { "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } }, { "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } }, { "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } }, { "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } }, { "keys": ["ctrl+g"], "command": { "action": "newTab" } }, { "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } }, { "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } }, { "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } }, { "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } } ``` ## References This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments. ## PR Checklist * [x] Closes #998 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated ## Validation Steps Performed There are tests 🎉 Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
{ "$ref": "#/definitions/NewTerminalArgs" },
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
{
"properties": {
"action": { "type": "string", "pattern": "splitPane" },
"split": {
"$ref": "#/definitions/SplitState",
schema: add support for "auto" split value (#4249)
2020-01-15 20:55:13 +01:00
"default": "auto",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "The orientation to split the pane in. Possible values:\n -\"auto\" (splits pane based on remaining space)\n -\"horizontal\" (think [-])\n -\"vertical\" (think [|])"
Add splitMode to JSON schema (#5123) ## Summary of the Pull Request Added `splitMode` to settings schema JSON and md files. The definition might need some tweaking. ## References ## PR Checklist * [x] Closes #4939
2020-04-03 02:11:31 +02:00
},
"splitMode": {
"default": "duplicate",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Control how the pane splits. Only accepts \"duplicate\" which will duplicate the focused pane's profile into a new pane."
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543) ## Summary of the Pull Request Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one. This also adds the param to the `split-pane` subcommand. ### Examples | commandline | result | | -- | -- | | `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) | | `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) | | `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) | ## PR Checklist * [x] Closes #6298 * [x] I work here * [x] Tests added/passed * [x] Docs PR: MicrosoftDocs/terminal#208 ## Detailed Description of the Pull Request / Additional comments I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version. ## Validation Steps Performed Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
},
"size": {
"default": 0.5,
"description": "Specify how large the new pane should be, as a fraction of the current pane's size. 1.0 would be 'all of the current pane', and 0.0 is 'None of the parent'. Accepts floating point values from 0-1 (default 0.5).",
"maximum": 1,
"minimum": 0,
"type": "number"
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
}
}
}
Use an Automatic split for splitPane by default (#5194) ## Summary of the Pull Request You no longer _need_ to specify the `split` argument to `splitPane`, it will default to `Automatic` instead of `None` ## PR Checklist * [x] Closes a discussion we had in team sync * [x] I work here * [x] Tests updated * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Also disables the tests that are broken in #5169 while I investigate
2020-04-01 02:59:31 +02:00
]
Add a 'splitPane' ShortcutAction (#3722) ## Summary of the Pull Request We already have "splitHorizontal" and "splitVertical", but those will both be deprecated in favor of "splitPane" with arguments. Currently, there's one argument: "style", which is one of "vertical" or "horizontal." ## References This is being done in pursuit of supporting #607 and #998. I don't really want to lob #998 in with this one, since both that and this are hefty enough PRs even as they are. (I have a branch for #998, but it needs this first) This will probably conflict with #3658 ## PR Checklist * [ ] Doesn't actually close anything, only enables #998 * [x] I work here * [ ] Tests added/passed - yea okay no excuses here * [x] Requires documentation to be updated ## Validation Steps Performed Added new keybindings with the args - works Tried the old keybindings without the args - still works --------------------------------------- * Add a 'splitPane' keybinding that can be used for splitting a pane either vertically or horizontally * Update documentation too * Good lord this is important * Add a test too, though I have no idea if it works * "style" -> "split" * pr comments from carlos
2019-11-28 14:42:15 +01:00
},
Add keybinding arg to openSettings (#6299) ## Summary of the Pull Request Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`. ## References #5915 - mini-spec ## PR Checklist * [x] Closes #2557 * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available. ## Validation Steps Performed Added the following to my settings.json: ```json { "command": "openSettings", "keys":... }, { "command": { "action": "openSettings" }, "keys":... }, { "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "allFiles" }, "keys":... } ```
2020-06-12 23:19:18 +02:00
"OpenSettingsAction": {
"description": "Arguments corresponding to a Open Settings Action",
"allOf": [
{
"$ref": "#/definitions/ShortcutAction"
},
{
"properties": {
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
"action": { "type": "string", "pattern": "openSettings" },
Add keybinding arg to openSettings (#6299) ## Summary of the Pull Request Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`. ## References #5915 - mini-spec ## PR Checklist * [x] Closes #2557 * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available. ## Validation Steps Performed Added the following to my settings.json: ```json { "command": "openSettings", "keys":... }, { "command": { "action": "openSettings" }, "keys":... }, { "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "allFiles" }, "keys":... } ```
2020-06-12 23:19:18 +02:00
"target": {
"type": "string",
"default": "settingsFile",
"description": "The settings file to open.",
"enum": [
"settingsFile",
"defaultsFile",
"allFiles"
]
}
}
}
]
},
Add `setTabColor` and `openTabColorPicker` actions (#6567) ## Summary of the Pull Request Adds a pair of `ShortcutAction`s for setting the tab color. * `setTabColor`: This changes the color of the current tab to the provided color, or can be used to clear the color. * `openTabColorPicker`: This keybinding immediately activates the tab color picker for the currently focused tab. ## References ## PR Checklist * [x] scratches my own itch * [x] I work here * [x] Tests added/passed * [x] https://github.com/MicrosoftDocs/terminal/pull/69 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed * hey look there are tests * Tested with the following: ```json // { "command": "setTabColor", "keys": [ "alt+c" ] }, { "keys": "ctrl+alt+c", "command": { "action": "setTabColor", "color": "#123456" } }, { "keys": "alt+shift+c", "command": { "action": "setTabColor", "color": null} }, { "keys": "alt+c", "command": "openTabColorPicker" }, ```
2020-06-25 15:06:21 +02:00
"SetTabColorAction": {
"description": "Arguments corresponding to a Set Tab Color Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "setTabColor" },
"color": {
"$ref": "#/definitions/Color",
"default": null,
"description": "If provided, will set the tab's color to the given value. If omitted, will reset the tab's color."
}
}
}
]
},
Add support for changing the active color scheme with an action (#6993) ## Summary of the Pull Request Adds the `setColorScheme` action, to change the color scheme of the active control to one given by the `name` parameter. `name` is required. If `name` is not the name of a color scheme, the action does nothing. ## References * Being done as a stepping stone to #6689 ## PR Checklist * [x] Closes #5401 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Technically, the action is being done by changing the settings of the current `TerminalSettings` of the `TermControl`. Frankly, it should be operating on a copy of the `TermControl`'s `IControlSettings`, then updating the control's settings, or the Control should just listen for changes to it's setting's properties, and update in real time (without a manual call to `UpdateSettings`. However, both those paths are somewhere unknowable beyond #6904, so we'll just do this for now. ## Validation Steps Performed * tested manually with a scheme that exists * tested manually with a scheme that doesn't exist
2020-08-10 18:21:56 +02:00
"SetColorSchemeAction": {
"description": "Arguments corresponding to a Set Color Scheme Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "setColorScheme" },
"colorScheme": {
"type": "string",
"default": "",
"description": "the name of the scheme to apply to the active pane"
}
}
}
],
Fix schema for `setColorScheme` (#7433) `setColorScheme` should require `colorScheme` rather than `name`
2020-08-27 19:11:05 +02:00
"required": [ "colorScheme" ]
Add support for changing the active color scheme with an action (#6993) ## Summary of the Pull Request Adds the `setColorScheme` action, to change the color scheme of the active control to one given by the `name` parameter. `name` is required. If `name` is not the name of a color scheme, the action does nothing. ## References * Being done as a stepping stone to #6689 ## PR Checklist * [x] Closes #5401 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Technically, the action is being done by changing the settings of the current `TerminalSettings` of the `TermControl`. Frankly, it should be operating on a copy of the `TermControl`'s `IControlSettings`, then updating the control's settings, or the Control should just listen for changes to it's setting's properties, and update in real time (without a manual call to `UpdateSettings`. However, both those paths are somewhere unknowable beyond #6904, so we'll just do this for now. ## Validation Steps Performed * tested manually with a scheme that exists * tested manually with a scheme that doesn't exist
2020-08-10 18:21:56 +02:00
},
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537) ## Summary of the Pull Request Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_. ## References * Related to #4472 * Related to #5400 - I need this for the commandline mode of the Command Palette * Related to #5970 ## PR Checklist * [x] Closes oh, there's not actually an issue for this. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - yes it does ## Detailed Description of the Pull Request / Additional comments One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again. We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up. This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out. This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized. ## Validation Steps Performed This was what the json blob I was using for testing evolved into ```json { "command": { "action":"wt", "commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0", }, "keys": ["ctrl+shift+n"] } ``` I also added some tests. # TODO * [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process? - Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
"WtAction": {
"description": "Arguments corresponding to a wt Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "wt" },
"commandline": {
"type": "string",
"default": "",
"description": "a `wt` commandline to run in the current window"
}
}
}
],
"required": [ "commandline" ]
},
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
"CloseOtherTabsAction": {
"description": "Arguments for a closeOtherTabs action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "closeOtherTabs" },
"index": {
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
"oneOf": [
{ "type": "integer" },
Make schema compliant by fixing CloseTab* index definitions (#8547) * The index field should be of type `"null"` and not `null`. * The default value should be `null` and not `""` Closes #8024
2020-12-11 05:26:56 +01:00
{ "type": "null" }
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
],
Make schema compliant by fixing CloseTab* index definitions (#8547) * The index field should be of type `"null"` and not `null`. * The default value should be `null` and not `""` Closes #8024
2020-12-11 05:26:56 +01:00
"default": null,
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
"description": "Close the tabs other than the one at this index. If no index is provided, use the focused tab's index."
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
}
}
}
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
]
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
},
"CloseTabsAfterAction": {
"description": "Arguments for a closeTabsAfter action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "closeTabsAfter" },
"index": {
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
"oneOf": [
{ "type": "integer" },
Make schema compliant by fixing CloseTab* index definitions (#8547) * The index field should be of type `"null"` and not `null`. * The default value should be `null` and not `""` Closes #8024
2020-12-11 05:26:56 +01:00
{ "type": "null" }
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
],
Make schema compliant by fixing CloseTab* index definitions (#8547) * The index field should be of type `"null"` and not `null`. * The default value should be `null` and not `""` Closes #8024
2020-12-11 05:26:56 +01:00
"default": null,
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
"description": "Close the tabs following the tab at this index. If no index is provided, use the focused tab's index."
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
}
}
}
Make index in closeOtherTabs and closeTabsAfter optional (#7390) ## Summary of the Pull Request The `index` action argument is now optional for `closeOtherTabs` and `closeTabsAfter`. When `index` is not defined, `index` is set to the focused tab's index. Also, adds the non-index version of these actions to defaults.json. ## PR Checklist * [X] Closes #7181 * [X] CLA signed * [X] Tests passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [X] Schema updated. ## Validation Steps Performed Opened 4 tabs and ran closeOtherTabs/closeTabsAfter from command palette.
2020-08-25 21:25:25 +02:00
]
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
},
add rowsToScroll to scrollUp/Down w/ fallback to system default (#7924) - The number of lines to move upon scroll up scroll down can be defined in ScrollUp and ScrollDown commands (parameter is called "rowsToScroll"). - If the number are not provided, use the system default (the one we are using for mouse scrolls), rather than 1 line. ## Validation Steps Performed * Manual testing * Added custom bindings for scroll commands with different values, verified they and the default appear and behave as expected * Checked that invalid values are not allowed Closes #5078
2020-10-27 02:19:52 +01:00
"ScrollUpAction": {
"description": "Arguments for a scrollUp action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "scrollUp" },
"rowsToScroll": {
"type": ["integer", "null"],
"default": null,
"description": "Scroll up rowsToScroll lines. If no value is provided, use the system-level defaults."
}
}
}
]
},
"ScrollDownAction": {
"description": "Arguments for a scrollDown action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "scrollDown" },
"rowsToScroll": {
"type": ["integer", "null"],
"default": null,
"description": "Scroll down rowsToScroll lines. If no value is provided, use the system-level defaults."
}
}
}
]
},
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-25 23:09:27 +01:00
"MoveTabAction": {
"description": "Arguments for moving a tab",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "moveTab" },
"direction": {
"$ref": "#/definitions/MoveTabDirection",
"description": "The direction to move the tab"
}
}
}
],
"required": [ "direction" ]
},
Add launchMode parameter to ToggleCommandPalette action (#8382) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8322 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated - https://github.com/MicrosoftDocs/terminal/pull/202 * [x] Schema updated. * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Added an optional launchMode parameter to "commandPalette" command. The values of the launchMode are either "action" (default) or "command line". ## Validation Steps Performed * Manual tests
2020-12-03 17:15:31 +01:00
"CommandPaletteAction": {
"description": "Arguments for a commandPalette action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "commandPalette" },
"launchMode": {
"$ref": "#/definitions/CommandPaletteLaunchMode",
"default": "action",
"description": "Toggle command palette in either action or command line mode. If no value is provided, the palette will launch in action mode."
}
}
}
]
},
Add `findNext`, `findPrev` actions (#8917) This PR is a resurrection of #8522. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new action for navigating to the next & previous search results. These actions are unbound by default. These actions can be used from directly within the search dialog also, to immediately navigate the results. Furthermore, if you have a search started, and close the search box, then press this keybinding, _it will still perform the search_. So you can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep searching new results. Neat! If you dispatch the action on the key down, then dismiss a selection on a key up, we'll end up immediately destroying the selection when you release the bound key. That's annoying. It also bothers @carlos-zamora in #3758. However, I _think_ we can just only dismiss the selection on a key up. I _think_ that's fine. It _seems_ fine so far. We've got an entire release cycle to futz with it. ## Validation Steps Performed I've played with it all day and it seems _crisp_. Closes #7695 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
"FindMatchAction": {
"description": "Arguments corresponding to a Find Match Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "findMatch" },
"direction": {
"$ref": "#/definitions/FindMatchDirection",
"default": "prev",
"description": "The direction to search in. \"prev\" will search upwards in the buffer, and \"next\" will search downwards."
}
}
}
],
"required": [ "direction" ]
},
Add support for the `newWindow` action (#9208) Finally implements the `newWindow` action. It does so by `ShellExecute`ing `wt.exe` with commandline args corresponding to the ones that would create the same `NewTerminalArgs`. This works with #8898 and #9118 to allow new windows (even with `windowingBehavior: useExisting`) This is taken from my auto-elevate branch, hence the references to elevation References #5000 References projects/5 References #8898 References #9118 Closes #1051
2021-02-20 00:51:30 +01:00
"NewWindowAction": {
"description": "Arguments corresponding to a New Window Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{ "$ref": "#/definitions/NewTerminalArgs" },
{
"properties": {
"action": { "type":"string", "pattern": "newWindow" }
}
}
]
},
Allow overriding tab switcher mode on command level (#9507) ## Summary of the Pull Request Currently, when the MRU is enabled we lose the keybinding allowing us to go forward/backward (aka right/left in LTR) in the tab view. To fix that, this PR introduces "tabSwitcherMode" optional parameter to the prevTab / nextTab commands. If it is not provided the global setting will be used. So if you want to go to adjacent tabs, even if MRU is enabled on the system level you can use: ``` { "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"} ``` or even ``` {"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"} ``` if you don't want tab switcher to show up <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9330 * [x] CLA signed. * [x] Tests added/passed * [ ] Documentation updated - not yet. Waiting for approval. * [x] Schema updated. * [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
"PrevTabAction": {
"description": "Arguments corresponding to a Previous Tab Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type":"string", "pattern": "prevTab" },
"tabSwitcherMode": {
"$ref": "#/definitions/SwitchToAdjacentTabArgs",
"default": null,
"description": "Move to the previous tab using \"tabSwitcherMode\". If no mode is provided, use the one globally defined one."
}
}
}
]
},
"NextTabAction": {
"description": "Arguments corresponding to a Next Tab Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type":"string", "pattern": "nextTab" },
"tabSwitcherMode": {
"$ref": "#/definitions/SwitchToAdjacentTabArgs",
"default": null,
"description": "Move to the next tab using \"tabSwitcherMode\". If no mode is provided, use the one globally defined one."
}
}
}
]
},
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 18:00:04 +02:00
"RenameTabAction": {
"description": "Arguments corresponding to a renameTab Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "renameTab" },
"title": {
"type": "string",
"default": "",
"description": "A title to assign to the tab. If omitted or null, this action will restore the tab's title to the original value."
}
}
}
]
},
"RenameWindowAction": {
"description": "Arguments corresponding to a renameWindow Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "renameWindow" },
"name": {
"type": "string",
"default": "",
"description": "A name to assign to the window."
}
}
}
]
},
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
2021-05-21 23:55:57 +02:00
"FocusPaneAction": {
"description": "Arguments corresponding to a focusPane Action",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "focusPane" },
"id": {
"type": "string",
"default": "",
"description": "The ID of the pane to focus"
}
}
}
]
},
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"GlobalSummonAction": {
"description": "This is a special action that works globally in the OS, rather than only in the context of the terminal window. When pressed, this action will summon the terminal window.",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "globalSummon" },
"desktop": {
"type": "string",
"default": "toCurrent",
"description": "This controls how the terminal should interact with virtual desktops.\n- \"any\": Leave the window on whichever desktop it's already on - will switch to that desktop as the window is activated.\n- \"toCurrent\" (default): Move the window to the current virtual desktop.\n- \"onCurrent\": Only summon the window if it's already on the current virtual desktop. ",
"enum": [
"any",
"toCurrent",
"onCurrent"
]
},
"monitor": {
"type": "string",
"default": "toMouse",
"description": "This controls the monitor that the window will be summoned from/to.\n- \"any\": Summon the most recently used window, regardless of which monitor it's currently on.\n- \"toCurrent\": Summon the most recently used window to the monitor with the current foreground window.\n- \"toMouse\" (default): Summon the most recently used window to the monitor where the mouse cursor is.",
"enum": [
"any",
"toCurrent",
"toMouse"
]
},
"name": {
"type": "string",
"description": "When provided, summon the window whose name or ID matches the given name value. If no such window exists, then create a new window with that name."
},
"dropdownDuration": {
"type": "number",
"minimum": 0,
"default": 0,
"description": "When provided with a positive number, \"slide\" the window in from the top of the screen using an animation that lasts dropdownDuration milliseconds."
},
"toggleVisibility": {
"type": "boolean",
"default": true,
"description": "When true, pressing the assigned keys for this action will dismiss (minimize) the window when the window is currently the foreground window."
}
}
}
]
},
"QuakeModeAction": {
"description": "This action is a special variation of the globalSummon action. It specifically summons a window called \"_quake\". If you would like to change the behavior of the quakeMode action, we recommended creating a new globalSummon entry.",
"allOf": [
{ "$ref": "#/definitions/ShortcutAction" },
{
"properties": {
"action": { "type": "string", "pattern": "quakeMode" }
}
}
]
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"Keybinding": {
"additionalProperties": false,
"properties": {
"command": {
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
"description": "The action executed when the associated key bindings are pressed.",
"oneOf": [
Remove a heap of legacy settings deserialization (#5190) This commit removes support for: * legacy keybindings of all types * `colorScheme.colors`, as an array * A `globals` object in the root of the settings file * `profile.colorTable` and `profile.colorscheme` (the rare v0.1 all-lowercase variety) Fixes #4091. Fixes #1069.
2020-03-31 22:58:28 +02:00
{ "$ref": "#/definitions/AdjustFontSizeAction" },
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
{ "$ref": "#/definitions/CopyAction" },
{ "$ref": "#/definitions/ShortcutActionName" },
{ "$ref": "#/definitions/NewTabAction" },
{ "$ref": "#/definitions/SwitchToTabAction" },
{ "$ref": "#/definitions/MoveFocusAction" },
schema: adding missing comma to line 212 (#3772)
2019-11-28 23:15:16 +01:00
{ "$ref": "#/definitions/ResizePaneAction" },
Fixed #3799: Introduce sendInput command (#7249) ## Summary of the Pull Request This PR enables users to send arbitrary text input to the shell via a keybinding. ## PR Checklist * [x] Closes #3799 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [x] Schema updated. * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #3799 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed Added the following keybindings: ```json { "keys": "p", "command": { "action": "sendInput", "input": "foobar" } }, { "keys": "q", "command": { "action": "sendInput", "input": "\u001b[A" } }, ``` Ensured that when pressing <kbd>P</kbd> "foobar" is echoed to the shell and when pressing <kbd>Q</kbd> the shell history is being navigated backwards.
2020-08-12 15:46:53 +02:00
{ "$ref": "#/definitions/SendInputAction" },
Add `null`, `unbound` to schema for keybindings (#5221) ## Summary of the Pull Request Add `null`, `unbound` to schema for keybindings ## PR Checklist * [x] Closes #4751 * [x] I work here * [n/a] Tests added/passed * [x] Requires documentation to be updated
2020-04-02 21:43:46 +02:00
{ "$ref": "#/definitions/SplitPaneAction" },
Add keybinding arg to openSettings (#6299) ## Summary of the Pull Request Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`. ## References #5915 - mini-spec ## PR Checklist * [x] Closes #2557 * [x] Tests added/passed ## Detailed Description of the Pull Request / Additional comments Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available. ## Validation Steps Performed Added the following to my settings.json: ```json { "command": "openSettings", "keys":... }, { "command": { "action": "openSettings" }, "keys":... }, { "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... }, { "command": { "action": "openSettings", "target": "allFiles" }, "keys":... } ```
2020-06-12 23:19:18 +02:00
{ "$ref": "#/definitions/OpenSettingsAction" },
Add `setTabColor` and `openTabColorPicker` actions (#6567) ## Summary of the Pull Request Adds a pair of `ShortcutAction`s for setting the tab color. * `setTabColor`: This changes the color of the current tab to the provided color, or can be used to clear the color. * `openTabColorPicker`: This keybinding immediately activates the tab color picker for the currently focused tab. ## References ## PR Checklist * [x] scratches my own itch * [x] I work here * [x] Tests added/passed * [x] https://github.com/MicrosoftDocs/terminal/pull/69 ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed * hey look there are tests * Tested with the following: ```json // { "command": "setTabColor", "keys": [ "alt+c" ] }, { "keys": "ctrl+alt+c", "command": { "action": "setTabColor", "color": "#123456" } }, { "keys": "alt+shift+c", "command": { "action": "setTabColor", "color": null} }, { "keys": "alt+c", "command": "openTabColorPicker" }, ```
2020-06-25 15:06:21 +02:00
{ "$ref": "#/definitions/SetTabColorAction" },
Add support for changing the active color scheme with an action (#6993) ## Summary of the Pull Request Adds the `setColorScheme` action, to change the color scheme of the active control to one given by the `name` parameter. `name` is required. If `name` is not the name of a color scheme, the action does nothing. ## References * Being done as a stepping stone to #6689 ## PR Checklist * [x] Closes #5401 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Technically, the action is being done by changing the settings of the current `TerminalSettings` of the `TermControl`. Frankly, it should be operating on a copy of the `TermControl`'s `IControlSettings`, then updating the control's settings, or the Control should just listen for changes to it's setting's properties, and update in real time (without a manual call to `UpdateSettings`. However, both those paths are somewhere unknowable beyond #6904, so we'll just do this for now. ## Validation Steps Performed * tested manually with a scheme that exists * tested manually with a scheme that doesn't exist
2020-08-10 18:21:56 +02:00
{ "$ref": "#/definitions/SetColorSchemeAction" },
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537) ## Summary of the Pull Request Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_. ## References * Related to #4472 * Related to #5400 - I need this for the commandline mode of the Command Palette * Related to #5970 ## PR Checklist * [x] Closes oh, there's not actually an issue for this. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - yes it does ## Detailed Description of the Pull Request / Additional comments One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again. We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up. This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out. This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized. ## Validation Steps Performed This was what the json blob I was using for testing evolved into ```json { "command": { "action":"wt", "commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0", }, "keys": ["ctrl+shift+n"] } ``` I also added some tests. # TODO * [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process? - Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
{ "$ref": "#/definitions/WtAction" },
Add `closeOtherTabs`, `closeTabsAfter` actions (#7176) ## Summary of the Pull Request Adds support for two actions, `closeOtherTabs` and `closeTabsAfter`. Both these actions accept an `index` parameter. * `closeOtherTabs`: Close tabs other than `index` * `closeTabsAfter`: Close tabs after `index` (This is also "Close tabs to the right") ## References * This PR is being made to unblock @RahulRavishankar in #1912 ## PR Checklist * [x] I work here * [ ] Tests added/passed * [x] Requires documentation to be updated * [ ] We should file an issue for "add an `index` param to `closeTab`" to add similar support to the close tab action * [ ] We should file an issue for "make the `index` param to `closeOtherTabs`, `closeTabsAfter` optional" to make them both work on the _active_ tab when there's no `index` provided ## Validation Steps Performed * _Verified that_ closing all tabs when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing all tabs when I have a tab other than the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have the `index`'th tab selected _works as expected_ * _Verified that_ closing tabs to the right when I have a tab other than the `index`'th tab selected _works as expected_ - This one has one caveat: for whatever reason, if you run this action when the tab that's currently focused is _before_ the `index` param, then the tabs will expand to fill the entire width of the tab row, until you mouse over them. Probably has something to do with tabs not resizing down until there's a mouse exit event.
2020-08-06 23:47:50 +02:00
{ "$ref": "#/definitions/CloseOtherTabsAction" },
{ "$ref": "#/definitions/CloseTabsAfterAction" },
add rowsToScroll to scrollUp/Down w/ fallback to system default (#7924) - The number of lines to move upon scroll up scroll down can be defined in ScrollUp and ScrollDown commands (parameter is called "rowsToScroll"). - If the number are not provided, use the system default (the one we are using for mouse scrolls), rather than 1 line. ## Validation Steps Performed * Manual testing * Added custom bindings for scroll commands with different values, verified they and the default appear and behave as expected * Checked that invalid values are not allowed Closes #5078
2020-10-27 02:19:52 +01:00
{ "$ref": "#/definitions/ScrollUpAction" },
{ "$ref": "#/definitions/ScrollDownAction" },
Teach Terminal to move tabs with key bindings (#8338) ## Summary of the Pull Request Introduces a new command called `moveTab` This command has a single mandatory argument with values of `forward` and `backward` ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/3593 * [x] CLA signed. * [x] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198 * [x] Schema updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Went for the straightforward solution of moving the tab and the tabViewItem. ## Validation Steps Performed * Manual testing
2020-11-25 23:09:27 +01:00
{ "$ref": "#/definitions/MoveTabAction" },
Add `findNext`, `findPrev` actions (#8917) This PR is a resurrection of #8522. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new action for navigating to the next & previous search results. These actions are unbound by default. These actions can be used from directly within the search dialog also, to immediately navigate the results. Furthermore, if you have a search started, and close the search box, then press this keybinding, _it will still perform the search_. So you can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep searching new results. Neat! If you dispatch the action on the key down, then dismiss a selection on a key up, we'll end up immediately destroying the selection when you release the bound key. That's annoying. It also bothers @carlos-zamora in #3758. However, I _think_ we can just only dismiss the selection on a key up. I _think_ that's fine. It _seems_ fine so far. We've got an entire release cycle to futz with it. ## Validation Steps Performed I've played with it all day and it seems _crisp_. Closes #7695 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
{ "$ref": "#/definitions/FindMatchAction" },
Add support for the `newWindow` action (#9208) Finally implements the `newWindow` action. It does so by `ShellExecute`ing `wt.exe` with commandline args corresponding to the ones that would create the same `NewTerminalArgs`. This works with #8898 and #9118 to allow new windows (even with `windowingBehavior: useExisting`) This is taken from my auto-elevate branch, hence the references to elevation References #5000 References projects/5 References #8898 References #9118 Closes #1051
2021-02-20 00:51:30 +01:00
{ "$ref": "#/definitions/NewWindowAction" },
Allow overriding tab switcher mode on command level (#9507) ## Summary of the Pull Request Currently, when the MRU is enabled we lose the keybinding allowing us to go forward/backward (aka right/left in LTR) in the tab view. To fix that, this PR introduces "tabSwitcherMode" optional parameter to the prevTab / nextTab commands. If it is not provided the global setting will be used. So if you want to go to adjacent tabs, even if MRU is enabled on the system level you can use: ``` { "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"} ``` or even ``` {"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"} { "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"} ``` if you don't want tab switcher to show up <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9330 * [x] CLA signed. * [x] Tests added/passed * [ ] Documentation updated - not yet. Waiting for approval. * [x] Schema updated. * [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
{ "$ref": "#/definitions/NextTabAction" },
{ "$ref": "#/definitions/PrevTabAction" },
Add support for renaming windows (#9662) ## Summary of the Pull Request This PR adds support for renaming windows. ![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif) ![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif) It does so through two new actions: * `renameWindow` takes a `name` parameter, and attempts to set the window's name to the provided name. This is useful if you always want to hit <kbd>F3</kbd> and rename a window to "foo" (READ: probably not that useful) * `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a `TextBox`. When the user hits Ok, it'll request a rename for the provided value. This lets the user pick a new name for the window at runtime. In both cases, if there's already a window with that name, then the monarch will reject the rename, and pop a `Toast` in the window informing the user that the rename failed. Nifty! ## References * Builds on the toasts from #9523 * #5000 - process model megathread ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747 * [x] I work here * [x] Tests addded (and pass with the help of #9660) * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews. > PAIN: We can't immediately focus the textbox in the TeachingTip. It's > not technically focusable until it is opened. However, it doesn't > provide an even tto tell us when it is opened. That's tracked in > microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to > click on the text box manually. > We're also not using a ContentDialog for this, because in Xaml > Islands a text box in a ContentDialog won't recieve _any_ keypresses. > Fun! ## Validation Steps Performed I've been playing with ```json { "keys": "f1", "command": "identifyWindow" }, { "keys": "f2", "command": "identifyWindows" }, { "keys": "f3", "command": "openWindowRenamer" }, { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } }, { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } }, ``` and they seem to work as expected
2021-04-02 18:00:04 +02:00
{ "$ref": "#/definitions/RenameTabAction" },
{ "$ref": "#/definitions/RenameWindowAction" },
Add support for `focusPane` action, `focus-pane` subcommand (#10142) ## Summary of the Pull Request Adds support for the `focusPane` action, and the `focus-pane` subcommand. These allow the user to focus a pane by it's ID. * `focusPane` accepts an `id`, identifying the id of the pane to focus. * `focus-pane`, `fp` requires the parameter `--target,-t` to ID the pane it's going to focus. ## PR Checklist * [x] Closes #5803 * [x] Closes #5464 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - oh no ## Detailed Description of the Pull Request / Additional comments The ID isn't _totally_ useful right now, since users can't see them. But they're there, and used in-order. This is just slightly more ergonomic for complicated commandlines than `mf up; mf left` ## Validation Steps Performed Tested in command palette Tested a variety of commandlines. `wtd -w 0 mf down ; sp` and `wtd -w 0 fp -t 1 ; sp` gave me special difficulty.
2021-05-21 23:55:57 +02:00
{ "$ref": "#/definitions/FocusPaneAction" },
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
{ "$ref": "#/definitions/GlobalSummonAction" },
{ "$ref": "#/definitions/QuakeModeAction" },
Add `null`, `unbound` to schema for keybindings (#5221) ## Summary of the Pull Request Add `null`, `unbound` to schema for keybindings ## PR Checklist * [x] Closes #4751 * [x] I work here * [n/a] Tests added/passed * [x] Requires documentation to be updated
2020-04-02 21:43:46 +02:00
{ "type": "null" }
Add support for arbitrary args in keybindings (#3391) ## 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
2019-11-14 23:23:40 +01:00
]
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
},
"keys": {
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Defines the key combinations used to call the command. It must be composed of...\n -any number of modifiers (ctrl/alt/shift)\n -a non-modifier key",
Accept String value for Keybindings's Keys (#4714) ## Summary of the Pull Request `keys` in `keybindings` now accepts a string value. This assumes that you wanted a keychord of size 1. The schema and user docs were properly updated too. This means that the following keybinding is now accepted in your profiles.json: ```json { "command": "copy", "keys": "ctrl+c" } ``` as opposed to... ```json { "command": "copy", "keys": [ "ctrl+c" ] } ``` ## PR Checklist * [X] Closes #4713 * [X] CLA signed. * [X] Tests added/passed * [X] Requires documentation to be updated ## Validation Steps Performed - [X] tested the new schema - [X] added test
2020-02-27 21:53:31 +01:00
"oneOf": [
{
"$ref": "#/definitions/KeyChordSegment"
},
{
"items": {
"$ref": "#/definitions/KeyChordSegment"
},
"minItems": 1,
"type": "array"
}
]
Introduce IconConverter (#7830) ## Summary of the Pull Request Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source. This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist. ## References Based on #7667 ## PR Checklist * [X] Closes #7784 * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. ## Validation Steps Performed Deploy succeeded.
2020-10-08 20:29:04 +02:00
},
"icon": { "$ref": "#/definitions/Icon" },
"name": {
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"description": "The name that will appear in the command palette. If one isn't provided, the terminal will attempt to automatically generate a name.\nIf name is a string, it will be the name of the command.\nIf name is a object, the key property of the object will be used to lookup a localized string resource for the command",
"properties": {
"key": {
"type": "string"
}
},
Introduce IconConverter (#7830) ## Summary of the Pull Request Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source. This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist. ## References Based on #7667 ## PR Checklist * [X] Closes #7784 * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. ## Validation Steps Performed Deploy succeeded.
2020-10-08 20:29:04 +02:00
"type": [
"string",
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"object",
Introduce IconConverter (#7830) ## Summary of the Pull Request Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source. This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist. ## References Based on #7667 ## PR Checklist * [X] Closes #7784 * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. ## Validation Steps Performed Deploy succeeded.
2020-10-08 20:29:04 +02:00
"null"
]
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
},
"iterateOn": {
"type": "string",
"description": "Used to create iterable commands based on other objects in your settings. Possible values:\n- \"profiles\" \n- \"schemes\"",
"enum": [
"profiles",
"schemes"
]
},
"commands": {
"description": "List of commands to execute",
"items": {
"$ref": "#/definitions/Keybinding/properties/command"
},
"minItems": 1,
"type": "array"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
}
},
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"anyOf": [
{"required": ["name","commands"]},
{"required": ["command"]}
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
],
"type": "object"
},
"Globals": {
"additionalProperties": true,
"description": "Properties that affect the entire window, regardless of the profile settings.",
"properties": {
Add support for "Always on top" mode (#6903) This PR adds support for always on top mode, via two mechanisms: * The global setting `alwaysOnTop`. When set to true, the window will be created in the "topmost" group of windows. Changing this value will hot-reload whether the window is in the topmost group. * The action `toggleAlwaysOnTop`, which will toggle the `alwaysOnTop` property at runtime. ## Detailed Description of the Pull Request / Additional comments All "topmost" windows maintain an internal z-ordering relative to one another, but they're all always above all other "non-topmost" windows. So multiple Windows Terminal windows which are both `alwaysOnTop` will maintain a z-order relative to one another, but they'll all be on top of all other windows. ## Validation Steps Performed Toggled always on top mode, both in the settings and also at runtime, and verified that it largely did what I expected. Closes #3038
2020-07-14 23:02:18 +02:00
"alwaysOnTop": {
"default": false,
"description": "When set to true, the window is created on top of all other windows. If multiple windows are all \"always on top\", the most recently focused one will be the topmost",
"type": "boolean"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"alwaysShowTabs": {
"default": true,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "When set to true, tabs are always displayed. When set to false and \"showTabsInTitlebar\" is set to false, tabs only appear after opening a new tab.",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"type": "boolean"
},
Add `centerOnLaunch` setting (#9036) This PR is a resurrection of #8414. @Hegunumo has apparently deleted their account, but the contribution was still valuable. I'm just here to get it across the finish line. This PR adds new global setting `centerOnLaunch`. When set to `true`, the Terminal window will be centered on the display it opens on. So the interactions are like: * `initialPos: x,y`, `centered: true`, `launchMode: default` center on the monitor that x,y is on * `initialPos: x,y`, `centered: true`, `launchMode: maximized` maximized on the monitor that x,y is on (centered adds nothing) * `initialPos: <omitted>`, `centered: true`, `launchMode: default` center on the default monitor * `initialPos: <omitted>`, `centered: true`, `launchMode: focus` center, focus mode on the default monitor * `initialPos: <omitted>`, `centered: true`, `launchMode: maximized` maximized on the default monitor (centered adds nothing) ## Validation Steps Performed I've played with it on multiple different monitors, and it seems to work on all of them. Closes #8414 (original PR) Closes #7722 Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-19 23:30:24 +01:00
"centerOnLaunch": {
"default": false,
"description": "When set to `true`, the terminal window will auto-center itself on the display it opens on. The terminal will use the \"initialPosition\" to determine which display to open on.",
"type": "boolean"
},
Control 'Touch Keyboard and Handwriting Panel Service' warning (#9015) Add a setting to turn off the warning if 'Touch Keyboard and Handwriting Panel Service' is disabled. The service might not start in some case, and it doesn't affect the input in some computer. This PR turn off the warning even if the service is disabled. The setting name is "inputServiceWarning". ## Validation Steps Performed I manually set the service to "Disabled", restarted the Terminal, verified the warning up, then set "inputServiceWarning" to false and restarted the Terminal, and the warning didn't appear. References #8095 References https://github.com/microsoft/terminal/issues/7886#issuecomment-729350169
2021-02-22 21:08:49 +01:00
"inputServiceWarning": {
"default": true,
"description": "Warning if 'Touch Keyboard and Handwriting Panel Service' is disabled.",
"type": "boolean"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"copyOnSelect": {
"default": false,
"description": "When set to true, a selection is immediately copied to your clipboard upon creation. When set to false, the selection persists and awaits further action.",
"type": "boolean"
},
Add support for "focus follows mouse" mode (#8965) ## PR Checklist * [x] Closes #6459 * [x] CLA signed. * [ ] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/248 * [x] Schema updated. * [x] I've discussed this with core contributors already.
2021-02-09 23:18:20 +01:00
"focusFollowMouse": {
"default": false,
"description": "When set to true, the terminal will focus the pane on mouse hover.",
"type": "boolean"
},
Add 'copyFormatting' global setting (#5299) ## Summary of the Pull Request Implements `copyFormatting` as a global setting. When enabled, formatting such as font and foreground/background colors are copied to the clipboard on _all_ copy operations. Also updates the schema and docs. ## References #5212 - Spec for Formatted Copying #4191 - Setting to enable/disable formatted copy #5263 - PR prematurely merged without approval of #5212 This feature will also have an impact on these yet-to-be-implemented features: - #5262 - copyFormatting Keybinding Arg for Copy - #1553 - Pointer Bindings - #4191 - add array support for `copyFormatting` ## Detailed Description of the Pull Request We already check if the hstring passed into the clipboard is empty before setting it. So the majority of the changes are actually just adding the global setting in. ## Validation Steps Performed | `copyFormatting` | Mouse Copy | Keyboard Copy | |--|--|--| | not set (`false`) | ✔ | ✔ | | `true` | ✔ | ✔ | | `false` | ✔ | ✔ |
2020-04-10 01:32:38 +02:00
"copyFormatting": {
Add copyFormatting setting to all settings json files (#5404) ## Summary of the Pull Request Added `copyFormatting` to defaults json files and userDefaults. ## PR Checklist * [X] Closes #5403
2020-04-21 01:49:12 +02:00
"default": true,
Add copyFormatting keybinding arg and array support (#6004) Adds array support for the existing `copyFormatting` global setting. This allows users to define which formats they would specifically like to be copied. A boolean value is still accepted and is translated to the following: - `false` --> `"none"` or `[]` - `true` --> `"all"` or `["html", "rtf"]` This also adds `copyFormatting` as a keybinding arg for `copy`. As with the global setting, a boolean value and array value is accepted. CopyFormat is a WinRT enum where each accepted format is a flag. Currently accepted formats include `html`, and `rtf`. A boolean value is accepted and converted. `true` is a conjunction of all the formats. `false` only includes plain text. For the global setting, `null` is not accepted. We already have a default value from before so no worries there. For the keybinding arg, `null` (the default value) means that we just do what the global arg says to do. Overall, the `copyFormatting` keybinding arg is an override of the global setting **when using that keybinding**. References #5212 - Spec for formatted copying References #2690 - disable html copy Validated behavior with every combination of values below: - `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` } - `copyFormatting` copy arg: { `null`, `true`, `false`, `[]`, `[, "html"]`} Closes #4191 Closes #5262
2020-08-15 03:02:24 +02:00
"description": "When set to `true`, the color and font formatting of selected text is also copied to your clipboard. When set to `false`, only plain text is copied to your clipboard. An array of specific formats can also be used. Supported array values include `html` and `rtf`. Plain text is always copied.",
"$ref": "#/definitions/CopyFormat"
Add 'copyFormatting' global setting (#5299) ## Summary of the Pull Request Implements `copyFormatting` as a global setting. When enabled, formatting such as font and foreground/background colors are copied to the clipboard on _all_ copy operations. Also updates the schema and docs. ## References #5212 - Spec for Formatted Copying #4191 - Setting to enable/disable formatted copy #5263 - PR prematurely merged without approval of #5212 This feature will also have an impact on these yet-to-be-implemented features: - #5262 - copyFormatting Keybinding Arg for Copy - #1553 - Pointer Bindings - #4191 - add array support for `copyFormatting` ## Detailed Description of the Pull Request We already check if the hstring passed into the clipboard is empty before setting it. So the majority of the changes are actually just adding the global setting in. ## Validation Steps Performed | `copyFormatting` | Mouse Copy | Keyboard Copy | |--|--|--| | not set (`false`) | ✔ | ✔ | | `true` | ✔ | ✔ | | `false` | ✔ | ✔ |
2020-04-10 01:32:38 +02:00
},
Make whitespace trimming in block selection configurable (#9807) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/9706 * [x] CLA signed. * [ ] Tests added/passed * [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/313 * [x] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments Added global flag named `trimBlockSelection` set to `false` by default. The setting was added to Interactions menu of the SUI.
2021-04-24 00:36:51 +02:00
"trimBlockSelection": {
"default": false,
"description": "When set to true, trailing white-spaces will be removed from text in rectangular (block) selection while copied to your clipboard. When set to false, the white-spaces will be preserved.",
"type": "boolean"
},
Add a setting to disable URL detection (#10022) <!-- 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 Adds a global setting, `experimental.detectHyperlinks`, that controls whether we automatically detect links and make them clickable. Default is set to true. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9981 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [x] Schema updated. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed When `detectHyperlinks` is set to false, links do not underline on hover and are not clickable.
2021-05-17 06:20:09 +02:00
"experimental.detectURLs": {
"default": true,
"description": "When set to true, URLs will be detected by the Terminal. This will cause URLs to underline on hover and be clickable by pressing Ctrl.",
"type": "boolean"
},
Add an animation to pane entrance/exit (#7364) Adds an entrance animation when panes are created. This animation can be disabled with the `disableAnimations` global setting. Although the XAML animation documentation was pretty heavy on the _do it in XAML_ route, our panes are created pretty much entirely in code, so we've got to create the animations in code as well. 200ms as the duration of the animation was picked _super_ arbitrarily. 300ms felt too long, and 166ms felt like it was only visible for a single frame. see also: * [Motion in practice](https://docs.microsoft.com/en-us/windows/uwp/design/motion/motion-in-practice) * [This example](https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Xaml.Media.Animation.Storyboard?view=winrt-19041#examples) what what I ended up using, albeit ported to cppwinrt. * [`Timeline.AllowDependentAnimations`](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.media.animation.timeline.allowdependentanimations?view=winrt-19041#Windows_UI_Xaml_Media_Animation_Timeline_AllowDependentAnimations) * [easing functions](https://docs.microsoft.com/en-us/windows/uwp/design/motion/key-frame-and-easing-function-animations#easing-functions) ## Validation Steps Performed Man have I been opening panes Closes #1001 Closes #7366
2020-10-10 01:06:40 +02:00
"disableAnimations": {
"default": false,
"description": "When set to `true`, visual animations will be disabled across the application.",
"type": "boolean"
},
Add settings to warn about large or multiline pastes (#6631) Before sending calling the `HandleClipboardData` member function on the `PasteFromClipboardEventArgs` object when we receive a request from the `TermControl` to send it the clipboard's text content, we now display a warning to let the user choose whether to continue or not if the text is larger than 5 KiB or contains the _new line_ character, which can be a security issue if the user is pasting the text in a shell. These warnings can be disabled with the `largePasteWarning` and `multiLinePasteWarning` global settings respectively. Closes #2349
2020-07-01 21:43:28 +02:00
"largePasteWarning": {
"default": true,
"description": "When set to true, trying to paste text with more than 5 KiB of characters will display a warning asking you whether to continue or not with the paste.",
"type": "boolean"
},
"multiLinePasteWarning": {
"default": true,
"description": "When set to true, trying to paste text with a \"new line\" character will display a warning asking you whether to continue or not with the paste.",
"type": "boolean"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"defaultProfile": {
Allow the default profile to be specified by name (#5706) ## Summary of the Pull Request This looks like a big diff, but there's a bunch of existing code that just got moved around, and there's a cool new Utils template. The tests all pass, and this passed manual validation. I tried weird things like "making a profile named `{ }`" (w/ enough spaces to look like a guid), and yeah it doesn't let you specify that one as a name, but _why would you do that?!_ Okay, this pull request abstracts the conversion of a profile name into an optional profile guid out of the "New Terminal Tab Args" handler and into a common space for all of CascadiaSettings to use. It also cleans up the conversion of indices and names into optional GUIDs and turns _those_ into further helpers. It also introduces a cool new template for running value_or multiple times on a chain of optionals. CoalesceOptionals is a "choose first, with fallback" for N>1 optionals. On top of all this, I've built support for an "unparsed default GUID": we load the user's defaultProfile as a string, and as part of settings validation we unpack that string using the helpers outlined above. ## References Couples well with #5690. ## PR Checklist * [x] Incidentally fixes #2876 * [x] Core Contributor * [x] Tests added/passed * [x] Requires documentation to be updated (done) * [x] I've discussed this with core contributors already ## Validation Steps Performed Added additional test collateral to make sure that this works.
2020-06-01 22:26:00 +02:00
"description": "Sets the default profile. Opens by clicking the \"+\" icon or typing the key binding assigned to \"newTab\".",
"type": "string"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
},
Introduce startupActions in settings (#8770) Procedural solution for https://github.com/microsoft/terminal/issues/756. Introduces a `startupActions` global setting. This setting is as string with the same format as actions in command line arguments. It is used only if command line arguments were not provided (aka running pure wt.exe). The setting allows implicit new-tabs. In the case of invalid syntax we show the warning dialog and ignore the setting. The documentation PR is here: https://github.com/MicrosoftDocs/terminal/pull/217
2021-01-15 19:30:11 +01:00
"startupActions": {
"description": "Sets the list of actions to apply if no command line is provided. Uses the same format as command line arguments",
"type": "string"
},
doc: add `disabledProfileSources` to the schema (#5549)
2020-04-25 00:15:27 +02:00
"disabledProfileSources": {
"description": "Disables all the dynamic profile generators in this list, preventing them from adding their profiles to the list of profiles on startup.",
"items": {
"$ref": "#/definitions/DynamicProfileSource"
},
"type": "array"
},
Add renderer settings to mitigate blurry text for some graphics devices ## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - #778 introduced this, almost certainly. ## PR Checklist * [x] Closes #5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## Detailed Description of the Pull Request / Additional comments When we switched from full-screen repaints to incremental rendering, it seems like we exposed a situation where some display drivers and hardware combinations do not handle scroll and/or dirty regions (from `IDXGISwapChain::Present1`) without blurring the data from the previous frame. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. We hope in the future to figure out what's actually going on here and mitigate it further in software, but until then, these escape hatches are available. 1. `experimental.rendering.forceFullRepaint` - This one restores the pre-778 behavior to the Terminal. On every single frame paint, we'll invalidate the entire screen and repaint it. 2. `experimental.rendering.software` - This one uses the software WARP renderer instead of using the hardware and display driver directly. The theory is that this will sidestep any driver bugs or hardware variations. One, the other, or both of these may be field-applied by users who are experiencing this behavior. Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. We don't believe that's acceptable when seemingly a majority of the users are experiencing the performance benefit with no detriment to graphical display. ## Validation Steps Performed - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue.
2020-05-11 23:54:03 +02:00
"experimental.rendering.forceFullRepaint": {
"description": "When set to true, we will redraw the entire screen each frame. When set to false, we will render only the updates to the screen between frames.",
"type": "boolean"
},
"experimental.rendering.software": {
"description": "When set to true, we will use the software renderer (a.k.a. WARP) instead of the hardware one.",
"type": "boolean"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"initialCols": {
"default": 120,
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
"description": "The number of columns displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"maximum": 999,
"minimum": 1,
"type": "integer"
},
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"initialPosition": {
"$ref": "#/definitions/Coordinates",
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
"description": "The position of the top left corner of the window upon first load. On a system with multiple displays, these coordinates are relative to the top left of the primary display. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), the window will be maximized on the monitor specified by those coordinates."
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"initialRows": {
"default": 30,
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
"description": "The number of rows displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"maximum": 999,
"minimum": 1,
"type": "integer"
},
Add startOnUserLogin & fullscreen launchMode to schema (#7300) Fixes #7294 Co-authored-by: Mike Griese <migrie@microsoft.com>
2020-08-18 02:24:00 +02:00
"startOnUserLogin": {
"default": false,
"description": "When set to true, this enables the launch of Windows Terminal at startup. Setting this to false will disable the startup task entry. If the Windows Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
"type": "boolean"
},
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"launchMode": {
"default": "default",
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
"description": "Defines whether the terminal will launch as maximized, full screen, or in a window. Setting this to \"focus\" is equivalent to launching the terminal in the \"default\" mode, but with the focus mode enabled. Similar, setting this to \"maximizedFocus\" will result in launching the terminal in a maximized window with the focus mode enabled.",
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"enum": [
Add startOnUserLogin & fullscreen launchMode to schema (#7300) Fixes #7294 Co-authored-by: Mike Griese <migrie@microsoft.com>
2020-08-18 02:24:00 +02:00
"fullscreen",
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"maximized",
7124: Add focus and maximizedFocus launch modes (#7873) This commit introduces two new launch modes: focus and maximizedFocus. * Focused mode, behaves like a default mode, but with the Focus Mode enabled. * Maximized focused mode, behaves like a Maximized mode, but with the Focus Mode enabled. There two ways to invoke these new modes: * In the settings file: you set the "launchMode" to either "focus" or "maximizedFocus" * In the command line options, you can path -f / --focus, which is mutually exclusive with the --fullscreen, but can be combined with the --maximized: * Passing -f / --focus will launch the terminal in the "focus" mode * Passing -fM / --focus --maximized will launch the terminal in the "maximizedFocus" mode This should resolve a relevant part in the command line arguments mega-thread #4632 Closes #7124 Closes #7825 Closes #7875
2020-10-15 00:19:51 +02:00
"default",
"focus",
"maximizedFocus"
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
],
"type": "string"
},
Terminal uses system default for number of rows scrolled at a t… (#3575) The terminal will use the system setting to determine the number of lines to scroll at a time. This can be overridden by adding rowsToScroll to app global settings file. terminal will use the system setting if the app setting is 0, or not specified. No restart is needed to reflect setting changes in system or the settings file. The default was hardcoded to 4 in the code with a todo comment. 1 works better on precision touchpads, where 4 scrolls too fast. Co-authored-by: Hannes Nel <hannesne@microsoft.com>
2020-01-06 18:39:02 +01:00
"rowsToScroll": {
"default": "system",
schema: make rowsToScroll deprecation message mention bindings (#8439)
2020-11-30 19:13:51 +01:00
"description": "This parameter once allowed you to override the systemwide \"choose how many lines to scroll at one time\" setting. It no longer does so. However, you can customize the number of lines to scroll in \"scrollUp\" and \"scrollDown\" bindings.",
Terminal uses system default for number of rows scrolled at a t… (#3575) The terminal will use the system setting to determine the number of lines to scroll at a time. This can be overridden by adding rowsToScroll to app global settings file. terminal will use the system setting if the app setting is 0, or not specified. No restart is needed to reflect setting changes in system or the settings file. The default was hardcoded to 4 in the code with a todo comment. 1 works better on precision touchpads, where 4 scrolls too fast. Co-authored-by: Hannes Nel <hannesne@microsoft.com>
2020-01-06 18:39:02 +01:00
"maximum": 999,
"minimum": 0,
Remove the rowsToScroll setting and just always use the system setting (#6891) This parameter was added as a workaround for our fast trackpad scrolling. Since that was fixed before 1.0 shipped, in #4554, it has been largely vestigial. There is no reason for us to keep it around any longer. It was also the only "logic" in TerminalSettings, which is otherwise a library that only transits data between two other libraries. I have not removed it from the schema, as I do not want to mark folks' settings files invalid to a strict schema parser. While I was in the area, I added support for "scroll one screen at a time" (which is represented by the API returning WHEEL_PAGESCROLL), fixing #5610. We were also storing it in an int (whoops) instead of a uint. Fixes #5610
2020-07-14 03:38:11 +02:00
"type": [ "integer", "string" ],
"deprecated": true
Terminal uses system default for number of rows scrolled at a t… (#3575) The terminal will use the system setting to determine the number of lines to scroll at a time. This can be overridden by adding rowsToScroll to app global settings file. terminal will use the system setting if the app setting is 0, or not specified. No restart is needed to reflect setting changes in system or the settings file. The default was hardcoded to 4 in the code with a todo comment. 1 works better on precision touchpads, where 4 scrolls too fast. Co-authored-by: Hannes Nel <hannesne@microsoft.com>
2020-01-06 18:39:02 +01:00
},
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"actions": {
"description": "Properties are specific to each custom action.",
"items": {
"$ref": "#/definitions/Keybinding"
},
"type": "array"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"keybindings": {
profile.schema: add missing actions and commands keys (#10384) Add missing keys to the schema: - globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility) - quakeMode - iterateOn - commands Also enforces required keys for commands and deprecates "keybindings" ## PR Checklist * [x] Closes #7443 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. ## Detailed Description of the Pull Request / Additional comments There were some other pending keys mentioned on the issue, but I don't think they are pending anymore. ## Validation Steps Performed Changed the `"$schema"` value in my settings.json to point to the edited one.
2021-06-10 20:10:48 +02:00
"description": "[deprecated] Use actions instead.",
"deprecated": true,
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"items": {
"$ref": "#/definitions/Keybinding"
},
"type": "array"
},
Add a language switcher using PrimaryLanguageOverride (#10309) ## Summary of the Pull Request This PR adds a global "language" setting, which may be set to any supported BCP 47 tag. Additionally a ComboBox is added to the settings UI under "Appearance", listing all languages with their localized names. This PR introduces one new issue: If you change the language while the app is running, the UI will be in a torn state, as not all UI elements refresh automatically if the `PrimaryLanguageOverride` is changed. ## PR Checklist * [x] Closes #5497 * [x] I work here * [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 * [x] Schema updated ## Validation Steps Performed * UI language changes when changing the "language" in settings.json before starting WT / while WT is running. ✔️ * "language" field is removed from settings.json if "Use system default" is selected. ✔️ * "language" field is added or updated in settings.json if any other language is selected. ✔️ * Removes qps- languages if debugFeatures is false. ✔️ * Correctly refreshes all UI elements with the new language. ❌
2021-06-11 01:24:21 +02:00
"language": {
"default": "",
"description": "Sets an override for the app's preferred language, expressed as a BCP-47 language tag like en-US.",
"type": "string"
},
Rename 'requestedTheme' to 'theme' (#5265) ## Summary of the Pull Request Renames the `requestedTheme` global setting to `theme`. Propagates updates to... - schema - doc - defaults.json - universal-defaults.json ## PR Checklist * [X] Closes #5264 ## Validation Steps Performed | `theme` | Success? | |--|--| | `system` | ✔ | | `light` | ✔ | | `dark` | ✔ | But we really know that `dark` is the one we care about here 😉
2020-04-07 21:14:06 +02:00
"theme": {
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"default": "system",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets the theme of the application. The special value \"system\" refers to the active Windows system theme.",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"enum": [
"light",
"dark",
"system"
],
"type": "string"
},
"showTabsInTitlebar": {
"default": true,
"description": "When set to true, the tabs are moved into the titlebar and the titlebar disappears. When set to false, the titlebar sits above the tabs.",
"type": "boolean"
},
"showTerminalTitleInTitlebar": {
"default": true,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "When set to true, titlebar displays the title of the selected tab. When set to false, titlebar displays \"Windows Terminal\".",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"type": "boolean"
},
Add a setting to disable pane snapping (#4154) ## Summary of the Pull Request Adds a setting `snapToGridOnResize` to disable snapping the window on resize, and defaults it to `false`. ## References Introduced by pr #3181 ## PR Checklist * [x] Closes #3995 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated
2020-01-09 18:19:21 +01:00
"snapToGridOnResize": {
"default": false,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "When set to true, the window will snap to the nearest character boundary on resize. When false, the window will resize smoothly",
Add a setting to disable pane snapping (#4154) ## Summary of the Pull Request Adds a setting `snapToGridOnResize` to disable snapping the window on resize, and defaults it to `false`. ## References Introduced by pr #3181 ## PR Checklist * [x] Closes #3995 * [x] I work here * [ ] Tests added/passed * [ ] Requires documentation to be updated
2020-01-09 18:19:21 +01:00
"type": "boolean"
},
Add tab width modes: equal and titleLength (#3876) * tab sizing functionality * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * updated variable names to match spec * added to defaults.json * fixed merge conflict Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-01-10 01:16:54 +01:00
"tabWidthMode": {
"default": "equal",
Add support for `compact` tab sizing (#5787) ## Summary of the Pull Request Really couldn't be more starightforward. MUX 2.4 added support for "compact" sized tabs. This PR (targeting the 2.4 PR currently, will move to `master` when that merges) enables users to specify `"tabWidthMode": "compact"` in their global settings to get this behavior. ## References * #5778 - PR to move to MUX 2.4 * [microsoft-ui-xaml#2016](https://github.com/microsoft/microsoft-ui-xaml/pull/2016) - the MUX PR for compact tab sizing. * #597 - Tab sizing options? ## PR Checklist * [x] I don't think we have an issue for this, though I could be wrong. * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments In this screenshot, I'm hovering over tab 2, but the ubuntu tab is focused: ![image](https://user-images.githubusercontent.com/18356694/81302365-e6ef4000-903f-11ea-9ce3-5f5ce92e5ba4.png) In this screenshot, tab 2 is focused: ![image](https://user-images.githubusercontent.com/18356694/81302383-ea82c700-903f-11ea-9820-92348d5adc64.png)
2020-06-05 20:51:04 +02:00
"description": "Sets the width of the tabs. Possible values include:\n -\"equal\" sizes each tab to the same width\n -\"titleLength\" sizes each tab to the length of its title\n -\"compact\" sizes each tab to the length of its title when focused, and shrinks to the size of only the icon when the tab is unfocused.",
Add tab width modes: equal and titleLength (#3876) * tab sizing functionality * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * updated variable names to match spec * added to defaults.json * fixed merge conflict Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-01-10 01:16:54 +01:00
"enum": [
Add support for `compact` tab sizing (#5787) ## Summary of the Pull Request Really couldn't be more starightforward. MUX 2.4 added support for "compact" sized tabs. This PR (targeting the 2.4 PR currently, will move to `master` when that merges) enables users to specify `"tabWidthMode": "compact"` in their global settings to get this behavior. ## References * #5778 - PR to move to MUX 2.4 * [microsoft-ui-xaml#2016](https://github.com/microsoft/microsoft-ui-xaml/pull/2016) - the MUX PR for compact tab sizing. * #597 - Tab sizing options? ## PR Checklist * [x] I don't think we have an issue for this, though I could be wrong. * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments In this screenshot, I'm hovering over tab 2, but the ubuntu tab is focused: ![image](https://user-images.githubusercontent.com/18356694/81302365-e6ef4000-903f-11ea-9ce3-5f5ce92e5ba4.png) In this screenshot, tab 2 is focused: ![image](https://user-images.githubusercontent.com/18356694/81302383-ea82c700-903f-11ea-9820-92348d5adc64.png)
2020-06-05 20:51:04 +02:00
"compact",
Add tab width modes: equal and titleLength (#3876) * tab sizing functionality * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * updated variable names to match spec * added to defaults.json * fixed merge conflict Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-01-10 01:16:54 +01:00
"equal",
"titleLength"
],
"type": "string"
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"wordDelimiters": {
"default": " ./\\()\"'-:,.;<>~!@#$%^&*|+=[]{}~?│",
"description": "Determines the delimiters used in a double click selection.",
"type": "string"
No more are you sure boxes (#4101) <!-- 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 So this PR adds a profile setting called "confirmCloseAllTabs", that allows one to enable or disable the "Do you want close all tabs?" dialog that appears when you close a window with multiple open tabs. It current defaults to "true". Also adds a checkbox to that dialog that also sets "confirmCloseAllTabs" <!-- 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 #3883 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Requires documentation to be updated * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- 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 I added a checkbox to the close dialog to set this setting, but I'm not sure how to best go about actually changing the setting from code; am open to suggestions, as to how it should be done, or if I should also just remove it and stick with the profile setting. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. Set "confirmCloseAllTabs" to false in my profile.json file. 2. Opened a 2nd tab. 3. Closed the window 4. Observed that there was no confirmation before the window closed. 5. Set "confirmCloseAllTabs" to true 6. Repeat steps 2 and 3 7. Observe that there was a confirmation before the window closed.
2020-01-31 02:09:39 +01:00
},
"confirmCloseAllTabs": {
"default": true,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "When set to \"true\" closing a window with multiple tabs open will require confirmation. When set to \"false\", the confirmation dialog will not appear.",
Add renderer settings to mitigate blurry text for some graphics devices ## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - #778 introduced this, almost certainly. ## PR Checklist * [x] Closes #5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## Detailed Description of the Pull Request / Additional comments When we switched from full-screen repaints to incremental rendering, it seems like we exposed a situation where some display drivers and hardware combinations do not handle scroll and/or dirty regions (from `IDXGISwapChain::Present1`) without blurring the data from the previous frame. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. We hope in the future to figure out what's actually going on here and mitigate it further in software, but until then, these escape hatches are available. 1. `experimental.rendering.forceFullRepaint` - This one restores the pre-778 behavior to the Terminal. On every single frame paint, we'll invalidate the entire screen and repaint it. 2. `experimental.rendering.software` - This one uses the software WARP renderer instead of using the hardware and display driver directly. The theory is that this will sidestep any driver bugs or hardware variations. One, the other, or both of these may be field-applied by users who are experiencing this behavior. Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. We don't believe that's acceptable when seemingly a majority of the users are experiencing the performance benefit with no detriment to graphical display. ## Validation Steps Performed - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue.
2020-05-11 23:54:03 +02:00
"type": "boolean"
Provide global setting to use ATS for nextTab and prevTab (#7321) <!-- 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 splits the anchored and unanchored tab switcher into two. The anchored tab switcher is now baked into `nextTab`/`prevTab`, and the unanchored tab switcher command is just named `tabSearch`. `tabSearch` takes no arguments. To reflect this distinction, `CommandPalette.cpp` now refers to one as `TabSwitchMode` and the other as `TabSearchMode`. I've added a global setting named `useTabSwitcher` (name up for debate) that makes the Terminal use the anchored tab switcher experience for `nextTab` and `prevTab`. I've also given the control the ability to detect <kbd>Alt</kbd> KeyUp events and to dispatch keybinding events. By listening for keybindings, the ATS can react to `nextTab`/`prevTab` invocations for navigation in addition to listening for <kbd>tab</kbd> and the arrow keys. Closes #7178 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] CLA signed. * [x] Documentation updates: microsoftdocs/terminal#107 * [x] Schema updated.
2020-08-21 17:39:40 +02:00
},
"useTabSwitcher": {
"default": true,
Allow the user to use the tab switcher with in-order tab switching (#8076) ## Summary of the Pull Request Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string: * `true`, `"mru"`: Use the tab switcher with MRU tab switching * `"inOrder"`: Use the tab switcher, with in-order tab switching * `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order. This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread. ## References * #7952 introduced MRU tab switching ## PR Checklist * [x] Closes #8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task * [x] I work here * [x] Tests added/passed - YOU BET THEY WERE * [ ] Requires documentation to be updated ## Validation Steps Performed I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting. I also _ran the test_ I added.
2020-11-05 15:28:16 +01:00
"description": "Deprecated. Please use \"tabSwitcherMode\" instead.",
"oneOf": [
{
"type": "boolean"
},
{
"enum": [
"mru",
"inOrder",
8249: Remove trailing commas in profiles.schema.json (#8257) Fixes https parsing of the latest version of `profiles.schema.json`, particularly by VS Code Intellisense. * [x] Closes #8249 The VS Code parsing warning below is a known and unrelated existing issue due to VS Code only supporting JSON Schema Draft 7. It does not prevent Intellisense from functioning. > Draft 2019-09 schemas are not yet fully supported. ## Validation Steps Performed Manually tested and successfully validated by fixing a local copy of `profiles.schema.json` and defining it as `$schema` in `settings.json`
2020-11-13 17:27:27 +01:00
"disabled"
Allow the user to use the tab switcher with in-order tab switching (#8076) ## Summary of the Pull Request Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string: * `true`, `"mru"`: Use the tab switcher with MRU tab switching * `"inOrder"`: Use the tab switcher, with in-order tab switching * `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order. This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread. ## References * #7952 introduced MRU tab switching ## PR Checklist * [x] Closes #8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task * [x] I work here * [x] Tests added/passed - YOU BET THEY WERE * [ ] Requires documentation to be updated ## Validation Steps Performed I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting. I also _ran the test_ I added.
2020-11-05 15:28:16 +01:00
],
"type": "string"
}
],
"deprecated": true
},
"tabSwitcherMode": {
Change the default tab switch mode back to inOrder (#8326) We changed the default to "mru", and that was unkind to all our existing users.
2020-11-20 00:57:35 +01:00
"default": "inOrder",
Allow the user to use the tab switcher with in-order tab switching (#8076) ## Summary of the Pull Request Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string: * `true`, `"mru"`: Use the tab switcher with MRU tab switching * `"inOrder"`: Use the tab switcher, with in-order tab switching * `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order. This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread. ## References * #7952 introduced MRU tab switching ## PR Checklist * [x] Closes #8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task * [x] I work here * [x] Tests added/passed - YOU BET THEY WERE * [ ] Requires documentation to be updated ## Validation Steps Performed I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting. I also _ran the test_ I added.
2020-11-05 15:28:16 +01:00
"description": "When set to \"true\" or \"mru\", the \"nextTab\" and \"prevTab\" commands will use the tab switcher UI, with most-recently-used ordering. When set to \"inOrder\", these actions will switch tabs in their current ordering. Set to \"false\" to disable the tab switcher.",
"oneOf": [
{
"type": "boolean"
},
{
"enum": [
"mru",
"inOrder",
8249: Remove trailing commas in profiles.schema.json (#8257) Fixes https parsing of the latest version of `profiles.schema.json`, particularly by VS Code Intellisense. * [x] Closes #8249 The VS Code parsing warning below is a known and unrelated existing issue due to VS Code only supporting JSON Schema Draft 7. It does not prevent Intellisense from functioning. > Draft 2019-09 schemas are not yet fully supported. ## Validation Steps Performed Manually tested and successfully validated by fixing a local copy of `profiles.schema.json` and defining it as `$schema` in `settings.json`
2020-11-13 17:27:27 +01:00
"disabled"
Allow the user to use the tab switcher with in-order tab switching (#8076) ## Summary of the Pull Request Changes the way the `useTabSwitcher` setting works. It now accepts either a boolean or a string: * `true`, `"mru"`: Use the tab switcher with MRU tab switching * `"inOrder"`: Use the tab switcher, with in-order tab switching * `false`, `"disabled"`: Don't use the tab switcher. Tabs will switch in-order. This is following the discussion chronicled in #8025, as well as the follow-up investigation in that thread. ## References * #7952 introduced MRU tab switching ## PR Checklist * [x] Closes #8025 - there's also discussion of using a parameter in an action to override this setting, but that should get punted to a follow-up task * [x] I work here * [x] Tests added/passed - YOU BET THEY WERE * [ ] Requires documentation to be updated ## Validation Steps Performed I've been switching tabs all day and all night, with different settings values, and hot-reloading the setting. I also _ran the test_ I added.
2020-11-05 15:28:16 +01:00
],
"type": "string"
}
]
Add support for the `windowingBehavior` setting (#9118) Adds support for the `windowingBehavior` global setting. This setting controls how mutiple instances of `wt` behave in the absence of the `-w` parameter. This setting has three values: * `"useNew"`: (default) Multiple `wt` invocations (without the `-w` param) always create new windows. * `"useAnyExisting"`: When starting a new `wt`, we'll instead default to any existing windows. `wt -w -1` will still create new windows. * `"useExisting"`: Similar to `useAnyExisting`, but limits to windows on the current desktop. The IVirtualDesktopManager interface is _very_ limited. Hence why we have to track the HWNDs manually, and ask if they're on the current desktop. ## Validation Steps Performed I've been playing with it for a week now. References #5000 References projects/5 References #8898 Spec'd in #8135 Closes #2227 Closes https://github.com/microsoft/terminal/projects/5#card-51431448 Closes https://github.com/microsoft/terminal/projects/5#card-51431433
2021-02-19 22:09:17 +01:00
},
"windowingBehavior": {
"default": "useNew",
"description": "Controls how new terminal instances attach to existing windows. \"useNew\" will always create a new window. \"useExisting\" will create new tabs in the most recently used window on this virtual desktop, and \"useAnyExisting\" will create tabs in the most recent window on any desktop.",
"enum": [
"useNew",
"useExisting",
"useAnyExisting"
],
"type": "string"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
}
},
"required": [
"defaultProfile"
],
"type": "object"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"Profile": {
"description": "Properties specific to a unique profile.",
"additionalProperties": false,
"properties": {
"acrylicOpacity": {
"default": 0.5,
"description": "When useAcrylic is set to true, it sets the transparency of the window for the profile. Accepts floating point values from 0-1 (default 0.5).",
"maximum": 1,
"minimum": 0,
"type": "number"
},
Add support for cleartype text antialiasing (#4711) ## Summary of the Pull Request I needed to do something to keep sane so today I day of learned about antialiasing. This PR adds the ability to specify the `"antialiasingMode"` as a setting. * "antialiasingMode": "grayscale": the current behavior, `D2D1_TEXT_ANTIALIAS_MODE_GRAYSCALE` * "antialiasingMode": "cleartype": use `D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE` instead ## PR Checklist * [x] Closes #1298 * [x] I work here * [ ] I didn't add tests * [x] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments Grayscale: ![image](https://user-images.githubusercontent.com/18356694/75173847-2373f680-56f5-11ea-8896-c1cf04c61d41.png) Cleartype: ![image](https://user-images.githubusercontent.com/18356694/75173854-25d65080-56f5-11ea-9de1-e2d1c343cae5.png) Side-by-side (can you tell which is which?) <!-- grayscale, cleartype --> ![image](https://user-images.githubusercontent.com/18356694/75173864-28d14100-56f5-11ea-8bdd-d47a60fbbe4d.png)
2020-02-25 23:19:57 +01:00
"antialiasingMode": {
"default": "grayscale",
"description": "Controls how text is antialiased in the renderer. Possible values are \"grayscale\", \"cleartype\" and \"aliased\". Note that changing this setting will require starting a new terminal instance.",
"enum": [
"grayscale",
"cleartype",
"aliased"
],
"type": "string"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"background": {
"$ref": "#/definitions/Color",
schema: add default colors for foreground and background (#4468) Added `#000000` as default for `background` and `#FFFFFF` as default for `foreground` in JSON schema. ## PR Checklist * [x] Closes #3466
2020-02-05 18:24:10 +01:00
"default": "#0c0c0c",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets the background color of the text. Overrides \"background\" from the color scheme. Uses hex color format: \"#rrggbb\".",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"type": ["string", "null"]
},
Add support for a profile to specify an "unfocused" appearance (#8392) This pull request adds an appearance configuration object to our settings model and app lib, allowing the control to be rendered differently depending on its state, and then uses it to add support for an "unfocused" appearance that the terminal will use when it's not in focus. To accomplish this, we isolated the appearance-related settings from Profile (into AppearanceConfig) and TerminalSettings (into the IControlAppearance and ICoreAppearance interfaces). A bunch of work was done to make inheritance work. The unfocused appearance inherits from the focused one _for that profile_. This is important: If you define a defaults.unfocusedAppearance, it will apply all of defaults' settings to any leaf profile when a terminal in that profile is out of focus. Specified in #8345 Closes #3062 Closes #2316
2021-04-09 00:46:16 +02:00
"unfocusedAppearance": {
"$ref": "#/definitions/AppearanceConfig",
"description": "Sets the appearance of the terminal when it is unfocused.",
"type": ["object", "null"]
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"backgroundImage": {
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets the file location of the image to draw over the window background.",
Fix desktopWallpaper background image casing (#8206) - Change `DesktopWallpaper` to `desktopWallpaper` for `backgroundImage` to match our other settings - Add `desktopWallpaper` to json schema
2020-11-09 23:50:29 +01:00
"oneOf": [
{
"type": ["string", null]
},
{
"enum": [
"desktopWallpaper"
]
}
Support for navigating panes by MRU (#8183) Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
2020-12-11 19:36:05 +01:00
],
"type": [ "string", "null" ]
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"backgroundImageAlignment": {
"default": "center",
"enum": [
"bottom",
"bottomLeft",
"bottomRight",
"center",
"left",
"right",
"top",
"topLeft",
"topRight"
],
Add descriptions for `backgroundImageAlignment`, `backgroundImageOpacity` (#5533) These were already in the `SettingsSchema.md`, so I just updated the `profiles.schema.json` to have the descriptions as well. * [x] closes #5520 * [x] I work here. * [x] This is docs.
2020-04-24 19:15:35 +02:00
"description": "Sets how the background image aligns to the boundaries of the window. Possible values: \"center\", \"left\", \"top\", \"right\", \"bottom\", \"topLeft\", \"topRight\", \"bottomLeft\", \"bottomRight\"",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"type": "string"
},
"backgroundImageOpacity": {
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"default": 1.0,
Add descriptions for `backgroundImageAlignment`, `backgroundImageOpacity` (#5533) These were already in the `SettingsSchema.md`, so I just updated the `profiles.schema.json` to have the descriptions as well. * [x] closes #5520 * [x] I work here. * [x] This is docs.
2020-04-24 19:15:35 +02:00
"description": "Sets the transparency of the background image. Accepts floating point values from 0-1.",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"maximum": 1.0,
"minimum": 0.0,
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"type": "number"
},
"backgroundImageStretchMode": {
"default": "uniformToFill",
"description": "Sets how the background image is resized to fill the window.",
"enum": [
"fill",
"none",
"uniform",
"uniformToFill"
],
"type": "string"
},
Add a setting to configure the audible bell (#7793) Adds a new setting, `bellStyle`, to be able to disable the audible bell added in #7679. Currently, this setting accepts two values: * `audible`: play a noise on a bell * `none`: Don't play a noise. In the future, we can add a `"bellStyle": "visible"` for flashing the Terminal instead of making a noise on bell. ## Validation Steps Performed Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of triggering a bell. I set the setting to `none`, and presto, the bell stopped. Closes #2360
2020-10-16 00:27:27 +02:00
"bellStyle": {
"default": "audible",
Add a setting to flash the pane when BEL is emitted (#9270) <!-- 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 Adds a new bellStyle called `window`. When `window` is set and a BEL is emitted, we flash the pane that emitted it. Additionally, changes bellStyle in the SUI to a list of checkboxes instead of radio buttons, to match bellStyle being a flag-enum. Deprecates 'BellStyle::Visual' in the schema, but still allows it to be set in the json (it maps to `Window | Taskbar`) <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #6700 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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. * [x] I work here <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed GIF in Teams
2021-05-25 00:51:03 +02:00
"description": "Controls what happens when the application emits a BEL character. When set to \"all\", the Terminal will play a sound, flash the taskbar icon (if the terminal window is not in focus) and flash the window. An array of specific behaviors can also be used. Supported array values include `audible`, `window` and `taskbar`. When set to \"none\", nothing will happen.",
Add a setting to configure the audible bell (#7793) Adds a new setting, `bellStyle`, to be able to disable the audible bell added in #7679. Currently, this setting accepts two values: * `audible`: play a noise on a bell * `none`: Don't play a noise. In the future, we can add a `"bellStyle": "visible"` for flashing the Terminal instead of making a noise on bell. ## Validation Steps Performed Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of triggering a bell. I set the setting to `none`, and presto, the bell stopped. Closes #2360
2020-10-16 00:27:27 +02:00
"$ref": "#/definitions/BellStyle"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"closeOnExit": {
"default": "graceful",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"oneOf": [
{
"enum": [
"never",
"graceful",
"always"
],
"type": "string"
},
{
"type": "boolean"
}
]
},
"colorScheme": {
"default": "Campbell",
"description": "Name of the terminal color scheme to use. Color schemes are defined under \"schemes\".",
"type": "string"
},
"commandline": {
"description": "Executable used in the profile.",
"type": "string"
},
"cursorColor": {
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"oneOf": [
{ "$ref": "#/definitions/Color" },
{"type": "null"}
],
"description": "Sets the color of the cursor. Overrides the cursor color from the color scheme. Uses hex color format: \"#rrggbb\"."
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"cursorHeight": {
[Settings UI] Represent Cursor Height as a slider (#9386) Change the vintage cursor height number box to a slider. ## References Related: #9370 ## PR Checklist * [x] Closes #9377 * [x] zadjii-msft edit: Now _this one_ closes #9175 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. * [ ] ## Detailed Description of the Pull Request / Additional comments It seems like the cursor height couldn't be lower than 25 percent regardless of the given value, so I've changed the `MinCursorHeightPercent` in CustomTextRenderer header file. ## Validation Steps Performed Manual validation ![CursorHeightSlider](https://user-images.githubusercontent.com/39456018/110041939-bf076080-7d66-11eb-8d58-ba9a84922803.gif)
2021-03-09 18:13:32 +01:00
"description": "Sets the percentage height of the cursor starting from the bottom. Only works when cursorShape is set to \"vintage\". Accepts values from 1-100.",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"maximum": 100,
[Settings UI] Represent Cursor Height as a slider (#9386) Change the vintage cursor height number box to a slider. ## References Related: #9370 ## PR Checklist * [x] Closes #9377 * [x] zadjii-msft edit: Now _this one_ closes #9175 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. * [ ] ## Detailed Description of the Pull Request / Additional comments It seems like the cursor height couldn't be lower than 25 percent regardless of the given value, so I've changed the `MinCursorHeightPercent` in CustomTextRenderer header file. ## Validation Steps Performed Manual validation ![CursorHeightSlider](https://user-images.githubusercontent.com/39456018/110041939-bf076080-7d66-11eb-8d58-ba9a84922803.gif)
2021-03-09 18:13:32 +01:00
"minimum": 1,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"type": ["integer","null"],
"default": 25
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"cursorShape": {
"default": "bar",
Add `doubleUnderscore` cursor style (#7827) Adds a new cursor type "doubleUnderscore". Tested manually. Closes #6786
2021-01-20 20:36:07 +01:00
"description": "Sets the shape of the cursor. Possible values:\n -\"bar\" ( ┃, default )\n -\"doubleUnderscore\" ( ‗ )\n -\"emptyBox\" ( ▯ )\n -\"filledBox\" ( █ )\n -\"underscore\" ( ▁ )\n -\"vintage\" ( ▃ )",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"enum": [
"bar",
Add `doubleUnderscore` cursor style (#7827) Adds a new cursor type "doubleUnderscore". Tested manually. Closes #6786
2021-01-20 20:36:07 +01:00
"doubleUnderscore",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"emptyBox",
"filledBox",
"underscore",
"vintage"
],
"type": "string"
},
Add some issue numbers for TODOs from #3468 (#3931) ## Summary of the Pull Request The original PR had a few TODOs in it without issue numbers. IMO, this wasn't important enough to block the PR over. _Also I'm impatient and wanted that setting_. After I merged the PR I created the issues and added the numbers myself. ## References ## PR Checklist * [x] Closes nothing, this just adds a couple TODOs * [x] I work here * [x] this _really_ doesn't need tests * [x] This _is_ a docs update
2019-12-12 19:55:26 +01:00
"experimental.retroTerminalEffect": {
"description": "When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
"type": "boolean"
},
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
"experimental.pixelShaderPath": {
"description": "Use to set a path to a pixel shader to use with the Terminal. Overrides `experimental.retroTerminalEffect`. This is an experimental feature, and its continued existence is not guaranteed.",
"type": "string"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"fontFace": {
Include Cascadia Mono in-package, switch to it by default (#5505) It was brought to our attention that shipping a font with ligatures as our default font could be an accessibility issue for the visually-impaired. Unfortunately, we don't have a renderer setting to disable ligatures (#759). Fortunately however, we DO already have a version of Cascadia that doesn't have ligatures. If we ship that and set it as our default font, we'll at least let people _opt_ to have ligatures enabled by switching from `Cascadia Mono` to `Cascadia Code`. ## PR Checklist * [x] Closes internal discussion * [x] CLA signed * [ ] Tests added/passed * [x] Requires documentation to be updated * [x] I've discussed this with core contributors already.
2020-04-24 00:12:36 +02:00
"default": "Cascadia Mono",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"description": "Name of the font face used in the profile.",
"type": "string"
},
"fontSize": {
"default": 12,
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Size of the font in points.",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"minimum": 1,
"type": "integer"
},
Add font weight options (#6048) ## Summary of the Pull Request Adds the ability to specify the font weight in the profiles, right next to the size and the font face. ## PR Checklist * [x] Closes #1751 * [x] I work here. * [x] Tested manually, see below. * [x] Added documentation to the schema * [x] Requires docs.microsoft.com update, filed as https://github.com/MicrosoftDocs/terminal/issues/26 * [x] I'm a core contributor. ## Detailed Description of the Pull Request / Additional comments - Weights can be specified according to the OpenType specification values. We accept either the friendly name or the numerical value that applies to each weight. - Weights are carried through per-profile and sent into the renderer. - Weights are carried through to the TSF/IME overlay. - The names are restricted to the set seen at https://docs.microsoft.com/en-us/uwp/api/windows.ui.text.fontweights. - There are alternate names at https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ne-dwrite-dwrite_font_weight for the same values (ultra-black is just an alias for extra-black at 950). ## Validation Steps Performed - Cascadia Code normal ![image](https://user-images.githubusercontent.com/18221333/82480181-46117380-9a88-11ea-9436-a5fe4ccd4350.png) - Cascadia Code bold ![image](https://user-images.githubusercontent.com/18221333/82480202-4f9adb80-9a88-11ea-9e27-a113b41387f5.png) - Segoe UI Semilight ![image](https://user-images.githubusercontent.com/18221333/82480306-73f6b800-9a88-11ea-93f7-d773ab7ccce8.png) - Segoe UI Black ![image](https://user-images.githubusercontent.com/18221333/82480401-9688d100-9a88-11ea-957c-0c8e03a8cc29.png) - Segoe UI 900 (value for Black) ![image](https://user-images.githubusercontent.com/18221333/82480774-26c71600-9a89-11ea-8cf6-aaeab1fd0747.png)
2020-05-20 22:17:17 +02:00
"fontWeight": {
"default": "normal",
Fix deserialization failure message of combined types (#8558) Closes #7690
2020-12-15 20:33:52 +01:00
"description": "Sets the weight (lightness or heaviness of the strokes) for the given font. Possible values:\n -\"thin\"\n -\"extra-light\"\n -\"light\"\n -\"semi-light\"\n -\"normal\" (default)\n -\"medium\"\n -\"semi-bold\"\n -\"bold\"\n -\"extra-bold\"\n -\"black\"\n -\"extra-black\"\n or the corresponding numeric representation of OpenType font weight.",
Fix syntax errors in font weight options (#6248)
2020-05-29 07:28:13 +02:00
"oneOf": [
Add font weight options (#6048) ## Summary of the Pull Request Adds the ability to specify the font weight in the profiles, right next to the size and the font face. ## PR Checklist * [x] Closes #1751 * [x] I work here. * [x] Tested manually, see below. * [x] Added documentation to the schema * [x] Requires docs.microsoft.com update, filed as https://github.com/MicrosoftDocs/terminal/issues/26 * [x] I'm a core contributor. ## Detailed Description of the Pull Request / Additional comments - Weights can be specified according to the OpenType specification values. We accept either the friendly name or the numerical value that applies to each weight. - Weights are carried through per-profile and sent into the renderer. - Weights are carried through to the TSF/IME overlay. - The names are restricted to the set seen at https://docs.microsoft.com/en-us/uwp/api/windows.ui.text.fontweights. - There are alternate names at https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ne-dwrite-dwrite_font_weight for the same values (ultra-black is just an alias for extra-black at 950). ## Validation Steps Performed - Cascadia Code normal ![image](https://user-images.githubusercontent.com/18221333/82480181-46117380-9a88-11ea-9436-a5fe4ccd4350.png) - Cascadia Code bold ![image](https://user-images.githubusercontent.com/18221333/82480202-4f9adb80-9a88-11ea-9e27-a113b41387f5.png) - Segoe UI Semilight ![image](https://user-images.githubusercontent.com/18221333/82480306-73f6b800-9a88-11ea-93f7-d773ab7ccce8.png) - Segoe UI Black ![image](https://user-images.githubusercontent.com/18221333/82480401-9688d100-9a88-11ea-957c-0c8e03a8cc29.png) - Segoe UI 900 (value for Black) ![image](https://user-images.githubusercontent.com/18221333/82480774-26c71600-9a89-11ea-8cf6-aaeab1fd0747.png)
2020-05-20 22:17:17 +02:00
{
"enum": [
"thin",
"extra-light",
"light",
"semi-light",
"normal",
"medium",
"semi-bold",
"bold",
"extra-bold",
"black",
"extra-black"
],
"type": "string"
},
{
"maximum": 990,
"minimum": 100,
"type": "integer"
}
Fix syntax errors in font weight options (#6248)
2020-05-29 07:28:13 +02:00
]
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"foreground": {
"$ref": "#/definitions/Color",
schema: add default colors for foreground and background (#4468) Added `#000000` as default for `background` and `#FFFFFF` as default for `foreground` in JSON schema. ## PR Checklist * [x] Closes #3466
2020-02-05 18:24:10 +01:00
"default": "#cccccc",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets the text color. Overrides \"foreground\" from the color scheme. Uses hex color format: \"#rrggbb\".",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"type": ["string", "null"]
},
"guid": {
"$ref": "#/definitions/ProfileGuid",
"description": "Unique identifier of the profile. Written in registry format: \"{00000000-0000-0000-0000-000000000000}\"."
},
"hidden": {
"default": false,
Fix a bunch of spelling errors across the project (#4295) Generated by https://github.com/jsoref/spelling `f`; to maintain your repo, please consider `fchurn` I generally try to ignore upstream bits. I've accidentally included some items from the `deps/` directory. I expect someone will give me a list of items to drop, I'm happy to drop whole files/directories, or to split the PR into multiple items (E.g. comments/locals/public). Closes #4294
2020-02-10 21:40:01 +01:00
"description": "If set to true, the profile will not appear in the list of profiles. This can be used to hide default profiles and dynamically generated profiles, while leaving them in your settings file.",
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"type": "boolean"
},
"historySize": {
"default": 9001,
"description": "The number of lines above the ones displayed in the window you can scroll back to.",
"minimum": -1,
"type": "integer"
},
Introduce IconConverter (#7830) ## Summary of the Pull Request Introduce the `IconPathConverter` to `TerminalApp`. `Command` and `Profile` now both return the unexpanded icon path. `IconPathConverter` is responsible for expanding the icon path and retrieving the appropriate icon source. This also removes `Profile`'s expanded icon path and uses the `IconPathConverter` when necessary. This allows users to set profile icons to emoji as well. However, emoji do not appear in the jumplist. ## References Based on #7667 ## PR Checklist * [X] Closes #7784 * [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. ## Validation Steps Performed Deploy succeeded.
2020-10-08 20:29:04 +02:00
"icon":{ "$ref": "#/definitions/Icon" },
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"name": {
"description": "Name of the profile. Displays in the dropdown menu.",
"minLength": 1,
"type": "string"
},
"padding": {
"default": "8, 8, 8, 8",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"description": "Sets the padding around the text within the window. Can have three different formats:\n -\"#\" sets the same padding for all sides \n -\"#, #\" sets the same padding for left-right and top-bottom\n -\"#, #, #, #\" sets the padding individually for left, top, right, and bottom.",
Allow profile.padding to be an int (or any other type :|) (#7235) ## Summary of the Pull Request We're expecting that people have treated `padding` as an integer, and the type-based converter is too strict for that. This PR widens its scope and explicitly allows for it in the schema. ## PR Checklist * [x] Closes #7234
2020-08-10 21:48:33 +02:00
"oneOf": [
{
"pattern": "^-?[0-9]+(\\.[0-9]+)?( *, *-?[0-9]+(\\.[0-9]+)?|( *, *-?[0-9]+(\\.[0-9]+)?){3})?$",
"type": "string"
},
{
"type": "integer"
}
]
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"scrollbarState": {
"default": "visible",
"description": "Defines the visibility of the scrollbar.",
"enum": [
"visible",
"hidden"
],
"type": "string"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"selectionBackground": {
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"oneOf": [
{"$ref": "#/definitions/Color"},
{ "type": "null" }
],
"description": "Sets the background color of selected text. Overrides selectionBackground set in the color scheme. Uses hex color format: \"#rrggbb\"."
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"snapOnInput": {
"default": true,
"description": "When set to true, the window will scroll to the command input line when typing. When set to false, the window will not scroll when you start typing.",
"type": "boolean"
},
Allow Ctrl+Alt <> AltGr aliasing to be disabled (#6212) ## Summary of the Pull Request Some people wish to use Ctrl+Alt combinations without Windows treating those as an alias for AltGr combinations. This PR adds a new `altGrAliasing` setting allowing one to control this behavior. ## PR Checklist * [x] Closes #6211 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Manual testing * [x] Requires documentation to be updated: https://github.com/MicrosoftDocs/terminal/issues/50 * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx ## Validation Steps Performed * Choose a German keyboard layout * Using `showkey -a` ensured that both `Ctrl+Alt+Q/E` and `AltGr+Q/E` produce `@/€` * Added `"altGrAliasing": false` to the WSL profile * Using `showkey -a` ensured `Ctrl+Alt+Q/E` now produces `^[^Q/E` while `AltGr+Q/E` continues to produce `@/€`
2020-06-05 18:11:41 +02:00
"altGrAliasing": {
"default": true,
"description": "By default Windows treats Ctrl+Alt as an alias for AltGr. When altGrAliasing is set to false, this behavior will be disabled.",
"type": "boolean"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"source": {
"description": "Stores the name of the profile generator that originated this profile.",
Add default values to defaults.json (#5231) ## Summary of the Pull Request This updates defaults.json to include the default values for all global and profile settings. Most default keybinding args are added too. This also updates a few outdated items found in the docs. ## PR Checklist * [X] Closes #5189 ## Validation Steps Performed After making the changes, I made sure all of the settings are deserialized by debugging and stepping through the `LayerJson` code. - [X] Global Settings I was mainly looking for two things: - the key/value pair is found and read - the value did not change before/after the pair was read
2020-04-10 01:13:57 +02:00
"type": ["string", "null"]
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"startingDirectory": {
"description": "The directory the shell starts in when it is loaded.",
"type": "string"
},
"suppressApplicationTitle": {
Added initialPosition and launchMode to settings schema (#4222) * added initialPosition and launchMode to schema * regex works * fixed regex bug * remove lookaround * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * update description in settingsschema.md * edit descriptions to have code markings * remove code backticks from schema Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
2020-01-28 20:44:47 +01:00
"description": "When set to true, tabTitle overrides the default title of the tab and any title change messages from the application will be suppressed. When set to false, tabTitle behaves as normal.",
doc: clean up the schema (#5304) ## Summary of the Pull Request This PR performs a number of miscellaneous clean-up tasks on our schema: - [X] allow null for some settings - [X] update some default values to be more useful - [X] consistently use " instead of ' - [X] remove colorTable - [X] provide missing description for `backgroundImageOpacity` - [X] update cursorShape to have options match order displayed in vs code - [X] if a setting has multiple options, provide a list of those options with a short description on each - this one I only did a few times - [X] remove a little bit of ambiguity on some descriptions ## PR Checklist Closes #5279 ## Detailed Description of the Pull Request / Additional comments Validation was performed for... - [X] Global Settings - [X] Profile Settings - [x] Keybinding Actions ## Validation Steps Performed I linked VS Code to the my version of the schema. Defined all settings from scratch in settings.json. Anytime I found something off, I updated the schema and saw if it looks right.
2020-04-28 21:14:30 +02:00
"type": "boolean",
"default": false
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
doc: Add tabColor to JSON schema (#9843)
2021-04-15 19:32:18 +02:00
"tabColor": {
"$ref": "#/definitions/Color",
"description": "Sets the color of the profile's tab. Using the tab color picker will override this color.",
"type": ["string", "null"]
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"tabTitle": {
"description": "If set, will replace the name as the title to pass to the shell on startup. Some shells (like bash) may choose to ignore this initial value, while others (cmd, powershell) may use this value over the lifetime of the application.",
Add default values to defaults.json (#5231) ## Summary of the Pull Request This updates defaults.json to include the default values for all global and profile settings. Most default keybinding args are added too. This also updates a few outdated items found in the docs. ## PR Checklist * [X] Closes #5189 ## Validation Steps Performed After making the changes, I made sure all of the settings are deserialized by debugging and stepping through the `LayerJson` code. - [X] Global Settings I was mainly looking for two things: - the key/value pair is found and read - the value did not change before/after the pair was read
2020-04-10 01:13:57 +02:00
"type": ["string", "null"]
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
"useAcrylic": {
"default": false,
"description": "When set to true, the window will have an acrylic background. When set to false, the window will have a plain, untextured background.",
"type": "boolean"
}
},
"type": "object"
},
"ProfileList": {
"description": "A list of profiles and the properties specific to each.",
"items": {
"$ref": "#/definitions/Profile",
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"required": [
"guid",
"name"
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
]
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
},
"type": "array"
},
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"ProfilesObject": {
"description": "A list of profiles and default settings that apply to all of them",
"properties": {
"list": {
"$ref": "#/definitions/ProfileList"
},
"defaults": {
"description": "The default settings that apply to every profile.",
"$ref": "#/definitions/Profile"
}
Fix matches of multiple schemas on "profiles" (#4045) <!-- 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 Adds proper `type` for `ProfilesObject` definition to avoid warnings about matches of multiple schemas. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References Original issue: #3909 Related PR: #3892 Relates VSCode issue: https://github.com/microsoft/vscode/issues/86738 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [X] Closes #3909 * [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] No new tests ~Tests added/passed~ * [ ] No docs update needed ~Requires documentation to be updated~ * [X] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #3909 (marked as help wanted) <!-- 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 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. Download `doc/cascadia/profiles.schema.json` locally 1. Open `profiles.json` from WT in VSCode 1. Replace `$schema` value with path to local copy (verified that all errors are still in place and validations works as before) 1. Update it with `type` on `ProfilesObject` 1. Check that `Matches multiple schemas when only one must validate` warning is fixed
2019-12-30 15:15:50 +01:00
},
"type": "object"
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"SchemeList": {
"description": "Properties are specific to each color scheme. ColorTool is a great tool you can use to create and explore new color schemes. All colors use hex color format.",
"items": {
"additionalProperties": false,
"properties": {
"name": {
"description": "Name of the color scheme.",
"minLength": 1,
"type": "string"
},
"background": {
"$ref": "#/definitions/Color",
"description": "Sets the background color of the color scheme."
},
"black": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI black."
},
"blue": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI blue."
},
"brightBlack": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright black."
},
"brightBlue": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright blue."
},
"brightCyan": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright cyan."
},
"brightGreen": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright green."
},
"brightPurple": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright purple."
},
"brightRed": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright red."
},
"brightWhite": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright white."
},
"brightYellow": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI bright yellow."
},
Add cursorColor to color scheme (#4651) Add the option to set the cursor color as part of the color scheme. This is very useful for light themes, where the cursor disappears unless its color is set in the profile. Related to issue #764, but doesn't fully resolve it. ## Validation I tested this manually by creating a light color scheme, setting the cursor color to black and setting the profile color scheme to the newly created color scheme. I validated the cursor is black, then set the cursor color in the profile (to red) and saw it trumps the cursor color from the color scheme.
2020-03-17 21:11:03 +01:00
"cursorColor": {
"$ref": "#/definitions/Color",
"default": "#FFFFFF",
"description": "Sets the cursor color of the color scheme."
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"cyan": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI cyan."
},
"foreground": {
"$ref": "#/definitions/Color",
"description": "Sets the foreground color of the color scheme."
},
"green": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI green."
},
"purple": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI purple."
},
"red": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI red."
},
Add Selection Background Color as a setting to Profiles and Col… (#3471) <!-- 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
2019-11-13 19:17:39 +01:00
"selectionBackground": {
"$ref": "#/definitions/Color",
"description": "Sets the selection background color of the color scheme."
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"white": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI white."
},
"yellow": {
"$ref": "#/definitions/Color",
"description": "Sets the color used as ANSI yellow."
}
},
"type": "object"
},
"type": "array"
}
},
doc: remove "globals" from schema (#5229) ## Summary of the Pull Request Minor cleanup on the schema. Globals isn't accepted anymore, so the schema should not help you autocomplete anymore. ## Validation Steps Performed Imported the new schema. You do _not_ get a warning when globals is in. But, the schema won't suggest things when inside globals. It's just treated as an unknown item. However, "defaultProfile" is still required (more of a sanity test)
2020-04-03 22:58:56 +02:00
"allOf": [
{ "$ref": "#/definitions/Globals" },
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
{
doc: remove "globals" from schema (#5229) ## Summary of the Pull Request Minor cleanup on the schema. Globals isn't accepted anymore, so the schema should not help you autocomplete anymore. ## Validation Steps Performed Imported the new schema. You do _not_ get a warning when globals is in. But, the schema won't suggest things when inside globals. It's just treated as an unknown item. However, "defaultProfile" is still required (more of a sanity test)
2020-04-03 22:58:56 +02:00
"additionalItems": true,
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"properties": {
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
"profiles": {
"oneOf": [
doc: remove "globals" from schema (#5229) ## Summary of the Pull Request Minor cleanup on the schema. Globals isn't accepted anymore, so the schema should not help you autocomplete anymore. ## Validation Steps Performed Imported the new schema. You do _not_ get a warning when globals is in. But, the schema won't suggest things when inside globals. It's just treated as an unknown item. However, "defaultProfile" is still required (more of a sanity test)
2020-04-03 22:58:56 +02:00
{ "$ref": "#/definitions/ProfileList" },
{ "$ref": "#/definitions/ProfilesObject" }
Add support for "User Default" settings II (#3892) ## Summary of the Pull Request _This is attempt 2 at this feature_. The original PR can be found at #3369. These are settings that apply to _every_ profile, before user customizations. If the user wants to add "default profile settings", they can make the `"profiles"` property an _object_, instead of a list, and add `"defaults"` key underneath that object. The users list of profiles should then be under the `list` property of the `profiles` object. ## References #2515, #2603, #3369, #3569 ## PR Checklist * [x] Closes #2325 * [x] I work here * [x] Tests added/passed * [x] schema, docs updated ## Detailed Description of the Pull Request / Additional comments ~~Discussion in #2325 itself serves as the "spec" for this task. I thought we'd need more discussion on the topic, but it ended up being pretty straightforward.~~ I should not have said that in the original PR. We've had a better spec review now that I think we're happier with. ## Validation Steps Performed _ran the tests_
2019-12-11 01:39:29 +01:00
]
},
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
"schemes": { "$ref": "#/definitions/SchemeList" }
},
"required": [
"profiles",
"schemes",
doc: remove "globals" from schema (#5229) ## Summary of the Pull Request Minor cleanup on the schema. Globals isn't accepted anymore, so the schema should not help you autocomplete anymore. ## Validation Steps Performed Imported the new schema. You do _not_ get a warning when globals is in. But, the schema won't suggest things when inside globals. It's just treated as an unknown item. However, "defaultProfile" is still required (more of a sanity test)
2020-04-03 22:58:56 +02:00
"defaultProfile"
Add profiles.json schema to doc folder (#2704) * added profiles.json schema to doc folder * addressed most comments * addressed most comments * fixed keybindings regex and color table * updated schema and settings documentation * Delete dlfk * Update doc/cascadia/SettingsSchema.md Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * Update doc/cascadia/profiles.schema.json Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com> * updated schema
2019-09-27 22:38:49 +02:00
]
}
]
Enable fullscreen mode (#3408) ## 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
2019-11-05 20:40:29 +01:00
}
Reference in a new issue Copy permalink