The major change in schemars 1.0 is that now schemas are represented as
plain json values instead of specialized datatypes. This allows for more
concise construction and manipulation.
This change also improves how settings schemas are generated. Each top
level settings type was being generated as a full root schema including
the definitions it references, and then these were merged. This meant
generating all shared definitions multiple times, and might have bugs in
cases where there are two types with the same names.
Now instead the schemar generator's `definitions` are built up as they
normally are and the `Settings` trait no longer has a special
`json_schema` method. To handle types that have schema that vary at
runtime (`FontFamilyName`, `ThemeName`, etc), values of
`ParameterizedJsonSchema` are collected by `inventory`, and the schema
definitions for these types are replaced.
To help check that this doesn't break anything, I tried to minimize the
overall [schema
diff](https://gist.github.com/mgsloan/1de549def20399d6f37943a3c1583ee7)
with some patches to make the order more consistent + schemas also
sorted with `jq -S .`. A skim of the diff shows that the diffs come
from:
* `enum: ["value"]` turning into `const: "value"`
* Differences in handling of newlines for "description"
* Schemas for generic types no longer including the parameter name, now
all disambiguation is with numeric suffixes
* Enums now using `oneOf` instead of `anyOf`.
Release Notes:
- N/A
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This PR updates the `ThemeRegistry` to return structured errors from the
`get` and `get_icon_theme` methods (which are used to retrieve themes
and icon themes, respectively).
We want to be able to carry the name of the theme that was not found as
state on the error, which is why we use a `Result` and not an `Option`.
However, we also want to be able to accurately identify when the error
case is "not found" so we can take appropriate action, based on the
circumstances.
By using a custom error type instead of an `anyhow::Error`, we get both.
There isn't any functional change in this PR. This just sets us up for
future improvements in this error.
Release Notes:
- N/A
This PR reverts #20076 to turn the `ThemeRegistry` back into a regular
struct again.
It doesn't actually help us by having it behind a trait.
Release Notes:
- N/A
This PR converts the `ThemeRegistry` type into a trait instead of a
concrete implementation.
This allows for the extension store to depend on an abstraction rather
than the concrete theme registry implementation.
We currently have two `ThemeRegistry` implementations:
- `RealThemeRegistry` — this was previously the `ThemeRegistry` and
contains the real implementation of the registry.
- `VoidThemeRegistry` — a null object that doesn't have any behavior.
Release Notes:
- N/A
This PR adds a theme preview tab to help get an at a glance overview of
the styles in a theme.
You can open it using `debug: open theme preview`.
The next major theme preview PR will move this into it's own crate, as
it will grow substantially as we add content.
Next for theme preview:
- Update layout to two columns, with controls on the right for selecting
theme, layer/elevation-index, etc.
- Cover more UI elements in preview
- Display theme colors in a more helpful way
- Add syntax & markdown previews
Release Notes:
- Added a way to preview the current theme's styles with the `debug:
open theme preview` command.
This PR does some spring cleaning on the `theme` crate:
- Removed two unused stories and the story dep
- Removed the `one` theme family (from the `theme` crate, not the app),
this is now `zed_default_themes`.
- This will hopefully remove some confusion caused by this theme we
started in rust but didn't end up using
- Removed `theme::prelude` (it just re-exported scale colors, which we
don't use outside `theme`)
- Removed completely unused `zed_pro` themes (we started on these during
the gpui2 port and didn't finish them.)
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR adds a warning when the deprecated `scrollbar_thumb.background`
style property is present in a theme.
This property has been succeeded by `scrollbar.thumb.background`.
The primary reason for this is to get it into the `zed-extension` CLI so
that we can use it to detect which themes need to be updated.
Release Notes:
- N/A
This PR removes the `color` crate, as it was not used anywhere.
We had added this experimentally, but right now its existence is just a
source of confusion.
Release Notes:
- N/A
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
Reverts zed-industries/zed#7481
This would regress performance because we'd be using the standard
library's hash maps everywhere, so reverting for now.
This PR fixes some formatting issues in some of the `Cargo.toml` files.
I tried to fix most of these in #7126, but there were a few that I
missed.
Release Notes:
- N/A
This PR sorts the dependency lists in our `Cargo.toml` files so that
they are in alphabetical order.
This should make them easier to visually scan when looking for a
dependency.
Apologies in advance for any merge conflicts 🙈
Release Notes:
- N/A
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 adds a newtype wrapper around the global `ThemeRegistry`.
This allows us to limit where the `ThemeRegistry` can be accessed
directly via `cx.global` et al., without going through the dedicated
methods on the `ThemeRegistry`.
Release Notes:
- N/A
This PR removes the themes defined using the `UserTheme` types, as we're
now loading the themes via JSON.
The `theme_importer` has also been reworked to read in a VS Code theme
and output a new JSON theme.
Release Notes:
- N/A
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.
- [x] Fill in GPL license text.
- [x] live_kit_client depends on live_kit_server as non-dev dependency,
even though it seems to only be used for tests. Is that an issue?
Release Notes:
- N/A
We temporarily let it grow when the message size exceed the limit,
but restore the buffer's capacity shortly after. This ensures that,
for each connection in its entire lifetime, we only ever use 1MB.
