This PR extends our support for parsing hex color codes to `Rgba` to
additionally support 3-value (`#rgb`) and 4-value (`#rgba`) formats.
See [here](https://developer.mozilla.org/en-US/docs/Web/CSS/hex-color)
for more details on these hex color variants.
Release Notes:
- N/A
When this feature is set the `themes` module won't be compiled.
This allows us to run the `theme_importer` even when the `themes` module
has compile errors in it.
[[PR Description]]
Adds documentation to ColorScaleSteps:
```rust
/// Returns the specified step in the [`ColorScale`].
#[inline]
pub fn step(&self, step: ColorScaleStep) -> Hsla {
// Steps are one-based, so we need convert to the zero-based vec index.
self.0[step.0 - 1]
}
/// `Step 1` - Used for main application backgrounds.
///
/// This step provides a neutral base for any overlaying components, ideal for applications' main backdrop or empty spaces such as canvas areas.
///
#[inline]
pub fn step_1(&self) -> Hsla {
self.step(ColorScaleStep::ONE)
}
/// `Step 2` - Used for both main application backgrounds and subtle component backgrounds.
///
/// Like `Step 1`, this step allows variations in background styles, from striped tables, sidebar backgrounds, to card backgrounds.
#[inline]
pub fn step_2(&self) -> Hsla {
self.step(ColorScaleStep::TWO)
}
/// `Step 3` - Used for UI component backgrounds in their normal states.
///
/// This step maintains accessibility by guaranteeing a contrast ratio of 4.5:1 with steps 11 and 12 for text. It could also suit hover states for transparent components.
#[inline]
pub fn step_3(&self) -> Hsla {
self.step(ColorScaleStep::THREE)
}
/// `Step 4` - Used for UI component backgrounds in their hover states.
///
/// Also suited for pressed or selected states of components with a transparent background.
#[inline]
pub fn step_4(&self) -> Hsla {
self.step(ColorScaleStep::FOUR)
}
/// `Step 5` - Used for UI component backgrounds in their pressed or selected states.
#[inline]
pub fn step_5(&self) -> Hsla {
self.step(ColorScaleStep::FIVE)
}
/// `Step 6` - Used for subtle borders on non-interactive components.
///
/// Its usage spans from sidebars' borders, headers' dividers, cards' outlines, to alerts' edges and separators.
#[inline]
pub fn step_6(&self) -> Hsla {
self.step(ColorScaleStep::SIX)
}
/// `Step 7` - Used for subtle borders on interactive components.
///
/// This step subtly delineates the boundary of elements users interact with.
#[inline]
pub fn step_7(&self) -> Hsla {
self.step(ColorScaleStep::SEVEN)
}
/// `Step 8` - Used for stronger borders on interactive components and focus rings.
///
/// It strengthens the visibility and accessibility of active elements and their focus states.
#[inline]
pub fn step_8(&self) -> Hsla {
self.step(ColorScaleStep::EIGHT)
}
/// `Step 9` - Used for solid backgrounds.
///
/// `Step 9` is the most saturated step, having the least mix of white or black.
///
/// Due to its high chroma, `Step 9` is versatile and particularly useful for semantic colors such as
/// error, warning, and success indicators.
#[inline]
pub fn step_9(&self) -> Hsla {
self.step(ColorScaleStep::NINE)
}
/// `Step 10` - Used for hovered or active solid backgrounds, particularly when `Step 9` is their normal state.
#[inline]
pub fn step_10(&self) -> Hsla {
self.step(ColorScaleStep::TEN)
}
/// `Step 11` - Used for text and icons requiring low contrast or less emphasis.
#[inline]
pub fn step_11(&self) -> Hsla {
self.step(ColorScaleStep::ELEVEN)
}
/// `Step 12` - Used for text and icons requiring high contrast or prominence.
#[inline]
pub fn step_12(&self) -> Hsla {
self.step(ColorScaleStep::TWELVE)
}
```
Release Notes:
- N/A
This PR reworks the way we define our third-party themes to make them
work as overlays on top of a base theme.
We introduce the concept of a `UserThemeFamily` that contains
`UserTheme`s. Rather than being an entire theme definition on their own,
a `UserTheme` just contains optional overrides for the values in a
`Theme`.
When resolving a `UserTheme`, we apply it on top of the base theme. Any
values not overridden in the `UserTheme` will fall back to the `Theme`
defaults.
Right now we are just using `UserTheme` to model third-party themes that
we distribute with the Zed binary. However, this same structure can also
be used to import arbitrary user themes (such as from a theme registry,
or even a theme blob from the settings file).
Release Notes:
- N/A
This PR renames the `ThemeVariant` type to `Theme`.
This better reflects its purpose, as well as matches the same name as we
had before, which should make porting crates slightly easier.
Release Notes:
- N/A
This PR applies a number of field renames in the `ThemeColors` struct
from the `import-theme` branch.
This will help prevent this branch from diverging too far from `main`.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Marshall Bowers <1486634+maxdeviant@users.noreply.github.com>
This PR removes the `Default` impl for `ThemeColors`.
Since we need default light and dark variants for `ThemeColors`, we
can't use a single `Default` impl.
Release Notes:
- N/A
This PR adjusts the representations of `ColorScale`s to allow us to
remove an unsafe `From` impl when converting from the statically-defined
representation of the scale.
Release Notes:
- N/A
This PR adds a new `ui_font_size` setting that can be used to control
the scale of the entire UI.
We use the value in this setting to set the base rem size of the window.
Release Notes:
- N/A
This PR adjusts the individual color scale functions to return
`ColorScaleSet`s instead of `DefaultColorScaleSet`s.
We only use the `DefaultColorScaleSet`s to simplify the construction of
the scales, so it isn't necessary to surface them outside of the
function.
Release Notes:
- N/A
This PR updates the `ThemeStyles` struct to use the `Refineable` trait
instead of a custom declarative macro for generating refinements.
Release Notes:
- N/A
This PR removes the old `Theme` definition in favor of the new
`ThemeVariant`s.
The new `SyntaxStyles` have been reverted to the old `SyntaxTheme` that
operates by storing the syntax styles as a vector of
`gpui2::HighlightStyle`s.
This is necessary for the intended usage by `language2`, where we find
the longest key in the theme's syntax styles that matches the capture
name:
18431051d9/crates/language2/src/highlight_map.rs (L15-L41)
This PR reworks the theme definition in the `theme2` crate to be based
off of the new theme work that @iamnbutler has been working on.
We're still developing the new theme system, but it is complete enough
that we can now load the default theme and use it to theme the storybook
(albeit with some further refining of the color palette required).
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Marshall Bowers <marshall@zed.dev>