This was added before we were handling key equivalents, and is no longer
needed. Furthermore in the gpui2 re-write we stopped sending the correct
modifiers so this hasn't worked for the last year.
Fixes#21520
Release Notes:
- Fixed a bug where cmd-escape could act like .
Similar to #20826 but keeps the Swift implementation. There were quite a
few changes in the `call` crate, and so that code now has two variants.
Closes#13714
Release Notes:
- Added preliminary Linux support for voice chat and viewing
screenshares.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
The macOS input handler assumes that you want to insert control
sequences when
you type ctrl-alt-X (you probably don't...).
Release Notes:
- (nightly only) fix ctrl-alt-X shortcuts
Co-Authored-By: Richard Feldman <richard@zed.dev>
Closes#21392
Release Notes:
- Fixed dismissing the macOS IME menu with escape when no marked text
was present
---------
Co-authored-by: Richard Feldman <richard@zed.dev>
Closes#15788, #13258
This is a long-standing issue with a few previous attempts to fix it,
such as [this one](https://github.com/zed-industries/zed/pull/17496).
However, that fix was later reverted because it resolved the blur issue
but caused a size issue. Currently, both blur and size issues persist
when you set a custom cursor size from GNOME Settings and use fractional
scaling.
This PR addresses both issues.
---
### Context
A new Wayland protocol,
[cursor-shape-v1](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/194),
allows the compositor to handle rendering the cursor at the correct size
and shape. This protocol is implemented by KDE, wlroots (Sway-like
environments), etc. Zed supports this protocol, so there are no issues
on these desktop environments.
However, GNOME has not yet
[adopted](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212) this
protocol. As a result, apps must fall back to manually rendering the
cursor by specifying the theme, size, scale, etc., themselves. Zed also
implements this fallback but does not correctly account for the display
scale.
---
### Scale Fix
For example, if your cursor size is `64px` and you’re using fractional
scaling (e.g., `150%`), the display scale reported by the window query
will be an integer value, `2` in this case. Why `2` if the scale is
`150%`? That’s what the new protocol aims to improve. However, since
GNOME Wayland uses this integer scale everywhere, it’s sufficient for
our use case.
To fix the issue, we set the `buffer_scale` to this value. But that
alone doesn’t solve the problem. We also need to generate a matching
theme cursor size for this scaled version. This can be calculated as
`64px` * `2`, resulting in `128px` as the theme cursor size.
---
### Size Fix
The XDG Desktop Portal’s `cursor-size` event fails to read the cursor
size because it expects an `i32` but encounters a type error with `u32`.
Due to this, the cursor size was interpreted as the default `24px`
instead of the actual size set via user.
---
### Tested
This fix has been tested with all possible combinations of the
following:
- [x] GNOME Normal Scale (100%, 200%, etc.)
- [x] GNOME Fractional Scaling (125%, 150%, etc.)
- [x] GNOME Cursor Sizes (**Settings > Accessibility > Seeing**, e.g.,
`24px`, `64px`, etc.)
- [x] GNOME Experimental Feature `scale-monitor-framebuffer` (both
enabled and disabled)
- [x] KDE (`cursor-shape-v1` protocol)
---
**Result:**
64px custom cursor size + 150% Fractional Scale:
https://github.com/user-attachments/assets/cf3b1a0f-9a25-45d0-ab03-75059d3305e7
---
Release Notes:
- Fixed mouse cursor size and blur issues on Wayland
Closes#19866
This PR supersedes #19228, as #19228 encountered too many merge
conflicts.
After some exploration, I found that for paths with the `\\?\` prefix,
we can safely remove it and consistently use the clean paths in all
cases. Previously, in #19228, I thought we would still need the `\\?\`
prefix for IO operations to handle long paths better. However, this
turns out to be unnecessary because Rust automatically manages this for
us when calling IO-related APIs. For details, refer to Rust's internal
function
[`get_long_path`](https://github.com/rust-lang/rust/blob/017ae1b21f7be6dcdcfc95631e54bde806653a8a/library/std/src/sys/path/windows.rs#L225-L233).
Therefore, we can always store and use paths without the `\\?\` prefix.
This PR introduces a `SanitizedPath` structure, which represents a path
stripped of the `\\?\` prefix. To prevent untrimmed paths from being
mistakenly passed into `Worktree`, the type of `Worktree`’s `abs_path`
member variable has been changed to `SanitizedPath`.
Additionally, this PR reverts the changes of #15856 and #18726. After
testing, it appears that the issues those PRs addressed can be resolved
by this PR.
### Existing Issue
To keep the scope of modifications manageable, `Worktree::abs_path` has
retained its current signature as `fn abs_path(&self) -> Arc<Path>`,
rather than returning a `SanitizedPath`. Updating the method to return
`SanitizedPath`—which may better resolve path inconsistencies—would
likely introduce extensive changes similar to those in #19228.
Currently, the limitation is as follows:
```rust
let abs_path: &Arc<Path> = snapshot.abs_path();
let some_non_trimmed_path = Path::new("\\\\?\\C:\\Users\\user\\Desktop\\project");
// The caller performs some actions here:
some_non_trimmed_path.strip_prefix(abs_path); // This fails
some_non_trimmed_path.starts_with(abs_path); // This fails too
```
The final two lines will fail because `snapshot.abs_path()` returns a
clean path without the `\\?\` prefix. I have identified two relevant
instances that may face this issue:
-
[lsp_store.rs#L3578](https://github.com/zed-industries/zed/blob/0173479d18e2526c1f9c8b25ac94ec66b992a2b2/crates/project/src/lsp_store.rs#L3578)
-
[worktree.rs#L4338](https://github.com/zed-industries/zed/blob/0173479d18e2526c1f9c8b25ac94ec66b992a2b2/crates/worktree/src/worktree.rs#L4338)
Switching `Worktree::abs_path` to return `SanitizedPath` would resolve
these issues but would also lead to many code changes.
Any suggestions or feedback on this approach are very welcome.
cc @SomeoneToIgnore
Release Notes:
- N/A
* 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
This PR adds a function, WindowContext::drop_image, to manually remove a
RenderImage from the sprite atlas. In addition, PlatformAtlas::remove
was added to support this behavior. Previously, there was no way to
request a RenderImage to be removed from the sprite atlas, and since
they are not removed automatically the sprite would remain in video
memory once added until the window was closed. This PR allows a
developer to request the image be dropped from memory manually, however
it does not add automatic removal.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
When launching the Pinyin keyboard, macOS will sometimes try to peek one
character back in the string.
This caused a panic if the preceding character was an emoji. The docs
say
"don't assume the range is valid", so now we don't.
Release Notes:
- (macOS) Fixed a panic when using the Pinyin keyboard with emojis
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"
This is broken because of the way we try to emulate macOS's
ApplePressAndHoldEnabled.
Release Notes:
- Fixed holding down space in the terminal (preview only)
Issues found:
* audio does not work well with various set-ups using USB
* switching audio during initial join may leave the client with no audio
at all
* audio streaming is done on the main thread, beachballing certain
set-ups
* worse screenshare quality (seems that there's no dynamic scaling
anymore, compared to the Swift SDK)
This reverts commit 1235d0808e.
Release Notes:
- N/A
See https://github.com/livekit/rust-sdks/pull/355
Todo:
* [x] make `call` / `live_kit_client` crates use the livekit rust sdk
* [x] create a fake version of livekit rust API for integration tests
* [x] capture local audio
* [x] play remote audio
* [x] capture local video tracks
* [x] play remote video tracks
* [x] tests passing
* bugs
* [x] deafening does not work
(https://github.com/livekit/rust-sdks/issues/359)
* [x] mute and speaking status are not replicated properly:
(https://github.com/livekit/rust-sdks/issues/358)
* [x] **linux** - crash due to symbol conflict between WebRTC's
BoringSSL and libcurl's openssl
(https://github.com/livekit/rust-sdks/issues/89)
* [x] **linux** - libwebrtc-sys adds undesired dependencies on `libGL`
and `libXext`
* [x] **windows** - linker error, maybe related to the C++ stdlib
(https://github.com/livekit/rust-sdks/issues/364)
```
libwebrtc_sys-54978c6ad5066a35.rlib(video_frame.obj) : error LNK2038:
mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't
match value 'MD_DynamicRelease' in
libtree_sitter_yaml-df6b0adf8f009e8f.rlib(2e40c9e35e9506f4-scanner.o)
```
* [x] audio problems
Release Notes:
- Switch from Swift to Rust LiveKit SDK 🦀
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Re-land of #20515 with less brokenness
In particular it turns out that for control, the .characters() method
returns the control code. This mostly didn't make a difference, except
when the control code matched tab/enter/escape (for
ctrl-y,ctrl-[/ctrl-c) as we interpreted the key incorrectly.
Secondly, we were setting IME key too aggressively. This led to (in vim
mode) cmd-shift-{ being interpreted as [, so vim would wait for a second
[ before letting you change tab.
Release Notes:
- N/A
This reverts commit https://github.com/zed-industries/zed/pull/20515
I'm reverting for now to fix issues with key bindings on Nightly:
* `ctrl-c` and `ctrl-m` are being treated as `ctrl-enter`
* `ctrl-[` isn't working in vim mode
* there's a delay before `cmd-shift-[` switches tabs w/ vim mode enabled
Release Notes:
- N/A
On x86 Macs BOOL is not the same within the `objc` crate we're using.
This only comes up on nightly builds (not on CI), so I don't think I
have a way to trigger this issue locally.
Release Notes:
- N/A
Closes#19738
This change refactors how we handle input on macOS to avoid simulating
our own IME. This fixes a number of small edge-cases, and also lets us
remove a bunch of code that had been added to work around bugs in the
previous version.
Release Notes:
- On macOS: Keyboard shortcuts are now handled before activating the IME
system, this enables using vim's default mode on keyboards that use IME
menus (like Japanese).
- On macOS: Improvements to handling of dead-keys. For example when
typing `""` on a Brazillian keyboard, you now get a committed " and a
new marked ", as happens in other apps. Also, you can now type cmd-^ on
an AZERTY keyboard for indent; and ^ on a QWERTZ keyboard now goes to
the beginning of line in vim normal mode, or `d i "` no requires no
space to delete within quotes on Brazilian keyboards (though `d f "
space` is still required as `f` relies on the input handler, not a
binding).
- On macOS: In the terminal pane, holding down a key will now repeat
that key (as happens in iTerm2) instead of opening the character
selector.
Closes #16343Closes#10972
Release Notes:
- (breaking change) On macOS when using a keyboard that supports an
extended Latin character set (e.g. French, German, ...) keyboard
shortcuts are automatically updated so that they can be typed without
`option`. This fixes several long-standing problems where some keyboards
could not type some shortcuts.
- This mapping works the same way as
[macOS](https://developer.apple.com/documentation/swiftui/view/keyboardshortcut(_:modifiers:localization:)).
For example on a German keyboard shortcuts like `cmd->` become `cmd-:`,
`cmd-[` and `cmd-]` become `cmd-ö` and `cmd-ä`. This mapping happens at
the time keyboard layout files are read so the keybindings are visible
in the command palette. To opt out of this behavior for your custom
keyboard shortcuts, set `"use_layout_keys": true` in your binding
section. For the mappings used for each layout [see
here](https://github.com/zed-industries/zed/blob/a890df1863ca939ee7f0ada6e629b6f83eb18bc5/crates/settings/src/key_equivalents.rs#L7).
---------
Co-authored-by: Will <will@zed.dev>
Updates #10972
Release Notes:
- Fixed builtin keybindings that don't require cmd on macOS, non-Latin,
ANSI layouts. For example you can now use ctrl-ա (equivalent to ctrl-a)
on an Armenian keyboard to get to the beginning of the line.
---------
Co-authored-by: Will <will@zed.dev>
Those seem to require a corresponding NSTextView/NSTextField with
explicitly enabled `allowsUndo` property. But Zed does not use any of
these *Text* elements, so there's nothing to allow undo on. Hence, use
the Zed handler, making both actions always enabled instead of being
always disabled.
Closes https://github.com/zed-industries/zed/issues/12335
Release Notes:
- Fixed undo and redo macOS menu items being always disabled
([#12335](https://github.com/zed-industries/zed/issues/12335))
Related comment on issue
https://github.com/zed-industries/zed/issues/14222#issuecomment-2418375056
On `crates/gpui/src/platform/linux/text_system.rs` on method
`CosmicTextSystem::new` `load_system_fonts` is being called twice:
```rust
pub(crate) fn new() -> Self {
let mut font_system = FontSystem::new();
// todo(linux) make font loading non-blocking
font_system.db_mut().load_system_fonts();
Self(RwLock::new(CosmicTextSystemState {
font_system,
swash_cache: SwashCache::new(),
scratch: ShapeBuffer::default(),
loaded_fonts_store: Vec::new(),
font_ids_by_family_cache: HashMap::default(),
postscript_names: HashMap::default(),
}))
}
```
First one on `FontSystem::new()` and second one is explicit on
`font_system.db_mut().load_system_fonts()`. The first call
`FontSystem::new()` is defined as:
```
pub fn new() -> Self {
Self::new_with_fonts(core::iter::empty())
}
```
And `new_with_fonts`:
```rust
/// Create a new [`FontSystem`] with a pre-specified set of fonts.
pub fn new_with_fonts(fonts: impl IntoIterator<Item = fontdb::Source>) -> Self {
let locale = Self::get_locale();
log::debug!("Locale: {}", locale);
let mut db = fontdb::Database::new();
//TODO: configurable default fonts
db.set_monospace_family("Fira Mono");
db.set_sans_serif_family("Fira Sans");
db.set_serif_family("DejaVu Serif");
Self::load_fonts(&mut db, fonts.into_iter());
Self::new_with_locale_and_db(locale, db)
}
```
Finally `Self::load_fonts(&mut db, fonts.into_iter())` calls
`load_system_fonts`:
```rust
#[cfg(feature = "std")]
fn load_fonts(db: &mut fontdb::Database, fonts: impl Iterator<Item = fontdb::Source>) {
#[cfg(not(target_arch = "wasm32"))]
let now = std::time::Instant::now();
db.load_system_fonts();
for source in fonts {
db.load_font_source(source);
}
...
```
Release Notes:
- Remove duplicate font loading on Linux
Closes#16969
Release Notes:
- Fixed a bug in macOS Sequoia where you can't save a new file as
`*.sql`, it would rename to `.sql.s`. As a side effect you can no longer
save a new file as `*sql.s`. We hope to remove this workaround when the
operating system fixes its bug; in the meantime you can either set
`"use_system_path_prompts": false` in your settings file to skip the
macOS dialogues, or create new files by right clicking in the project
panel.
Closes#19181
When the keystroke was empty ("") the `ime_key` was converted from
`None` to `Some("")` when `with_simulated_ime` was called. That was
leading to not intentional behavior when an empty keystroke was combined
with `shift-up` in a keybinding `["workspace::SendKeystrokes", "shift-up
"]`.
By adding a `key.is_empty()` we make sure the `ime_key` keeps as `None`.
This was manually tested.
Release Notes:
- Fixed empty keystroke with simulated ime
Signed-off-by: Bruno Calza <brunoangelicalza@gmail.com>
Closes#18705 (comment)
This PR fixes the issue where the Zed window was not displaying
correctly on launch. Now, when Zed is closed in a maximized state, it
will reopen in a maximized state.
On macOS, when a window is created but not yet visible, calling `zoom`
or `toggle_fullscreen` will still affect the hidden window. However,
this behavior is different on Windows, so special handling is required.
Also, since #18705 hasn't been reviewed yet, I'm not sure if this PR
should be merged now or if it should wait until #18705 is reviewed
first.
Release Notes:
- N/A
TL;DR: Another O(n^2) strikes.
In #19194 we received a report about a 7Mb JSON file that Zed struggles
with. Naturally this file showcased a O(n^2) in line layout; this file
has one long line.
During line layout for Mac we have to convert between UTF-16 and UTF-8
indices in the string, as CoreText works with UTF-16 and Rust strings
are UTF-8. The problem stemmed from the fact that we were re-seeking our
string converter on each glyph, which boils down to: we were reparsing
[0..curr_string_position] bytes up to full length of the string, which
is the O(n^2) in question. This PR changes this behaviour to reuse the
Index Converter if the position we're seeking to is not yet reached.
Basically, we're treating the converter as forward iterator and we try
to seek with the same iterator, if possible.
Where previously you could not even open the file in OP (within
reasonable time frame, I waited for 40 seconds before giving up), now
you can do it in.. slightly over a second. The best part is: the
experience is still not ideal. Typing in the buffer is sluggish. Still,
this is a start.
Release Notes:
- Mac: Improved performance with very long lines
This will allow us to compile debug builds of the remote-server for a
different architecture than the one we are developing on.
This also adds a CI step for building our remote server with minimal
dependencies.
Release Notes:
- N/A
- The App Shortcuts in macOS System Settings does not work for Zed since the menu items titles were not set.
- Previously you could set a shortcut for `Zoom`.
- This add support for `Window->Zoom` as well.
- Closes#18610
This PR addresses the same issue as PR #18578. After a full day of
research and testing, I believe I’ve found the best solution to resolve
this issue. With this PR, the window creation behavior on Windows
becomes more consistent with macOS:
- When `params.show` is `true`: The window is created and immediately
displayed.
- When `params.show` is `false`: The window is created but remains
hidden until the first call to `activate_window`.
As I mentioned in #18578, `winit` creates hidden windows by setting the
window's `exstyle` to `WS_EX_NOACTIVATE | WS_EX_TRANSPARENT |
WS_EX_LAYERED | WS_EX_TOOLWINDOW`, which is different from the method
used in this PR. Here, the window is created with normal parameters, but
we do not call `ShowWindow` so the window is not shown.
I'm not sure why `winit` doesn't use a smilliar approach like this PR to
create hidden windows. My guess is that `winit` is creating this hidden
window to function as a "DispatchWindow" — serving a purpose similar to
`WindowsPlatform` in `zed`. To ensure the window stays hidden even if
`ShowWindow` is called, they use the `exstyle` approach.
With the method used in this PR, my initial tests haven't revealed any
issues.
Release Notes:
- N/A
This fixes the problem of a `Project` sometimes not being dropped when
closing the single, last window of Zed.
Turns out, it wasn't get dropped for the following reason:
1. `editor::Editor` held a reference to project
2. The macOS `input_handler` on the `Window` held a reference to that
`Editor`
3. The AppKit window (and its input handler) get dropped asynchronously
(in the code in this diff), after the window is closed.
4. After the window is closed and no `cx.update()` calls are made
anymore, `flush_effects` is not called anymore.
5. But `flush_effects` is where we dropped entities that don't have any
more references.
In short: we dropped `Editor`, which held a reference to `Project`, out
of band, `flush_effects` wasn't called anymore, and thus the `Project`
wasn't dropped.
cc @ConradIrwin @bennetbo since we talked about this.
Release Notes:
- N/A
Co-authored-by: Antonio <antonio@zed.dev>
Cole Miller
Conrad Irwin
feeiyu
tims
Matin Aniss
张小白
Peter Tripp
Jason LeeandFloyd Wang
Gowtham Kandthedeveloper-sharath
Kyle Kelley
Caleb Heydon
Alvaro Parker
Bruno Calza
wannacu
Henry Chu
Thorsten BallandAntonio