theming: support theming customizations through the preferences

[vince-fugnitto]

Feature Description:

The goal is to support customization of the theme through the preferences (settings.json).
With this ability, end-users can easily customize their application's theme (such as the editor), in order to meet their needs and taste.

For example, I use the following theming customizations in my own vscode app (user settings):

"workbench.colorCustomizations": {
  "activityBar.background": "#181818",
  "editor.background": "#1D1D1D",
  "menu.background": "#222222",
  "panel.background": "#222222",
  "sideBar.background": "#1A1A1A",
  "statusBar.background": "#181818"
}

I'd like to see such customziations possible from the framework one day 😃

[danarad05]

@vince-fugnitto @amiramw @offer8

After digging in, we have a few options:

1. Using current @theia/monaco-editor-core@0.20.x which doesn't provider API for updating colorCustomizations, tokenColorCustomizations and semanticTokenColorCustomizations - we can override theme colors using colorCustomizations but we would need to save locally original theme settings as this is overriding theme default settings.
2. We wait for merging of monaco-editor-core@0.23.x and then we could use IWorkbenchThemeService to update colorCustomizations, tokenColorCustomizations and semanticTokenColorCustomizations without overriding theme default settings.
3. Not sure but I think that with monaco@0.23.x we could theoretically update monaco editor colors when updating user settings file - if Theia user settings file location was same as VS Code user settings file - which it isn't currently. Or if we could update monaco to use Theia settings file - so that a change in settings file would be caught by monaco editor.

Please advise
Thanks.

[vince-fugnitto]

@danarad05 I'd be fine to wait for the monaco upgrade if you believe it will lead to a cleaner solution overall and is not the highest priority.

Part of the overall effort might also include registering missing colors through the ColorRegistry, for example:

theia/packages/core/src/browser/common-frontend-contribution.ts

Line 1072 in 3782e9b

registerColors(colors: ColorRegistry): void {

[danarad05]

@vince-fugnitto

Concerning:

if Theia user settings file location was same as VS Code user settings file - which it isn't currently. Or if we could update monaco to use Theia settings file - so that a change in settings file would be caught by monaco editor.

What are reasons- AFAYK - for separating Theia User settings directory from VS Code User settings directory? - meaning , why is Theia User settings dir not in same location as VS Code?

[vince-fugnitto]

@danarad05 Theia User settings directory from VS Code User settings directory?

I'm not really sure as to why we'd want to re-use vscode's configuration directory (located for example in the user's home) or if it makes sense. The framework allows us to build IDE-like products and they should have their own configuration folder (as today) which does not interfere with one another. I do not think it's best practice for example for products to use configurations of other products. It's one thing to support preferences in a workspace that contains .vscode folder, but not a configuration folder.

We must think that each Theia-based product (where a user can potentially install more than one) should manage its own:

• settings
• extensions
• keymaps
• workspaces
• etc.

Think of a scenario where a user has vscode, and multiple theia-based products. The idea of re-using vscode configurations does not work, and means that for each of their products they will get preferences, styling of the other.