CLOSES #39042
This is a reopening of #34985+.
_Original descrioption_:
In Wayland, the client implement key repeat themself. In Zed this is
ultimately handled by the gpui crate by inserting a timer source into
the event loop which repeat itself if the key is still held down [1].
But it seems the processing of the repeated key event happen
synchronously inside the timer source handler, meaning the effective
rate become slightly lower (since the repeated timer is scheduled using
the 1/rate as delay).
I measured the event processing time on my laptop and it's typically
around 3ms, but sometimes spiking at 10ms. At low key repeat rates this
is probably not _very_ noticeable. I see the default in Zed is set to a
(measly) 16/s, but I assume most systems will use something closer to
25, which is a 40ms delay. So ~3ms is around 7.5% of the delay. At
higher rate the discrepancy become worse of course.
I can visible notice the spikes, and doing some crude stopwatch
measurements using gedit as a reference I can reproduce around 5-10%
slower rates in Zed.
IMO this is significant enough to warrant improving, especially since
some people can get quite used the repeat rate and might feel something
being "off" in Zed.
~~The suggested fix simply subtract the processing time from the next
delay timer.~~
[1] https://github.com/olejorgenb/zed/blob/32df726f3b7fa83e7399f6629c59e0a3f3fff125/crates/gpui/src/platform/linux/wayland/client.rs#L1355
Release Notes:
- Improved Wayland (Linux) key repeat rate precision
It is optional for Wayland servers to support server-side decorations.
In particular, GNOME chooses to not implement SSD
(https://gitlab.gnome.org/GNOME/mutter/-/issues/217). So, even if the
application requests SSD, it must draw client-side decorations unless
the application receives a response from the server confirming the
request for SSD.
Before, when the user requested SSD for Zed, but the Wayland server did
not support it, there were no server-side decorations (window titlebar)
drawn, but Zed did not draw the window minimize, maximize, and close
buttons either. This fixes Zed so it always draws the window control
buttons if the Wayland server does not support SSD.
Before on GNOME Wayland with SSD requested:
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/68a6d853-623d-401f-8e7f-21d4dea00543"
/>
After on GNOME Wayland with SSD requested:
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/b258ae8b-fe0e-4ba2-a541-ef6f2c38f788"
/>
Release Notes:
- Fixed window control buttons not showing in GNOME Wayland when SSD
requested
Reverts zed-industries/zed#36848
Turns out this broke copying a screenshot from apps like CleanShot X and
then pasting it over. We should land this again after taking a look at
those cases. Pasting screenshots from the native macOS screenshot
functionality works though.
cc @seantimm
Release Notes:
- Fixed issue where copying a screenshot from apps like CleanShot X into
Agent Panel didn't work as expected.
Problem: Some macOS environments report no devices via
MTLCopyAllDevices, causing startup failure with “unable to access a
compatible graphics device,” especially on Apple Silicon.
Change: Prefer MTLCreateSystemDefaultDevice
(metal::Device::system_default()) first. If None, enumerate devices and
select a non‑removable, low‑power device by preference.
Why this works: On Apple Silicon the system default is the unified GPU;
on Intel, the fallback keeps a stable policy and avoids accidentally
picking removable/high‑power devices.
Impact: Fixes startup on affected ASi systems; improves selection
consistency on Intel multi‑GPU. Behavior unchanged where
system_default() succeeds.
Risk: Low. Aligns with Apple’s recommended selection path. Still fails
early with a clearer message if no Metal devices exist.
Closes#37689.
Release Notes:
- Fixed: Startup failure on some Apple Silicon machines when Metal
device enumeration returned no devices by falling back to the system
default device.
---------
Co-authored-by: 张小白 <364772080@qq.com>
Co-authored-by: Kate <work@localcc.cc>
The WM_DPICHANGED suggested RECT is calculated for non-maximized
windows. When a maximized window's DPI changes, we now query the
monitor's work area directly to ensure the window correctly fills the
entire screen.
For non-maximized windows, the original behavior using the
system-suggested RECT is preserved.
Release Notes:
- windows: Fixed maximized window size when DPI scale changes
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Closes https://github.com/zed-industries/zed/issues/42944
The powershell we discovered might be in a directory with higher
permission requirements which will cause us to fail using it.
Release Notes:
- Fixed powershell discovery disregarding admin requirements
This PR updates window background rendering to use the **official DWM
backdrop API** (`DwmSetWindowAttribute`) instead of the legacy
`SetWindowCompositionAttribute`.
It also adds **Mica** and **Mica Alt** options to
`WindowBackgroundAppearance` for native Windows 11 effects.
### Motivation
Enables modern, stable, and GPU-accelerated backdrops consistent with
Windows 11’s Fluent Design.
Removes reliance on undocumented APIs while maintaining backward
compatibility with older Windows versions.
### Changes
* Added `MicaBackdrop` and `MicaAltBackdrop` variants.
* Switched to DWM API for applying backdrop effects.
* Verified fallback behavior on Windows 10.
### Release Notes:
- Added `WindowBackgroundAppearance::MicaBackdrop` and
`WindowBackgroundAppearance::MicaAltBackdrop` for Windows 11 Mica and
Mica Alt window backdrops.
### Screenshots
- `WindowBackgroundAppearance::Blurred`
<img width="553" height="354" alt="image"
src="https://github.com/user-attachments/assets/57c9c25d-9412-4141-94b5-00000cc0b1ec"
/>
- `WindowBackgroundAppearance::MicaBackdrop`
<img width="553" height="354" alt="image"
src="https://github.com/user-attachments/assets/019f541c-3335-4c9e-b026-71f5a1786534"
/>
- `WindowBackgroundAppearance::MicaAltBackdrop`
<img width="553" height="354" alt="image"
src="https://github.com/user-attachments/assets/5128d600-c94d-4c89-b81a-8b842fe1337a"
/>
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Closes#4947
Taken inspiration from @tasuren implementation, plus the addition for
the double click enabled on the whole title bar too to
maximizes/restores the window.
I was not able to test the application on Linux, no need to test on
Windows since the feature is enabled by the OS.
Release Notes:
- Fixed title bar not fully draggable on macOS
- Fixed not being able to maximizes/restores the window with double
click on the whole title bar on macOS
Summary
Fixes UI scaling issue that occurs when starting Zed after disconnecting
an external monitor on macOS. The window's scale factor and drawable
size are now properly updated when the window changes screens.
Problem Description
When an external monitor is disconnected and Zed is started with only
the built-in screen active, the UI scale becomes incorrect. This happens
because:
1. macOS triggers the `window_did_change_screen` callback when a window
moves between displays (including when displays are disconnected)
2. The existing implementation only restarted the display link but
didn't update the window's scale factor or drawable size
3. This left the window with stale scaling information from the previous
display configuration
Root Cause
The `window_did_change_screen` callback in
`crates/gpui/src/platform/mac/window.rs` was missing the logic to update
the window's scale factor and drawable size when moving between screens.
This logic was only present in the `view_did_change_backing_properties
callback`, which isn't triggered when external monitors are
disconnected.
Solution
- Extracted common logic: Created a new `update_window_scale_factor()`
function that encapsulates the scale factor and drawable size update
logic
- Added scale factor update to screen change: Modified
`window_did_change_screen` to call this function after restarting the
display link
- Refactored existing code: Updated `view_did_change_backing_properties`
to use the new shared function, reducing code duplication
The fix ensures that whenever a window changes screens (due to monitor
disconnect, reconnect, or manual movement), the scale factor, drawable
size, and renderer state are properly synchronized.
Testing
- ✅ Verified that UI scaling remains correct after disconnecting
external monitor
- ✅ Confirmed that reconnecting external monitor works properly
- ✅ Tested that manual window movement between displays updates scaling
correctly
- ✅ No regressions observed in normal window operations
To verity my fix worked I had to copy my preview workspace over my dev
workspace, once I had done this I could reproduce the issue on main
consistently. After switching to the branch with this fix the issue was
resolved.
The fix is similar to what was done on
https://github.com/zed-industries/zed/pull/35686 (Windows)
Closes#37245#38229
Release Notes:
- Fixed: Update scale factor and drawable size when macOS window changes
screen
---------
Co-authored-by: Kate <work@localcc.cc>
We've had several outages with a proximate cause of "vercel is
complicated",
and auto-update is considered a critical feature; so lets not use vercel
for
that.
Release Notes:
- Auto Updates (and remote server binaries) are now downloaded via
https://cloud.zed.dev instead of https://zed.dev. As before, these URLs
redirect to the GitHub release for actual downloads.
- Enable Alt+Numpad input
- For this to be effective, the default keybindings for Alt+{Number}
will need to be unbound. This won't be needed once we gain the ability
to differentiate numpad digit keys from alphanumeric digit keys.
- Fixes https://github.com/zed-industries/zed/issues/40699
- Fix a number of edge cases with dead keys
Release Notes:
- N/A
Technically these should not be possible to hit, but sentry says
otherwise. Turning these into errors should give us more information
than the abort due to unwinding across ffi boundaries.
Fixes ZED-321
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Release Notes:
- N/A
---
https://github.com/user-attachments/assets/d46b77ae-88ba-43da-93ad-3656a7fecaf9
The system menu is only support for macOS, so here just modify the macOS
platform special code.
The Windows, Linux used `ApplicationMenu`, I have already added
`checked` option to Zed's ContextMenu.
Then later when this PR merged, we can improve "View" menu to show check
state to panels (Project Panel, Outline Panel, ...).
Given that when we lose our devices unrecoverably we will panic anyways,
might as well do so eagerly which makes it clearer.
Additionally this PR replaces all uses of `ManuallyDrop` with `Option`,
as otherwise we need to do manual bookkeeping of what is and isn't
initialized when we try to recover devices as we can bail out halfway
while recovering. In other words, the code prior to this was fairly
unsound due to freely using `ManuallyDrop::drop`.
Fixes ZED-1SS
Release Notes:
- N/A *or* Added/Fixed/Improved ...
- On macOS, pasting now inserts the actual file path when the clipboard
contains a file URL (public.file-url/public.url)
- Terminal paste remains text-only; no temp files or data URLs are
created. If only raw image bytes exist on the clipboard, paste is a
no-op.
- Scope: macOS only; no dependency changes.
- Added a test (test_file_url_converts_to_path) that verifies URL→path
conversion using a unique pasteboard.
Release Notes:
- Improved pasting on macOS: now inserts the actual file path when the
clipboard contains a file URL (enables image paste support for Claude
Code)
On macOS, the Function key is reserved for system use and should not be
used in application code.
This commit updated keystroke matching and key event handling to ignore
the Function key modifier while users are typing or pressing
keybindings.
For some keyboards with compact layout (like my 65% keyboard), there is
no separated backtick key. Esc and it shares the same physical key. To
input backtick, users may press `Fn-Esc`. However, macOS will still
deliver events with Fn key modifier to applications. Cocoa framework can
handle this correctly, which typically ignore the Fn directly. GPUI
should also follow the same rule, otherwise, the backtick key on those
keyboards won't work.
Release Notes:
- Fixed a bug where typing fn-\` on macOS would not insert a `.
The Alt+Numpad buffer that's maintained by the input stack is getting
corrupted, leading to garbage characters being inserted on keystrokes
like Alt+Up. Disable the automatic handling of Alt+Numpad for now until
the cause of this corruption is understood. The Alt+Numpad input did not
work anyway, so this does not regress anything.
Release Notes:
- windows: Fixed corrupted characters being inserted when Alt is pressed
(preview only)
Works around an issue, which can be reproduced in the following program:
```rs
use windows::Win32::UI::Input::KeyboardAndMouse::{GetKeyboardState, VK_CONTROL};
fn main() {
let mut keyboard_state = [0u8; 256];
unsafe {
GetKeyboardState(&mut keyboard_state).unwrap();
}
let ctrl_down = (keyboard_state[VK_CONTROL.0 as usize] & 0x80) != 0;
println!("Is Ctrl down: {ctrl_down}");
}
```
In debug mode, this program prints the correct answer. In release mode,
it always prints false. The optimizer appears to think that
`keyboard_state` isn't mutated and remains zeroed, and folds the
`modifier_down` comparisons to `false`.
Release Notes:
- N/A
`ICustomDestinationList::AppendCategory` rejects an empty `IObjectArray`
and returns an `E_INVALIDARG` error. Error propagated and caused an
early-return from `update_jump_list()`.
<img width="1628" height="540" alt="image"
src="https://github.com/user-attachments/assets/f8143297-c71e-42a1-a505-66cd77dfa599"
/>
Release Notes:
- N/A
This reintroduces `layer_shell` support after #32651 was reverted. On
top of that, it allows setting options for the created surface,
restricts the enum variant to the `wayland` feature, and adds an example
that renders a clock widget using the protocol.
I've renamed the `WindowKind` variant to `LayerShell` from `Overlay`,
since the protocol can also be used to render wallpapers and such, which
doesn't really fit with the word.
Things I'm still unsure of:
- We need to get the layer options types to the user somehow, but
nothing from the `platform::linux` crate was exported, I'm assuming
intentionally. I've kept the types inside the module (instead of doing
`pub use layer_shell::*` to not pollute the global namespace with
generic words like `Anchor` or `Layer` Let me know if you want to do
this differently.
- I've added the options to the `WindowKind` variant. That's the only
clean way I see to supply them when the window is created. This makes
the kind no longer implement `Copy`.
- The options don't have setter methods yet and can only be defined on
window creation. We'd have to make fallible functions for setting them,
which only work if the underlying surface is a `layer_shell` surface.
That feels un-rust-y.
CC @zeroeightysix
Thanks to @wuliuqii, whose layer-shell implementation I've also looked
at while putting this together.
Release Notes:
- Add support for the `layer_shell` protocol on wayland
---------
Co-authored-by: Ridan Vandenbergh <ridanvandenbergh@gmail.com>
Ole Jørgen Brønner
Lukas Wirth
Piotr OsiewiczandConrad Irwin
Be
Smit Barmase
Xiaobo Liu
Kirill BulatovandLukas Wirth
Barani SandJohn Tur
Ivan Pasquariello
Rafael LüderandKate
localcc
Richard Feldman
TryanksandMikayla Maki
Jason Lee
Sean Timm
Cyandev
scuzqy
Antal Szabó
Hilmar WiegandandRidan Vandenbergh
Sushant Mishra