It allows us to receive messages from the dispatcher,
which breaks us out of waiting and lets us execute
main thread runnables as a part of the main loop.
Release Notes:
- Fixed a bug that caused inconsistent frame rate when scrolling on
certain hardware.
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
- Send app version and release stage to collab on connect
- Read the new header on the server
Release Notes:
- Added the ability to collaborate with users on different releases of
Zed.
This PR fixes this error when compiling a release build:
<img width="504" alt="Screenshot 2024-01-30 at 2 30 38 PM"
src="https://github.com/zed-industries/zed/assets/1486634/96470735-2b9e-4945-b4c3-c86ef0168b8c">
`DebugBelow` only exists when compiling with `debug_assertions`, so we
only want to implement it using that same criterion.
Release Notes:
- N/A
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR is a follow-up to #7084, where I noted that I wasn't satisfied
with using `SharedUri` to represent both URIs and paths on the local
filesystem:
> I'm still not entirely happy with this naming, as the file paths that
we can store in here are not _really_ URIs, as they are lacking a
protocol.
>
> I want to explore changing `SharedUri` / `SharedUrl` back to alway
storing a URL and treat local filepaths differently, as it seems we're
conflating two different concerns under the same umbrella, at the
moment.
`SharedUri` has now been reverted to just containing a `SharedString`
with a URI.
`ImageSource` now has a new `File` variant that is used to load an image
from a `PathBuf`.
Release Notes:
- N/A
This PR renames `SharedUrl` to `SharedUri` to better reflect its intent.
I'm still not entirely happy with this naming, as the file paths that we
can store in here are not _really_ URIs, as they are lacking a protocol.
I want to explore changing `SharedUri` / `SharedUrl` back to alway
storing a URL and treat local filepaths differently, as it seems we're
conflating two different concerns under the same umbrella, at the
moment.
Release Notes:
- N/A
This PR implements support for loading and displaying images from a
local file using gpui's `img` element.
API Changes:
- Changed `SharedUrl` to `SharedUrl::File`, `SharedUrl::Network`
Usage:
```rust
// load from network
img(SharedUrl::network(...)) // previously img(SharedUrl(...)
// load from filesystem
img(SharedUrl::file(...))
```
This will be useful when implementing markdown image support, because we
need to be able to render images from the filesystem (relative/absolute
path), e.g. when implementing markdown preview #5064.
I also added an example `image` to the gpui crate, let me know if this
is useful. Showcase:
<img width="872" alt="image"
src="https://github.com/zed-industries/zed/assets/53836821/b4310a26-db81-44fa-9a7b-61e7d0ad4349">
**Note**: The example is fetching images from [Lorem
Picsum](https://picsum.photos) ([Github
Repo](https://github.com/DMarby/picsum-photos)), which is a free
resource for fetching images in a specific size. Please let me know if
you're okay with using this in the example.
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.
Simplify Zed's collaboration system by:
- Only allowing member management on root channels.
- Disallowing moving sub-channels between different roots.
- Disallowing public channels nested under private channels.
This should make the mental model easier to understand, and makes it
clearer
who has what access. It is also significantly simpler to implement, and
so
hopefully more performant and less buggy.
Still TODO:
- [x] Update collab_ui to match.
- [x] Fix channel buffer tests.
Release Notes:
- Simplified channel membership management.