### Summary
This PR introduces channels: a new way of starting collaboration
sessions. You can create channels and invite others to join them. You
can then hold a call in a channel, where any member of the channel is
free to join the call without needing to be invited.
Channels are displayed in a new panel called the collaboration panel,
which now also contains the contacts list, and the current call. The
collaboration popover has been removed from the titlebar.
For now, the channels functionality will only be revealed to staff, so
the public-facing change is just the move from the popover to the panel.
### To-do
* User-facing UI
* [x] signed-out state for collab panel
* [x] new icon for collab panel
* [x] for now, channels section only appears for zed staff
* [x] current call section styling
(https://zed-industries.slack.com/archives/C05CJUNF2BU/p1691189389988239?thread_ts=1691189120.403009&cid=C05CJUNF2BU)
* [x] Channel members
* Channels
* [x] style channel name editor
* [x] decide on a special "empty state" for the panel, when user has no
contacts
* [x] ensure channels are sorted in a consistent way (expose channel id
paths to client)
* [x] Figure out layered panels UX
* [x] Change add contacts to be the same kind of tabbed modal
* [x] race condition between channel updates and user fetches
(`ChannelStore::handle_update_contacts`)
* [x] race condition between joining channels and channel update
messages `collab::rpc::channel_updated`)
* [x] don't display mic as muted when microphone share is pending upon
first joining call
Release Notes:
- Moved the collaboration dropdown into its own panel.
- Added settings for disabling the AI assistant panel button.
- Switch to lazily initializing audio output sources
(https://github.com/zed-industries/community/issues/1840,
https://github.com/zed-industries/community/issues/1919)
I went to add in `zprofile` to the bash language config to get syntax
highlighting for it. After adding it in, Zed was still not highlighting
the file. I checked and saw that we are using `Path::extension()` in
`language_for_file()`, which [returns `None` when a file's name begins
with a
`.`](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.extension),
such as in the case of `.zprofile`. This PR adds a custom method, with
some tests, that just tries to grab the last component in the file name
if `Path::extension` returns `None`. Not sure if `ext` is the best name,
but I can't use `extension`.
Maybe this method should be called `extension_or_hidden_file_name()`?
Release Notes:
- Fixed a bug where language detection would fail for files starting
with `.` in their names.
- Added syntax highlighting for `.zprofile` files
When editing rust code, the project diagnostics view sometimes fails to
update, so that you have to close the view and re-open it to see the
correct state.
This PR fixes one possible cause of that problem. There was an async
step in between *receiving* diagnostics from the language server and
updating the diagnostics, due to an async call to
`LspAdapter::process_diagnostics`. This could cause the following
sequence of events to happen:
1. Rust-analyzer sends us new diagnostics for a file `a.rs`
2. We call `process_diagnostics` with those diagnostics
3. Rust-analyzer sends us a `WorkDoneProgress` message, indicating that
the "flycheck" (aka `cargo check`) process has completed
4. We update the project diagnostics view due to this message.
5. The `process_diagnostics` call for `a.rs` completes
6. 💥 We have the new diagnostics for `a.rs`, but do not update the
project diagnostics view again.
This PR fixes this bug by simply making `process_diagnostics`
synchronous. There is no I/O or expensive computation happening in that
method. If we need to make it asynchronous in the future, we need to
introduce a queue that ensures that `publishDiagnostics` and
`workDoneProgress` messages are processed serially.
Release Notes:
- Fixed a bug where the project diagnostics view would sometimes fail to
update properly when using Rust-analyzer.
Instead of returning a usize for the window id, I'm instead returning a
`WindowHandle<V: View>` where `V` is the type of the window's root view.
@as-cii helped me with a cool technique using generic associated types
where methods on `WindowHandle` can return either T or Option<T>
depending on the `BorrowWindowContext::Result` associated type.
Some example usage...
```rs
let window = cx.add_window(|cx| MyView::new(cx));
let my_view = window.root(cx); // If cx is TestAppContext, returns MyView. Otherwise returns Option<MyView>, because the window could be closed.
```
This isn't insanely beneficial on its own, but I think it will help
clean up our testing story. I'm planning on making `window` more useful
in tests for laying out elements, etc.
- [x] Rework tests that call `add_window` 😅 to expect only a window in
return.
- [x] Get tests passing
- [x] 🚬 test
