Closes#51312
- Remove platform-specific #[cfg] gates from PinchEvent, event
listeners, and dispatch logic in GPUI
- Windows: Intercept Ctrl+ScrollWheel (emitted by precision trackpads
for pinch gestures) and convert them to GPUI PinchEvents
- Image Viewer: remove redundant platform-specific blocks
- X11: Bump XInput version to 2.4 and implement handlers for
XinputGesturePinch events
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Pinching gestures now available on all devices.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Previously, the GPUI profiler allocates one CircularBuffer per thread,
and `CircularBuffer<N>` always preallocates space for N entries. As a
result it allocates ~20MB/thread, and on my machine about 33 threads are
created at startup for a total of 600MB used.
In this PR I change it to use a VecDeque that can gradually grow up to
20MB as data is written. At least in my experiments it seems that this
caps overall usage at about 21MB perhaps because only one thread writes
very much usage data.
Since this is fixed overhead for everyone running Zed it seems like a
worthwhile gain.
This also folds duplicated code across platforms into the common gpui
profiler.
Before:
<img width="4804" height="2192" alt="Image"
src="https://github.com/user-attachments/assets/7060ee5b-ef80-49cb-b7be-de33e9a2e7a5"
/>
After:
<img width="5052" height="1858" alt="image"
src="https://github.com/user-attachments/assets/513494df-0974-4604-9796-15a12ef1c134"
/>
I got here from #35780 but I don't think this is tree-size related, it
seems to be fixed overhead.
Release Notes:
- Improved: Significantly less memory used to record internal profiling
information.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
After GPU device recovery clears the atlas, the next frame could
re-present a stale scene via the needs_present path (which skips scene
rebuilding). The stale scene references texture IDs that no longer exist
in the cleared atlas, causing an index-out-of-bounds panic.
Fix this by setting a force_render_after_recovery flag when device
recovery completes. The platform refresh loop reads this flag and passes
force_render: true in RequestFrameOptions, ensuring GPUI rebuilds the
scene before presenting.
Fixes ZED-5QT
Release Notes:
- N/A or Added/Fixed/Improved ...
Currently, Zed always places three fixed window buttons (Minimize,
Maximize and Close) on the right side of the window in a fixed order
ignoring any user configuration or desktop environment preference (like
elementary).
This PR adds support for GNOME-style layout strings (`minimize:close`).
By default, we pull it from the gsettings portal, but we also allow
manual configuration via `title_bar.button_layout` config key.
<img width="1538" height="797" alt="image"
src="https://github.com/user-attachments/assets/5db6bfa2-3052-4640-9228-95c37f318929"
/>
Closes#46512
I know it's a relatively large PR for my first one and I'm new to Rust.
So, sorry if I've made any huge mistakes. I had just made it for
personal use and then decided to try to clean it up and submit it.
I've tested with different configs on Linux. Untested on other
platforms, but should have no impact.
If it's not up to par, it's okay, feel free to close :)
Release Notes:
- Added support for GNOME's window buttons configuration on Linux.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
#### Context
On X11, the Settings window title displayed as `"Zed â██ Settings"`
instead of "Zed — Settings"`. The em-dash (U+2014) was garbled because
the window creation path only set the legacy `WM_NAME` property (Latin-1
encoded), but never set `_NET_WM_NAME` (UTF-8). Modern taskbars prefer
`_NET_WM_NAME`, so without it they fell back to `WM_NAME` and
misinterpreted the UTF-8 bytes as Latin-1.
`set_title()` already sets both properties, which is why windows that
update their title after creation (like the main workspace) were
unaffected.
The fix adds `_NET_WM_NAME` during window creation, matching what
`set_title()` already does.
#### Closes#51871
#### How to Review
Single change in `crates/gpui_linux/src/linux/x11/window.rs` focus on
the new `_NET_WM_NAME` property being set alongside the existing
`WM_NAME` in `X11Window::new`.
#### Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
#### Video
[Screencast from 2026-03-19
11-19-45.webm](https://github.com/user-attachments/assets/ff810e37-90ac-4ce2-a8f5-ad83e66aa3b8)
Release Notes:
- Fixed garbled characters in window titles on Linux X11 (e.g., Settings
window)
when a resizing configure event is throttled (skipped to limit redraws
to once per vblank) the xdg_surface serial was never acknowledged. the
early return bypassed the ack_configure call that follows the throttle
check, violating the xdg-shell protocol requirement that every configure
serial be acknowledged before the next surface commit.
fix by calling ack_configure before the early return so the compositor
always receives the acknowledgment, dosent matter whether the resize
itself is applied.
Release Notes:
- N/A
Closes#48169
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed "No Apps Available" dialog when opening URIs on Linux/Wayland
Swaps the order of `open_uri_internal` function: try xdg-open first, and
only fall back to the portal if every candidate command fails.
Build Tests:
I tested the build on Arch Linux & MacOS Tahoe and there were no issues.
No error logs when opening repo links.
When the connection to X is broken zed will go into an infinite loop and
eat up 100% (of one core) of CPU; this change causes it to exit with an
error instead.
I encountered this behavior while running zed in
[Xephyr](https://freedesktop.org/wiki/Software/Xephyr/) for testing,
though I do sometimes terminate my X server as a way to log out or
attempt to recover from a (very) broken state, and I appreciate a
graceful exit in those situations!
Exiting in case of X server disconnect is common practice in my
observations, likely as the difficulty of recreating state stored
server-side outweighs the potential utility in attempting to recover (if
"reconnecting" to an X server is ever desired in regular usage,
[Xpra](https://xpra.org/index.html) might be able to help!).
Release Notes:
- N/A
Previously, `get_layer_surface` always passed `None` as the output,
causing all layer shell windows to appear on the compositor's default
output regardless of the requested display.
Store `wl_output` proxies in client state and resolve them from
`DisplayId` so the correct output is passed to `get_layer_surface`.
Release Notes:
- N/A
Co-Authored-By: Eric Holk <eric@zed.dev>
In app drop we had been calling `.close()` on the executors. This caused
problems with the BackgroundExecutor on Linux because it raced with
concurrent work: If task A was running and about to poll task B, the
poll to task B would panic with "Task polled after completion". This
didn't really matter (because the app was shutting down anyway) but
inflated our panic metrics on Linux.
It turns out that the call to `.close()` is not needed. It was added to
prevent foreground tasks being scheduled after the app was dropped; but
on all platforms the App run method does not return until after the
ForegroundExecutor is stopped (so no further tasks will run anyway).
The background case is more interesting. In test code it didn't matter
(the background executor is simulated on the main thread so tests can't
leak tasks); in app code it also didn't really make a difference. When
`fn main` returns (which it does immediately after the app is dropped)
all the background threads will be cancelled anyway.
Further confounding debugging, it turns out that the App does not get
dropped on macOS and Windows due to a reference cycle; so this was only
happening on Linux where the app quit callback is dropped instead of
retained after being called. (Fix in #50985)
Release Notes:
- N/A
---------
Co-authored-by: Eric Holk <eric@zed.dev>
I'm embedding a 3D viewport inside GPUI by creating a child window with
its own surface that fits the bounds of a GPUI element, and I need
access to the raw window handle of the current window to manage it.
Right now on X11 this is stubbed as unimplemented and results in a
panic. I've copied most of the same implementation from the associated
`RawWindow` into `X11Window`.
Small clip of a Bevy app embedded inside GPUI with a popover that draws
above the 3d surface to show testing was done:
[Screencast_20260304_182657.webm](https://github.com/user-attachments/assets/829f9197-1613-41a7-af83-d377f3154751)
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Added implementations of `rwh::HasDisplayHandle` and
`rwh::HasWindowHandle` for `X11Window`
This uses the compositor hints if available to pick the best GPU. If
none is
available, it tries each GPU in turn, and the first that actually works
is chosen
Release Notes:
- Linux: Select a more appropriate GPU
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Implements a basic web platform for the wasm32-unknown-unknown target
for gpui
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: John Tur <john-tur@outlook.com>
The test suite was failing with this error: methods
`is_screen_capture_supported` and `screen_capture_sources` are never
used. I added allow(dead_code) attribute on both methods to fix it
action that was failing:
https://github.com/zed-industries/zed/actions/runs/22444029970/job/64993825469
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
## Summary
Fixes RefCell borrow panic on Linux (Wayland and X11) when callbacks try
to register new callbacks.
**Root cause:** Linux GPUI backends invoked callbacks while still
holding a `RefCell` borrow on the `Callbacks` struct. If a callback
tried to register a new
callback (e.g., `on_window_should_close`), it would panic with "already
borrowed: BorrowMutError".
**Bug pattern:**
```rust
// Callback runs while borrow is held - panics if callback borrows
callbacks
if let Some(ref mut fun) = self.callbacks.borrow_mut().input {
fun(input);
}
Fix: Apply the take-call-restore pattern (already used in macOS
backend):
// Take callback out, release borrow, call, restore
let callback = self.callbacks.borrow_mut().input.take();
if let Some(mut fun) = callback {
let result = fun(input);
self.callbacks.borrow_mut().input = Some(fun);
}
Changes
- Wayland (window.rs): Fixed 6 callback invocations
- X11 (window.rs): Fixed 4 callback invocations
Test plan
- cargo check -p gpui compiles successfully
- Tested on Linux (Wayland) - no more RefCell panic
Release Notes:
- Fixed a crash on Linux when window callbacks attempted to register new
callbacks
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Fixes ZED-54X
Release Notes:
- Linux: wait to request a graphics context until we have a window so we
can (ideally) pick a better context or (less ideally) fail more
gracefully.
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
#2874 on steroids
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: Eric Holk <eric@zed.dev>
