Skip to content

Add default values to defaults.json#5231

Merged
13 commits merged intomasterfrom
dev/cazamor/settings-defaults
Apr 9, 2020
Merged

Add default values to defaults.json#5231
13 commits merged intomasterfrom
dev/cazamor/settings-defaults

Conversation

@carlos-zamora
Copy link
Member

@carlos-zamora carlos-zamora commented Apr 3, 2020

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

Validation Steps Performed

After making the changes, I made sure all of the settings are deserialized by debugging and stepping through the LayerJson code.

  • 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

@carlos-zamora carlos-zamora added the Area-Settings Issues related to settings and customizability, for console or terminal label Apr 3, 2020
@carlos-zamora
Copy link
Member Author

I'm also cross-validating this with the schema by moving these settings to settings.json and running the updated schema on it. Here's some interesting findings:

  • Global Settings: None
  • Profile Settings:
    • "Warning: Incorrect type. Expected string." when I set these properties to null
      • "backgroundImage"
      • "selectionBackground"
      • "cursorColor"
      • "cursorHeight"
      • "icon"
      • "tabTitle"
      • "source"
  • Keybindings:

I can add "null" as acceptable via the schema and double check it serializes them properly by setting them in "profiles.defaults" then trying to unset them in my "profiles.list".

But again, I want a "go-ahead" before I start doing that.

@DHowett-MSFT
Copy link
Contributor

Null is allowable for those.

@WSLUser
Copy link
Contributor

WSLUser commented Apr 6, 2020

I like the changes if user feedback is a factor here. Use of null makes sense to me for those particular settings. You can always define those manually in profiles.json, which is what usually happens anyways.

Should I go ahead and make sure all keybindings are there too?

Yes.

I can also add in missing keybinding args and set them to their default value just to show that they exist

This would prove helpful when configuring your own keybindings (instead of having to go to docs). Basically the defaults.json is a template and profiles.json should be a mirror replica that overrides defaults.json for those settings that are explicitly different.

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I like the format of using the profiles.defaults like this.
  2. If it isn't terribly difficult to add the possible keybinding args too, that would probably also be appreciated.

// If `profiles` was an object, then look for the `defaults` object
// underneath it for the default profile settings.
auto defaultSettings{ Json::Value::null };
auto primaryDefaultSettings{ Json::Value::null };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is implemented in somewhat the wrong order. Right now we...

  1. Load defaults/profiles.list
  2. Apply defaults/profiles.defaults
  3. Apply user/profiles.defaults
  4. Load user/profiles.list

when what we really want is to swap 1 and 2.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. This was a lot larger and more complex of a change than we hoped. Removed the code changes and opened #5276

@carlos-zamora
Copy link
Member Author

carlos-zamora commented Apr 7, 2020

Follow-up tasks:

  • Allow null for some color settings in the schema #5279: selectionBackground and cursorColor should be nullable in the schema
    • this requires me doing some untangling from the Color reference. It's a sizeable change.
  • #YYYY: allow keys to be nullable
    • similar problem as before. Requires some untangling that may be a bit too big.
    • RESOLUTION: no schema change necessary. Just add in as a comment.

I'll probably do them all as one PR. But I'll update this comment with the appropriate follow-up GH issues.

@DHowett-MSFT
Copy link
Contributor

• #YYYY: allow keys to be nullable

sorry, what? absolutely not.

@carlos-zamora
Copy link
Member Author

• #YYYY: allow keys to be nullable

sorry, what? absolutely not.

Well, this one's annoying. So we have the closeTab keybinding action. This isn't set by default. I added it in like this:

{ "command": "closeTab", "keys": null },

but I'm not fond of it.

@carlos-zamora
Copy link
Member Author

FYI: I omitted adding the newTerminalArgs for splitPane and newTab because they're really cumbersome. I think they'd be more confusing to see than not to see.

@DHowett-MSFT
Copy link
Contributor

This is an example of somewhere we definitely shouldn't violate our schema just to educate users about an option they almost certainly do not want to begin with.

@DHowett-MSFT
Copy link
Contributor

like, put that thing in a comment with a keys value and say it closes a whole tab without confirmation even if it has multiple panes in

@carlos-zamora
Copy link
Member Author

@DHowett-MSFT hmm, should I do the same with this then? There's no real value for a user to define them as null.

  • #XXXX: selectionBackground and cursorColor should be nullable in the schema

@DHowett-MSFT
Copy link
Contributor

For those, there is. Cascading settings mean that they could be inherited from some other place, and they would need to be uninherited.

@carlos-zamora carlos-zamora force-pushed the dev/cazamor/settings-defaults branch from e85da26 to 8914042 Compare April 7, 2020 22:04
// Miscellaneous
"confirmCloseAllTabs": true,
"theme": "system",
"rowsToScroll": "system",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i hate this setting.

"source": null,

// Experimental Settings
"experimental.retroTerminalEffect": false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we're going with the "don't make any code changes, and hope that these match the compiled-in defaults forever" option?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope. Latest commit removed these. Unfortunately, if we have profiles as an object instead of a list, I think we just lose all of the profiles.defaults info. So, I've turned it back into a list.

Not happy about this change :/ but I'm still brainstorming a way to make it look prettier.

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Apr 7, 2020
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Apr 7, 2020
@carlos-zamora carlos-zamora marked this pull request as ready for review April 8, 2020 00:05
@cinnamon-msft
Copy link
Contributor

cinnamon-msft commented Apr 8, 2020

Should we put somewhere that ctrl+shift+w will close a tab if there aren't any panes? Or it will close the whole window if there's only one tab?

@DHowett-MSFT
Copy link
Contributor

If we consider it implicit that every tab contains a single pane by default, it is implied.

@cinnamon-msft
Copy link
Contributor

I would argue people would assume there aren't any panes if they didn't split any.

@DHowett-MSFT
Copy link
Contributor

We should rename it to closeTheSmallestThingICurrentlyHaveInFocus.

@carlos-zamora
Copy link
Member Author

Should we put somewhere that ctrl+shift+w will close a tab if there aren't any panes? Or it will close the whole window if there's only one tab?

I think that's something worth mentioning. But defaults.json isn't the place for it. Definitely in the docs though. And the schema too, if it isn't in there already.

{ "command": "find", "keys": "ctrl+shift+f" },

// Tab Management
// "command": "closeTab" is unbound by default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we bind this to something? This seems like basic functionality we should have a binding for.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The windows "standard" is ctrl+f4, but be aware that it doesn't ask for confirmation and will destroy any number of panes worth of work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, we don't ask for confirmation when you click the 'x' button on the tab now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I'm not saying it's more dangerous than the X button, just that it's as dangerous. If we litter minefields around folks' keyboards, like we once did with ctrl+w, there's a chance for DSAT. Not a huge one, just a chance.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm personally ok with it being unbound be default. Mainly because there's other methods to close a tab (i.e.: exit, click X button, close pane, etc...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer it to be bound to ctrl+f4. Every other command except unbound has a default binding.

Copy link
Member Author

@carlos-zamora carlos-zamora Apr 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cinnamon-msft and I had an offline discussion. We'll be holding off on ctrl+f4 being bound to close tab until we can get a confirmation dialog for closing the tab, if multiple panes are open.

follow-up work item: #5301

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good to me

@DHowett-MSFT
Copy link
Contributor

Any changes you make to this file please make sure you reflect to the universal file. Do remember the profiles differ 😄

Co-Authored-By: Dustin L. Howett (MSFT) <[email protected]>
@cinnamon-msft cinnamon-msft self-requested a review April 9, 2020 23:00
@carlos-zamora carlos-zamora added the AutoMerge Marked for automatic merge by the bot when requirements are met label Apr 9, 2020
@ghost
Copy link

ghost commented Apr 9, 2020

Hello @carlos-zamora!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 2bd1e39 into master Apr 9, 2020
@ghost ghost deleted the dev/cazamor/settings-defaults branch April 9, 2020 23:14
@ghost
Copy link

ghost commented Apr 22, 2020

🎉Windows Terminal Preview v0.11.1121.0 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Settings Issues related to settings and customizability, for console or terminal AutoMerge Marked for automatic merge by the bot when requirements are met

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make sure default settings are all set in defaults.json

6 participants