Commit Graph
109 Commits
Author SHA1 Message Date
Piotr OsiewiczandJunkui Zhang 985dcf7523 chore: Bump Rust version to 1.88 (#33439)
Goodies in this version:
- if-let chains 🎉
- Better compiler perf for Zed
(https://github.com/rust-lang/rust/pull/138522)

For more, see: https://releases.rs/docs/1.88.0/

Release Notes:

- N/A

---------

Co-authored-by: Junkui Zhang <364772080@qq.com>
2025-06-26 20:54:19 +02:00
Michael Sloan dfdeb1bf51 linux: Don't insert characters if modifiers other than shift are held (#33424)
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.
2025-06-25 17:11:59 -06:00
Michael Sloan aae4778b4e gpui: Add more flushing of x11 requests (#33407)
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
2025-06-25 19:46:15 +00:00
Michael Sloan aa1b2d74ee x11: Improve error handling (#32913)
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
2025-06-18 01:40:17 +00:00
90aa99bb14 Add Caps Lock support (#30470)
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>
2025-06-18 00:43:33 +00:00
Michael Sloan 3bed5b767f x11: Halt periodic refresh for windows that aren't visible (#32775)
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.
2025-06-16 02:09:43 +00:00
Mikayla Maki 69e99b9f2f Remove unescessary unimplemented (#32264)
Release Notes:

- N/A
2025-06-06 11:25:21 -07:00
Matin Aniss ca3f46588a gpui: Implement dynamic window control elements (#30828)
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
2025-06-06 10:11:24 -07:00
Michael Sloan 711a9e5753 x11: Remove logs for mac-os specific set_edited and show_character_palette (#32203)
Release Notes:

- N/A
2025-06-06 00:14:20 +00:00
047e7eacec gpui: Improve window.prompt to support ESC with non-English cancel text on macOS (#29538)
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>
2025-05-30 15:26:27 +00:00
Piotr Osiewicz dc64ec9cc8 chore: Bump Rust edition to 2024 (#27800)
Follow-up to https://github.com/zed-industries/zed/pull/27791

Release Notes:

- N/A
2025-03-31 20:55:27 +02:00
Piotr Osiewicz 0729d24d77 chore: Prepare for Rust edition bump to 2024 (without autofix) (#27791)
Successor to #27779 - in this PR I've applied changes manually, without
futzing with if let lifetimes at all.

Release Notes:

- N/A
2025-03-31 20:10:36 +02:00
Floyd Wang b4254a33e0 gpui: Support window resizing for PlatformWindow (#27477)
Support resizing windows to a specified size.

## macOS

https://github.com/user-attachments/assets/8c639bc2-ee5f-4adc-a850-576dac939574


## Wayland

[wayland.webm](https://github.com/user-attachments/assets/3d593604-83b4-488f-8f63-1cf4c0c0cb9a)

## X11

[x11.webm](https://github.com/user-attachments/assets/ce8fa62e-fb74-4641-abe8-70574011e630)

## Windows

https://github.com/user-attachments/assets/abb03e48-f82a-4d62-90b3-2598a4866c3f

Release Notes:

- N/A
2025-03-28 20:02:15 -07:00
Conrad Irwin 63091459d8 Allow too many arguments (#26375)
This is nearly half of our #allows, and seems like something we happily
break whenever we need

Release Notes:

- N/A
2025-03-10 13:38:30 -06:00
Cole Miller c0c48d30db Revert "file_finder: Remove common segments of long paths in search results (#25049)" (#25163)
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
2025-02-19 15:32:29 +00:00
Cole MillerandMax 9ef0501853 file_finder: Remove common segments of long paths in search results (#25049)
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>
2025-02-18 10:09:15 -05:00
Mike Qin 9c3482083b Map window after set_app_id() under X11 (#23046)
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
2025-01-30 16:47:16 -08:00
6fca1d2b0b Eliminate GPUI View, ViewContext, and WindowContext types (#22632)
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>
2025-01-26 03:02:45 +00:00
tims b46b261f11 linux: Fix process PID to window mapping for X11 (#22348)
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):

![image](https://github.com/user-attachments/assets/8b40128b-addb-4c88-944e-b1d26b908bf5)

Release Notes:

- Fix `robotgo` failing when Zed window is open on Linux
2025-01-04 00:10:36 +00:00
timsandmgsloan@gmail.com <michael@zed.dev> ca9cee85e1 linux: Fix non-maximized Zed windows growing larger across sessions (#22301)
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>
2024-12-20 22:23:25 +00:00
298b9df589 Switch to a single GPU context in Blade (#20853)
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>
2024-12-18 14:47:09 -07:00
Cole Miller 613deb6421 Remove panics from X11Window::set_title (#22173)
Release Notes:

- N/A
2024-12-17 22:15:35 -05:00
Marshall Bowers ba44db7f49 gpui: Rename GPUSpecs to GpuSpecs (#22166)
This PR renames the `GPUSpecs` type to `GpuSpecs` to match Rust naming
conventions.

Release Notes:

- N/A
2024-12-17 17:22:53 -05:00
Michael Sloan c9f2c2792c Improve error handling and resource cleanup in linux/x11/window.rs (#21079)
* 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
2024-11-22 16:03:46 -07:00
Conrad Irwin e062f30d9e Rename ime_key -> key_char and update behavior (#20953)
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"
2024-11-20 20:29:47 -07:00
Michael Sloan aad3ed7f91 Fix window drawing when switching X11 workspaces by presenting when expose events occur (#20535)
Closes #18184

Release Notes:

- Fix window drawing when switching X11 workspaces, particularly for tiling window managers such as i3wm and XMonad.
2024-11-12 01:20:25 -07:00
Michael SloanandThorsten Ball 527c9097f8 linux: Various X11 scroll improvements (#18484)
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>
2024-10-01 09:14:40 +02:00
wannacu 8ae74bc6df gpui: Fix pre-edit position after applying scale factor (#18214)
before:

![image](https://github.com/user-attachments/assets/20590089-3333-4ca8-a371-b07acfbe43f9)

after:

![image](https://github.com/user-attachments/assets/2d25623e-0602-4d24-b563-64e1d2ec3492)

Release Notes:

- N/A
2024-09-30 12:57:59 +02:00
Fernando Tagawa 59be07ad90 x11: Implement Drag and Drop (#17491)
Closes #16225

Release Notes:

- x11: Implemented Drag and Drop.
2024-09-09 14:27:45 -07:00
Thorsten BallandBennet 938c90fd3b Revert FPS counter (#17485)
**UPDATE**: Response so far seems to be that this fixes the performance
issues on Intel MacBooks. So we're going to go ahead and merge it.

This reverts the FPS counter added in 11753914d (#16422) because in this
issue someone bisected recent performance regressions down to this
commit:

- https://github.com/zed-industries/zed/issues/16729

Another issue that's possibly related:

-
https://github.com/zed-industries/zed/issues/17305#issuecomment-2332316242

We're reverting this in a PR to create a bundle that people can try out.

Assets:

- Universal Binary:
https://github.com/zed-industries/zed/actions/runs/10735702994/artifacts/1900460781
- x86/Intel:
https://github.com/zed-industries/zed/actions/runs/10735702994/artifacts/1900461236
- Apple Silicon:
https://github.com/zed-industries/zed/actions/runs/10735702994/artifacts/1900460978


Release Notes:

- Removed the recently-added FPS counter since the changes it made to
the Metal renderer on macOS could lead to performance regressions on
Intel MacBooks.

Co-authored-by: Bennet <bennet@zed.dev>
2024-09-06 15:35:00 +02:00
Fernando TagawaandMikayla Maki 8e8927db4b linux: Fix IME panel position while enumerating input methods (#12495)
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>
2024-08-28 19:58:40 -07:00
11753914d7 Add a setting to show time to first window draw and frames per second in status bar (#16422)
I want to showcase Zed's performance via videos, and this seemed like a
good way to demonstrate it.


https://github.com/user-attachments/assets/f4a5fabc-efe7-4b48-9ba5-719882fdc856

Release Notes:

- On macOS, you can now set assign `performance.show_in_status_bar:
true` in your settings to show the time to the first window draw on
startup and then current FPS of the containing window's renderer.

---------

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: David Soria Parra <167242713+dsp-ant@users.noreply.github.com>
Co-authored-by: Danny Hua <danny.hua@hey.com>
2024-08-18 15:22:19 -06:00
apricotbucket28 8e6af73784 x11: Do not check hover state on properties change (#15518)
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
2024-07-30 19:02:48 -07:00
Thorsten Ball f58ef9b82b zed: Persist window stack order across restarts (#15419)
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
2024-07-29 17:05:56 +02:00
apricotbucket28 04e25525bf x11: Fix window menu not showing (#15328)
Fixes
https://github.com/zed-industries/zed/issues/15245#issuecomment-2252790889

Release Notes:

- Linux: Fixed window menu not showing on X11
2024-07-27 12:29:48 -07:00
apricotbucket28 88653c4e3e linux: Respect window_min_size property (#15314)
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
2024-07-26 18:02:31 -07:00
Conrad Irwin bdf1d4edea linux: Better GPU debugging (#14706)
Release Notes:

- linux: Added GPU information to `editor: Copy System Specs to
Clipboard`
- linux: Show a prominant warning before running under llvmpipe and
similar.
2024-07-23 09:56:45 -06:00
ee623f77c1 linux/x11: Restore differentiation of mouse/keyboard focus (#13995)
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>
2024-07-10 19:54:26 +02:00
apricotbucket28 23c84f8dc0 linux: Treat fullscreen as tiled on X11 and prevent resizing while maximized (#13990)
Two quick fixes for issues I noticed:

1. Fullscreening an unmaximized X11 window still showed rounded window
corners and allowed resizing
2. Maximized windows still allowed for resizing on corners due to
missing checks

![image](https://github.com/zed-industries/zed/assets/71973804/47df4de2-4013-4e51-88c3-d33b52a909f5)


Release Notes:

- N/A
2024-07-09 16:30:30 +02:00
Thorsten Ball b3dad0bfcb Revert "x11: Differentiate between mouse and keyboard focus #13943" (#13974)
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
2024-07-09 11:12:42 +02:00
30479bf062 Improve window decorations: check for compositor support (#13822)
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>
2024-07-08 20:34:37 -06:00
Conrad IrwinandMax b0ecda6370 x11 calloop 2 (#13955)
Release Notes:

- N/A

---------

Co-authored-by: Max <max@zed.dev>
2024-07-08 18:38:36 -06:00
apricotbucket28 75377bbe0f x11: Differentiate between mouse and keyboard focus (#13943)
Fixes https://github.com/zed-industries/zed/issues/13897

Release Notes:

- N/A
2024-07-08 13:59:30 -06:00
Thorsten Ball e69f9d6cf9 linux/x11: Fix gap when tiling windows side by side (#13859)
By leveraging the `_GTK_EDGE_CONSTRAINTS` atom we can get all four
booleans for the `Tiling` struct and figure out which side is free when
the window is tiled to half of the screen.

For the logic behind the `_GTK_EDGE_CONSTRAINTS` see:
-
https://github.com/GNOME/mutter/blob/8e9d13aa3b3baa099ca32bbcb10afb4d9eea4460/src/x11/window-x11.c#L65-L75
-
https://github.com/GNOME/mutter/blob/8e9d13aa3b3baa099ca32bbcb10afb4d9eea4460/src/x11/window-x11.c#L1205-L1231

(I used Claude 3.5 Sonnet with our code and these pieces from `mutter`
to generate the Rust code, that was pretty sweet)

This fixes the gap in the middle when a GPUI window is tiled to the left
and another window to the right.

It's not _perfect_ but it looks a lot better.

Here's a diff that makes it look better:

```diff
diff --git a/crates/gpui/examples/window_shadow.rs b/crates/gpui/examples/window_shadow.rs
index 122231f6b..7fa29dadc 100644
--- a/crates/gpui/examples/window_shadow.rs
+++ b/crates/gpui/examples/window_shadow.rs
@@ -72,8 +72,8 @@ impl Render for WindowShadow {
                     .when(!(tiling.top || tiling.left), |div| div.rounded_tl(rounding))
                     .when(!tiling.top, |div| div.pt(shadow_size))
                     .when(!tiling.bottom, |div| div.pb(shadow_size))
-                    .when(!tiling.left, |div| div.pl(shadow_size))
-                    .when(!tiling.right, |div| div.pr(shadow_size))
+                    .when(!tiling.left, |div| div.pl(shadow_size - border_size))
+                    .when(!tiling.right, |div| div.pr(shadow_size - border_size))
                     .on_mouse_move(|_e, cx| cx.refresh())
                     .on_mouse_down(MouseButton::Left, move |e, cx| {
                         let size = cx.window_bounds().get_bounds().size;
```

But that makes it look weird on Wayland, so I didn't do it.

I think it's fine for now. Chromium looks bad and has a gap, so we're
already better.

## Before

![before_1](https://github.com/zed-industries/zed/assets/1185253/875c5cdd-c0be-4295-beb0-bb9ba5beaa52)


![before_2](https://github.com/zed-industries/zed/assets/1185253/0b96be70-4c34-4e99-aeb2-ab741171ad14)

## After

![after_1](https://github.com/zed-industries/zed/assets/1185253/aa51da77-daf1-4ef8-a33f-a83731e0c7e1)

![after_2](https://github.com/zed-industries/zed/assets/1185253/8ce7902d-90b6-4f06-ba2c-626e643abe56)


Release Notes:

- N/A
2024-07-05 15:02:14 +02:00
Thorsten Ball 2a923e338f linux/x11: Set transparency to false by default (#13848)
The previous code lead to a ton of error messages from Blade on my X11
machine, even with *client-side decorations working well!*

As @someone13574 pointed out
[here](https://github.com/zed-industries/zed/pull/13611#issuecomment-2201685030)
things still work with this being false. And if someone changes a theme
with transparent background, then it will get set anyway. We just don't
do it by default.

And as @jansol pointed out
[here](https://github.com/zed-industries/zed/issues/5040#issuecomment-2096560629):

> On X11 it may be possible to configure a compositor to blur window
backgrounds but Zed has no way to influence that.

So we don't lose anything, I think, but get rid of a ton of error
messages in the logs.

Proof of shadows etc. still working:

![Screenshot from 2024-07-05
10-17-38](https://github.com/zed-industries/zed/assets/1185253/1216b38b-8011-46e7-b86f-c0f5fc3f6f64)



Release Notes:

- N/A
2024-07-05 10:55:45 +02:00
Owen Law 56e3fc794a linux/x11: Fix bugs related to unflushed commands (#13844)
**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
2024-07-05 09:16:28 +02:00
Thorsten Ball c8b106245c linux/x11: Resize on GTK_EDGE_CONSTRAINTS atom (#13833)
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
2024-07-04 18:29:08 +02:00
47aa761ca9 Linux window decorations (#13611)
This PR adds support for full client side decorations on X11 and Wayland

TODO:
- [x] Adjust GPUI APIs to expose CSD related information
- [x] Implement remaining CSD features (Resizing, window border, window
shadow)
- [x] Integrate with existing background appearance and window
transparency
- [x] Figure out how to check if the window is tiled on X11
- [x] Implement in Zed
- [x] Repeatedly maximizing and unmaximizing can panic
- [x] Resizing is strangely slow
- [x] X11 resizing and movement doesn't work for this:
https://discord.com/channels/869392257814519848/1204679850208657418/1256816908519604305
- [x] The top corner can clip with current styling
- [x] Pressing titlebar buttons doesn't work
- [x] Not showing maximize / unmaximize buttons
- [x] Noisy transparency logs / surface transparency problem
https://github.com/zed-industries/zed/pull/13611#issuecomment-2201685030
- [x] Strange offsets when dragging the project panel
https://github.com/zed-industries/zed/pull/13611#pullrequestreview-2154606261
- [x] Shadow inset with `_GTK_FRAME_EXTENTS` doesn't respect tiling on
X11 (observe by snapping an X11 window in any direction)

Release Notes:

- N/A

---------

Co-authored-by: conrad <conrad@zed.dev>
Co-authored-by: Owen Law <81528246+someone13574@users.noreply.github.com>
Co-authored-by: apricotbucket28 <71973804+apricotbucket28@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
2024-07-03 11:28:09 -07:00
64755a7aea linux/x11: Custom run loop with mio instead of calloop (#13646)
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>
2024-07-03 17:05:26 +02:00
Conrad Irwin 6a1b257d39 Fix X11 window activation better (#13604)
Release Notes:

- N/A
2024-06-27 14:36:29 -06:00