For future reference: WIP branch of copy/pasting a mixture of images and
text: https://github.com/zed-industries/zed/tree/copy-paste-images -
we'll come back to that one after landing this one.
Release Notes:
- You can now paste images into the Assistant Panel to include them as
context. Currently works only on Mac, and with Anthropic models. Future
support is planned for more models, operating systems, and image
clipboard operations.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Jason <jason@zed.dev>
Co-authored-by: Kyle <kylek@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
The names suggested by `buffer_font_family` are reported by
`all_font_names`. Therefore, `all_font_names` should report family names
rather than postscript names.
close#14854
Release Notes:
- N/A
Since `WindowsDispatcher` requires a minimum Windows version of Windows
10 Fall Creators Update (10.0.16299), and the `alacritty_terminal`
dependency relies on conPTY, an API introduced in the same version,
additionally, `DirectWriteTextSystem` also relies on Windows 10 Fall
Creators Update (10.0.16299), so it seems reasonable to make
`CosmicTextSystem` Linux-only. And we can use `DirectWriteTextSystem` on
the Windows platform exclusively. I hope this approach makes sense.
Release Notes:
- N/A
Now it is possible to change keyboard layouts with `setxkbmap` without
having to restart zed.
Release Notes:
- x11: Support for keyboard layout hot plugging.
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>
This PR consists of two main changes:
1. The first commit changes the `open` crate for opening URLs/paths for
the `OpenURI` desktop portal. This fixes the activation token not being
passed to programs (at least on KDE).
2. The second commit implements the window `activate()` API on Wayland.
This allows KWin and Mutter to show a visual indicator when the window
is requesting attention. (see
https://github.com/zed-industries/zed/issues/12557)
Release Notes:
- N/A
Pass on all the XkbStateNotify information to XKB.
> "All parameters must always be passed, or the resulting state may be
incoherent."
>
https://docs.rs/xkbcommon/latest/xkbcommon/xkb/struct.State.html#method.update_mask
Previously, many keymaps using multiple groups/layers would not work and
remain in group0.
Release Notes:
- Fixed handling of Xkb keymap groups on X11.
```
Thread "main" panicked with "divide by zero error when dividing duration by scalar" at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/time.rs:1172:31
0: zed::reliability::init_panic_hook::{{closure}}
at crates/zed/src/reliability.rs:58:29
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/alloc/src/boxed.rs:2036:9
std::panicking::rust_panic_with_hook
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:799:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:664:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys_common/backtrace.rs:171:18
4: rust_begin_unwind
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:652:5
5: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/panicking.rs:72:14
6: core::panicking::panic_display
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/panicking.rs:263:5
7: core::option::expect_failed
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/option.rs:1994:5
8: core::option::Option<T>::expect
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/option.rs:895:21
<core::time::Duration as core::ops::arith::Div<u32>>::div
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/time.rs:1172:31
9: <gpui::platform::linux::wayland::client::WaylandClientStatePtr as wayland_client::event_queue::Dispatch<wayland_client::protocol::wl_keyboard::WlKeyboard,()>>::event::{{closure}}
at crates/gpui/src/platform/linux/wayland/client.rs:1211:63
10: <core::cell::RefCell<calloop::sources::DispatcherInner<S,F>> as calloop::sources::EventDispatcher<Data>>::process_events::{{closure}}
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/sources/mod.rs:327:61
11: <calloop::sources::timer::Timer as calloop::sources::EventSource>::process_events
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/sources/timer.rs:122:38
12: <core::cell::RefCell<calloop::sources::DispatcherInner<S,F>> as calloop::sources::EventDispatcher<Data>>::process_events
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/sources/mod.rs:326:9
13: calloop::loop_logic::EventLoop<Data>::dispatch_events
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/loop_logic.rs:445:31
14: calloop::loop_logic::EventLoop<Data>::dispatch
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/loop_logic.rs:559:9
15: calloop::loop_logic::EventLoop<Data>::run
at /home/atassis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/calloop-0.13.0/src/loop_logic.rs:596:13
16: <gpui::platform::linux::wayland::client::WaylandClient as gpui::platform::linux::platform::LinuxClient>::run
at crates/gpui/src/platform/linux/wayland/client.rs:655:9
17: gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run
at crates/gpui/src/platform/linux/platform.rs:153:9
18: gpui::app::App::run
at crates/gpui/src/app.rs:140:9
19: zed::main
at crates/zed/src/main.rs:382:5
20: core::ops::function::FnOnce::call_once
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:250:5
21: std::sys_common::backtrace::__rust_begin_short_backtrace
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys_common/backtrace.rs:155:18
22: std::rt::lang_start::{{closure}}
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:159:18
23: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:284:13
std::panicking::try::do_call
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
std::rt::lang_start_internal::{{closure}}
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:48
std::panicking::try::do_call
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
std::rt::lang_start_internal
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:20
24: std::rt::lang_start
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:158:17
25: main
26: __libc_start_call_main
27: __libc_start_main_impl
28: _start
```
This error was happening when I started typing. This PR fixes this
error.
Fedora 40, latest kernel, gnome 46, wayland.
Release Notes:
- N/A
This has been bugging me for a while. If you create a new file and then
save it, the dialogue would show the home directory and not the folder
that you were in.
This fixes it.
Release Notes:
- N/A
**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>
Release Notes:
- N/A
Fixed#13463 Fixed crash when the locale was non UTF-8 and fixed the
fallback locale.
Fixed#13010 Fixed crash when `compose.keysym()` was `XKB_KEY_NoSymbol`
I also extracted the `xkb_compose_state` to a single place
The clipboard library we use for X11 doesn't yet support multiple
formats on the clipboard, so for now we just store this in memory for
the current zed process, as we do for Wayland.
Fixes: #11971
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
The KeyEnter serial will be too old if another client replaces the
selection before the user unfocuses and refocuses the window (i.e.,
triggers another KeyEnter event).
The KeyPress event is more likely to be new enough.
Release Notes:
- Fixed setting clipboard sometimes not working on wayland
([#13445](https://github.com/zed-industries/zed/issues/13445)).
apricotbucket28
Thorsten Ball
Piotr Osiewicz
张小白
Fernando Tagawa
Conrad Irwin
CharlesChen0823
aohanhongzhi
fsh
Taimuraz Kaitmazov
Owen Law
Keenan Wresch
Matt Fellenz