Closes #ISSUE
Initially, the `SettingsUi` trait was tied to `Settings`, however, given
that the `Settings::FileContent` type (which may be the same as the type
that implements `Settings`) will be the type that more directly maps to
the JSON structure (and therefore have the documentation, correct field
names (or `serde` rename attributes), etc) it makes more sense to have
the deriving of `SettingsUi` occur on the `FileContent` type rather than
the `Settings` type.
In order for this to work a relatively important change had to be made
to the derive macro, that being that it now "unwraps" options into their
inner type, so a field with type `Option<Foo>` where `Foo: SettingsUi`
will treat the field as if it were just `Foo`, expecting there to be a
default set in `default.json`. This imposes some restrictions on what
`Settings::FileContent` can be as seen in 1e19398 where `FileContent`
itself can't be optional without manually implementing `SettingsUi`, as
well as introducing some risk that if the `FileContent` type has
`serde(default)`, the default value will override the default value from
`default.json` in the UI even though it may differ (but it should!).
A future PR should probably replace the other settings with `FileContent
= Option<T>` (all of which currently have `T == bool`) with wrapper
structs and have `KEY = None` so the further niceties
`derive(SettingsUi)` will provide such as path renaming, custom UI, auto
naming and doc comment extraction can be used.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Follow up of https://github.com/zed-industries/zed/pull/33334
After chatting with @MrSubidubi we found out that he had an old defaults
setting (most likely from when he encountered a previous window tabbing
bug):
```
❯ defaults read dev.zed.Zed-Nightly
{
NSNavPanelExpandedSizeForOpenMode = "{800, 448}";
NSNavPanelExpandedSizeForSaveMode = "{800, 448}";
NSNavPanelExpandedStateForSaveMode = 1;
NSOSPLastRootDirectory = {length = 828, bytes = 0x626f6f6b 3c030000 00000410 30000000 ... dc010000 00000000 };
"NSWindow Frame NSNavPanelAutosaveName" = "557 1726 800 448 -323 982 2560 1440 ";
"NSWindowTabbingShoudShowTabBarKey-GPUIWindow-GPUIWindow-(null)-HT-FS" = 1;
}
```
> That suffix is AppKit’s fallback autosave name when no tabbing
identifier is set. It encodes the NSWindow subclass (GPUIWindow), plus
traits like HT (hidden titlebar) and FS (fullscreen).
Which explains why it only happened on the Nightly build, since each
bundle has it's own defaults. It also explains why the tabbar would
disappear when he activated the `use_system_window_tabs` setting,
because with that setting activated, the tabbing identifier becomes
"zed" (instead of the default one when omitted) for which he didn't have
the `NSWindowTabbingShoudShowTabBarKey` default.
The original implementation was perhaps a bit naive and relied fully on
macOS to determine if the tabbar should be shown. I've updated the code
to always hide the tabbar, if the setting is turned off and there is
only 1 tab entry.
While testing, I also noticed that the menu's like 'merge all windows'
wouldn't become active when the setting was turned on, only after a full
workspace reload. So I added a setting observer as well, to immediately
set the correct window properties to enable all the features without a
reload.
Release Notes:
- N/A
## Goal
This PR creates the initial settings ui structure with the primary goal
of making a settings UI that is
- Comprehensive: All settings are available through the UI
- Correct: Easy to understand the underlying JSON file from the UI
- Intuitive
- Easy to implement per setting so that UI is not a hindrance to future
settings changes
### Structure
The overall structure is settings layer -> data layer -> ui layer.
The settings layer is the pre-existing settings definitions, that
implement the `Settings` trait. The data layer is constructed from
settings primarily through the `SettingsUi` trait, and it's associated
derive macro. The data layer tracks the grouping of the settings, the
json path of the settings, and a data representation of how to render
the controls for the setting in the UI, that is either a marker value
for the component to use (avoiding a dependency on the `ui` crate) or a
custom render function.
Abstracting the data layer from the ui layer allows crates depending on
`settings` to implement their own UI without having to add additional UI
dependencies, thus avoiding circular dependencies. In cases where custom
UI is desired, and a creating a custom render function in the same crate
is infeasible due to circular dependencies, the current solution is to
implement a marker for the component in the `settings` crate, and then
handle the rendering of that component in `settings_ui`.
### Foundation
This PR creates a macro and a trait both called `SettingsUi`. The
`SettingsUi` trait is added as a new trait bound on the `Settings`
trait, this allows the type system to guarantee that all settings
implement UI functionality. The macro is used to derived the trait for
most types, and can be modified through attributes for unique cases as
well.
A derive-macro is used to generate the settings UI trait impl, allowing
it the UI generation to be generated from the static information in our
code base (`default.json`, Struct/Enum names, field names, `serde`
attributes, etc). This allows the UI to be auto-generated for the most
part, and ensures consistency across the UI.
#### Immediate Follow ups
- Add a new `SettingsPath` trait that will be a trait bound on
`SettingsUi` and `Settings`
- This trait will replace the `Settings::key` value to enable
`SettingsUi` to infer the json path of it's derived type
- Figure out how to render `Option<T> where T: SettingsUi` correctly
- Handle `serde` attributes in the `SettingsUi` proc macro to correctly
get json path from a type's field and identity
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This is a pure refactor that consolidates all SSH remoting logic such
that it should be straightforward to add another transport to the
remoting system.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
Release Notes:
- N/A
---
In the same vein as #29538, the "Services" menu on macOS depended on the
text being exactly "Services", not allowing for i18n of the menu name.
This PR introduces a new menu type called `OsMenu` that defines a
special menu that can be populated by the system. Currently, it takes
one enum value, `ServicesMenu` that tells the system to populate its
contents with the items it would usually populate the "Services" menu
with.
An example of this being used has been implemented in the `set_menus`
example:
`cargo run -p gpui --example set_menus`
---
Point to consider:
In `mac/platform.rs:414` the existing code for setting the "Services"
menu remains for backwards compatibility. Should this remain now that
this new method exists to set the menu, or should it be removed?
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This pull request should be idempotent, but lays the groundwork for
avoiding to connect to collab in order to interact with AI features
provided by Zed.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
This PR updates the user menu in the title bar to show the plan from the
`CloudUserStore` instead of the `UserStore`.
We're still leveraging the RPC connection to listen for `UpdateUserPlan`
messages so that we can get live-updates from the server, but we are
merely using this as a signal to re-fetch the information from Cloud.
Release Notes:
- N/A
This PR updates the user menu in the title bar to base the "signed in"
state on the user in the `CloudUserStore` rather than the `UserStore`.
This makes it possible to be signed-in—at least, as far as the user menu
is concerned—even when disconnected from Collab.
Release Notes:
- N/A
Making icons consistent, adjusting spacing, and moving the "Leave Call"
button to be the very last, which makes more sense to me than the
"Share" button being the last. Sharing your project is still part of the
call, so in the left edge of the button strip is where, conceptually,
the option to end the call should be, I think!
Release Notes:
- N/A
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>
Closes#31805
This is an issue with Linux currently that `window.focus` is `None` upon
startup in both X11 and Wayland. Specifically, the order in which
[this](8d05a3d389/crates/gpui/src/window.rs (L3116))
and
[this](8d05a3d389/crates/gpui/src/app.rs (L956))
are executed varies between Linux and macOS. That is, one tries to
remove (blur) focus from a window, while other checks window focus to
put that focus id to a frame. In macOS, blur happens afterwards setting
focus on a frame, but in Linux, the inverse of it happens, leading to
`window.focus` to `None`.
For the time being, we handle all visible buttons to take care of this
**focus can be `None`** case, and make it work anyway. But, we should
look at the deeper issue mentioned above with GPUI. Created new issue to
track that https://github.com/zed-industries/zed/issues/34591.
Release Notes:
- Fixed an issue where button clicks wouldn’t work on startup until
clicked on the center pane on Linux.
@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>
