Closes#32219#29666
Release Notes:
- Linux: Now skips insertion of characters when modifiers are held. Before, characters were inserted if there's no match in the keymap.
Flushes should happen after sending messages to X11 when effects should
be applied quickly. This is not needed for requests that return replies
since it automatically flushes in that case.
Release Notes:
- N/A
Continuing this work from a while back in #21079, now greatly aided by
agent + sonnet 4. With this change, there are now only a few spots that
explicitly panic, though errors during initialization will panic.
Motivation was this recent user panic in `handle_event`, figured fixing
all this use of unwrap was a great use of the agent.
> called `Result::unwrap()` on an `Err` value: X11 GetProperty for
_NET_WM_STATE failed.
Release Notes:
- N/A
Closes#21700
Release Notes:
- Added caps lock support and show a warning if the user is entering an
SSH password with Caps Lock enabled
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: 张小白 <364772080@qq.com>
This adds handling of UnmapNotify / MapNotify / VisibilityNotify to
track whether windows are visible. When hidden, the refresh loop is
halted until visible again. Often these refreshes were just checking if
the window is dirty, but I believe it sometimes did a full re-render for
things that change without user interaction (cursor blink, animations).
This also changes handling of Expose events to set a flag indicating the
next refresh should have `require_presentation: true`.
Release Notes:
- x11: No longer refreshes windows that aren't visible.
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
Release Notes:
- N/A
----
The before version GPUI used `Cancel` for cancel text, if we use
non-English text (e.g.: "取消" in Chinese), then the press `Esc` to cancel
will not work.
So this PR to change it by use `PromptButton` to instead the `&str`,
then we can use `PromptButton::cancel("取消")` for the `Cancel` button.
Run `cargo run -p gpui --example window` to test.
---
Platform Test:
- [x] macOS
- [x] Windows
- [x] Linux (x11 and Wayland)
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This reverts commit 9ef0501853 due to a
panic.
```
{
"thread": "main",
"payload": "9 is not a valid char boundary in path \"crates/…/LiveKitBridge/\"",
"location_data": {
"file": "crates/file_finder/src/file_finder.rs",
"line": 646
}
}
```
Release Notes:
- N/A
This PR makes progress on #7711 by identifying any common prefix of the
paths in the file finder's search results, and replacing the "interior"
of that prefix---every path segment but the first and last---with `...`,
when a heuristic indicates that the longest path would otherwise
overflow the modal.
The elision is not applied to any segment that contains a match for the
search query.
There may be more work to do on #7711 in the case of long result paths
that do not share a significant common prefix.
Release Notes:
- Improved display of long paths in the file finder modal
Co-authored-by: Max <max@zed.dev>
GPUI applications can set the window class by the `app_id` window
option. However, GPUI will map the window first and then change the
window class after the window is displayed. This doesn't work on some
X11 window managers. FVWM, for example, does not track window class
after a window is mapped. Because in practice, a window shouldn't change
its application group on the fly.
This PR fixed this by adding a `map_window()` function `PlatformWindow`.
On X11, it will `set_app_id()` first and then map the window.
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
Closes#22326
This PR adds process PID information to window created by X11, so that
window manager can identify which process this window belongs to.
Without this property, the window manager would have no reliable way to
know which process created this window.
In original issue, `robotgo` throws error on `x, y, w, h :=
robotgo.GetBounds(pid)` this method. If we go deeper into the source
code of `robotgo`, it calls `GetXidFromPid` which goes through all
windows, and tries to check for provided pid. Hence, when it tries to do
that for Zed, it fails and returns `0, err` to caller.
```go
// Robotgo source code trying to look through all windows and query pid
// GetXidFromPid get the xid from pid
func GetXidFromPid(xu *xgbutil.XUtil, pid int) (xproto.Window, error) {
windows, err := ewmh.ClientListGet(xu)
if err != nil {
return 0, err
}
for _, window := range windows {
wmPid, err := ewmh.WmPidGet(xu, window)
if err != nil {
return 0, err
}
if uint(pid) == wmPid {
return window, nil
}
}
return 0, errors.New("failed to find a window with a matching pid.")
}
```
Querying for pid for active Zed window:
Before:
```sh
tims@lemon ~/w/go-repro [127]> xprop -root _NET_ACTIVE_WINDOW
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x4e00002
tims@lemon ~/w/go-repro> xprop -id 0x4e00002 _NET_WM_PID
_NET_WM_PID: not found.
```
After:
```sh
tims@lemon ~/w/go-repro> xprop -root _NET_ACTIVE_WINDOW
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x4e00002
tims@lemon ~/w/go-repro> xprop -id 0x4e00002 _NET_WM_PID
_NET_WM_PID(CARDINAL) = 103548
tims@lemon ~/w/go-repro>
```
Correct zed process PID (below) assosiated with zed window (shown
above):

Release Notes:
- Fix `robotgo` failing when Zed window is open on Linux
Closes#17870
Context:
On Linux, when creating a new window, bounds are either pulled from
existing workspace data (serialized in an SQLite DB) or fall back to
some default constants if no data exists.
These bounds include the full dimensions of the window (width and
height), which already account for insets. However, properties like
`inset` (Wayland) or `last_insets` (X11) exist only at the platform
level and are not part of the window bounds themselves.
During rendering, we call `set_client_inset`, which updates the inset
values and also adjusts the window bounds, increasing their dimensions.
In Zed's case, the inset is 10px, which adds 20px to both the width and
height (10px from each side).
Problem:
When quitting, the full window bounds (which already account for inset)
are saved to the DB. On reopening, these saved bounds are used to create
the window. `set_client_inset` runs again and inflates the dimensions
even more.
Solution:
Store window bounds *without* the inset-inflated dimensions. On the next
session, `set_client_inset` will take care of applying the inset,
resulting window dimensions matching the previous session. This fix is
in the PR.
Alternative Solution:
Another option is to save the inset explicitly in the DB and apply it
during window creation. But this means storing more data, and the inset
would need to be platform-agnostic, which adds complexity. Doesn’t seem
worth it for no real gain.
X11 Before:
```sh
saving window bounds with width: 1136, height: 784
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s
Running `target/debug/zed`
saving window bounds with width: 1156, height: 804 <---- +20px
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/zed`
saving window bounds with width: 1176, height: 824 <---- +20px
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s
Running `target/debug/zed`
saving window bounds with width: 1196, height: 844 <---- +20px
```
X11 After:
```sh
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/zed`
saving window bounds with width: 1116, height: 764
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/zed`
saving window bounds with width: 1116, height: 764 <---- same
tims@lemon ~/w/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
Running `target/debug/zed`
saving window bounds with width: 1116, height: 764 <---- same
```
On Wayland, saving occurs only when you actually resize the window (on
X11, saving happens both on init and while dragging the window). To
trigger saving, I manually resized the window by ~1px to make it print.
Wayland Before:
```sh
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 36s
Running `target/debug/zed`
saving window bounds with width: 945, height: 577
tims@orange ~/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.77s
Running `target/debug/zed`
saving window bounds with width: 966, height: 597 <--- +20px on both (1px increase in width is me resizing)
tims@orange ~/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.87s
Running `target/debug/zed`
saving window bounds with width: 987, height: 618 <--- +20px on both (1px increase in width and height is me resizing)
tims@orange ~/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.89s
Running `target/debug/zed`
saving window bounds with width: 1006, height: 638 <--- +20px on both (1px decrease in width is me resizing)
```
Wayland After:
```sh
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.82s
Running `target/debug/zed`
saving window bounds with width: 925, height: 558
tims@orange ~/zed (fix-window-growing-larger)> cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.84s
Running `target/debug/zed`
saving window bounds with width: 925, height: 557 <--- same (1px decrease in height is me resizing)
saving window bounds with width: 925, height: 558
```
Release Notes:
- Fix non-maximized zed windows growing larger across sessions on Linux
---------
Co-authored-by: mgsloan@gmail.com <michael@zed.dev>
Closes#17005
Release Notes:
- Improved GPU context management: share a single context with multiple
surfaces.
### High Level
Blade got a proper support for Surface objects in
https://github.com/kvark/blade/pull/203.
That was mainly motivated by Zed needing to draw multiple windows. With
the Surface API, Zed is now able to have the GPU context tied to the
"Platform" instead of "Window". Practically speaking, this means:
- architecture more sound
- faster to open/close windows
- less surprises, more robust
### Concerns
1. Zed has been using a temporary workaround for the platform bug on
some Intel+Nvidia machines that makes us unable to present -
https://github.com/kvark/blade/pull/144 . This workaround is no longer
available with the new architecture. I'm looking for ideas on how to
approach this better.
- we are now picking up the change in
https://github.com/kvark/blade/pull/210, which allows forcing a specific
Device ID. This should allow Zed users to work around the issue. We
could help them to automate it, too.
2. ~~Metal-rs dependency is switched to
https://github.com/kvark/metal-rs/tree/blade, since upstream isn't
responsive in merging changes that are required for Blade. Hopefully,
temporary.~~
- ~~we can also hack around it by just transmuting the texture
references, since we know those are unchanged in the branch. That would
allow Blade to use it's own version of Metal, temporarily, if switching
metal-rs in the workspace is a concern.~~
- merged my metal-rs changes and updated Zed to use the upstream github
reference
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
* Fixes registration of event handler for xinput-2 device changes,
revealed by this improvement.
* Pushes `.unwrap()` panic-ing outwards to callers.
* Includes a description of what the X11 call was doing when a failure
was encountered.
* Fixes a variety of places where the X11 reply wasn't being inspected
for failures.
* Destroys windows on failure during setup. New structure makes it
possible for the caller of `open_window` to carry on despite failures,
and so partially initialized window should be removed (though all calls
I looked at also panic currently).
Considered pushing this through `linux/x11/client.rs` too but figured
it'd be nice to minimize merge conflicts with #20853.
Release Notes:
- N/A
As part of the recent changes to keyboard support, ime_key is no longer
populated by the IME; but instead by the keyboard.
As part of #20877 I changed some code to assume that falling back to key
was
ok, but this was not ok; instead we need to populate this more similarly
to how
it was done before #20336.
The alternative fix could be to instead of simulating these events in
our own
code to push a fake native event back to the platform input handler.
Closes #ISSUE
Release Notes:
- Fixed a bug where tapping `shift` coudl type "shift" if you had a
binding on "shift shift"
Closes #14089, #14416, #15970, #17230, #18485
Release Notes:
- Fixed some cases where Linux X11 mouse scrolling doesn't work at all
(#14089, ##15970, #17230)
- Fixed handling of switching between Linux X11 devices used for
scrolling (#14416, #18485)
Change details:
Also includes the commit from PR #18317 so I don't have to deal with
merge conflicts.
* Now uses valuator info from slave pointers rather than master. This
hopefully fixes remaining cases where scrolling is fully
broken. https://github.com/zed-industries/zed/issues/14089,
https://github.com/zed-industries/zed/issues/15970,
https://github.com/zed-industries/zed/issues/17230
* Per-device recording of "last scroll position" used to calculate
deltas. This meant that swithing scroll devices would cause a sudden
jump of scroll position, often to the beginning or end of the
file (https://github.com/zed-industries/zed/issues/14416).
* Re-queries device metadata when devices change, so that newly
plugged in devices will work, and re-use of device-ids don't use old
metadata with a new device.
* xinput 2 documentation describes support for multiple master
devices. I believe this implementation will support that, since now it
just uses `DeviceInfo` from slave devices. The concept of master
devices is only used in registering for events.
* Uses popcount+bit masking to resolve axis indexes, instead of
iterating bit indices.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Release Notes:
- N/A
This updates the IME position every time the selection changes, this is
probably only useful when you enumerate languages with your IME.
TODO:
- ~There is a rare chance that the ime panel is not updated because the
window input handler is None.~
- ~Update IME panel in vim mode.~
- ~Update IME panel when leaving Buffer search input.~
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This fixes an issue where the window's hovered state would be incorrect,
causing the cursor not to update because it would think the window
wasn't hovered ([relevant
check](https://github.com/zed-industries/zed/blob/a03beeeb5bcce3fbb464a5d2a06a6ae47e8dda92/crates/gpui/src/window.rs#L3016-L3017)).
The code here doesn't really seem to make sense, since there's already
the `XinputEnter` and `XinputLeave` events that indicate mouse focus
state on the window. The properties change event wouldn't necessarily
indicate when mouse focus changes.
Thanks @Emc2356 for reporting this on the Discord and helping figure out
the issue!
Release Notes:
- Linux: Fixed the cursor sometimes not changing on X11
This changes the workspace/session serialization to also persist the
order of windows across restarts.
Release Notes:
- Improved restoring of windows across restarts: the order of the
windows is now also restored. That means windows that were in the
foreground when Zed was quit will be in the foreground after restart.
(Right now only supported on Linux/X11, not on Linux/Wayland.)
Demo:
https://github.com/user-attachments/assets/0b8162f8-f06d-43df-88d3-c45d8460fb68
https://github.com/zed-industries/zed/pull/13126 added the
`window_min_size` property for window creation, but it was only
implemented for macOS. This PR implements the property on Linux as well.
Release Notes:
- N/A
Release Notes:
- linux: Added GPU information to `editor: Copy System Specs to
Clipboard`
- linux: Show a prominant warning before running under llvmpipe and
similar.
This restores https://github.com/zed-industries/zed/pull/13943 which was
reverted in #13974 because it was possible to get in a state where focus
could not be restored on a window.
In this PR there's an additional change: `FocusIn` and `FocusOut` events
are always handled, even if the `event.mode` is not "NORMAL". In my
testing, `alt-tabbing` between windows didn't produce `FocusIn` and
`FocusOut` events when we had that check. Now, with the check removed,
it's possible to switch focus between two windows again with `alt-tab`.
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This reverts #13943 and reopens#13897 since the fix in #13943 comes
with a regression:
Sometimes Zed loses keyboard focus and can't be restored. I haven't
figured out yet exactly when and how this happens and can't reliably
reproduce it yet, but there's something off with focus handling.
One reliable way to reproduce _one_ of the problems:
1. Open two zed windows
2. Focus one Zed window
3. Hover with the mouse over the other
4. Try to type in the window that should still be focused
So, to be careful, I'm going to revert the PR first, since I couldn't
find an obvious fix yet. If we do find a fix, we can unrevert.
Release Notes:
- N/A
Adds the `compositor_support` to the `X11WindowState` struct so that
correct window decorations are selected
Release notes:
- N/A
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
**Edit**:
This PR adds flushes to functions which should have an immediate affect.
I've observed it fixing the following bugs (but there are probably
more):
- The cursor not updating when just hovering.
- The window not maximising after clicking the full-screen button until
you move the mouse.
- The window not minimising after clicking the minimise button until you
move the mouse.
---
**Original content**:
Following #13646, the cursor style wouldn't change because the
`change_window_attributes` command wasn't being flushed. I guess it was
working before because something else was flushing it somewhere else so
it was never noticed.
I just added `check()` which flushes the command so that the cursor will
actually update when just hovering. Before you would need to interact
with the window so that something else could flush the command.
Release Notes:
- N/A
With the new window decorations resizing was _really_ laggy on my X11
machine.
Before:
- Click on window border (hitbox doesn't work properly, but that's
another issue)
- Drag and resize
- 4-5s nothing happens
- Window is resized
After:
- Click on window border
- Drag and resize
- Window is resized
I'm still not 100% sure on why this happens on my machine and not
Conrad's/Mikayla's, but seems like that GTK_EDGE_CONSTRAINTS atom is
sent when resizing.
The other thing that I can't explain is that we get a `ConfigureNotify`
when resizing, with the right size, but maybe not often enough?
Anyway, for now we'll go with this.
Release Notes:
- N/A
This changes the implementation of the X11 client to use `mio`, as a
polling mechanism, and a custom run loop instead of `calloop` and its
callback-based approach.
We're doing this for one big reason: more control over how we handle
events.
With `calloop` we don't have any control over which events are processed
when and how long they're processes for. For example: we could be
blasted with 150 input events from X11 and miss a frame while processing
them, but instead of then drawing a new frame, calloop could decide to
work off the runnables that were generated from application-level code,
which would then again cause us to be behind.
We kinda worked around some of that in
https://github.com/zed-industries/zed/pull/12839 but the problem still
persists.
So what we're doing here is to use `mio` as a polling-mechanism. `mio`
notifies us if there are X11 on the XCB connection socket to be
processed. We also use its timeout mechanism to make sure that we don't
wait for events when we should render frames.
On top of `mio` we now have a custom run loop that allows us to decide
how much time to spend on what — input events, rendering windows, XDG
events, runnables — and in what order we work things off.
This custom run loop is consciously "dumb": we render all windows at the
highest frame rate right now, because we want to keep things predictable
for now while we test this approach more. We can then always switch to
more granular timings. But considering that our loop runs and checks for
windows to be redrawn whenever there's an event, this is more an
optimization than a requirement.
One reason for why we're doing this for X11 but not for Wayland is due
to how peculiar X11's event handling is: it's asynchronous and by
default X11 generates synthetic events when a key is held down. That can
lead to us being flooded with input events if someone keeps a key
pressed.
So another optimization that's in here is inspired by [GLFW's X11 input
handling](https://github.com/glfw/glfw/blob/b35641f4a3c62aa86a0b3c983d163bc0fe36026d/src/x11_window.c#L1321-L1349):
based on a heuristic we detect whether a `KeyRelease` event was
auto-generated and if so, we drop it. That essentially halves the amount
of events we have to process when someone keeps a key pressed.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Conrad <conrad@zed.dev>