This PR mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Included in this is a performance improvement to make use of the
`TextLayoutCache` when calling `layout` for `Text` elements.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR fixes the kitchen sink story in the storybook.
Included are some additional changes that make it so the kitchen sink is
automatically populated by all of the defined stories.
Release Notes:
- N/A
This PR removes the need for writing manual mappings in the `FromStr`
implementation for the `StorySelector` enum used in the storybook CLI.
We are now using the
[`EnumString`](https://docs.rs/strum/0.25.0/strum/derive.EnumString.html)
trait from `strum` to automatically derive snake_cased names for the
enums.
This will cut down on some of the manual work needed to wire up more
stories to the storybook.
Release Notes:
- N/A
This PR puts the `Theme` returned from the `theme` function behind an
`Arc`.
### Motivation
While working on wiring up window focus events for the `TitleBar`
component we ran into issues where `theme` was holding an immutable
borrow to the `ViewContext` for the entirety of the `render` scope,
which prevented having mutable borrows in the same scope.
### Explanation
To avoid this, we can make `theme` return an `Arc<Theme>` to allow for
cheap clones and avoiding the issues with the borrow checker.
Release Notes:
- N/A
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This PR factors out the bulk of the boilerplate required to setup a
story in the storybook out into separate components.
The pattern we're using here is adapted from the "[associated
component](https://maxdeviant.com/posts/2021/react-associated-components/)"
pattern in React.
Release Notes:
- N/A
This PR updates the `storybook` with support for adding stories for
individual components.
### Motivation
Right now we just have one story in the storybook that renders an entire
`WorkspaceElement`.
While iterating on the various UI components, it will be helpful to be
able to create stories of those components just by themselves.
This is especially true for components that have a number of different
states, as we can render the components in all of the various states in
a single layout.
### Explanation
We achieve this by adding a simple CLI to the storybook.
The `storybook` binary now accepts an optional `[STORY]` parameter that
can be used to indicate which story should be loaded. If this parameter
is not provided, it will load the workspace story as it currently does.
Passing a story name will load the corresponding story, if it exists.
For example:
```
cargo run -- elements/avatar
```
<img width="723" alt="Screenshot 2023-09-21 at 10 29 52 PM"
src="https://github.com/zed-industries/zed/assets/1486634/5df489ed-8607-4024-9c19-c5f4541f97c9">
```
cargo run -- components/facepile
```
<img width="785" alt="Screenshot 2023-09-21 at 10 30 07 PM"
src="https://github.com/zed-industries/zed/assets/1486634/e04a4577-7403-405d-b23c-e765b7a06229">
Release Notes:
- N/A
This PR reorganizes the exports for the `ui` module in the `storybook`
crate.
### Motivation
Currently we expose each of the various elements/components/modules in
two places:
- Through the module itself (e.g., `ui::element::Avatar`)
- Through the `ui` module's re-exports (e.g., `ui::Avatar`)
This means it's possible to import any given item from two spots, which
can lead to inconsistencies in the consumers. Additionally, it also
means we're shipping the exact module structure underneath `ui` as part
of the public API.
### Explanation
To avoid this, we can avoid exposing each of the individual modules
underneath `ui::{element, component, module}` and instead export just
the module contents themselves.
This makes the `ui` module namespace flat.
Release Notes:
- N/A
Marshall Bowers
Nathan Sobo
