Instead of selecting a screen to share arbitrarily, we'll now allow user
to select the screen to share. Note that sharing multiple screens at the
time is still not supported (though prolly not too far-fetched).
Related to #4666
Release Notes:
- Added screen selector dropdown to screen share button
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
This includes making sure that both the agent panel and Zed's edit
prediction have a consistent narrative when it comes to onboarding users
into the AI features, considering the possible different plans and
conditions (such as being signed in/out, account age, etc.)
Release Notes:
- N/A
---------
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
@probably-neb I guess we should be opening the keymap editor from title
bar and menu as well. I believe this got missed in this: #34568.
Release Notes:
- Open Keymap editor from settings from menu and title bar.
A nicer way to visualize in which plan you're in and a bit of
personalization by adding the GitHub handle you're signed with in the
user menu, as a complement to the avatar photo itself. Taking advantage
of the newly added Chip component.
<img width="320" height="476" alt="CleanShot 2025-07-16 at 1 33 08@2x"
src="https://github.com/user-attachments/assets/36718a42-27d1-499e-ac81-1eef2cd00347"
/>
Release Notes:
- N/A
Closes#22869
Release Notes:
- Added `show_menus` setting to always show menu bar for Linux and
Windows.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes #ISSUE
Adds a new `documentation` method to actions, that is extracted from doc
comments when using the `actions!` or derive macros.
Additionally, this PR adds doc comments to as many action definitions in
Zed as possible.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Instead of a menagerie of macros for implementing `Action`, now there
are just two:
* `actions!(editor, [MoveLeft, MoveRight])`
* `#[derive(..., Action)]` with `#[action(namespace = editor)]`
In both contexts, `///` doc comments can be provided and will be used in
`JsonSchema`.
In both contexts, parameters can provided in `#[action(...)]`:
- `namespace = some_namespace` sets the namespace. In Zed this is
required.
- `name = "ActionName"` overrides the action's name. This must not
contain "::".
- `no_json` causes the `build` method to always error and
`action_json_schema` to return `None`
and allows actions not implement `serde::Serialize` and
`schemars::JsonSchema`.
- `no_register` skips registering the action. This is useful for
implementing the `Action` trait
while not supporting invocation by name or JSON deserialization.
- `deprecated_aliases = ["editor::SomeAction"]` specifies deprecated old
names for the action.
These action names should *not* correspond to any actions that are
registered. These old names
can then still be used to refer to invoke this action. In Zed, the
keymap JSON schema will
accept these old names and provide warnings.
- `deprecated = "Message about why this action is deprecation"`
specifies a deprecation message.
In Zed, the keymap JSON schema will cause this to be displayed as a
warning. This is a new feature.
Also makes the following changes since this seems like a good time to
make breaking changes:
* In `zed.rs` tests adds a test with an explicit list of namespaces. The
rationale for this is that there is otherwise no checking of `namespace
= ...` attributes.
* `Action::debug_name` renamed to `name_for_type`, since its only
difference with `name` was that it
* `Action::name` now returns `&'static str` instead of `&str` to match
the return of `name_for_type`. This makes the action trait more limited,
but the code was already assuming that `name_for_type` is the same as
`name`, and it requires `&'static`. So really this just makes the trait
harder to misuse.
* Various action reflection methods now use `&'static str` instead of
`SharedString`.
Release Notes:
- N/A
Closes#30513
- Abstract away common wrapper component to `platform_title_bar`.
- Use it in both zed and rules library.
- For rules library, keep traffic like only style for macOS, and add
custom title bar for Linux and Windows.
Release Notes:
- Added way to minimize, maximize, and close the rules library window
for Linux.
Allows setting element as window control elements which consist of
`Drag`, `Close`, `Max`, or `Min`. This allows you to implement
dynamically sized elements that control the platform window, this is
used for areas such as the title bar. Currently only implemented for
Windows.
Release Notes:
- N/A
Closes#16527
Release Notes:
- Added MacOS titlebar double-click action
---
Unfortunately, Apple doesn't seem to make the "Fill" API public or
documented anywhere.
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Follow up to #31179
In addition to seeing the version when in the `Click to restart and
update Zed` status, this PR allows us to see the version when in
`Downloading Zed update…` or `Installing Zed update…` status, in a
tooltip, when hovering on the activity indicator.
Will merge after tomorrow's release.
Release Notes:
- Added version information, in a tooltip, when hovering on the activity
indicator for both the download and install status.
Closes: https://github.com/zed-industries/zed/issues/31394
Onboarding has been valuable, but we're moving into a new phase as our
user base grows, and our ability to chat with everyone who books a call
will not scale linearly. For now, we are removing the option to book a
call from the application.
Release Notes:
- N/A
This is a follow-up to #30450 so that _global_ `title_bar` configs
shadow _defaults_. The way `SettingsSources::json_merge` works is by
considering non-json-nulls as values to propagate. So it's important
that configs be `Option<T>` so any intent in overriding values is
captured.
This PR follows the same `*Settings<FileContent = *SettingsContent>`
pattern used throughout to keep the `Option`s in the "settings content"
type with the finalized values in the "settings" type.
Release Notes:
- N/A
Closes#27642
Currently, the `Open (cmd-o)` action is used to open a local folder
picker when in a local project, and Zed's remote path modal in the case
of a remote project. While this looks intentional, there is now no way
to open a local project when you are in a remote project window. Neither
by shortcut, nor by UI, as the "Open Local Folder" button uses the same
`Open` action.
The reverse is not true, as we already have an `Open Remote
(ctrl-cmd-o)` action to open the remote modal, where you can select "Add
Folder" which opens the same Zed's remote path modal. This already works
in both local and remote window cases.
This PR makes two changes:
1. It changes `Open (cmd-o)` action such that it should always open the
local file picker regardless of which project is currently open, local
or remote. This way we have two non-ambiguios actions `Open` and `Open
Remote`.
2. It also changes the "Open a project" button (which shows up when no
project is open in the project panel) to open the recent modal (which
contains buttons to open either local or remote) instead of choosing on
behalf of the user.
P.S. If we want to open Zed's remote path modal directly, it should be
different action altogether. Not covered for now.
Release Notes:
- Fixed issue where "Open local folder" was not opening folder picker
when connected to a remote host.
- Added `from_existing_connection` flag to `OpenRemote` action to
directly open path picker for current connection, bypassing the Remote
Projects modal.
This is a dumb first pass at a standard text example. We'll use this to
start digging in to some text/scale rendering issues.
There will be a ton of follow-up features to this, but starting simple.
Release Notes:
- N/A
Designed to pair with #30444 to enable enterprises to make it harder to
sign into the collab server and perhaps accidentally end up sending code
to Zed.
Release Notes:
- N/A
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Follow-up to #30565
This PR fixes the default settings values for the `DiagnosticsSettings`.
The issue here was that due to the `#[derive(Default)]`, `button` would
be false by default, which unintentionally hid the diagnostics button by
default. The `#[serde(default = `default_true`)]` would only apply iff
the diagnostics key was already present in the user's settings. Thus, if
you have
```json
{
"diagnostics": {...}
}
```
in your settings, the button would show (given it was not disabled).
However, if the key was not present, the button was not shown: Due to
the derived default for the entire struct, the value would be false.
This PR fixes this by implementing the default instead and moving the
`#[serde(default)]` up to the level of the struct.
I also did the same for the inline diagnostics settings, which already
had a default impl and thus only needed the serde default on the struct
instead of on all the struct fields.
Lastly, I simplified the title bar settings, since the serde attributes
previously had no effect anyway (deserialization happened in the
`TitlebarSettingsContent`, so these attributes had no effect) and we can
remove the `TitlebarSettingsContent` as well as the attributes if we
implement a proper default implementation instead.
Release Notes:
- Fixed the diagnostics status bar button being hidden by default.
* project search button in the status bar
```jsonc
"search": {
"button": false
},
```
* project diagnostics button in the status bar
```jsonc
"diagnostics": {
"button": false
}
```
* project name and host buttons in the title bar
```jsonc
"title_bar": {
"show_project_items": false
}
```
* git branch button in the title bar
```jsonc
"title_bar": {
"show_branch_name": false
}
```
Before:
<img width="1728" alt="before"
src="https://github.com/user-attachments/assets/4b13b431-3ac1-43b3-8ac7-469e5a9ccf7e"
/>
After:
<img width="1728" alt="after"
src="https://github.com/user-attachments/assets/baf2765a-e27b-47a3-8897-89152b7a7c95"
/>
Release Notes:
- Added more settings to hide buttons from Zed UI
This PR updates the plan display in the user menu in the title bar to
hide plans that do not have a subscription period.
Release Notes:
- Improved the displaying of the plan in the user menu.
This PR removes all of the feature flag checks related to the Agent.
Tried to do this in the least invasive way possible; we can follow up
with a full removal.
Release Notes:
- N/A
Release Notes:
- Changed the git branch picker to make remote-tracking branches less
prominent
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
This PR puts the displaying of the plan in the user menu behind the
`new-billing` feature flag instead of the old `zed-pro` feature flag.
Release Notes:
- N/A
This PR adds the `FeatureFlag` suffix to the feature flag types that
were missing them.
This makes the names easier to search in the codebase.
Release Notes:
- N/A
Release Notes:
- Preview: Removed the layout button from the title bar. The
`bottom_dock_layout` setting still functions.
- Added a setting, `bottom_dock_layout`, for controlling the
relationship between the bottom dock and the left and right docks.
A user reported this issue [on
Discord](https://discord.com/channels/869392257814519848/873292398204170290/1357879959422636185).
The issue here only arises for users which recently installed Zed or had
previously not dismissed the Git Onboarding component. It was introduced
by https://github.com/zed-industries/zed/pull/27412, which made the
banner component reusable.
For every banner, there is a value stored in the KVP store when it was
first dismissed. For the git onboarding banner, this was
`zed_git_banner_dismissed_at` initially, but this key would have been
changed by the linked PR. A change would have resulted in the banner
being shown again for users who already dismissed the panel, so for the
special case of `Git Onboarding`, a check was added which ensured this
would not happen.
However, this check was only added for reading from the key from the DB
but not on writing the git onboarding dismissal it to the DB. Thus, if a
user who had not previously dismissed the panel opened Zed, we would
check for the old key to be present in the DB. Since that would not be
the case, the banner would be shown. If the user dismissed the panel, it
would be stored in the database with the new key. Thus, on a reopen of
Zed, the banner would again be shown since for the old key there would
still be no value present and users are unable to dismiss the panel.
This PR fixes this behavior by moving the check into the method that
generates the key. With this, users which were unaffected by the bug
will still not see the panel again. Users who would install Zed with
this change present will be able to properly dismiss the panel aswell.
Users which were affected by the bug need to dismiss the banner one more
time. That happens because I did not want to modify the dismissal check
to check for two keys (the original one and the new one), as it would
clutter the logic even more for this special case. If this would be
preferred, feel free to let me know.
Release Notes:
- Fixed an issue where dismissing the git onboarding banner would not be
persisted across sessions.
Add the following actions for use while calling: `Mute`, `Deafen`,
`ShareProject`, `ScreenShare`, `LeaveCall`
We were also interested in adding push-to-talk functionality for mute,
but that will go in a followup PR
Release Notes:
- Call actions (mute/screenshare/etc.) can now be bound to keys and run from the command palette.
---------
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This PR completes the process of moving git repository state storage and
scanning logic from the worktree crate to `project::git_store`.
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Conrad <conrad@zed.dev>
Piotr OsiewiczandDanilo Leal
Smit Barmase
Umesh Yadav
Mikayla MakiandKatie Geer
Ben Kunkle
Michael Sloan
Jason Lee
Ben Hamment
Matin Aniss
Chung Wei LeongandMikayla Maki
Joseph T. Lyons
Andres Suarez
Nate Butler
tidely
Tristan HumeandMikayla Maki
Finn Evers
Marshall Bowers
anteater
Shashank Verma
Thomas JensenandMikayla Maki
