This PR cleans out the README.md, moves most relevant build details to
`docs/src/developing_zed__building_zed.md`.
It also restructures and cleans up the Building Zed doc.
There are a number of outstanding TODOs to have this doc be ready for
external folks to be able to build Zed.
Release Notes:
- N/A
Written by @iamnbutler
This PR adds a basic CONTRIBUTING.md. It has a few links that need to be
added, which we marked as coming soon.
Here are a number of follow up tasks we need to do:
- [ ] Add CLA link
- [ ] Add public roadmap link
- [ ] Add link to channels doc once it is up
- [ ] Add link explaining how to find a channel related to your
contribution or or to create one
Release Notes:
- N/A
This PR adds the `color` crate, which will be the home of a number of
color-related utilities, and also acts as an interface between
[`palette`](https://crates.io/crates/palette) and the way `gpui` colors
work.
The goal of this crate is to centralize color utilities like mixing and
blending, building color ramps and sets of colors for state and more.
## Todo:
- [x] hex -> Color
- [x] Color mixing
- [x] Color blending using blend modes (overlay, multiply, etc)
- [ ] ~~Build color ramp from color~~
- [x] Build state set from color
- [ ] ~~Update Theme to use the color crate~~
Release Notes:
- None (Internal changes: Adds the `color` crate for working with
colors.)
In #3910 we made the welcome screen use the same background color as the
editor.
However, this later regressed in
86ea6562cd.
This PR fixes that regression and restores the correct color for the
welcome page.
Release Notes:
- Fixed the background color of the welcome screen.
This removes the terminal performance slightly by removing memmoves that
aren't needed after inlining a call.
It also removes a possibly unnecessary `String` allocation.
Release Notes:
- Improved terminal rendering performance by reducing allocations and
memory operations.
Before this change we wouldn't submit all possible primitives of the
same kind that are less-than the max order.
Result was that we would submit, say, 10 paths each in a separate batch
instead of actually batching them.
This was overly strict because even if the order of two different
primitives was the same, we could have still batched the 1st primitive
kind, if its implicit ordering was less than 2nd kind.
Example: say we have the following primitives and these orders
5x paths, order 3
2x sprites, order 3
Previously, we would submit 1 path, 1 path, 1 path, 1 path, 1 path, then
the sprites.
With this changes, we batch the 5 paths into one batch.
Release Notes:
- Improved performance when rendering lots of selection.
Before this change we wouldn't submit all possible primitives of the
same kind that are less-than the max order.
Result was that we would submit, say, 10 paths each in a separate batch
instead of actually batching them.
This was overly strict because even if the order of two different
primitives was the same, we could have still batched the 1st primitive
kind, if its implicit ordering was less than 2nd kind.
Example: say we have the following primitives and these orders
5x paths, order 3
2x sprites, order 3
Previously, we would submit 1 path, 1 path, 1 path, 1 path, 1 path, then
the sprites.
With this changes, we batch the 5 paths into one batch.
Co-authored-by: Antonio <antonio@zed.dev>
This "adds" the keybindings I was missing in Vim mode (e.g. `Ctrl-[` to
cancel a selection) by fixing the definitions in the keymap from
`Ctrl+[` to `Ctrl-[`.
Release Notes:
- Fixed missing `Ctrl-[` keybindings in Vim mode where `Ctrl-[` should
act like `Esc` but didn't.
This "adds" the keybindings I was missing in Vim mode (e.g. `Ctrl-[` to
cancel a selection) by fixing the definitions in the keymap from
`Ctrl+[` to `Ctrl-[`.
Previously, we were using `size_of` but passing the wrong type in
(`MonochromeSprite` instead of `PathSprite`). This caused us to read
outside of the `sprites` smallvec and triggered the segfault. This
reverts #4078 because I don't think using a `SmallVec` was the issue (it
might have masked this problem though, because we would most of the time
copy from the stack and not from the heap).
With this pull request we are also fixing another potential source of
segfaults, due to checking if we exhausted the instance buffer too late
when drawing underlines.
Release Notes:
- Fixed a crash that could happen during rendering.
Previously, we were using `size_of` but passing the wrong type in
(MonochromeSprite instead of PathSprite). This caused us to read outside
of the `sprites` smallvec and triggered the segfault.
We're occasionally seeing a crash in MetalRenderer::draw.
Looking at the backtrace, it seems almost certainly to be happening in
the call to `ptr::copy_nonoverlapping` on line 604 (see `#Don't Panic!`
channel notes)
As we already have added bounds checking to the destination, it seems
most
likely (however improbable) that somehow we're getting an invalid Ptr
and
length from the SmallVec.
To try and make progress on this, let's try a Vec for a bit lest there
is a subtle issue in SmallVec (though I couldn't spot one).
Release Notes:
- (maybe) Fixes SEGFAULT in MetalRenderer::draw
This PR increases the width of the border that we use to indicate when a
call participant is speaking.
This should make it more apparent in the UI when someone is speaking.
Release Notes:
- Increased the width of the ring used to indicate when someone is
speaking in a call.
