Project2's LLVM IR size is ~33-44% bigger than project1 due to the fact
that in gpui2 we call async_task::spawn(_local) with impl Future instead
of dyn Future, which leads to quite a few more instantiations of
RawTask.
LLVM-IR size for project2:
| build_type | main | this branch | project1 |
| debug | 2617795 | 2022814 | 1817866 |
| release | 4439033 | 3715086 | 3314489 |
Note that this PR is in line with what was done in GPUI1 (we've also
boxed futures there).
Release Notes:
- N/A
Project2's LLVM IR size is ~20-25% bigger than project1 due to the fact that in gpui2 we call async_task::spawn(_local) with impl Future instead of dyn Future, which leads to quite a few more instantiations of RawTask.
LLVM-IR size for project2:
| build_type | main | this branch | project1 |
| debug | 2617795 | 2022814 | 1817866 |
| release | 4439033 | 3715086 | 3314489 |
This updates our approach to action registration to make it
static/global.
There are 3 different approaches to creating an action, depending on the
complexity of your action's implementation. All of them involve defining
a data type with the correct trait implementations and registering it,
each a bit more powerful / verbose.
* Define a simple list of unit structs that implement `Action` -
`actions!(Foo, Bar, Baz)`
* Make a more complex data type into an action with `#[action]`. This
derives all the necessary traits and registers the action.
```rs
#[action]
struct MoveLeft {
word: true
}
```
* Implement all traits yourself and just register the action with
`#[register_action]`.
Release Notes:
N/A
[[PR Description]]
- Update the default theme player colors for `Zed Pro Moonlight` and
`Zed Pro Daylight`
- Adds the ability to create stories in the `theme2` crate
You can see them by running:
- `cargo run -p storybook2 -- components/players --theme "Zed Pro
Daylight"`
- `cargo run -p storybook2 -- components/players --theme`
The player colors crisscross back and forth on the color wheel so that
the colors are as distinct as possible.
We do have room to add additional players if needed. Just let me know if
we feel like the default 8 aren't cutting it.
Release Notes:
- N/A
This PR adds basic text input to Editors in zed2.
Note that we have *not* yet implemented the
`InputHandler::bounds_for_range` method on `Editor`, so the composition
and emoji picker windows are not yet positioned correctly.
[[PR Description]]
- Adds doc comments for most fields on ThemeColors
- Scaffolds out some upcoming additional fields (Will add in a later PR)
- Renames a few fields:
- `element_placeholder` -> `element_placeholder_text`
- `element_drop_target` -> `drop_target_background`
- Removes the redundant `element_placeholder_text` (This should be set
using `text_placeholder`
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
Ignore this PR for now.
This has a chance to speed up a build in case where e.g. we're
single-threaded in aarch64 build; at that point the x86_64 codegen can
take place. Also, MIR can probably be shared between the two
architectures, further reducing build time.
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
Piotr Osiewicz