Open pvinis opened 4 years ago
Can you explain what is the problem of having "workbench.colorTheme" in the setting? IMO all state should be in settings.
As I see it, that settings file is my file. I tell vscode how to look, how to work. That means that I can also use that file as a dotfile for me, move it to another computer, and have the same setup.
If vscode needs to save some state for itself, that doesn't concern me as a user. The fact that it's morning and it uses the light theme should not be in that file, the same way the window size is not in that file.
I can tell vscode that I want a new window to have dimensions AxB, and it will use this, and when I resize that new window, it's stored somewhere internally, because it's a temporary thing that can change without me caring about it.
Similarly, I can tell vscode to use a light theme and a dark theme. Then vscode knows, and uses these, and stores the currently used theme somewhere internal, without me needing to know it's morning or night in my settings file.
Does that make sense?
Yes, these are your settings but the current theme is one of these settings. Hidden settings make things very hard to undertstand. What if your user settings says "workbench.colorTheme": "Monokai", but in fact we show a light theme? Also extensions can read the settings through API to find out what the current theme is.
What was discussed was to set it to a variable .e.g "workbench.colorTheme": "${preferredTheme}".
Yes, these are your settings but the current theme is one of these settings. Hidden settings make things very hard to undertstand. What if your user settings says "workbench.colorTheme": "Monokai", but in fact we show a light theme?
If I already have "workbench.preferredDarkColorTheme"
and "workbench.preferredLightColorTheme"
set, I would not look for "workbench.colorTheme"
to see if it's set to Monokai. I would look at the preferred ones.
Also extensions can read the settings through API to find out what the current theme is.
What was discussed was to set it to a variable .e.g "workbench.colorTheme": "${preferredTheme}".
That is great actually. I'm all for it! If "workbench.colorTheme"
is expected to always be there for extensions access etc, a value of "${preferredTheme}"
is great!
Yes, I'm using nix-darwin on macOS, my vscode settings.json is read-only. This means my vscode can switch themes when the system theme changes, but it cannot remember the status : (
It would be really nice if this feature to be added to VS Code. Most modern apps follow the system theme to change to dark or light. It would be amazing if VS Code also allowed specifying which dark and which light theme to switch to if the system theme changes, as the original description suggests.
On Windows (works in 10 and 11), the registry key VS Code should monitor to decide if the theme needs to change or not, is the following:
Apps should use Light (1) or Dark (0) theme:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppsUseLightTheme
FYI, there's another registry key, but AFAIK it's meant to be followed by the OS, not apps:
System should use Light (1) or Dark (0) theme:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize\SystemUsesLightTheme
@carlossanlop VS Code already supports OS theme change (see settings in OP). Concern of this issue is that it updates setting back and forth when OS theme changes to corresponding preferred theme, not about supporting feature in general.
Ah, that wasn't clear to me. The description said "Make settings like:" which led me to think the option didn't exist. Thanks for explaining.
Another problem with changing the settings automatically is that if multiple VS Code windows are open, each of them tries to apply the same change to settings.json at the same time. As a result, what I'm observing is that, at theme change, all windows but one show "Failed to save 'settings.json': The content of the file is newer" and open a tab for settings.json with a "modified" status.
"${preferredTheme}"
seems like a good solution.
This is still an issue.
This is also an issue when using workspaces; the workbench.colorTheme
gets hard-coded in its 'current' state into the .code-workspace
file.
See my comment on #124572.
Like @VergeDX, I ran into this due to my settings.json being read-only and generated by Nix. https://github.com/microsoft/vscode/issues/196119#issue-1954984108
"workbench.colorTheme" should not be in the user settings if the automatic dark-mode switch is on. Or at least it shouldn't be changed by vscode for the user.
That file is for me to tell vscode what to do. Not for vscode to tell me what it did.
My dotfiles are changing depending on the time of day now, and that's not the way it should be.
Copied from about:
Steps to Reproduce:
"workbench.colorTheme": "Base16 Light Tomorrow"
appear in settings. This setting shouldn't be there, it's not my setting. It's vscode's "state".Does this issue occur when all extensions are disabled?: Yes