TODO:
- [x] Finish GPUI changes on other operating systems
This is a largely internal change to how we report data to our
diagnostics and telemetry. This PR also includes an update to our blade
backend which allows us to report errors in a more useful way when
failing to initialize blade.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Turns out we still get FocusOut and UnmapNotify events after the window
has been destroyed, which resulted in error messages popping up because
we can't find the window anymore that we want to mark as unfocused.
Release Notes:
- N/A
I noticed that when I use my mouse wheel, we get a ton of the
`XkbStateNotify` events, but the modifiers don't change, so we add a ton
of useless input events for the window.
Release Notes:
- N/A
This helps with the problem of keyboard input feeling laggy when the
event loop is under load.
What would previously happen is:
- N events from X11 arrive
- N events get forwarded to XIM
- N events are handled in N iterations of the event loop (sadly, yes: we
only seem to be getting back one `ClientMessage` per poll from XCB
connection)
- Each event is pushed into the channel
- N event loop iterations are needed to get the events off the channel
and handle them
With this change, we get rid of the last 2 steps: instead of pushing the
event onto a channel, we store it on the XIM handler itself, and then
work it off synchronously.
Usually one shouldn't block the event loop, but I think in this case -
user input! - it's better to handle the events directly instead of
re-enqueuing them again in a channel, where they can accumulate and need
multiple iterations of the loop to be worked off.
This does *not* fix the problem of input feeling choppy/slower when the
system is under load, but it makes the behavior now feel exactly the
same as when XIM is disabled.
I also think the code is easier to understand since it's more
straightforward.
Release Notes:
- N/A
This change ensures that the event loop prioritizes enqueueing another
render or handling user input over executing runnables.
It's a subtle change as a result of a week of digging into performance
on X11. It's also not perfect: ideally we'd get rid of the intermediate
channel here and had more control over when and how we run runnables vs.
X11 events, but I think short of rewriting how we use an event loop,
this is good cost/benefit change.
To illustrate:
Before this change, it was possible to block the app from rendering for
a long time by just creating a ton of futures that were executed on the
"main" thread (we don't have a "main" thread on Linux, but we have a
single thread in which we run the event loop).
That was relatively easy to reproduce by opening the `zed` repository
and starting `rust-analyzer`: at some point `rust-analyzer` sends us so
many notifications, that are all handled in futures, that the event loop
is busy just working off the runnables, never getting to the events that
X11 sends us or our own timer to re-enqueue another render.
When you put print statements into the code to show when which event was
handled, you'd see something like this **before this change**:
```
[ ... hundreds of runnable.run() ... ]
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 56.942049ms
X11 event
new render tick timer. lag: 9.668µs
X11 event
new render tick timer. lag: 9.955µs
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 12.462µs
X11 event
new render tick timer. lag: 14.868µs
X11 event
new render tick timer. lag: 11.234µs
X11 event
new render tick timer. lag: 11.681µs
X11 event
new render tick timer. lag: 13.926µs
X11 event
```
Note the `lag: 56ms`: that's the difference between when we wanted to
execute the callback that enqueues another render and when it ran.
Longer lags are possible, this is just the first one I grabbed from the
logs.
Now, compare this with the logs **after this change**:
```
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
new render tick timer. lag: 36.051µs
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
X11 event
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
runnable.run()
```
In-between many `runnable.run()` we'll always handle events.
So, in essence, what this change does is to introduce 2 priorities into
the X11 event queue:
- high: X11 events (user events, render events, ...), render tick, XIM
events, ...
- low: all async rust code
I've tested this with a debug build and release build and I think the
app now feels more responsive. It doesn't feel perfect still, especially
in the slow debug builds, but I couldn't observe 10s lockups anymore.
Since it's a pretty small change, I think we should go for it and see
how it behaves.
Thanks to @maan2003 this now also includes the same change to Wayland.
Release Notes:
- N/A
---------
Co-authored-by: maan2003 <manmeetmann2003@gmail.com>
This fixes#11236 by ignoring the `bounds.origin` values when the window
is only being resized.
The cause for the issue was that the `ConfigureNotify` event would
contain "wrong" values when the window was being resized (by dragging a
corner).
In my case it would *always* contain x:14/y:49, which is I think might
map to the origin of the top bar in GNOME.
We would then persist these wrong values when serializing the workspace.
On restart, we'd use these values and end up with the window decorations
in the wrong place.
What I still don't know:
1. What exactly the 14/49 map to, because it's not the origin of the top
bar in GNOME. I also tried the X11 TranslateCoordinates call but
couldn't get meaningful results back (even taking scale factor into
account).
2. Why the window decorations end up looking wrong vs. the window being
in the first place. But if you look at my screenshot in #11236, it looks
like the decorations are off exactly by 14/49px.
That being said, I think the solution here is a good one for now: we
don't do an additional X11 call and when we're resizing, we're not
interested in the origin changing.
Release Notes:
- N/A
Proof:
[Screencast from 2024-06-03
15-08-36.webm](https://github.com/zed-industries/zed/assets/1185253/90efccfc-8ec6-42d2-8380-1625eff57805)
Release Notes:
- N/A
Fixes#12198 and some minor fixes:
* IBus was intercepting normal keys like `a`, `k` which caused some
problems in vim mode.
* Wayland: Trying to commit the pre_edit on click wasn't working
properly, should be fixed now.
* X11: The pre_edit was supposed to be cleared when losing keyboard
focus.
* X11: We should commit the pre_edit on click.
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
The method has been tested on:
- Gnome 46 (Working)
- Gnome 40 (Not supported)
Tasks
- [x] Implements a draft which get and provides the user theme to
components which needs it
- [x] Implements a way to call the callback function when the theme is
updated
- [X] Cleans the code
Release notes:
- N/A
This (mostly) allows the CSD added in
https://github.com/zed-industries/zed/pull/11525 to work in X11. It's
still a bit buggy as it detects a second window drag right after the
first one finishes, but it's probably better to change the way window
drags are detected in the title bar itself (as that causes other
issues).
The CSD can be tested by changing the return value of
`should_render_window_controls` to true.
Also fixes F11 crashing.
Release Notes:
- N/A
If opening a url opens the first browser window the call does not return
completely blocking the ui until the browser window is closed. Using
spawn instead of status does not block, but we will loose the exitstatus
of the browser window.
Release Notes:
- N/A
This pull request adds XIM (X Input Method) support to x11 platform.
The implementation utilizes [xim-rs](https://crates.io/crates/xim), a
XIM library written entirely in Rust, to provide asynchronous XIM
communication.
Preedit and candidate positioning are fully supported in the editor
interface, yet notably absent in the terminal environment.
This work is sponsored by [Rainlab Inc.](https://rainlab.co.jp/en/)
Release Notes:
- N/A
---------
Signed-off-by: npmania <np@mkv.li>
Release Notes:
- N/A
Fixes#9207
Known Issues:
- [ ] ~~After launching Zed and immediately trying to change input
method, the input panel will appear at Point{0, 0}~~
- [ ] ~~`ime_handle_preedit` should not trigger `write_to_primary`~~
Move to other PR
- [ ] ~~Cursor is visually stuck at the end.~~ Move to other PR
Currently tested with KDE & fcitx5.
If you go to the file tree and press "x" (which is
"project_panel::RevealInFinder"). It will open the default file
manager(in my case nautilus). But on Linux it makes Zed unresponsive.
This fixes that.
Release Notes:
- Fixed Zed blocked after opening file manager in the file tree on
Linux.
The previous implementation relied on a background thread to wake up the
main thread,
which was prone to priority inversion under heavy load.
In a synthetic test, where we spawn 200 git processes while doing a 5ms
timeout, the old version blocked for 5-80ms, the new version blocks for
5.1-5.4ms.
Release Notes:
- Improved responsiveness of the main thread under high system load
This fixes restart after updates not working on Linux.
On Linux we can't reliably get the binary path after an update, because
the original binary was deleted and the path will contain ` (deleted)`.
See: https://github.com/rust-lang/rust/issues/69343
We *could* strip ` (deleted)` off, but that feels nasty. So instead we
save the original binary path, before we do the installation, then
restart.
Later on, we can also change this to be a _new_ binary path returned by
the installers, which we then have to start.
Release Notes:
- N/A
Now, regardless of how the Zed window is closed, Zed can remember the
window's restore size.
- [x] Windows implementation
- [x] macOS implementation
- [x] Linux implementation (partial)
- [x] update SQL data base (mark column `fullscreen` as deprecated)
The current implementation on Linux is basic, and I'm not sure if it's
correct.
The variable `fullscreen` in SQL can be removed, but I'm unsure how to
do it.
edit: mark `fullscreen` as deprecated
### Case 1
When the window is closed as maximized, reopening it will open in the
maximized state, and returning from maximized state will restore the
position and size it had when it was maximized.
https://github.com/zed-industries/zed/assets/14981363/7207752e-878a-4d43-93a7-41ad1fdb3a06
### Case 2
When the window is closed as fullscreen, reopening it will open in
fullscreen mode, and toggling fullscreen will restore the position and
size it had when it entered fullscreen (note that the fullscreen
application was not recorded in the video, showing a black screen, but
it had actually entered fullscreen mode).
https://github.com/zed-industries/zed/assets/14981363/ea5aa70d-b296-462a-afb3-4c3372883ea3
### What's more
- As English is not my native language, some variable and struct names
may need to be modified to match their actual meaning.
- I am not familiar with the APIs related to macOS and Linux, so
implementation for these two platforms has not been done for now.
- Any suggestions and ideas are welcome.
Release Notes:
- N/A
This implements `app_version` on Linux by using an optional,
compile-time `RELEASE_VERSION` env var that can be set.
We settled on the `RELEASE_VERSION` as the name, since it's similar to
`RELEASE_CHANNEL` which we use in Zed.
cc @ConradIrwin @mikayla-maki
Release Notes:
- N/A
Co-authored-by: Bennet <bennetbo@gmx.de>
This fixes a race-condition that showed up when trying to restart
Nightly/Preview/...
When running with these release channels, Zed tries to ensure that
there's only one instance of Zed running.
It does that by listening on a TCP socket to which other instances can
connect on start. If the other instance receives a message, it knows
that another Zed instance is running and exits.
On Linux, though, we ran into a race condition:
1. `kill -0`, which checks whether a process is still running, returns
an error, signalling that the old Zed process has exited
2. BUT: the process was still listening on the TCP port.
It seems like that on Linux, process resources aren't guaranteed to be
cleaned up as soon as signal handling stops working for a process.
The fix is to wait until the process is no longer listening on any TCP
sockets.
There's a slight downside to this: GPUI processes that never listen on
any TCP sockets now have to pay the cost of an additional `lsof` call
when restarting. We do think that it's a reasonable tradeoff for now
though, since the other options (extending the platform interface to
provide callbacks, sharing the listening port in the framework, ...)
seem wider-reaching only to fix a very local bug.
Release Notes:
- N/A
Co-authored-by: Bennet <bennetbo@gmx.de>
Fixed various small issues on Linux, mainly on Wayland.
Apart from the first commit (which should be self-describing), the other
commits have a description explaining the issue and what they do.
caadc58bead6cb654d7e1da25faaba72be79cd27 should fix
https://github.com/zed-industries/zed/issues/11037
Release Notes:
- N/A
This PR replaces all pointer events on X11 with their XI2 equivalents,
which fixes problems with scroll events not being reported when a mouse
button is down. Additionally it closes#11206 by resetting the tracked
global scroll valulator position with `None` on a leave event to prevent
a large scroll delta if scrolling is done outside the window. Lastly, it
resolves the bad window issue kvark was having.
Release Notes:
- Fixed X11 Scroll snapping (#11206 ).
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Release Notes:
- N/A
This changes the first click detection in Wayland by requiring first
click after the keyboard loses focus, and after a `wl_pointer` enters a
window that has keyboard focus
Notable things I've had to fix due to 1.78:
- Better detection of unused items
- New clippy lint (`assigning_clones`) that points out places where assignment operations with clone rhs could be replaced with more performant `clone_into`
Release Notes:
- N/A
Since Wayland doesn't have a way for windows to activate themselves,
currently, when you click on a link in Zed, the browser window opens in
the background.
This PR implements the `xdg-activation` protocol to get an activation
token, which the browser can use to raise its window.
https://github.com/zed-industries/zed/assets/71973804/8b3456c0-89f8-4201-b1cb-633a149796b7
Release Notes:
- N/A
This should have fixed the problems that some users were reporting with
https://github.com/zed-industries/zed/pull/10695 .
The problem was with devices which send more than one valuator axis in a
single event whereas the original PR assumed there would only ever be
one axis per event. This version also does away with the complicated
device selection and instead just uses the master pointer device, which
automatically uses all sub-pointers.
Edit: Confirmed working for one of the user's which the first attempt
was broken for.
Release Notes:
- Added smooth scrolling for X11 on Linux
- Added horizontal scrolling for X11 on Linux
fixes https://github.com/zed-industries/zed/issues/9132
By setting the app id, window managers like `sway` can apply custom
configuration like `for_window [app_id="zed"] floating enable`.
Tested using `wlprop`/`hyprctl activewindow` for wayland, `xprop` for
x11.
Release Notes:
- Zed now sets the window app id / class, which can be used e.g. in
window managers like `sway`/`i3` to define custom rules
fixes#11048
## Problem
in the situation `press right`, `press left`, `release right` the
following happens right now:
- `keypressed right`, `current_keysym` is set to `right`
- `keypressed left`, `current_keysym` is set to `left`
the repeat timer runs asynchronously and emits keyrepeats since
`current_keysym.is_some()`
- `keyreleased right`, `current_keysym` is set to None
the repeat timer no longer emits keyrepeats
- `keyreleased left`, this is where `current_keysym` should actually be
set to None.
## Solution
Only reset `current_keysym` if the released key matches the last pressed
key.
Release Notes:
- N/A
* Otherwise is_maximized always returns `true`
Release Notes:
- Fixed maximized state. Tested with a dummy maximize/restore button
with the `zoom()` (not implemented yet). Without the right `maximized`,
in toggle zoom function is not possible to call `set_maximized()` or
`unset_maximized()`.
```rust
fn zoom(&self) {
if self.is_maximized() {
self.borrow_mut().toplevel.unset_maximized();
} else {
self.borrow_mut().toplevel.set_maximized();
}
}
```
Release Notes:
- N/A
Picks up https://github.com/kvark/blade/pull/113 and a bunch of other
fixes.
Should prevent the exclusive full-screen on Vulkan - related to #9728
cc @kazatsuyu
Note: this PR doesn't enable transparency, this is left to follow-up
Mikayla MakiandConrad Irwin
Thorsten Ball
apricotbucket28
Owen Law
Raunak Raj
Fernando TagawaandMikayla Maki
citorva
Jakob Hellermann
Moritz Bitsch
npmania
bbb651
Flafy
张小白
Soroush MirzaeiandMikayla
Dzmitry MalyshauandJan Solanti
Piotr Osiewicz
Fernando Tagawa