starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity
Files
1282d56a33bb15206fcb3a09d3bea0a33036f2cd
terminal/src/cascadia/TerminalSettingsModel/defaults.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

806 lines
36 KiB
JSON
Raw Normal View History

Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
// THIS IS AN AUTO-GENERATED FILE! Changes to this file will be ignored.
{
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
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-09 16:13:57 -07:00
// Launch Settings
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"initialCols": 120,
"initialRows": 30,
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-09 16:13:57 -07:00
"launchMode": "default",
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 16:02:18 -05:00
"alwaysOnTop": false,
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-09 16:13:57 -07:00
// Selection
"copyOnSelect": false,
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-20 16:49:12 -07:00
"copyFormatting": true,
Change trimBlockSelection default to true (#12737) Changed the default value of `"trimBlockSelection"` to `true`. * [x] Closes #12536 ## Validation Steps Performed Without editing the setting, the toggle switch was enabled by default in the settings UI.
2022-03-24 10:54:12 -07:00
"trimBlockSelection": true,
Trim trailing whitespace option (#11473) <!-- 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 Opt in setting to trim trailing white space when pasting a text into the terminal <!-- 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 #9400 * [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. * [ ] 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 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Manually testing to paste text with and without trailing white spaces, with and without the option activated
2021-10-28 17:38:23 +02:00
"trimPaste": true,
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-09 16:13:57 -07:00
"wordDelimiters": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502",
// Tab UI
"alwaysShowTabs": true,
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"showTabsInTitlebar": true,
"showTerminalTitleInTitlebar": true,
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-09 16:16:54 -08:00
"tabWidthMode": "equal",
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-19 17:57:35 -06:00
"tabSwitcherMode": "inOrder",
Add shield to tab row when elevated (#11224) ## Summary of the Pull Request Adds a visible indicator that a Terminal window is elevated. This icon can be disabled with `"showAdminShield" false` in the global settings. ## References * spec'd in #8455 * Also in https://github.com/microsoft/terminal/projects/5 * big picture: #5000 ## PR Checklist * [x] Closes #1939 * [x] I work here * [n/a] Tests added/passed * [ ] Requires documentation to be updated - yea probably ## Validation Steps Performed ![image](https://user-images.githubusercontent.com/18356694/133293009-4215e319-fbf9-4ca8-8af5-afe2fa8bb62d.png) ![image](https://user-images.githubusercontent.com/18356694/133292970-90cb17fd-16c7-429a-a25f-8457850eb278.png)
2021-09-23 12:44:20 -05:00
"showAdminShield": true,
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-09 16:13:57 -07:00
// Miscellaneous
Replace `confirmCloseAllTabs` with `confirmOnClose` (#20055) ## Summary of the Pull Request Replaces the `warning.confirmCloseAllTabs` setting with a `warning.confirmOnClose` enum setting that accepts the following: - `never`: don't present a warning dialog when closing a session - `automatic`: present a warning dialog when closing multiple tabs/panes at once - `always`: present a warning dialog when closing any session The confirmation dialog contains a "don't ask me again" checkbox. When checked, we update the setting to `never`. This setting also affects the following actions: - "close other tabs" - "close tabs after" - "close other panes" - "quit" The appropriate confirmation dialog is shown in these scenarios. We also present an aggregate dialog instead of prompting the user once per tab/pane. If there are no other tabs/panes, we don't present a dialog and treat the key binding as unhandled (passing the key through). ## References and Relevant Issues Iteration of #19944 ## Validation Steps Performed - closing a tab: - ✅ 1 pane --> no dialog - ✅ 2 panes --> dialog - ✅ action and middle clicking tab trigger same flow - close all other tabs: - ✅ no other tabs --> no dialog - ✅ 1 other tab --> dialog - close all other panes: - ✅ 1 pane --> no dialog - ✅ 2 panes --> dialog - close all tabs after the current tab: - ✅ no tabs after --> no dialog (even if tabs before) - ✅ 1 tab after --> dialog - close window: - ✅ 2 tabs --> dialog - ✅ 2 panes --> dialog - ✅ 1 tab with one pane --> no dialog - Quit the Terminal: - ✅ 3 windows --> dialog - ✅1 window --> dialog - ✅ "don't ask me again" checkbox checked --> setting changed to "never" - ✅ "never" --> no dialog for scenarios above - ✅ "always" --> dialog always appears, even when closing a single pane ## PR Checklist Closes #5301 Closes #6641 "don't ask me again" checkbox is also mentioned in #10000 Co-authored by @zadjii-msft
2026-05-04 10:43:34 -07:00
"warning.confirmOnClose": "automatic",
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
"theme": "dark",
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-09 16:13:57 -07:00
"snapToGridOnResize": true,
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-09 18:06:40 -05:00
"disableAnimations": false,
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 20:30:11 +02:00
"startupActions": "",
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-10 00:18:20 +02:00
"focusFollowMouse": false,
Replace TrayIcon with NotificationIcon (#11219) This PR simply replaces all uses of "TrayIcon" and "Tray" with "NotificationIcon" and "NotificationArea" to be more accurate. Originally I kinda wanted to only replace all occurrences of it in settings and user facing things, but I figured I might as well make it consistent throughout all of our code.
2021-09-14 09:12:40 -07:00
"minimizeToNotificationArea": false,
"alwaysShowNotificationIcon": false,
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"profiles":
[
{
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"name": "Windows PowerShell",
Hardcode the paths to Windows PowerShell and CMD (#6684) Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228 (powershell was not found) Refs #4682, Fixes #6082 (stray powershell.exe)
2020-06-26 10:33:38 -07:00
"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
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-09 16:13:57 -07:00
"icon": "ms-appx:///ProfileIcons/{61c54bbd-c2c6-5271-96e7-009a87ff44bf}.png",
Change Windows Powershell default scheme to Campbell (#5432) The "Campbell Powershell" color scheme does not have a high enough color contrast ratio. Campbell does, so we're changing it there. Closes (only upon validation) #5393.
2020-04-21 10:19:54 -07:00
"colorScheme": "Campbell",
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-09 16:13:57 -07:00
"antialiasingMode": "grayscale",
[DxD] Add 'Automatic' as a mode for CloseOnExit (#13560) ## Summary of the Pull Request Adds a new mode to `CloseOnExit`: `Automatic`. In this mode, if a process handed off by defterm terminates for whatever reason, we always close (i.e. we treat the mode as `Always`), but for processes launched by Terminal we terminate as with the `Graceful` behaviour. ## PR Checklist * [x] Closes #13325 * [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'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 ## Detailed Description of the Pull Request / Additional comments - Adds a new enum value to `CloseOnExit` - Adds a new function to `Pane`: `FinalizeConfigurationGivenDefault`: this is a function that should be called when the pane is created via default terminal handoff, and can contain any special configurations we should set given that the pane was created via handoff ## Validation Steps Performed
2022-08-01 14:11:18 -07:00
"closeOnExit": "automatic",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"cursorShape": "bar",
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-23 15:12:36 -07:00
"fontFace": "Cascadia Mono",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"fontSize": 12,
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-09 16:13:57 -07:00
"hidden": false,
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"historySize": 9001,
"padding": "8, 8, 8, 8",
"snapOnInput": true,
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": true,
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-09 16:13:57 -07:00
"startingDirectory": "%USERPROFILE%",
"useAcrylic": false
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
},
{
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
Localize the profile name for cmd, change it to Command Prompt (#5287) This commit introduces another template replacement for the user's default settings, COMMAND_PROMPT_LOCALIZED_NAME, which will be replaced with the contents of the CommandPromptDisplayName resource. By default, that will be "Command Prompt." This name change will apply only for new users, and only on first launch. Changes in the system locale after first launch will not impact the name of the profile. If the user _removes_ the name from their command prompt profile, its name will revert irrecoverably to "Command Prompt". They will not be given a chance to regenerate a localized name. Fixes #4476.
2020-04-08 13:41:58 -07:00
"name": "Command Prompt",
Hardcode the paths to Windows PowerShell and CMD (#6684) Occasionally, we get users with corrupt PATH environment variables: they can't lauch PowerShell, because for some reason it's dropped off their PATH. We also get users who have stray applications named `powershell.exe` just lying around in random system directories. We can combat both of these issues by simply hardcoding where we expect PowerShell and CMD to live. %SystemRoot% was chosen over %WINDIR% because apparently (according to Stack Overflow), SystemPath is read-only and WINDIR isn't. Refs #6039, #4390, #4228 (powershell was not found) Refs #4682, Fixes #6082 (stray powershell.exe)
2020-06-26 10:33:38 -07:00
"commandline": "%SystemRoot%\\System32\\cmd.exe",
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-09 16:13:57 -07:00
"icon": "ms-appx:///ProfileIcons/{0caa0dad-35be-5f56-a8ff-afceeeaa6101}.png",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"colorScheme": "Campbell",
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-09 16:13:57 -07:00
"antialiasingMode": "grayscale",
[DxD] Add 'Automatic' as a mode for CloseOnExit (#13560) ## Summary of the Pull Request Adds a new mode to `CloseOnExit`: `Automatic`. In this mode, if a process handed off by defterm terminates for whatever reason, we always close (i.e. we treat the mode as `Always`), but for processes launched by Terminal we terminate as with the `Graceful` behaviour. ## PR Checklist * [x] Closes #13325 * [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'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 ## Detailed Description of the Pull Request / Additional comments - Adds a new enum value to `CloseOnExit` - Adds a new function to `Pane`: `FinalizeConfigurationGivenDefault`: this is a function that should be called when the pane is created via default terminal handoff, and can contain any special configurations we should set given that the pane was created via handoff ## Validation Steps Performed
2022-08-01 14:11:18 -07:00
"closeOnExit": "automatic",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"cursorShape": "bar",
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-23 15:12:36 -07:00
"fontFace": "Cascadia Mono",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"fontSize": 12,
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-09 16:13:57 -07:00
"hidden": false,
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"historySize": 9001,
"padding": "8, 8, 8, 8",
"snapOnInput": true,
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": true,
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-09 16:13:57 -07:00
"startingDirectory": "%USERPROFILE%",
"useAcrylic": false
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
}
],
"schemes":
[
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-09 16:13:57 -07:00
// A profile can override the following color scheme values:
// - "foreground"
// - "background"
// - "cursorColor"
Add CAM16 based color scheme "Dimidium" (#18563) Okay, here is a challenge for the default color scheme. This PR adds the [Dimidium] color scheme. Refs #17818 Refs #18502 I adjusted colors using CAM16. I prioritized lightness so that all colors (especially blue) has appropriate contrast with the background. [Brief information about the Dimidium color scheme](https://github.com/dofuuz/dimidium/blob/main/README.md) [Detailed explanation on crafting the color scheme with CAM16](https://dofuuz.github.io/color/2024/03/17/dimidium-terminal-color-scheme.html) [Dimidium]: https://github.com/dofuuz/dimidium
2025-02-21 06:16:40 +09:00
{
"name": "Dimidium",
"background": "#141414",
"foreground": "#BAB7B6",
"cursorColor": "#37E57B",
Adjust "Dimidium" color scheme (#19303) - Add Selection BG color - Make Bright white brighter ## Summary of the Pull Request Final tune for Dimidium color scheme before its release. ## References and Relevant Issues #18563 ## Detailed Description of the Pull Request / Additional comments I made little change to Dimidium color scheme. <img width="640" height="174" alt="cmp-lightness1c" src="https://github.com/user-attachments/assets/2e4aa6ca-5864-4901-b323-2e2bb2bf00e8" /> ![preview-terminal](https://github.com/user-attachments/assets/8a53c54d-942a-44a2-9ee7-9ff8a6d2dfab) <img width="584" height="207" alt="image" src="https://github.com/user-attachments/assets/b70b0759-7961-4f8f-aaa7-762fc48e425b" /> - Adjusted "Bright white" slightly brighter, hoping it can be distinguished better from "White". - Defined "Selection Background" color. This will be the final tune for Dimidum color scheme.
2025-09-04 01:04:28 +09:00
"selectionBackground": "#8DB8E5",
Add CAM16 based color scheme "Dimidium" (#18563) Okay, here is a challenge for the default color scheme. This PR adds the [Dimidium] color scheme. Refs #17818 Refs #18502 I adjusted colors using CAM16. I prioritized lightness so that all colors (especially blue) has appropriate contrast with the background. [Brief information about the Dimidium color scheme](https://github.com/dofuuz/dimidium/blob/main/README.md) [Detailed explanation on crafting the color scheme with CAM16](https://dofuuz.github.io/color/2024/03/17/dimidium-terminal-color-scheme.html) [Dimidium]: https://github.com/dofuuz/dimidium
2025-02-21 06:16:40 +09:00
"black": "#000000",
"red": "#CF494C",
"green": "#60B442",
"yellow": "#DB9C11",
"blue": "#0575D8",
"purple": "#AF5ED2",
"cyan": "#1DB6BB",
"white": "#BAB7B6",
"brightBlack": "#817E7E",
"brightRed": "#FF643B",
"brightGreen": "#37E57B",
"brightYellow": "#FCCD1A",
"brightBlue": "#688DFD",
"brightPurple": "#ED6FE9",
"brightCyan": "#32E0FB",
Adjust "Dimidium" color scheme (#19303) - Add Selection BG color - Make Bright white brighter ## Summary of the Pull Request Final tune for Dimidium color scheme before its release. ## References and Relevant Issues #18563 ## Detailed Description of the Pull Request / Additional comments I made little change to Dimidium color scheme. <img width="640" height="174" alt="cmp-lightness1c" src="https://github.com/user-attachments/assets/2e4aa6ca-5864-4901-b323-2e2bb2bf00e8" /> ![preview-terminal](https://github.com/user-attachments/assets/8a53c54d-942a-44a2-9ee7-9ff8a6d2dfab) <img width="584" height="207" alt="image" src="https://github.com/user-attachments/assets/b70b0759-7961-4f8f-aaa7-762fc48e425b" /> - Adjusted "Bright white" slightly brighter, hoping it can be distinguished better from "White". - Defined "Selection Background" color. This will be the final tune for Dimidum color scheme.
2025-09-04 01:04:28 +09:00
"brightWhite": "#DEE3E4"
Add CAM16 based color scheme "Dimidium" (#18563) Okay, here is a challenge for the default color scheme. This PR adds the [Dimidium] color scheme. Refs #17818 Refs #18502 I adjusted colors using CAM16. I prioritized lightness so that all colors (especially blue) has appropriate contrast with the background. [Brief information about the Dimidium color scheme](https://github.com/dofuuz/dimidium/blob/main/README.md) [Detailed explanation on crafting the color scheme with CAM16](https://dofuuz.github.io/color/2024/03/17/dimidium-terminal-color-scheme.html) [Dimidium]: https://github.com/dofuuz/dimidium
2025-02-21 06:16:40 +09:00
},
Add Oklab based color scheme "Ottosson" (#18502) Campbell has been the default color scheme for a long time now, but it has quite some issues with hue and chroma. This PR introduces a new scheme which was created using the Oklab color space to find colors with maximal distance to each other and well distributed and consistent hue and chroma. Because of this, I've named the scheme after the creator of Oklab.   Closes #17818
2025-02-03 15:11:27 -08:00
{
"name": "Ottosson",
"background": "#000000",
"foreground": "#bebebe",
"cursorColor": "#ffffff",
"selectionBackground": "#92a4fd",
"black": "#000000",
"red": "#be2c21",
"green": "#3fae3a",
"yellow": "#be9a4a",
"blue": "#204dbe",
"purple": "#bb54be",
"cyan": "#00a7b2",
"white": "#bebebe",
"brightBlack": "#808080",
"brightRed": "#ff3e30",
"brightGreen": "#58ea51",
"brightYellow": "#ffc944",
"brightBlue": "#2f6aff",
"brightPurple": "#fc74ff",
"brightCyan": "#00e1f0",
"brightWhite": "#ffffff"
},
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
{
"name": "Campbell",
"foreground": "#CCCCCC",
"background": "#0C0C0C",
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 22:11:03 +02:00
"cursorColor": "#FFFFFF",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"black": "#0C0C0C",
"red": "#C50F1F",
"green": "#13A10E",
"yellow": "#C19C00",
Give powershell its own scheme (#2936) Fixes #2883.
2019-09-27 20:20:03 -05:00
"blue": "#0037DA",
"purple": "#881798",
"cyan": "#3A96DD",
"white": "#CCCCCC",
"brightBlack": "#767676",
"brightRed": "#E74856",
"brightGreen": "#16C60C",
"brightYellow": "#F9F1A5",
"brightBlue": "#3B78FF",
"brightPurple": "#B4009E",
"brightCyan": "#61D6D6",
"brightWhite": "#F2F2F2"
},
{
"name": "Campbell Powershell",
"foreground": "#CCCCCC",
"background": "#012456",
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 22:11:03 +02:00
"cursorColor": "#FFFFFF",
Give powershell its own scheme (#2936) Fixes #2883.
2019-09-27 20:20:03 -05:00
"black": "#0C0C0C",
"red": "#C50F1F",
"green": "#13A10E",
"yellow": "#C19C00",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"blue": "#0037DA",
"purple": "#881798",
"cyan": "#3A96DD",
"white": "#CCCCCC",
"brightBlack": "#767676",
"brightRed": "#E74856",
"brightGreen": "#16C60C",
"brightYellow": "#F9F1A5",
"brightBlue": "#3B78FF",
"brightPurple": "#B4009E",
"brightCyan": "#61D6D6",
"brightWhite": "#F2F2F2"
},
{
"name": "Vintage",
"foreground": "#C0C0C0",
"background": "#000000",
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 22:11:03 +02:00
"cursorColor": "#FFFFFF",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"black": "#000000",
"red": "#800000",
"green": "#008000",
"yellow": "#808000",
"blue": "#000080",
"purple": "#800080",
"cyan": "#008080",
"white": "#C0C0C0",
"brightBlack": "#808080",
"brightRed": "#FF0000",
"brightGreen": "#00FF00",
"brightYellow": "#FFFF00",
"brightBlue": "#0000FF",
"brightPurple": "#FF00FF",
"brightCyan": "#00FFFF",
"brightWhite": "#FFFFFF"
},
{
"name": "One Half Dark",
"foreground": "#DCDFE4",
"background": "#282C34",
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 22:11:03 +02:00
"cursorColor": "#FFFFFF",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"black": "#282C34",
"red": "#E06C75",
"green": "#98C379",
"yellow": "#E5C07B",
"blue": "#61AFEF",
"purple": "#C678DD",
"cyan": "#56B6C2",
"white": "#DCDFE4",
"brightBlack": "#5A6374",
"brightRed": "#E06C75",
"brightGreen": "#98C379",
"brightYellow": "#E5C07B",
"brightBlue": "#61AFEF",
"brightPurple": "#C678DD",
"brightCyan": "#56B6C2",
"brightWhite": "#DCDFE4"
},
{
"name": "One Half Light",
"foreground": "#383A42",
"background": "#FAFAFA",
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 22:11:03 +02:00
"cursorColor": "#4F525D",
Fix the bad default light theme selection background color (#16789) ## Summary of the Pull Request Fixed default selection background colors with light schemes. Default color now matches the scheme and contrasts well ## References and Relevant Issues none ## Detailed Description of the Pull Request / Additional comments This is my first contribution ever :) Even though its simple, im happy to help ## Validation Steps Performed ## PR Checklist - [ ] Closes #8716 - [ ] 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 (if necessary)
2024-04-29 14:59:59 -04:00
"selectionBackground": "#383A42",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"black": "#383A42",
"red": "#E45649",
"green": "#50A14F",
"yellow": "#C18301",
"blue": "#0184BC",
"purple": "#A626A4",
"cyan": "#0997B3",
"white": "#FAFAFA",
"brightBlack": "#4F525D",
"brightRed": "#DF6C75",
"brightGreen": "#98C379",
"brightYellow": "#E4C07A",
"brightBlue": "#61AFEF",
"brightPurple": "#C577DD",
"brightCyan": "#56B5C1",
"brightWhite": "#FFFFFF"
},
{
"name": "Solarized Dark",
"foreground": "#839496",
"background": "#002B36",
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 22:11:03 +02:00
"cursorColor": "#FFFFFF",
Swap brightBlack/black in the Solarized color schemes (#6985) Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618.
2020-07-20 13:50:50 -07:00
"black": "#002B36",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"red": "#DC322F",
"green": "#859900",
"yellow": "#B58900",
"blue": "#268BD2",
"purple": "#D33682",
"cyan": "#2AA198",
"white": "#EEE8D5",
Swap brightBlack/black in the Solarized color schemes (#6985) Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618.
2020-07-20 13:50:50 -07:00
"brightBlack": "#073642",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"brightRed": "#CB4B16",
"brightGreen": "#586E75",
"brightYellow": "#657B83",
"brightBlue": "#839496",
"brightPurple": "#6C71C4",
"brightCyan": "#93A1A1",
"brightWhite": "#FDF6E3"
},
{
"name": "Solarized Light",
"foreground": "#657B83",
"background": "#FDF6E3",
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 22:11:03 +02:00
"cursorColor": "#002B36",
Fix the bad default light theme selection background color (#16789) ## Summary of the Pull Request Fixed default selection background colors with light schemes. Default color now matches the scheme and contrasts well ## References and Relevant Issues none ## Detailed Description of the Pull Request / Additional comments This is my first contribution ever :) Even though its simple, im happy to help ## Validation Steps Performed ## PR Checklist - [ ] Closes #8716 - [ ] 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 (if necessary)
2024-04-29 14:59:59 -04:00
"selectionBackground": "#2C4D57",
Swap brightBlack/black in the Solarized color schemes (#6985) Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618.
2020-07-20 13:50:50 -07:00
"black": "#002B36",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"red": "#DC322F",
"green": "#859900",
"yellow": "#B58900",
"blue": "#268BD2",
"purple": "#D33682",
"cyan": "#2AA198",
"white": "#EEE8D5",
Swap brightBlack/black in the Solarized color schemes (#6985) Original notes from @M-Pixel: > Console applications assume that backgrounds are black, and that > `lightBlack`/`DarkGrey` are lighter than `black`/`Black`. This > assumption is accounted for by all color schemes in `defaults.json`, > except for the Solarized themes. > > The Solarized Dark theme, in particular, makes `-Parameters` invisible > against the background in PowerShell, which is obviously an unacceptable > usability flaw. > > This change makes `black` and `background` to the same (which is common > throughout the color schemes), and makes `brightBlack` (`DarkGray` in > .NET) lighter than black (which is obviously more correct given the > meanings of those words). Out of the box, we ship a pretty bad behavior. If I look at all of the existing shipped color schemes--and that includes things like Tango and One Half--we are universally following a `background` == `black` rule. If I consult gnome-terminal or xterm, they do the same thing; Xterm by default, gnome-terminal for solarized. The background generally matches color index `0` across all their **dark** schemes. Konsole and lxterminal disagree and map background to `0 intense` for Solarized. I want to put our Solarized schemes on a deprecation path, but unfortunately we still need to ship _something_ for users who we're going to strand on them. I'm going to have to swallow my bitter and say that yes, we should probably just change the index mapping and go with something that works right out of the box while we figure out how to do perceptual color nudging and eventually remove bad defaults (like Solarized). From #6618. Fixes #4047. Closes #6618.
2020-07-20 13:50:50 -07:00
"brightBlack": "#073642",
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
"brightRed": "#CB4B16",
"brightGreen": "#586E75",
"brightYellow": "#657B83",
"brightBlue": "#839496",
"brightPurple": "#6C71C4",
"brightCyan": "#93A1A1",
"brightWhite": "#FDF6E3"
Add the Tango color schemes for Terminal and ColorTool (#5305) The Tango color scheme is part of the Tango Desktop Project, which was released to the public domain in 2009. More information is available at http://tango-project.org/. This commit adds the "Tango Dark" and "Tango Light" color scheme presets. Closes #5281 Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-14 17:47:02 +00:00
},
{
"name": "Tango Dark",
Improve default foregrounds for Tango schemes (#5598) Followup to ea61aa3b. The default foreground in the iTerm2 defaults for the Tango Dark color scheme is too bright, use the value for ANSI 7 (white) instead. References #5305 Sorry, I should have really done this in the original PR. Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-27 22:20:02 +00:00
"foreground": "#D3D7CF",
Add the Tango color schemes for Terminal and ColorTool (#5305) The Tango color scheme is part of the Tango Desktop Project, which was released to the public domain in 2009. More information is available at http://tango-project.org/. This commit adds the "Tango Dark" and "Tango Light" color scheme presets. Closes #5281 Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-14 17:47:02 +00:00
"background": "#000000",
"cursorColor": "#FFFFFF",
"black": "#000000",
"red": "#CC0000",
"green": "#4E9A06",
"yellow": "#C4A000",
"blue": "#3465A4",
"purple": "#75507B",
"cyan": "#06989A",
"white": "#D3D7CF",
"brightBlack": "#555753",
"brightRed": "#EF2929",
"brightGreen": "#8AE234",
"brightYellow": "#FCE94F",
"brightBlue": "#729FCF",
"brightPurple": "#AD7FA8",
"brightCyan": "#34E2E2",
"brightWhite": "#EEEEEC"
},
{
"name": "Tango Light",
Improve default foregrounds for Tango schemes (#5598) Followup to ea61aa3b. The default foreground in the iTerm2 defaults for the Tango Dark color scheme is too bright, use the value for ANSI 7 (white) instead. References #5305 Sorry, I should have really done this in the original PR. Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-27 22:20:02 +00:00
"foreground": "#555753",
Add the Tango color schemes for Terminal and ColorTool (#5305) The Tango color scheme is part of the Tango Desktop Project, which was released to the public domain in 2009. More information is available at http://tango-project.org/. This commit adds the "Tango Dark" and "Tango Light" color scheme presets. Closes #5281 Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-14 17:47:02 +00:00
"background": "#FFFFFF",
"cursorColor": "#000000",
Fix the bad default light theme selection background color (#16789) ## Summary of the Pull Request Fixed default selection background colors with light schemes. Default color now matches the scheme and contrasts well ## References and Relevant Issues none ## Detailed Description of the Pull Request / Additional comments This is my first contribution ever :) Even though its simple, im happy to help ## Validation Steps Performed ## PR Checklist - [ ] Closes #8716 - [ ] 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 (if necessary)
2024-04-29 14:59:59 -04:00
"selectionBackground": "#141414",
Add the Tango color schemes for Terminal and ColorTool (#5305) The Tango color scheme is part of the Tango Desktop Project, which was released to the public domain in 2009. More information is available at http://tango-project.org/. This commit adds the "Tango Dark" and "Tango Light" color scheme presets. Closes #5281 Signed-off-by: Rafael Kitover <rkitover@gmail.com>
2020-04-14 17:47:02 +00:00
"black": "#000000",
"red": "#CC0000",
"green": "#4E9A06",
"yellow": "#C4A000",
"blue": "#3465A4",
"purple": "#75507B",
"cyan": "#06989A",
"white": "#D3D7CF",
"brightBlack": "#555753",
"brightRed": "#EF2929",
"brightGreen": "#8AE234",
"brightYellow": "#FCE94F",
"brightBlue": "#729FCF",
"brightPurple": "#AD7FA8",
"brightCyan": "#34E2E2",
"brightWhite": "#EEEEEC"
Add Dark+, CGA and IBM color schemes (#16953) As discussed in #6176 and #16754. The "CGA" and "IBM 5153" names I'm told are the right ones to use: https://github.com/microsoft/terminal/issues/16754#issuecomment-2024066880 Closes #6176 Closes #16754
2024-03-28 05:28:26 -07:00
},
{
"name": "Dark+",
"foreground": "#cccccc",
"background": "#1e1e1e",
"cursorColor": "#808080",
"selectionBackground": "#ffffff",
"black": "#000000",
"red": "#cd3131",
"green": "#0dbc79",
"yellow": "#e5e510",
"blue": "#2472c8",
"purple": "#bc3fbc",
"cyan": "#11a8cd",
"white": "#e5e5e5",
"brightBlack": "#666666",
"brightRed": "#f14c4c",
"brightGreen": "#23d18b",
"brightYellow": "#f5f543",
"brightBlue": "#3b8eea",
"brightPurple": "#d670d6",
"brightCyan": "#29b8db",
"brightWhite": "#e5e5e5"
},
Add VSCode Dark Modern and Light Modern color schemes (#19728) This adds both the Dark Modern and Light Modern color schemes from VSCode to match issue #19162. I pulled the colors directly from VSCode's terminalColorRegistry.ts for accuracy. The existing Dark+ scheme uses the older terminal colors from before VSCode introduced the Modern variants, so this gives users access to the newer palette. The Dark Modern background is #1F1F1F which is the actual color used in VSCode currently, not #1E1E1E from the legacy theme. Light Modern uses #FFFFFF background with #3B3B3B foreground text. Tested locally in Windows Terminal and both schemes render correctly.
2026-01-12 15:28:47 -07:00
{
"name": "VSCode Dark Modern",
"foreground": "#CCCCCC",
"background": "#1F1F1F",
"cursorColor": "#FFFFFF",
"selectionBackground": "#264F78",
"black": "#000000",
"red": "#CD3131",
"green": "#0DBC79",
"yellow": "#E5E510",
"blue": "#2472C8",
"purple": "#BC3FBC",
"cyan": "#11A8CD",
"white": "#E5E5E5",
"brightBlack": "#666666",
"brightRed": "#F14C4C",
"brightGreen": "#23D18B",
"brightYellow": "#F5F543",
"brightBlue": "#3B8EEA",
"brightPurple": "#D670D6",
"brightCyan": "#29B8DB",
"brightWhite": "#E5E5E5"
},
{
"name": "VSCode Light Modern",
"foreground": "#3B3B3B",
"background": "#FFFFFF",
"cursorColor": "#000000",
"selectionBackground": "#ADD6FF",
"black": "#000000",
"red": "#CD3131",
"green": "#00BC00",
"yellow": "#949800",
"blue": "#0451A5",
"purple": "#BC05BC",
"cyan": "#0598BC",
"white": "#555555",
"brightBlack": "#666666",
"brightRed": "#CD3131",
"brightGreen": "#14CE14",
"brightYellow": "#B5BA00",
"brightBlue": "#0451A5",
"brightPurple": "#BC05BC",
"brightCyan": "#0598BC",
"brightWhite": "#A5A5A5"
},
Add Dark+, CGA and IBM color schemes (#16953) As discussed in #6176 and #16754. The "CGA" and "IBM 5153" names I'm told are the right ones to use: https://github.com/microsoft/terminal/issues/16754#issuecomment-2024066880 Closes #6176 Closes #16754
2024-03-28 05:28:26 -07:00
{
"background": "#000000",
"black": "#000000",
"blue": "#0000AA",
"brightBlack": "#555555",
"brightBlue": "#5555FF",
"brightCyan": "#55FFFF",
"brightGreen": "#55FF55",
"brightPurple": "#FF55FF",
"brightRed": "#FF5555",
"brightWhite": "#FFFFFF",
"brightYellow": "#FFFF55",
"cursorColor": "#00AA00",
"cyan": "#00AAAA",
"foreground": "#AAAAAA",
"green": "#00AA00",
"name": "CGA",
"purple": "#AA00AA",
"red": "#AA0000",
"selectionBackground": "#FFFFFF",
"white": "#AAAAAA",
"yellow": "#AA5500"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#0000AA",
"brightBlack": "#555555",
"brightBlue": "#5555FF",
"brightCyan": "#55FFFF",
"brightGreen": "#55FF55",
"brightPurple": "#FF55FF",
"brightRed": "#FF5555",
"brightWhite": "#FFFFFF",
"brightYellow": "#FFFF55",
"cursorColor": "#00AA00",
"cyan": "#00AAAA",
"foreground": "#AAAAAA",
"green": "#00AA00",
"name": "IBM 5153",
"purple": "#AA00AA",
"red": "#AA0000",
"selectionBackground": "#FFFFFF",
"white": "#AAAAAA",
"yellow": "#C47E00"
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
}
],
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
"themes": [
{
"name": "light",
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
"window": {
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
"applicationTheme": "light"
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
},
"tab": {
"background": "terminalBackground",
"unfocusedBackground": "#00000000"
},
"tabRow": {
"unfocusedBackground": "#FFFFFFFF"
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
}
},
{
"name": "dark",
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
"window": {
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
"applicationTheme": "dark"
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
},
"tab": {
"background": "terminalBackground",
"unfocusedBackground": "#00000000"
},
"tabRow": {
"unfocusedBackground": "#333333FF"
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
}
},
{
"name": "system",
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
"window": {
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
"applicationTheme": "system"
Update the default themes for 1.16 (#13743) More or less, as in #13554 * Dark theme by default (was `system`) * Justification: > I think the interesting thing that we have today is that the color > scheme is dark by default, but our window theme is set to system. > System theme in Windows 11 is defaulted to light unless changed by > the user. Now, we have a conflict between the theme and color scheme > in Terminal. > > I think our options become, make the color scheme match "default" > and set it to a light color scheme if the system theme is light, or > manually match the theme to the color scheme by setting it to dark. > > Given that Terminal has historically had a black background with > its Campbell color scheme, for a consistent UI experience, I'm > voting to change the window theme to be dark by default as well. * `tab.background: terminalBackground` * Change the tab row colors back to "what they were pre-Controlsv2" more or less - The ramp is based off of "Light tab row background from Edge's unfocused titlebar color, inactive tab row color BG from the controlsv1 colors" * `tabRow.unfocusedBackground` set `Transparent` Closes #13554
2022-08-31 13:32:32 -05:00
},
"tab": {
"background": "terminalBackground",
"unfocusedBackground": "#00000000"
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
}
Add "legacy" themes (#15108) This is a minimal version of the requests for #14858. In that thread we discussed FULL reverting the default themes to the old ones. In later discussion, we decided _meh_, let's just ship the legacy themes too, so it's easy to go back if you should choose. The default still remains the sane `dark`, but the `legacy*` themes are all right there, and given the same special treatment as the other inbox themes. Closes #14858 Closes #14844
2023-04-06 11:50:30 -05:00
},
{
"name": "legacyDark",
"tab": {
"background": null,
"unfocusedBackground": null
},
"window": {
"applicationTheme": "dark"
}
},
{
"name": "legacyLight",
"tab": {
"background": null,
"unfocusedBackground": null
},
"window": {
"applicationTheme": "light"
}
},
{
"name": "legacySystem",
"tab": {
"background": null,
"unfocusedBackground": null
},
"window": {
"applicationTheme": "system"
},
Initial Theme support (#12992) ##### ⚠️ targeting 1.15 ## Summary of the Pull Request Adds support for Themes, a new type of customization for the Terminal. Themes allow the user to customize elements of the Terminal window itself. In this first iteration, this PR adds support for two main properties: * enabling Mica as the window backdrop * changing the tab row color (read: changing the titelbar color) These represent the most important asks of theming in the Terminal. The properties added in this PR are: * Theme color variants: - `"#rrggbb"` or `"#aarrggbb"` - `"accent"` - `"terminalBackground"` * Properties (_listed here in dot notation, but implemented as sub-objects_) - `tabRow.background`: accepts a ThemeColor (above) - `window.applicationTheme`: accepts one of `{"system", "light", "dark"}` - `window.useMica`: accepts a boolean, defaults to false. ## References * As first described in #3327 * spec'd in #12530 ## PR Checklist * [x] Sorta enables #10509, but doesn't close it. That'll need more comprehensive changes to the titlebar code. * **update**: I totally disabled mica, but left the serialization code. It just seems silly without #10509. * [x] Closes #1963 * [x] Closes #3774 * [x] Closes #12939 * [x] Does the bulk of the #3327 work, but I'm going to leave that open since that's become my megathread for everything related to theming. * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **SURE DOES** ## Detailed Description of the Pull Request / Additional comments ### --> GO READ #12530 <-- Seriously. These themes aren't customizable in the SUI currently. You can change the active theme, and the UI will show all of the defined themes, but they're not editable there. They don't layer. You'll need to define your own themes. Thay can't come from fragments. This is a really cool future idea, but not implemented in this v0. The sub objects have some gnarly macros to generate a lot of the serialization code for you. ### TODOs * [x] I still have yet to establish what the accent color algorithm is. This might be proprietary and require a ThemeHelpers workaround. * [x] Make sure `terminalBackground` & the SUI result in something sensible * [x] Make sure runtime BG changes work with `terminalBackground`. One time, they didn't. `printf "\x1b]11;rgb:ff/00/ff\x07"` * [x] Acrylic Terminal BG's look weird, like, the opacity is always 50% or something. And the tab row looks all wrong then. ## Validation Steps Performed This is the blob I've been testing with: <details> ```jsonc // "useAcrylicInTabRow": true, "theme": "my dark", // "theme": "Edge", "theme": "orangey", "theme": "WHITE", // "theme": "terminal", "themes": [ { "name": "my dark", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#00000000", }, }, { "name": "Edge", "tabRow": { "background": "accent" }, "window": { "applicationTheme": "system" } }, { "name": "orangey", "window": { "applicationTheme": "light", "useMica": true, }, "tabRow": { "background": "#ff8800", }, }, { "name": "WHITE", "window": { "applicationTheme": "dark", "useMica": true, }, "tabRow": { "background": "#FFFFFF", }, }, { "name": "terminal", "window": { "applicationTheme": "dark", "useMica": false, }, "tabRow": { "background": "terminalBackground", }, }, ] ``` </details>
2022-07-07 06:54:54 -05:00
}
],
Replace "bindings" with "actions" (#7332) In #6532, we thought it would be a good idea to add "bindings" as an overload for "keybindings", as we were no longer going to use the keybindings array for just keybindings. We were going to add commands. So we started secretly treating `"bindings"` the same as `"keybindings"`. Then, in #7175, we discussed using "actions" as the key for the list of commands/keybindings/global actions, instead of using "bindings". We're going to be using this array as the global list of all actions, so it makes sense to just call it `"actions"`. This PR renames "bindings" to "actions". Fortunately, we never documented the "bindings" overload in the first place, so we can get away with this safely, and preferably before we ship "bindings" for too long. References #6899
2020-08-19 20:02:42 -05:00
"actions":
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
[
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
// Application-level Commands
{ "command": "closeWindow", "id": "Terminal.CloseWindow" },
{ "command": "toggleFullscreen", "id": "Terminal.ToggleFullscreen" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "toggleFocusMode", "id": "Terminal.ToggleFocusMode" },
{ "command": "toggleAlwaysOnTop", "id": "Terminal.ToggleAlwaysOnTop" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "openNewTabDropdown", "id": "Terminal.OpenNewTabDropdown" },
{ "command": { "action": "openSettings", "target": "settingsUI" }, "id": "Terminal.OpenSettingsUI" },
{ "command": { "action": "openSettings", "target": "settingsFile" }, "id": "Terminal.OpenSettingsFile" },
{ "command": { "action": "openSettings", "target": "defaultsFile" }, "id": "Terminal.OpenDefaultSettingsFile" },
Add action for opening settings directory in file explorer (#17690) Most of the logic is taken from the original PR (https://github.com/microsoft/terminal/pull/15417) and adapted to work with the palette. ## References and Relevant Issues [#12382](https://github.com/microsoft/terminal/issues/12382)
2024-12-05 04:20:13 -08:00
{ "command": { "action": "openSettings", "target": "directory" }, "id": "Terminal.OpenSettingsDirectory" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "find", "id": "Terminal.FindText" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "findMatch", "direction": "next" }, "id": "Terminal.FindNextMatch" },
{ "command": { "action": "findMatch", "direction": "prev" }, "id": "Terminal.FindPrevMatch" },
{ "command": "toggleShaderEffects", "id": "Terminal.ToggleShaderEffects" },
{ "command": "openTabColorPicker", "id": "Terminal.OpenTabColorPicker" },
{ "command": "renameTab", "id": "Terminal.RenameTab" },
{ "command": "openTabRenamer", "id": "Terminal.OpenTabRenamer" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "commandPalette", "id": "Terminal.ToggleCommandPalette" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "identifyWindow", "id": "Terminal.IdentifyWindow" },
{ "command": "openWindowRenamer", "id": "Terminal.OpenWindowRenamer" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "quakeMode", "id": "Terminal.QuakeMode" },
{ "command": "openSystemMenu", "id": "Terminal.OpenSystemMenu" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "quit", "id": "Terminal.Quit" },
{ "command": "restoreLastClosed", "id": "Terminal.RestoreLastClosed" },
{ "command": "openAbout", "id": "Terminal.OpenAboutDialog" },
Add a snippets pane (#17330) This adds a snippets pane, which can be a static pane with all your snippets (`sendInput` actions) in it. (See #17329) This pane has a treeview with these actions in it, that we can filter with a textbox at the top. Play buttons next to entries make it quick to run the command you found. Bound in the default actions with ```json { "command": { "action": "splitPane", "type": "snippets" }, "id": "Terminal.OpenSnippetsPane", "name": { "key": "SnippetsPaneCommandName" } }, ``` re: #1595 ---- TODO, from 06-04 bug bash * [x] Snippets pane doesn't display some "no snippets found" text if there aren't any yet * [x] open snippets pane; find a "send input"; click the play button on it; input is sent to active pane; begin typing * [x] I can open an infinite amount of suggestions panes * ~I'm closing this as by-design for now at least. Nothing stopping anyone from opening infinite of any kind of pane.~ * ~This would require kind of a lot of refactoring in this PR to mark a kind of pane as being a singleton or singleton-per-tab~ * Okay everyone hates infinite suggestions panes, so I got rid of that * [x] Ctrl+Shift+W should still work in the snippets pane even if focus isn't in textbox * [ ] open snippets pane; click on text box; press TAB key; * [ ] If you press TAB again, I have no idea where focus went * [x] some previews don't work. Like `^c` (`"input": "\u0003"`) * [x] nested items just give you a bit of extra space for no reason and it looks a little awkward * [x] UI Suggestion: add padding on the right side * [ ] [Accessibility] Narrator says "Clear buffer; Suggestions found 132" when you open the snippets pane - Note: this is probably Narrator reading out the command palette (since that's where I opened it from) - We should probably expect something like "Snippets", then (assuming focus is thrown into text box) "Type to filter snippets" or something like that
2024-07-08 13:26:07 -05:00
{ "command": "experimental.openTasks", "id": "Terminal.OpenTasks" },
Add action for Quick Fix and key binding for Suggestions (#17502) Adds a keybinding to open the quick fix menu, if one is available. When the action is used, we also open up the button (if it was collapsed) because that looks nice. The `showSuggestions` action is bound to `ctrl+shift+period` by default to align with VS' "quick actions" feature and VS Code's "quick fix" feature. This was chosen over binding to `quickFix` because it's more helpful. The quick fix button is a route for users that prefer to use the mouse. If users want to add a keybinding to activate the `quickFix` button, they can do that now. This PR also performs a bit of miscellaneous polish from the bug bash. This includes: - the suggestions UI now presents quick fixes first - scrolling may result in the button being drawn in the wrong place - The bug was tracked down this line: `TermControl::CursorPositionInDips()` --> `_core.CursorPosition()` --> `Terminal::GetViewportRelativeCursorPosition()`. The mutable viewport there does _not_ update when the user scrolls. Thus, the button would be drawn on the same position _on the screen_ even though we scrolled. To fix this, I include the `_scrollOffset` in the calculation. The only other place this function is used is with the suggestions UI, which does _not_ update the UIs position as we scroll (but if we're interested in doing that, we can now). Closes #17377
2024-07-17 15:28:30 -07:00
{ "command": "quickFix", "id": "Terminal.QuickFix" },
{ "command": { "action": "showSuggestions", "source": "all"}, "id": "Terminal.Suggestions" },
Open current working directory action. (#18013) ## Summary of the Pull Request Added open current directory action. ## References and Relevant Issues Need to set this: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory ## Detailed Description of the Pull Request / Additional comments ## Validation Steps Performed - Ensure shell has been configured - Run "Open current working directory" action in command palette - File explorer opens the correct directory ## PR Checklist - [x] Closes #12859 - [ ] 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 (if necessary)
2024-12-05 07:18:45 -05:00
{ "command": "openCWD", "id": "Terminal.OpenCWD" },
Add support for "workspaces" based on window names (redux) (#20314) This adds a new feature to the Windows Terminal: "Workspaces" Workspaces are very shamelessly inspired by Edge workspaces of the same name. The core idea is that when users name a window and they close that window, we will persist that Windows layout and buffers, seperately from the rest of window restoration. So a user can open a named window, open some profiles, some panes, do some stuff in it, then close it, and we will keep that state around for the next time the user opens that window name. Unnamed windows still behave the same. If you close an unnamed window, and it's not the last window, then we won't persist the state of it. To facilitate restoring named windows, we add a `openWorkspace` action. This allows us to persist the open workspace action in the window layout restoration path. So when we deserialize the list of tab layouts, and open workspace action will tell us, hey, go retrieve this known workspace from the state.json, instead of trying to serialize the window state in two places. As demoed in the video, we add a flyout to list the windows that the user has open, and the named workspaces that they have saved. This allows users to quickly reopen previously closed workspaces, as well as quickly rename a window, thereby adding it to the list of saved workspaces. This button can also be hidden using the theme settings. Closes #17084 (this is a reboot of #20162, but with the event from #20311)
2026-06-16 16:59:17 -05:00
{ "command": "workspaces", "id": "Terminal.Workspaces" },
Add an action for identifying windows (#9523) ## Summary of the Pull Request This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions: * `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default. ![identify-window-toast-000](https://user-images.githubusercontent.com/18356694/111529085-bf710580-872f-11eb-8880-b0b617596cfc.gif) * `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky. ![teaching-tip-dismiss-001](https://user-images.githubusercontent.com/18356694/111529292-fe06c000-872f-11eb-8d4a-5688e4ce1175.gif) That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382 Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows` ## References ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?" Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
2021-03-30 11:08:03 -05:00
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
// Tab Management
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-09 16:13:57 -07:00
// "command": "closeTab" is unbound by default.
// The closeTab command closes a tab without confirmation, even if it has multiple panes.
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "closeOtherTabs", "id": "Terminal.CloseOtherTabs" },
{ "command": "closeTabsAfter", "id": "Terminal.CloseTabsAfter" },
{ "command": { "action" : "moveTab", "direction": "forward" }, "id": "Terminal.MoveTabForward" },
{ "command": { "action" : "moveTab", "direction": "backward" }, "id": "Terminal.MoveTabBackward" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "newTab", "id": "Terminal.OpenNewTab" },
{ "command": "newWindow", "id": "Terminal.OpenNewWindow" },
{ "command": { "action": "newTab", "index": 0 }, "id": "Terminal.OpenNewTabProfile0" },
{ "command": { "action": "newTab", "index": 1 }, "id": "Terminal.OpenNewTabProfile1" },
{ "command": { "action": "newTab", "index": 2 }, "id": "Terminal.OpenNewTabProfile2" },
{ "command": { "action": "newTab", "index": 3 }, "id": "Terminal.OpenNewTabProfile3" },
{ "command": { "action": "newTab", "index": 4 }, "id": "Terminal.OpenNewTabProfile4" },
{ "command": { "action": "newTab", "index": 5 }, "id": "Terminal.OpenNewTabProfile5" },
{ "command": { "action": "newTab", "index": 6 }, "id": "Terminal.OpenNewTabProfile6" },
{ "command": { "action": "newTab", "index": 7 }, "id": "Terminal.OpenNewTabProfile7" },
{ "command": { "action": "newTab", "index": 8 }, "id": "Terminal.OpenNewTabProfile8" },
{ "command": "duplicateTab", "id": "Terminal.DuplicateTab" },
{ "command": "nextTab", "id": "Terminal.NextTab" },
{ "command": "prevTab", "id": "Terminal.PrevTab" },
{ "command": { "action": "switchToTab", "index": 0 }, "id": "Terminal.SwitchToTab0" },
{ "command": { "action": "switchToTab", "index": 1 }, "id": "Terminal.SwitchToTab1" },
{ "command": { "action": "switchToTab", "index": 2 }, "id": "Terminal.SwitchToTab2" },
{ "command": { "action": "switchToTab", "index": 3 }, "id": "Terminal.SwitchToTab3" },
{ "command": { "action": "switchToTab", "index": 4 }, "id": "Terminal.SwitchToTab4" },
{ "command": { "action": "switchToTab", "index": 5 }, "id": "Terminal.SwitchToTab5" },
{ "command": { "action": "switchToTab", "index": 6 }, "id": "Terminal.SwitchToTab6" },
{ "command": { "action": "switchToTab", "index": 7 }, "id": "Terminal.SwitchToTab7" },
{ "command": { "action": "switchToTab", "index": 4294967295 }, "id": "Terminal.SwitchToLastTab" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "moveTab", "window": "new" }, "id": "Terminal.MoveTabToNewWindow" },
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
// Pane Management
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "closeOtherPanes", "id": "Terminal.CloseOtherPanes" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "closePane", "id": "Terminal.ClosePane" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "splitPane", "split": "up" }, "id": "Terminal.SplitPaneUp" },
{ "command": { "action": "splitPane", "split": "down" }, "id": "Terminal.SplitPaneDown" },
{ "command": { "action": "splitPane", "split": "left" }, "id": "Terminal.SplitPaneLeft" },
{ "command": { "action": "splitPane", "split": "right" }, "id": "Terminal.SplitPaneRight" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": { "action": "splitPane", "splitMode": "duplicate", "split": "down" }, "id": "Terminal.DuplicatePaneDown" },
{ "command": { "action": "splitPane", "splitMode": "duplicate", "split": "right" }, "id": "Terminal.DuplicatePaneRight" },
{ "command": { "action": "splitPane", "splitMode": "duplicate", "split": "auto" }, "id": "Terminal.DuplicatePaneAuto" },
{ "command": { "action": "resizePane", "direction": "down" }, "id": "Terminal.ResizePaneDown" },
{ "command": { "action": "resizePane", "direction": "left" }, "id": "Terminal.ResizePaneLeft" },
{ "command": { "action": "resizePane", "direction": "right" }, "id": "Terminal.ResizePaneRight" },
{ "command": { "action": "resizePane", "direction": "up" }, "id": "Terminal.ResizePaneUp" },
{ "command": { "action": "moveFocus", "direction": "down" }, "id": "Terminal.MoveFocusDown" },
{ "command": { "action": "moveFocus", "direction": "left" }, "id": "Terminal.MoveFocusLeft" },
{ "command": { "action": "moveFocus", "direction": "right" }, "id": "Terminal.MoveFocusRight" },
{ "command": { "action": "moveFocus", "direction": "up" }, "id": "Terminal.MoveFocusUp" },
{ "command": { "action": "moveFocus", "direction": "previous" }, "id": "Terminal.MoveFocusPrevious" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "moveFocus", "direction": "previousInOrder" }, "id": "Terminal.MoveFocusPreviousInOrder" },
{ "command": { "action": "moveFocus", "direction": "nextInOrder" }, "id": "Terminal.MoveFocusNextInOrder" },
{ "command": { "action": "moveFocus", "direction": "first" }, "id": "Terminal.MoveFocusFirst" },
{ "command": { "action": "moveFocus", "direction": "parent" }, "id": "Terminal.MoveFocusParent" },
{ "command": { "action": "moveFocus", "direction": "child" }, "id": "Terminal.MoveFocusChild" },
{ "command": { "action": "swapPane", "direction": "down" }, "id": "Terminal.SwapPaneDown" },
{ "command": { "action": "swapPane", "direction": "left" }, "id": "Terminal.SwapPaneLeft" },
{ "command": { "action": "swapPane", "direction": "right" }, "id": "Terminal.SwapPaneRight" },
{ "command": { "action": "swapPane", "direction": "up" }, "id": "Terminal.SwapPaneUp" },
{ "command": { "action": "swapPane", "direction": "previous"}, "id": "Terminal.SwapPanePrevious" },
{ "command": { "action": "swapPane", "direction": "previousInOrder"}, "id": "Terminal.SwapPanePreviousInOrder" },
{ "command": { "action": "swapPane", "direction": "nextInOrder"}, "id": "Terminal.SwapPaneNextInOrder" },
{ "command": { "action": "swapPane", "direction": "first" }, "id": "Terminal.SwapPaneFirst" },
{ "command": "toggleBroadcastInput", "id": "Terminal.ToggleBroadcastInput" },
{ "command": "togglePaneZoom", "id": "Terminal.TogglePaneZoom" },
{ "command": "toggleSplitOrientation", "id": "Terminal.ToggleSplitOrientation" },
{ "command": "toggleReadOnlyMode", "id": "Terminal.ToggleReadOnlyMode" },
{ "command": "enableReadOnlyMode", "id": "Terminal.EnableReadOnlyMode" },
{ "command": "disableReadOnlyMode", "id": "Terminal.DisableReadOnlyMode" },
{ "command": { "action": "movePane", "index": 0 }, "id": "Terminal.MovePaneToTab0" },
{ "command": { "action": "movePane", "index": 1 }, "id": "Terminal.MovePaneToTab1" },
{ "command": { "action": "movePane", "index": 2 }, "id": "Terminal.MovePaneToTab2" },
{ "command": { "action": "movePane", "index": 3 }, "id": "Terminal.MovePaneToTab3" },
{ "command": { "action": "movePane", "index": 4 }, "id": "Terminal.MovePaneToTab4" },
{ "command": { "action": "movePane", "index": 5 }, "id": "Terminal.MovePaneToTab5" },
{ "command": { "action": "movePane", "index": 6 }, "id": "Terminal.MovePaneToTab6" },
{ "command": { "action": "movePane", "index": 7 }, "id": "Terminal.MovePaneToTab7" },
{ "command": { "action": "movePane", "index": 8 }, "id": "Terminal.MovePaneToTab8" },
{ "command": { "action": "movePane", "window": "new" }, "id": "Terminal.MovePaneToNewWindow" },
{ "command": "restartConnection", "id": "Terminal.RestartConnection" },
Add a snippets pane (#17330) This adds a snippets pane, which can be a static pane with all your snippets (`sendInput` actions) in it. (See #17329) This pane has a treeview with these actions in it, that we can filter with a textbox at the top. Play buttons next to entries make it quick to run the command you found. Bound in the default actions with ```json { "command": { "action": "splitPane", "type": "snippets" }, "id": "Terminal.OpenSnippetsPane", "name": { "key": "SnippetsPaneCommandName" } }, ``` re: #1595 ---- TODO, from 06-04 bug bash * [x] Snippets pane doesn't display some "no snippets found" text if there aren't any yet * [x] open snippets pane; find a "send input"; click the play button on it; input is sent to active pane; begin typing * [x] I can open an infinite amount of suggestions panes * ~I'm closing this as by-design for now at least. Nothing stopping anyone from opening infinite of any kind of pane.~ * ~This would require kind of a lot of refactoring in this PR to mark a kind of pane as being a singleton or singleton-per-tab~ * Okay everyone hates infinite suggestions panes, so I got rid of that * [x] Ctrl+Shift+W should still work in the snippets pane even if focus isn't in textbox * [ ] open snippets pane; click on text box; press TAB key; * [ ] If you press TAB again, I have no idea where focus went * [x] some previews don't work. Like `^c` (`"input": "\u0003"`) * [x] nested items just give you a bit of extra space for no reason and it looks a little awkward * [x] UI Suggestion: add padding on the right side * [ ] [Accessibility] Narrator says "Clear buffer; Suggestions found 132" when you open the snippets pane - Note: this is probably Narrator reading out the command palette (since that's where I opened it from) - We should probably expect something like "Snippets", then (assuming focus is thrown into text box) "Type to filter snippets" or something like that
2024-07-08 13:26:07 -05:00
{ "command": { "action": "splitPane", "type": "snippets" }, "id": "Terminal.OpenSnippetsPane", "name": { "key": "SnippetsPaneCommandName" } },
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
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-09 16:13:57 -07:00
// Clipboard Integration
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": { "action": "copy", "singleLine": false }, "id": "Terminal.CopyToClipboard" },
{ "command": "paste", "id": "Terminal.PasteFromClipboard" },
{ "command": "selectAll", "id": "Terminal.SelectAll" },
{ "command": "markMode", "id": "Terminal.ToggleMarkMode" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": "toggleBlockSelection", "id": "Terminal.ToggleBlockSelection" },
{ "command": "switchSelectionEndpoint", "id": "Terminal.SwitchSelectionEndpoint" },
{ "command": "expandSelectionToWord", "id": "Terminal.ExpandSelectionToWord" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "showContextMenu", "id": "Terminal.ShowContextMenu" },
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
Add an action to search the web for selected text (#15539) This PR adds a `searchWeb` command to search the selected text on the web. Arguments: - `queryUrl`: URL of the web page to launch (the selected text will be inserted where the first `%s` is found in the query string) To make the search text more "compact" and handle multi-line selections, I'm concatenating the selected lines and replacing consecutive whitespaces with a single space (we may change this with something more clever in case). ## Validation Steps Performed Manual testing with single, multi-line, block selections. Closes #10175 --------- Co-authored-by: Marco Pelagatti <marco.pelagatti@iongroup.com> Co-authored-by: Mike Griese <migrie@microsoft.com>
2023-06-21 19:24:45 +02:00
// Web Search
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "searchWeb" }, "name": { "key": "SearchWebCommandKey" }, "id": "Terminal.SearchWeb" },
Add an action to search the web for selected text (#15539) This PR adds a `searchWeb` command to search the selected text on the web. Arguments: - `queryUrl`: URL of the web page to launch (the selected text will be inserted where the first `%s` is found in the query string) To make the search text more "compact" and handle multi-line selections, I'm concatenating the selected lines and replacing consecutive whitespaces with a single space (we may change this with something more clever in case). ## Validation Steps Performed Manual testing with single, multi-line, block selections. Closes #10175 --------- Co-authored-by: Marco Pelagatti <marco.pelagatti@iongroup.com> Co-authored-by: Mike Griese <migrie@microsoft.com>
2023-06-21 19:24:45 +02:00
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
// Scrollback
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": "scrollDown", "id": "Terminal.ScrollDown" },
{ "command": "scrollDownPage", "id": "Terminal.ScrollDownPage" },
{ "command": "scrollUp", "id": "Terminal.ScrollUp" },
{ "command": "scrollUpPage", "id": "Terminal.ScrollUpPage" },
{ "command": "scrollToTop", "id": "Terminal.ScrollToTop" },
{ "command": "scrollToBottom", "id": "Terminal.ScrollToBottom" },
Add IDs to Commands (#16904) As laid out in #16816, adds an `ID` field to `Command`. **This first PR only adds IDs for built-in commands in defaults, and generates IDs for user-created commands that don't define an ID.** Also note that for now we **will not** be allowing IDs for iterable/nested commands. The follow-up PR is where we will actually use the IDs by referring to commands with them. Refs #16816 ## Validation Steps Performed User-created commands in the settings file get rewritten with generated IDs
2024-04-17 17:30:25 -07:00
{ "command": { "action": "clearBuffer", "clear": "all" }, "id": "Terminal.ClearBuffer" },
{ "command": "exportBuffer", "id": "Terminal.ExportBuffer" },
rename profiles.json to settings.json, clean up the defaults (#5199) This pull request migrates `profiles.json` to `settings.json` and removes the legacy roaming AppData settings migrator. It also: * separates the key bindings in defaults.json into logical groups * syncs the universal terminal defaults with the primary defaults * removes some stray newlines that ended up at the beginning of settings.json and defaults.json Fixes #5186. Fixes #3291. ### categorize key bindings ### sync universal with main ### kill stray newlines in template files ### move profiles.json to settings.json This commit also changes Get*Settings from returning a string to returning a std::filesystem::path. We gain in expressiveness without a loss in clarity (since path still supports .c_str()). NOTE: I tried to do an atomic rename with the handle open, but it didn't work for reparse points (it moves the destination of a symbolic link out into the settings folder directly.) (snip for atomic rename code) ```c++ auto path{ pathToSettingsFile.wstring() }; auto renameBufferSize{ sizeof(FILE_RENAME_INFO) + (path.size() * sizeof(wchar_t)) }; auto renameBuffer{ std::make_unique<std::byte[]>(renameBufferSize) }; auto renameInfo{ reinterpret_cast<FILE_RENAME_INFO*>(renameBuffer.get()) }; renameInfo->Flags = FILE_RENAME_FLAG_REPLACE_IF_EXISTS | FILE_RENAME_FLAG_POSIX_SEMANTICS; renameInfo->RootDirectory = nullptr; renameInfo->FileNameLength = gsl::narrow_cast<DWORD>(path.size()); std::copy(path.cbegin(), path.cend(), std::begin(renameInfo->FileName)); THROW_IF_WIN32_BOOL_FALSE(SetFileInformationByHandle(hLegacyFile.get(), FileRenameInfo, renameBuffer.get(), gsl::narrow_cast<DWORD>(renameBufferSize))); ``` (end snip) ### Stop resurrecting dead roaming profiles
2020-04-01 12:09:42 -07:00
// Visual Adjustments
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "command": { "action": "adjustFontSize", "delta": 1 }, "id": "Terminal.IncreaseFontSize" },
{ "command": { "action": "adjustFontSize", "delta": -1 }, "id": "Terminal.DecreaseFontSize" },
{ "command": "resetFontSize", "id": "Terminal.ResetFontSize" },
Add support for commands iterable on color schemes (#7329) ## Summary of the Pull Request ![cmdpal-set-color-scheme](https://user-images.githubusercontent.com/18356694/90517094-8eddd480-e12a-11ea-8be4-8b6782d8d88c.gif) Allows for creating commands that iterate over the user's color schemes. Also adds a top-level nested command to `defaults.json` that allows the user to select a color scheme (pictured above). I'm not sure there are really any other use cases that make sense, but it _really_ makes sense for this one. ## References * #5400 - cmdpal megathread * made possible by #6856, _and support from viewers like you._ * All this is being done in pursuit of #6689 ## PR Checklist * [x] Closes wait what? I could have swore there was an issue for this one... * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - okay maybe now I'll write some docs ## Detailed Description of the Pull Request / Additional comments Most of the hard work for this was already done in #6856. This is just another thing to iterate over. ## Validation Steps Performed * Played with this default command. It works great. * Added tests.
2020-08-19 12:33:19 -05:00
Add a pair of nested, iterable default commands (#7348) ## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-08-21 09:54:43 -05:00
// Other commands
Add support for commands iterable on color schemes (#7329) ## Summary of the Pull Request ![cmdpal-set-color-scheme](https://user-images.githubusercontent.com/18356694/90517094-8eddd480-e12a-11ea-8be4-8b6782d8d88c.gif) Allows for creating commands that iterate over the user's color schemes. Also adds a top-level nested command to `defaults.json` that allows the user to select a color scheme (pictured above). I'm not sure there are really any other use cases that make sense, but it _really_ makes sense for this one. ## References * #5400 - cmdpal megathread * made possible by #6856, _and support from viewers like you._ * All this is being done in pursuit of #6689 ## PR Checklist * [x] Closes wait what? I could have swore there was an issue for this one... * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - okay maybe now I'll write some docs ## Detailed Description of the Pull Request / Additional comments Most of the hard work for this was already done in #6856. This is just another thing to iterate over. ## Validation Steps Performed * Played with this default command. It works great. * Added tests.
2020-08-19 12:33:19 -05:00
{
Add a pair of nested, iterable default commands (#7348) ## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-08-21 09:54:43 -05:00
// Select color scheme...
Add support for commands iterable on color schemes (#7329) ## Summary of the Pull Request ![cmdpal-set-color-scheme](https://user-images.githubusercontent.com/18356694/90517094-8eddd480-e12a-11ea-8be4-8b6782d8d88c.gif) Allows for creating commands that iterate over the user's color schemes. Also adds a top-level nested command to `defaults.json` that allows the user to select a color scheme (pictured above). I'm not sure there are really any other use cases that make sense, but it _really_ makes sense for this one. ## References * #5400 - cmdpal megathread * made possible by #6856, _and support from viewers like you._ * All this is being done in pursuit of #6689 ## PR Checklist * [x] Closes wait what? I could have swore there was an issue for this one... * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - okay maybe now I'll write some docs ## Detailed Description of the Pull Request / Additional comments Most of the hard work for this was already done in #6856. This is just another thing to iterate over. ## Validation Steps Performed * Played with this default command. It works great. * Added tests.
2020-08-19 12:33:19 -05:00
"name": { "key": "SetColorSchemeParentCommandName" },
"commands": [
{
"iterateOn": "schemes",
"name": "${scheme.name}",
"command": { "action": "setColorScheme", "colorScheme": "${scheme.name}" }
}
]
},
Add a pair of nested, iterable default commands (#7348) ## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-08-21 09:54:43 -05:00
{
// New tab...
"name": { "key": "NewTabParentCommandName" },
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": "${profile.name}",
"command": { "action": "newTab", "profile": "${profile.name}" }
}
]
},
{
// Split pane...
"name": { "key": "SplitPaneParentCommandName" },
"commands": [
{
"iterateOn": "profiles",
"icon": "${profile.icon}",
"name": "${profile.name}...",
"commands": [
{
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "auto" }
},
{
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 16:14:57 -04:00
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "up" }
Add a pair of nested, iterable default commands (#7348) ## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-08-21 09:54:43 -05:00
},
{
Add the ability to split a pane and put the new pane first. (#11145) <!-- 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 directional modifiers for SplitState and convert those to the appropriate horizontal/vertical when splitting a pane. <!-- 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 #4340 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [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. * [ ] 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 "vertical" and "horizontal" splits were removed from `defaults.json`, but code was added to parse those as `right` and `down` respectively. It is also the case that if a user has a custom hotkey for `split: vertical` it will override the default for `split: right`. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Split the pane using each of the new directional movements
2021-09-15 16:14:57 -04:00
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "down" }
},
{
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "left" }
},
{
"command": { "action": "splitPane", "profile": "${profile.name}", "split": "right" }
Add a pair of nested, iterable default commands (#7348) ## Summary of the Pull Request ![cmdpal-default-nested-commands](https://user-images.githubusercontent.com/18356694/90684483-e6b13400-e22d-11ea-8ca6-fe90ca8d9e82.gif) Adds a pair of top-level commands that both have nested, iterable sub-commands. The "New Tab..." command has one child for each profile, and will open a new tab for that profile. The "Split Pane..." command similarly has a nested command for each profile, and also has a nested command for split auto/horizontal/vertical. ## References * megathread: #5400 * Would look better with icons from #6644 ## PR Checklist * [x] Closes #7174 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated
2020-08-21 09:54:43 -05:00
}
]
}
]
Add `adjustOpacity` action (#12092) Adds an action which can be used to change the opacity at runtime. This is a follow up to some of the other work I had been doing around opacity and settings previewing at the end of the year. > edit: pseudo-spec > > * `adjustOpacity`: > * `"opacity"`: (**required**) an integer number to set the opacity to. > * `"relative"`: (defaults to `true`) > * If false, set the opacity to the given value, which should be between [0, 100]. > * If true, then use `opacity` as a relative adjustment to the current opacity. So the implementation would get the current opacity for this pane, then add this action's opacity to that value. Should be between [-100, 100] > > This would allow both setting exactly 25% opacity with an action, and binding an action that increases/decreases the opacity one {amount} It's preview-able too, which is neat. ![adjust-opacity-preview-001](https://user-images.githubusercontent.com/18356694/140785805-5eecf6ec-0933-40e4-bcba-41b88d25b6a8.gif) * [x] Closes #11205 * [x] I work here * [x] Docs updated: https://github.com/MicrosoftDocs/terminal/pull/477
2022-01-12 13:06:31 -06:00
},
{
// Set opacity...
"name": { "key": "SetOpacityParentCommandName" },
"commands": [
{ "command": { "action": "adjustOpacity", "opacity": 0, "relative": false } },
{ "command": { "action": "adjustOpacity", "opacity": 25, "relative": false } },
{ "command": { "action": "adjustOpacity", "opacity": 50, "relative": false } },
{ "command": { "action": "adjustOpacity", "opacity": 75, "relative": false } },
{ "command": { "action": "adjustOpacity", "opacity": 100, "relative": false } }
]
Use type inference throughout the project (#12975) #4015 requires sweeping changes in order to allow a migration of our buffer coordinates from `int16_t` to `int32_t`. This commit reduces the size of future commits by using type inference wherever possible, dropping the need to manually adjust types throughout the project later. As an added bonus this commit standardizes the alignment of cv qualifiers to be always left of the type (e.g. `const T&` instead of `T const&`). The migration to type inference with `auto` was mostly done using JetBrains Resharper with some manual intervention and the standardization of cv qualifier alignment using clang-format 14. ## References This is preparation work for #4015. ## Validation Steps Performed * Tests pass ✅
2022-04-25 17:40:47 +02:00
}
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
],
"keybindings": [
// Application-level Keys
{ "keys": "alt+f4", "id": "Terminal.CloseWindow" },
{ "keys": "alt+enter", "id": "Terminal.ToggleFullscreen" },
{ "keys": "f11", "id": "Terminal.ToggleFullscreen" },
{ "keys": "ctrl+shift+space", "id": "Terminal.OpenNewTabDropdown" },
{ "keys": "ctrl+,", "id": "Terminal.OpenSettingsUI" },
{ "keys": "ctrl+shift+,", "id": "Terminal.OpenSettingsFile" },
{ "keys": "ctrl+alt+,", "id": "Terminal.OpenDefaultSettingsFile" },
{ "keys": "ctrl+shift+f", "id": "Terminal.FindText" },
Remove duplicate entries from defaults.json (#18527) - Remove duplicated entries. - Fix whitespace. Co-authored-by: João Guerra <joca-bt@users.noreply.github.com>
2025-02-12 19:06:43 +01:00
{ "keys": "ctrl+shift+p", "id": "Terminal.ToggleCommandPalette" },
{ "keys": "win+sc(41)", "id": "Terminal.QuakeMode" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
{ "keys": "alt+space", "id": "Terminal.OpenSystemMenu" },
Add action for Quick Fix and key binding for Suggestions (#17502) Adds a keybinding to open the quick fix menu, if one is available. When the action is used, we also open up the button (if it was collapsed) because that looks nice. The `showSuggestions` action is bound to `ctrl+shift+period` by default to align with VS' "quick actions" feature and VS Code's "quick fix" feature. This was chosen over binding to `quickFix` because it's more helpful. The quick fix button is a route for users that prefer to use the mouse. If users want to add a keybinding to activate the `quickFix` button, they can do that now. This PR also performs a bit of miscellaneous polish from the bug bash. This includes: - the suggestions UI now presents quick fixes first - scrolling may result in the button being drawn in the wrong place - The bug was tracked down this line: `TermControl::CursorPositionInDips()` --> `_core.CursorPosition()` --> `Terminal::GetViewportRelativeCursorPosition()`. The mutable viewport there does _not_ update when the user scrolls. Thus, the button would be drawn on the same position _on the screen_ even though we scrolled. To fix this, I include the `_scrollOffset` in the calculation. The only other place this function is used is with the suggestions UI, which does _not_ update the UIs position as we scroll (but if we're interested in doing that, we can now). Closes #17377
2024-07-17 15:28:30 -07:00
{ "keys": "ctrl+shift+period", "id": "Terminal.Suggestions" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
// Tab Management
// "command": "closeTab" is unbound by default.
// The closeTab command closes a tab without confirmation, even if it has multiple panes.
{ "keys": "ctrl+shift+t", "id": "Terminal.OpenNewTab" },
{ "keys": "ctrl+shift+n", "id": "Terminal.OpenNewWindow" },
{ "keys": "ctrl+shift+1", "id": "Terminal.OpenNewTabProfile0" },
{ "keys": "ctrl+shift+2", "id": "Terminal.OpenNewTabProfile1" },
{ "keys": "ctrl+shift+3", "id": "Terminal.OpenNewTabProfile2" },
{ "keys": "ctrl+shift+4", "id": "Terminal.OpenNewTabProfile3" },
{ "keys": "ctrl+shift+5", "id": "Terminal.OpenNewTabProfile4" },
{ "keys": "ctrl+shift+6", "id": "Terminal.OpenNewTabProfile5" },
{ "keys": "ctrl+shift+7", "id": "Terminal.OpenNewTabProfile6" },
{ "keys": "ctrl+shift+8", "id": "Terminal.OpenNewTabProfile7" },
{ "keys": "ctrl+shift+9", "id": "Terminal.OpenNewTabProfile8" },
{ "keys": "ctrl+shift+d", "id": "Terminal.DuplicateTab" },
{ "keys": "ctrl+tab", "id": "Terminal.NextTab" },
{ "keys": "ctrl+shift+tab", "id": "Terminal.PrevTab" },
{ "keys": "ctrl+alt+1", "id": "Terminal.SwitchToTab0" },
{ "keys": "ctrl+alt+2", "id": "Terminal.SwitchToTab1" },
{ "keys": "ctrl+alt+3", "id": "Terminal.SwitchToTab2" },
{ "keys": "ctrl+alt+4", "id": "Terminal.SwitchToTab3" },
{ "keys": "ctrl+alt+5", "id": "Terminal.SwitchToTab4" },
{ "keys": "ctrl+alt+6", "id": "Terminal.SwitchToTab5" },
{ "keys": "ctrl+alt+7", "id": "Terminal.SwitchToTab6" },
{ "keys": "ctrl+alt+8", "id": "Terminal.SwitchToTab7" },
{ "keys": "ctrl+alt+9", "id": "Terminal.SwitchToLastTab" },
// Pane Management
{ "keys": "ctrl+shift+w", "id": "Terminal.ClosePane" },
{ "keys": "alt+shift+-", "id": "Terminal.DuplicatePaneDown" },
{ "keys": "alt+shift+plus", "id": "Terminal.DuplicatePaneRight" },
{ "keys": "alt+shift+down", "id": "Terminal.ResizePaneDown" },
{ "keys": "alt+shift+left", "id": "Terminal.ResizePaneLeft" },
{ "keys": "alt+shift+right", "id": "Terminal.ResizePaneRight" },
{ "keys": "alt+shift+up", "id": "Terminal.ResizePaneUp" },
{ "keys": "alt+down", "id": "Terminal.MoveFocusDown" },
{ "keys": "alt+left", "id": "Terminal.MoveFocusLeft" },
{ "keys": "alt+right", "id": "Terminal.MoveFocusRight" },
{ "keys": "alt+up", "id": "Terminal.MoveFocusUp" },
{ "keys": "ctrl+alt+left", "id": "Terminal.MoveFocusPrevious" },
// Clipboard Integration
{ "keys": "ctrl+shift+c", "id": "Terminal.CopyToClipboard" },
{ "keys": "ctrl+insert", "id": "Terminal.CopyToClipboard" },
{ "keys": "enter", "id": "Terminal.CopyToClipboard" },
{ "keys": "ctrl+shift+v", "id": "Terminal.PasteFromClipboard" },
{ "keys": "shift+insert", "id": "Terminal.PasteFromClipboard" },
{ "keys": "ctrl+shift+a", "id": "Terminal.SelectAll" },
{ "keys": "ctrl+shift+m", "id": "Terminal.ToggleMarkMode" },
{ "keys": "menu", "id": "Terminal.ShowContextMenu" },
// Scrollback
{ "keys": "ctrl+shift+down", "id": "Terminal.ScrollDown" },
{ "keys": "ctrl+shift+pgdn", "id": "Terminal.ScrollDownPage" },
{ "keys": "ctrl+shift+up", "id": "Terminal.ScrollUp" },
{ "keys": "ctrl+shift+pgup", "id": "Terminal.ScrollUpPage" },
{ "keys": "ctrl+shift+home", "id": "Terminal.ScrollToTop" },
{ "keys": "ctrl+shift+end", "id": "Terminal.ScrollToBottom" },
Bind "Clear buffer" action to Ctrl+Shift+K (#18900) Closes #17894
2025-05-13 10:46:16 -07:00
{ "keys": "ctrl+shift+k", "id": "Terminal.ClearBuffer" },
Refactor ActionMap and Command to use ActionIDs (#17162) As outlined in #16816, refactor `ActionMap` to use the new action IDs added in #16904 ## Validation steps performed - [x] Legacy style commands are parsed correctly (and rewritten to the new format) - [x] Actions are still layered correctly and their IDs can be used to 'overwrite' actions in earlier layers - [x] Keybindings that refer to an ID defined in another layer work correctly - [x] User-defined actions without an ID have one generated for them (and their settings file is edited with it) - [x] Schema updated Refs #16816 Closes #17133
2024-06-03 17:23:51 -07:00
// Visual Adjustments
{ "keys": "ctrl+plus", "id": "Terminal.IncreaseFontSize" },
{ "keys": "ctrl+minus", "id": "Terminal.DecreaseFontSize" },
{ "keys": "ctrl+numpad_plus", "id": "Terminal.IncreaseFontSize" },
{ "keys": "ctrl+numpad_minus", "id": "Terminal.DecreaseFontSize" },
{ "keys": "ctrl+0", "id": "Terminal.ResetFontSize" },
{ "keys": "ctrl+numpad_0", "id": "Terminal.ResetFontSize" },
Add Cascading User + Default Settings (#2515) This PR represents the start of the work on Cascading User + default settings, #754. Cascading settings will be done in two parts: * [ ] Layered Default+User settings (this PR) * [ ] Dynamic Profile Generation (#2603). Until _both_ are done, _neither are going in. The dynamic profiles PR will target this PR when it's ready, but will go in as a separate commit into master. This PR covers adding one primary feature: the settings are now in two separate files: * a static `defaults.json` that ships with the package (the "default settings") * a `profiles.json` with the user's customizations (the "user settings) User settings are _layered_ upon the settings in the defaults settings. ## References Other things that might be related here: * #1378 - This seems like it's definitely fixed. The default keybindings are _much_ cleaner, and without the save-on-load behavior, the user's keybindings will be left in a good state * #1398 - This might have honestly been solved by #2475 ## PR Checklist * [x] Closes #754 * [x] Closes #1378 * [x] Closes #2566 * [x] I work here * [x] Tests added/passed * [x] Requires documentation to be updated - it **ABSOLUTELY DOES** ## Detailed Description of the Pull Request / Additional comments 1. We start by taking all of the `FromJson` functions in Profile, ColorScheme, Globals, etc, and converting them to `LayerJson` methods. These are effectively the same, with the change that instead of building a new object, they are simply layering the values on top of `this` object. 2. Next, we add tests for layering properties like that. 3. Now, we add a `defaults.json` to the package. This is the file the users can refer to as our default settings. 4. We then take that `defaults.json` and stamp it into an auto generated `.h` file, so we can use it's data without having to worry about reading it from disk. 5. We then change the `LoadAll` function in `CascadiaSettings`. Now, the function does two loads - one from the defaults, and then a second load from the `profiles.json` file, layering the settings from each source upon the previous values. 6. If the `profiles.json` file doesn't exist, we'll create it from a hardcoded `userDefaults.json`, which is stamped in similar to how `defaults.json` is. 7. We also add support for _unbinding_ keybindings that might exist in the `defaults.json`, but the user doesn't want to be bound to anything. 8. We add support for _hiding_ a profile, which is useful if a user doesn't want one of the default profiles to appear in the list of profiles. ## TODO: * [x] Still need to make Alt+Click work on the settings button * [x] Need to write some user documentation on how the new settings model works * [x] Fix the pair of tests I broke (re: Duplicate profiles) <hr> * Create profiles by layering them * Update test to layer multiple times on the same profile * Add support for layering an array of profiles, but break a couple tests * Add a defaults.json to the package * Layer colorschemes * Moves tests into individual classes * adds support for layering a colorscheme on top of another * Layer an array of color schemes * oh no, this was missed with #2481 must have committed without staging this change, uh oh. Not like those tests actually work so nbd * Layer keybindings * Read settings from defaults.json + profiles.json, layer appropriately This is like 80% of #754. Needs tests. * Add tests for keybindings * add support to unbind a key with `null` or `"unbound"` or `"garbage"` * Layer or clear optional properties * Add a helper to get an optional variable for a bunch of different types In the end, I think we need to ask _was this worth it_ * Do this with the stretch mode too * Add back in the GUID check for profiles * Add some tests for global settings layering * M A D W I T H P O W E R Add a MsBuild target to auto-generate a header with the defaults.json as a string in the file. That way, we can _always_ load the defaults. Literally impossible to not. * When the user's profile.json doesn't exist, create it from a template * Re-order profiles to match the order set in the user's profiles.json * Add tests for re-ordering profiles to match user ordering * Add support for hiding profiles using `"hidden": true` * Use the hardcoded defaults.json for the exception->"use defaults" case * Somehow I messed up the git submodules? * woo documentation * Fix a Terminal.App.Unit.Tests failure * signed/unsigned is hard * Use Alt+Settings button to open the default settings * Missed a signed/unsigned * Some very preliminary PR feedback * More PR feedback Use the wil helper for the exe path Move jsonutils into their own file kill some dead code * Add templates to these bois * remove some code for generating defaults, reorder defaults.json a tad * Make guid a std::optional * Large block of PR feedback * Remove some dead code * add some comments * tag some todos * stl is love, stl is life * add `-noprofile` * Fix the crash that dustin found * -Encoding ASCII * Set a profile's default scheme to Campbell * Fix the tests I regressed * Update UsingJsonSetting.md to reflect that changes from these PRs * Change how GenerateGuidForProfile works * Make AppKeyBindings do its own serialization * Remove leftover dead code from the previous commit * Fix up an enormous number of PR nits * Fix a typo; Update the defaults to match #2378 * Tiny nits * Some typos, PR nits * Fix this broken defaults case
2019-09-16 12:57:10 -07:00
]
}
Reference in New Issue Copy Permalink