Following-up on #8330
Invocation
```bash
cargo-machete --with-metadata --skip-target-dir --fix
````
There is more stuff to fix, but it chokes on `async-lock`:
```
cargo-machete found the following unused dependencies in /x/Code/zed:
rpc -- /x/Code/zed/crates/rpc/Cargo.toml:
async_lock
prost_build
serde_derive
Error: Dependency async_lock not found
```
Release Notes:
- N/A
I really think storybook is a cool standalone app but there are some
usability issues that are getting in the way of making this a fun tool
to use.
Currently it is not easy to gracefully exit out of storybook.
In fact even trying to Ctrl-c out of storybook seems currently broken to
me...
So the only real way to exit out of storybook is to kill the process
after a Ctrl-z.
This PR attempts to make this much easier by adding a simple app_menu
with a menu item called quit along with the ability to *Cmd-q* out of
storybook as well...
Both the menu item quit and *Cmd-q* gracefully exit storybook.
There are still a bunch of issues with storybook which I plan on
addressing in future PR's but this is a start and something that to me
is the highest priority to make storybook more functional and easy to
use moving forward.
One of my longer term goals of storybook is to have it be a nice stand
alone application similar to
[Loungy](https://github.com/MatthiasGrandl/Loungy) which can be used as
a nice tutorial application for how to develop a real world *gpui* app.
For that reason I added a *assets/keymaps/storybook.json* file as well.
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 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
The fonts we embed in Zed binary (Zed Sans & Zed Mono) weigh about 30Mb in total and we are cloning them several times during startup and loading of embedded assets (once explicitly in Zed and then under the hood in font-kit). Moreover, after loading we have at least 2 copies of each font in our program; one in .rdata and the other on the heap for use by font-kit.
This commit does away with that distinction (we're no longer allocating the font data) and slightly relaxes the interface of `TextSystem::add_fonts` by expecting one to pass `Cow<[u8]>` instead of `Arc<Vec<u8>>`. Additionally, `AssetSource::get` now returns `Cow<'static, [u8]>` instead of `Cow<'self, [u8]>`; all existing implementations conform with that change.
Note that this optimization takes effect only in Release builds, as the library we use for asset embedding - rust-embed - embeds the assets only in Release mode and in Dev builds it simply loads data from disk. Thus it returns `Cow<[u8]>` in it's interface. Therefore, we still copy that memory around in Dev builds, but that's not really an issue.
This patch makes no assumptions about the build profile we're running under, that's just an intrinsic property of rust-embed.
Tl;dr: this should shave off about 30Mb of memory usage and a fair chunk (~30ms) of startup time.
Release Notes:
- Improved startup time and memory usage.
This PR changes the theme loading to use the JSON themes bundled with
the binary rather then the Rust theme definitions.
### Performance
I profiled this using `cargo run --release` to see what the speed
differences would be now that we're deserializing JSON:
**Before:** `ThemeRegistry::load_user_themes` took 16.656666ms
**After:** `ThemeRegistry::load_user_themes` took 18.784875ms
It's slightly slower, but not by much. There is probably some work we
could do here to bring down the theme loading time in general.
Release Notes:
- N/A
- [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
Adding the typos crate to our CI will take some doing, as we have
several tests which rely on typos in various ways (e.g. checking state
as the user types), but I thought I'd take a first stab at fixing what
it finds.
Release Notes:
- N/A
This PR renames the `h_stack` and `v_stack` to `h_flex` and `v_flex`,
respectively.
We were previously using `h_stack` and `v_stack` to match SwiftUI, but
`h_flex` and `v_flex` fit better with the web/flexbox terminology that
the rest of GPUI uses.
Additionally, we were already calling the utility functions used to
implement `h_stack` and `v_stack` by the new names.
Release Notes:
- N/A
This PR adds some basic stories for collab notifications to make them
easier to work on:
<img width="1076" alt="Screenshot 2024-01-08 at 9 43 39 PM"
src="https://github.com/zed-industries/zed/assets/1486634/4a0adcfa-1134-49c2-b589-74ac1d52af4c">
I factored out a `CollabNotification` component that defines the general
structure for one of these notifications, and this is the component that
we use in the stories, with representative values passed to it to
simulate the different instances of the notification.
We can't use the actual notification components in the stories due to
their data dependencies.
Release Notes:
- N/A
This PR deletes the old `ui` and `storybook` crates in favor of their
newer variants that we'll be landing to `main` in the near future.
### Motivation
These crates are based off the old version of GPUI 2 (the `gpui2`
crate).
At this point we have since transitioned to the new version of GPUI 2
(the `gpui3` crate, currently still on the `gpui2` branch).
Having both copies around is confusing, so the old ones are going the
way of the dinosaurs.
Release Notes:
- N/A
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 mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Nate <nate@zed.dev>
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 mainlines the current state of new GPUI2-based UI from the
`gpui2-ui` branch.
Release Notes:
- N/A
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Marshall Bowers <1486634+maxdeviant@users.noreply.github.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Nate <nate@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
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
