This PR makes it so the One themes—One Dark and One Light—are used as a
fallback when trying to reload a theme that no longer exists in the
registry.
This makes it so when an extension providing the current theme is
removed, the active theme will change to either One Dark or One Light
(based on the system appearance) instead of retaining a cached version
of the theme.
Release Notes:
- Changed the behavior when uninstalling a theme to default to One Dark
or One Light (based on system appearance) rather than keeping a cached
version of the old theme.
This PR updates the various spots where we reload the theme to use
`ThemeSettings::reload_current_theme` instead of duplicating the code
each time.
Release Notes:
- N/A
This PR extends the extension directory watcher to also watch and reload
themes defined in extensions.
Release Notes:
- N/A
Co-authored-by: Max <max@zed.dev>
This PR changes our approach to initializing the `SystemAppearance` so
that we can do it earlier in the startup process.
Previously we were using the appearance from the window, meaning that we
couldn't initialize the value until we first opened the window.
Now we read the `window_appearance` from the `AppContext`. On macOS this
is backed by the
[`effectiveAppearance`](https://developer.apple.com/documentation/appkit/nsapplication/2967171-effectiveappearance)
on the `NSApplication`.
We currently still watch for changes to the appearance at the window
level, as the only hook I could find in the documentation is
[`viewDidChangeEffectiveAppearance`](https://developer.apple.com/documentation/appkit/nsview/2977088-viewdidchangeeffectiveappearance),
which is at the `NSView` level.
In my testing this makes it so Zed appropriately chooses the correct
light/dark theme on startup.
Release Notes:
- N/A
This PR adds support for configuring both a light and dark theme in
`settings.json`.
In addition to accepting just a theme name, the `theme` field now also
accepts an object in the following form:
```jsonc
{
"theme": {
"mode": "system",
"light": "One Light",
"dark": "One Dark"
}
}
```
Both `light` and `dark` are required, and indicate which theme should be
used when the system is in light mode and dark mode, respectively.
The `mode` field is optional and indicates which theme should be used:
- `"system"` - Use the theme that corresponds to the system's
appearance.
- `"light"` - Use the theme indicated by the `light` field.
- `"dark"` - Use the theme indicated by the `dark` field.
Thank you to @Yesterday17 for taking a first stab at this in #6881!
Release Notes:
- Added support for configuring both a light and dark theme and
switching between them based on system preference.
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR adds support for loading user themes in Zed.
Themes are loaded from the `themes` directory under the Zed config:
`~/.config/zed/themes`. This directory should contain JSON files
containing a `ThemeFamilyContent`.
Here's an example of the general structure of a theme family file:
```jsonc
{
"name": "Vitesse",
"author": "Anthony Fu",
"themes": [
{
"name": "Vitesse Dark Soft",
"appearance": "dark",
"style": {
"border": "#252525",
// ...
}
}
]
}
```
Themes placed in this directory will be loaded and available in the
theme selector.
Release Notes:
- Added support for loading user themes from `~/.config/zed/themes`.
This PR reworks how we access the `ThemeRegistry` global.
Previously we were making calls directly on the context, like
`cx.global::<ThemeRegistry>`. However, one problem with this is that it
spreads out the knowledge of exactly what type is stored in the global.
In order to make it easier to adjust the type we store in the context
(e.g., wrapping the `ThemeRegistry` in an `Arc`), we now call methods on
the `ThemeRegistry` itself for accessing the global.
It would also be interesting to see how we could prevent access to the
`ThemeRegistry` without going through one of these dedicated methods 🤔
Release Notes:
- N/A
This PR adds serialized versions of each of the themes that currently
ship with Zed.
In a future PR we'll be looking to make these the canonical
representations of the built-in themes.
Note that we're intentionally repurposing the `theme_importer` to do
this, so that crate is a bit rough-and-ready at the moment.
Release Notes:
- N/A
JSON LSP adapter now caches the schema. `workspace_configuration` is
back to being async, and we are also no longer asking for font names
twice while constructing the schema.
Release Notes:
- Improved performance when opening the .json files.
---------
Co-authored-by: Kirill <kirill@zed.dev>
This PR adds **experimental** support for overriding theme values in the
current theme.
Be advised that both the existence of this setting and the structure of
the theme itself are subject to change.
But this is a first step towards allowing Zed users to customize or
bring their own themes.
### How it works
There is a new `experimental.theme_overrides` setting in
`settings.json`.
This accepts an object containing overrides for values in the theme. All
values are optional, and will be overlaid on top of whatever theme you
currently have set by the `theme` field.
There is JSON schema support to show which values are supported.
### Example
Here's an example of it in action:
https://github.com/zed-industries/zed/assets/1486634/173b94b1-4d88-4333-b980-8fed937e6f6d
Release Notes:
- Added `experimental.theme_overrides` to `settings.json` to allow for
customizing the current theme.
- This setting is experimental and subject to change.
Marshall Bowers
Max Brunsfeld
Nate ButlerandAntonio Scandurra
