Settings editor theming

[roblourens]

The settings editor needs some new color tokens to be properly themeable. Currently, I use a couple hacks to ensure that the input controls look ok on the default themes. Here I'm documenting and discussing changes to make the editor look nice.

Besides the settings editor, the controls only show up in the sidebar and the panel, so they are only optimized for those backgrounds. The settings editor uses the editor background color, so we need to add separate color tokens for this scenario.

• TOC tree
  • This uses the common list styles that other tree/lists use. This should be safe because the same colors are used on the keybindings editor, on the same editor bg color

• Settings tree

  • Text: I override the list styles to use editorForeground and editorBackground for all states.
  • Border: Currently it uses listActiveSelectionBackground but for some themes, this is the same as the editor background color. This is for themes like "Monokai Pro" that are trying to disable the highlight bg on selected list items and just highlight the text.
  • There is a problem here. I don't use the selected item background as a background because it's too intense for some themes on large expanded settings. And I don't use the selected item text because it's designed to go with the selected item background. So for some themes like "Monokai Pro", it's impossible to tell which setting is selected.
  • The easiest way out of this is to add new tokens for the selected setting border. I propose to add:
    • settings.settingItemActiveSelectionBorder
    • settings.settingItemInactiveSelectionBorder
  • But I'm interested in any other creative suggestions. It's also possible to do something like, compute the distance between two colors (background and selected setting border) to decide whether the border is visible, and if not, fall back on some other color. Not sure we want to get into that.

• "Modified" label

  • I've already added settings.modifiedItemForeground
    

• Controls

  • Currently I steal the select element bg/border for input boxes and checkboxes, just because it looks better in most themes, probably since they also show up in the panel
  • We can either use the same colors for all control types, or provide different tokens for each control type. I think it would be helpful to distinguish controls by color, so I would lean towards different tokens for each type.
  • We need these colors:
    • Foreground
    • Background
    • Border
    • Placeholder? (If we use input placeholders to show the default value)
    • Validation? (We could be showing validation errors at some point but I haven't worked on that yet)
  • For these control types
    • Text
    • Enum
    • Number/Integer
    • Boolean
  • So either 3-5 new colors if all types share colors, or at least 12 if we allow different colors. Another option, they could share all colors except for the background, then I can tweak the background colors to make types look slightly different.

FYI
@bpasero
@Tyriar

Anyone else interested in theming.

[cleidigh]

@roblourens
Do you see the need to add any more theme control for the select box in addition to the current overrides ?

[roblourens]

I don't think so.

[aeschli]

@roblourens Can you add some screenshots to illustrate the various widgets?

[roblourens]

Is this what you mean?

These 4 settings have the 4 types of controls: text, bool, number, enum

[cleidigh]

@roblourens
I'm close to fixing the select box issue , margin issue still.

While working on this noticed a couple of things: (do you still want to track here?)

• Keyboard navigation is tricky as several things to not have tabs stops
• select boxes can merge into each other with no distinction , I think related to your background issues
• below screenshot from my WIP

Indentation, slight change in background color, limit displayed options - kind of tricky, don't really like any of these

[roblourens]

re: keyboard navigation. You can change the selected setting with the up/down arrow keys, then press tab or enter to focus that setting's control. What do you think of that?

Hopefully that border on the select dropdown is enough to distinguish it from other things of the same color.

[cleidigh]

I can't seem to Tab from the initial focus on the search bar into the settings tree.
The last apparent tab stop is the feedback icon. I would think if I tab from the sidebar list
I should land on the top of the setting tree. right now I have to mouseclick
( tedious for the disabled keyboard user like myself)

did I navigate wrong?

[roblourens]

You can use the down arrow to go from the search bar to the settings tree. You should also be able to tab from the table of contents to the settings tree.

[aeschli]

@roblourens Yes, that's a helpful screenshot. Maybe place it right in the description text where you describe the different colors we need. Same for TOC tree, setting tree, "Modified" label. That way we are sure we talks all about the same.

[roblourens]

In the UX call we decided to use focusBorder for the focused setting row border, and add a new color for an inactive border. But I noticed some other themes where this doens't look good. inputActiveOptionBorder might be better but also doesn't work in some themes. But given issues like #54039 this could all change so I'll leave it for now.

[bpasero]

@roblourens also update our docs: https://code.visualstudio.com/docs/getstarted/theme-color-reference

[eamodio]

@roblourens It seems that the background of the inputs isn't using the standard input background color:

As you can see comparing the search settings box and the delay input

[roblourens]

There are separate theme tokens for the controls, so that theme may be overriding it. Otherwise it should be the same. Which theme is that?

[eamodio]

Mine, Amethyst (Dark)

[roblourens]

I see, the problem is that you include dark_plus, dark_vs, and dark_defaults from vscode. The settings inputs will fall back on input.background but only if the extension hasn't configured the settings-specific fields to something else, which yours now has.

Do you know whether including the builtin files like that is a common thing to do?

[eamodio]

Ah, sorry about that. As for including them being common, I couldn't say.

[roblourens]

Ok, hopefully you're ok with just adding overrides to your theme for those settings then.

[eamodio]

Yup, thank you!