Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
https://github.com/user-attachments/assets/78db908e-cfe5-4803-b0dc-4f33bc457840
* starts to extract usernames out of `users/` GitHub API responses, and
pass those along with e-mails in the collab sessions as part of the
`User` data
* adjusts various prefill and seed test methods so that the new data can
be retrieved from GitHub properly
* if there's an active call, where guests have write permissions and
e-mails, allow to trigger `FillCoAuthors` action in the context of the
git panel, that will fill in `co-authored-by:` lines, using e-mail and
names (or GitHub handle names if name is absent)
* the action tries to not duplicate such entries, if any are present
already, and adds those below the rest of the commit input's text
Concerns:
* users with write permissions and no e-mails will be silently omitted
— adding odd entries that try to indicate this or raising pop-ups is
very intrusive (maybe, we can add `#`-prefixed comments?), logging seems
pointless
* it's not clear whether the data prefill will run properly on the
existing users — seems tolerable now, as it seems that we get e-mails
properly already, so we'll see GitHub handles instead of names in the
worst case. This can be prefilled better later.
* e-mails and names for a particular project may be not what the user
wants.
E.g. my `.gitconfig` has
```
[user]
email = mail4score@gmail.com
# .....snip
[includeif "gitdir:**/work/zed/**/.git"]
path = ~/.gitconfig.work
```
and that one has
```
[user]
email = kirill@zed.dev
```
while my GitHub profile is configured so, that `mail4score@gmail.com` is
the public, commit e-mail.
So, when I'm a participant in a Zed session, wrong e-mail will be
picked.
The problem is, it's impossible for a host to get remote's collaborator
git metadata for a particular project, as that might not even exist on
disk for the client.
Seems that we might want to add some "project git URL <-> user name and
email" mapping in the settings(?).
The design of this is not very clear, so the PR concentrates on the
basics for now.
When https://github.com/zed-industries/zed/pull/23308 lands, most of the
issues can be solved by collaborators manually, before committing.
Release Notes:
- N/A
I’ve also updated the documentation in
`development\local-collaboration.md` and
`docs\src\development\windows.md`.
Testing collab on my Windows machine:
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Earlier work by @osiewicz in #21931 aims to fix audio control tooltips
in the title bar to close#21929. However, its logic is not quite
correct, and does not match the toggle behavior for the controls.
This PR corrects the logic to match the toggle behavior for the
controls. It also updates capitalization and wording for consistency.
Release Notes:
- N/A
This PR updates the `call` crate to include the `test-support` feature
for `livekit_client_macos` when `call` is used with `test-support`.
This fixes running `cargo test -p copilot` and `cargo test -p editor`
(and perhaps some other crates).
Release Notes:
- N/A
Supersedes https://github.com/zed-industries/zed/pull/21653
This enables us to use `cargo test -p workspace` on macOS and Linux.
Note that the line diffs in `shared_screen.rs` are spurious, I just
re-ordered the `macos` and `cross-platform` modules to match the order
in the call crate.
Release Notes:
- N/A
Similar to #20826 but keeps the Swift implementation. There were quite a
few changes in the `call` crate, and so that code now has two variants.
Closes#13714
Release Notes:
- Added preliminary Linux support for voice chat and viewing
screenshares.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Issues found:
* audio does not work well with various set-ups using USB
* switching audio during initial join may leave the client with no audio
at all
* audio streaming is done on the main thread, beachballing certain
set-ups
* worse screenshare quality (seems that there's no dynamic scaling
anymore, compared to the Swift SDK)
This reverts commit 1235d0808e.
Release Notes:
- N/A
See https://github.com/livekit/rust-sdks/pull/355
Todo:
* [x] make `call` / `live_kit_client` crates use the livekit rust sdk
* [x] create a fake version of livekit rust API for integration tests
* [x] capture local audio
* [x] play remote audio
* [x] capture local video tracks
* [x] play remote video tracks
* [x] tests passing
* bugs
* [x] deafening does not work
(https://github.com/livekit/rust-sdks/issues/359)
* [x] mute and speaking status are not replicated properly:
(https://github.com/livekit/rust-sdks/issues/358)
* [x] **linux** - crash due to symbol conflict between WebRTC's
BoringSSL and libcurl's openssl
(https://github.com/livekit/rust-sdks/issues/89)
* [x] **linux** - libwebrtc-sys adds undesired dependencies on `libGL`
and `libXext`
* [x] **windows** - linker error, maybe related to the C++ stdlib
(https://github.com/livekit/rust-sdks/issues/364)
```
libwebrtc_sys-54978c6ad5066a35.rlib(video_frame.obj) : error LNK2038:
mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't
match value 'MD_DynamicRelease' in
libtree_sitter_yaml-df6b0adf8f009e8f.rlib(2e40c9e35e9506f4-scanner.o)
```
* [x] audio problems
Release Notes:
- Switch from Swift to Rust LiveKit SDK 🦀
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
This PR adds a new `extension` crate, containing some contents extracted
from the `extension_host`.
Right now it contains just the `ExtensionManifest` and
`ExtensionBuilder`, although we may move more of the extension interface
into here.
The introduction of the `extension` crate allows us to depend on it in
the `extension_cli`, thereby eliminating the need for the `no-webrtc`
feature on a number of crates.
Release Notes:
- N/A
This PR fixes an issue where the `zed-extension` CLI could no longer be
run as a static binary due to the following error:
```
dyld[36964]: Library not loaded: @rpath/WebRTC.framework/WebRTC
Referenced from: <56332E1D-292E-3F9B-97B9-8A9962D21599> /Users/maxdeviant/projects/zed-extensions/zed-extension
Reason: no LC_RPATH's found
fish: Job 1, './zed-extension --scratch-dir .…' terminated by signal SIGABRT (Abort)
```
This is the result of the addition of a dependency on `workspace` to the
`extension` crate (and thus, the `extension_cli` crate) in #12360.
Since we don't actually _need_ WebRTC in the extension CLI, we don't
care about dynamically linking it.
To resolve this, a new `no-webrtc` feature has been added to the
`live_kit_client` client crate and threaded through all of the crates
between it and the `extension_cli`.
Enabling the `no-webrtc` feature will prevent linking to the LiveKit
Swift SDK as well as linking the WebRTC framework.
Release Notes:
- N/A
Co-Authored-By: Mikayla <mikayla@zed.dev>
In a fit of ill-advisedness I called these things remote projects;
forgetting that remote project is also what we call collaboratively
shared projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
Release Notes:
- Made remote projects per-user instead of per-channel. If you'd like to
be part of the remote development alpha, please email hi@zed.dev.
---------
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Nate Butler <1714999+iamnbutler@users.noreply.github.com>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
When leaving a call/room in which a project was shared, the shared
project notification was not getting dismissed when the person that
shared the project left the room.
Although there was a `cx.emit(Event::Left)` call inside room, the event
was never received in the `project_shared_notification` module, because
the room is dropped before the event can be dispatched. Moving the
`cx.emit(Event::Left)` to the active call fixed the problem. Also
renamed `Event::Left` to `Event::RoomLeft` because the room join
equivalent is also called `Event::RoomJoined`.
Release Notes:
- Fixed project shared notification staying open, when the user that
shared the project left the room
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
Add plumbing for hosted projects. This will currently show them if they
exist
but provides no UX to create/rename/delete them.
Also changed the `ChannelId` type to not auto-cast to u64; this avoids
type
confusion if you have multiple id types.
Release Notes:
- N/A
- Open channel notes and chat on channel click
- WIP
- Fix compile error
- Don't join live kit until requested
- Track in_call state separately from in_room
Release Notes:
- Improved channels: you can now be in a channel without joining the
audio call automatically
**or**
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This change makes it so that if you are the first to join a channel,
your project is automatically shared.
It also makes it so that if you join a channel via a link and there are
no shared projects, you open the notes instead of an empty workspace
with nothing.
This is to try and address the discoverability of project sharing: we've
had
two reviews that have talked about channels, but not talked about
sharing
projects into them, which makes me suspect they didn't know about the
feature.
Release Notes:
- Added a setting `share_on_join` (defaulting to true). When set, and
you join an empty channel, your project is automatically shared.
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 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>
