Closes https://github.com/zed-industries/zed/issues/43208
This PR essentially unblocks the editable number field. The function
that shapes editor lines was hard-coding text alignment to the left,
meaning that whatever different alignment we'd pass through
`EditorStyles`would be ignored. To solve this, I just added a text align
and align width fields to the line paint function and updated all call
sites keeping the default configuration. Had to also add an
`alignment_offset()` helper to make sure the cursor positioning, the
selection background element, and the click-to-focus functionality were
kept in-sync with the non-left aligned editor.
Then... the big star of the show here is being able to add the `mode`
method to the number field, which uses `TextAlign::Center`, thus making
it work as we designed it to work.
https://github.com/user-attachments/assets/3539c976-d7bf-4d94-8188-a14328f94fbf
Next up, is turning the number filed to edit mode where applicable.
Release Notes:
- Fixed a bug where different text alignment configurations (i.e.,
center and right-aligned) wouldn't take effect in editors.
I've just enriched the existing tab_stop.rs example for GPUI with a
demonstration of tab_group. I don't think tab groups existed when the
original example was written.
(I didn't understand the behaviour for tab_group from the doccomments
and the example was missing, so I think this is a productive PR)
Release Notes:
- N/A
Closes #ISSUE
A [modal dialog](https://en.wikipedia.org/wiki/Modal_window) window is a
window that demands the user's immediate attention and blocks
interaction with other parts of the application until it's closed.
- On Windows this is done by disabling the parent window when the dialog
window is created and re-enabling the parent window when closed.
- On Wayland this is done using the
[`XdgDialog`](https://wayland.app/protocols/xdg-dialog-v1) protocol,
which hints to the compositor that the dialog should be modal. While
compositors like GNOME and KDE block parent interaction automatically,
the XDG specification does not guarantee this behavior, compositors may
deliver events to the parent window unfiltered. Since the specification
explicitly requires clients to implement event filtering logic
themselves, this PR implements client-side blocking in GPUI to ensure
consistent modal behavior across all Wayland compositors, including
those like Hyprland that don't block parent interaction.
- On X11 this is done by enabling the application window property
[`_NET_WM_STATE_MODAL`](https://specifications.freedesktop.org/wm/latest/ar01s05.html#id-1.6.8)
state.
I'm unable to implement this on MacOS as I lack the experience and the
hardware to test it. If anyone is interested on implementing this let me
know.
|Window|Linux (wayland)| Linux (x11) |MacOS|
|-|-|-|-|
|<video
src="https://github.com/user-attachments/assets/bfd0733a-445d-4b63-ac6b-ebe098a7dc74"></video>|<video
src="https://github.com/user-attachments/assets/024cd6ec-ff81-4250-a5be-5d207a023f8c"></video>|
N/A | <video
src="https://github.com/user-attachments/assets/656e60a5-26b2-4ee2-8368-1fbbe872453c"></video>|
TODO:
- [x] Block parent interaction client-side on X11
Release Notes:
- Added modal dialog window kind on GPUI
---------
Co-authored-by: Jason Lee <huacnlee@gmail.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#4644
Release Notes:
- Adds `MousePressureEvent`, an event that is sent anytime the touchpad
pressure changes, into `gpui`. MacOS only.
- Triggers go-to-defintion on force clicks in the editor.
This is my first contribution, let me know if I've missed something
here.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This reverts commit 082b80ec89.
This broke clicking, e.g. in snippets like
```rs
let x = vec![
1, 2, //
3,
];
```
clicking between `2` and `,` is quite off now.
Release Notes:
- N/A
Supersedes https://github.com/zed-industries/zed/pull/39910
At some point, these two (`index_for_x` and `closest_index_for_x`)
methods where separated out and some code paths used one, while other
code paths took the other. That said, their behavior is almost
identical:
- `index_for_x` computes the index behind the pixel offset, and returns
`None` if there's an overshoot
- `closest_index_for_x` computes the nearest index to the pixel offset,
taking into account whether the offset is over halfway through or not.
If there's an overshoot, it returns the length of the line.
Given these two behaviors, `closest_index_for_x` seems to be a more
useful API than `index_for_x`, and indeed the display map and other core
editor features use it extensively. So this PR is an experiment in
simply replacing one behavior with the other.
Release Notes:
- Improved the accuracy of mouse selections in Markdown
Release Notes:
- N/A
---
https://github.com/user-attachments/assets/d46b77ae-88ba-43da-93ad-3656a7fecaf9
The system menu is only support for macOS, so here just modify the macOS
platform special code.
The Windows, Linux used `ApplicationMenu`, I have already added
`checked` option to Zed's ContextMenu.
Then later when this PR merged, we can improve "View" menu to show check
state to panels (Project Panel, Outline Panel, ...).
This reintroduces `layer_shell` support after #32651 was reverted. On
top of that, it allows setting options for the created surface,
restricts the enum variant to the `wayland` feature, and adds an example
that renders a clock widget using the protocol.
I've renamed the `WindowKind` variant to `LayerShell` from `Overlay`,
since the protocol can also be used to render wallpapers and such, which
doesn't really fit with the word.
Things I'm still unsure of:
- We need to get the layer options types to the user somehow, but
nothing from the `platform::linux` crate was exported, I'm assuming
intentionally. I've kept the types inside the module (instead of doing
`pub use layer_shell::*` to not pollute the global namespace with
generic words like `Anchor` or `Layer` Let me know if you want to do
this differently.
- I've added the options to the `WindowKind` variant. That's the only
clean way I see to supply them when the window is created. This makes
the kind no longer implement `Copy`.
- The options don't have setter methods yet and can only be defined on
window creation. We'd have to make fallible functions for setting them,
which only work if the underlying surface is a `layer_shell` surface.
That feels un-rust-y.
CC @zeroeightysix
Thanks to @wuliuqii, whose layer-shell implementation I've also looked
at while putting this together.
Release Notes:
- Add support for the `layer_shell` protocol on wayland
---------
Co-authored-by: Ridan Vandenbergh <ridanvandenbergh@gmail.com>
Fixes a bug in https://github.com/zed-industries/zed/pull/39928
The bug caused all completions to appear in bold-face
Release Notes:
- Fixed a bug where bold-face font was applied to the wrong characters
in items in the autocomplete menu
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Close#35715
Release Notes:
- Fixed to wrap long URLs in editor.
<img width="836" height="740" alt="image"
src="https://github.com/user-attachments/assets/635ce792-5f19-4c76-b131-0d270d09b103"
/>
I remember when I was working on CJK line wrapping support in the early
days, I considered making `\` a line wrapping character, but for some
reason it was on the list of characters that were not allowed to wrap.
In reference to VS Code, it looks like `&`, `/`, `?` should wrap, so I
removed all of them.
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Release Notes:
- N/A
---
- Set `.SystemUIFont` as the GPUI default font.
- Add `Arial` to font fallback list.
- Add `Adwaita Sans` to default fallback list for Gnome.
- Move `Ubuntu` font to front of Gnome to make sure Ubuntu System takes
priority over `Ubuntu` font.
Our application get some crash report:
```
panicked at /Users/admin/.cargo/git/checkouts/zed-a70e2ad075855582/f1db3b4/crates/gpui/src/text_system.rs:150:9:
failed to resolve font 'Helvetica' or any of the fallbacks: Zed Plex Mono, Helvetica, Segoe UI, Cantarell, Ubuntu, Noto Sans, DejaVu Sans
```
This change to add `Arial` to fallback list, this font was included in
macOS and Windows.
Ref link (search "Arial"):
> Mac OS X (now known as [macOS](https://en.wikipedia.org/wiki/MacOS))
was the first Mac OS version to include Arial;
> https://en.wikipedia.org/wiki/Arial
- macOS Sequoia: https://support.apple.com/en-us/120414
- Windows 10:
https://learn.microsoft.com/en-us/typography/fonts/windows_10_font_list
- Gnome: https://developer.gnome.org/hig/guidelines/typography.html
Rendering breaks when both an element and its parent have opacity set.
The following code reproduces the issue:
```rust
struct Repro;
impl Render for Repro {
fn render(&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
fn make_box(bg: impl Into<Fill>) -> impl IntoElement {
div().size_8().bg(bg).hover(|style| style.opacity(0.5))
}
div()
.flex()
.items_center()
.justify_center()
.size(px(500.0))
.hover(|style| style.opacity(0.5))
.child(make_box(gpui::red()))
.child(make_box(gpui::green()))
.child(make_box(gpui::blue()))
}
}
```
Before (broken behavior):
https://github.com/user-attachments/assets/2c5c1e31-88b2-4f39-81f8-40060e3fe958
The child element resets its parent and siblings' opacity, which is an
unexpected behavior.
After (fixed behavior):
https://github.com/user-attachments/assets/48527033-b06f-4737-b6c3-0ee3d133f138
Release Notes:
- Fixed an issue where nested opacity is rendered incorrectly.
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This reverts commit ed7bd5a8ed.
We noticed this PR causes the editor to hang if you hold down any of the
menu item actions like ctrl+z, ctrl+x, etc
Release Notes:
- Fixed macOS menu item actions hanging the editor when their key
combination is held down
On macOS, traditionally when a keyboard shortcut is activated, the menu
in the menu bar flashes to indicate that the action was recognised.
<img width="289" height="172" alt="image"
src="https://github.com/user-attachments/assets/a03ecd2f-f159-4f82-b4fd-227f34393703"
/>
This PR adds this functionality to GPUI, where when a keybind is pressed
that triggers an action in the menu, the menu flashes.
Release Notes:
- N/A
Extracts and cleans up GPUI's scheduler code into a new `scheduler`
crate, making it pluggable by external runtimes. This will enable
deterministic integration testing with cloud components by providing a
unified test scheduler across Zed and backend code. In Zed, it will
replace the existing GPUI scheduler for consistent async task management
across platforms.
## Changes
- **Core Implementation**: `TestScheduler` with seed-based
randomization, session tracking (`SessionId`), and foreground/background
task separation for reproducible testing.
- **Executors**: `ForegroundExecutor` (!Send, thread-local) and
`BackgroundExecutor` (Send, with blocking/timeout support) as
GPUI-compatible wrappers.
- **Clock and Timer**: Controllable `TestClock` and future-based `Timer`
for time-sensitive tests.
- **Testing APIs**: `once()`, `with_seed()`, and `many()` methods for
configurable test runs.
- **Dependencies**: Added `async-task`, `chrono`, `futures`, etc., with
updates to `Cargo.toml` and lock file.
## Benefits
- **Integration Testing**: Facilitates reliable async tests involving
cloud sessions, reducing flakiness via deterministic execution.
- **Pluggability**: Trait-based design (`Scheduler`) allows easy
integration into non-GPUI runtimes while maintaining GPUI compatibility.
- **Cleanup**: Refactors GPUI scheduler logic for clarity, correctness
(no `unwrap()`, proper error handling), and extensibility.
Follows Rust guidelines; run `./script/clippy` for verification.
- [x] Define and test a core scheduler that we think can power our cloud
code and GPUI
- [ ] Replace GPUI's scheduler
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This reverts commit 40199266b6.
The issue with the commit is: ContentMask<Pixels>::intersect is doing
intersection of corner radii which makes inner containers use the max
corner radius out of all the parents when it should be more complex to
correctly clip children (clip sorting..?)
Release Notes:
- N/A
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
Release Notes:
- N/A
---
In the same vein as #29538, the "Services" menu on macOS depended on the
text being exactly "Services", not allowing for i18n of the menu name.
This PR introduces a new menu type called `OsMenu` that defines a
special menu that can be populated by the system. Currently, it takes
one enum value, `ServicesMenu` that tells the system to populate its
contents with the items it would usually populate the "Services" menu
with.
An example of this being used has been implemented in the `set_menus`
example:
`cargo run -p gpui --example set_menus`
---
Point to consider:
In `mac/platform.rs:414` the existing code for setting the "Services"
menu remains for backwards compatibility. Should this remain now that
this new method exists to set the menu, or should it be removed?
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This allows debugging Zed with Renderdoc, and also fixes an issue where
glyphs' bounds were miscalculated for certain sizes and scale factors.
Release Notes:
- N/A
---------
Co-authored-by: Kate <kate@zed.dev>
Co-authored-by: Julia <julia@zed.dev>
Co-authored-by: Junkui Zhang <364772080@qq.com>
This fixes an issue with tab indices where we would actually focus the
second focus handle on first focus instead of the first one. The test
was updated accordingly.
Release Notes:
- N/A
---------
Co-authored-by: Jason Lee <huacnlee@gmail.com>
This is another attempt to solve the same problem as
https://github.com/zed-industries/zed/pull/29718, while avoiding the
regression on Intel GPUs.
### Background
Currently, on main, all paths are first rendered to an intermediate
"atlas" texture, similar to what we use for rendering glyphs, but with
multi-sample antialiasing enabled. They are then drawn into our actual
frame buffer in a separate pass, via the "path sprite" shaders.
Notably, the intermediate texture acts as an "atlas" - the paths are
laid out in a non-overlapping way, so that each path could be copied to
an arbitrary position in the final scene. This non-overlapping approach
makes a lot sense for Glyphs (which are frequently re-used in multiple
places within a frame, and even across frames), but paths do not have
these properties.
* we clear the atlas every frame
* we rasterize each path separately. there is no deduping.
The problem with our current approach is that the path atlas textures
can end up using lots of VRAM if the scene contains many paths. This is
more of a problem in other apps that use GPUI than it is in Zed, but I
do think it's an issue for Zed as well. On Windows, I have hit some
crashes related to GPU memory.
In https://github.com/zed-industries/zed/pull/29718, @sunli829
simplified path rendering to just draw directly to the frame buffer, and
enabled msaa for the whole frame buffer. But apparently this doesn't
work well on Intel GPUs because MSAA is slow on those GPUs. So we
reverted that PR.
### Solution
With this PR, we rasterize paths to an intermediate texture with MSAA.
But rather than treating this intermediate texture like an *atlas*
(growing it in order to allocate non-overlapping rectangles for every
path), we simply use a single fixed-size, color texture that is the same
size as thew viewport. In this texture, we rasterize the paths in their
final screen position, allowing them to overlap. Then we simply blit
them from the resolved texture to the frame buffer.
### To do
* [x] Implement for Metal
* [x] Implement for Blade
* [x] Fix content masking for paths
* [x] Fix rendering of partially transparent paths
* [x] Verify that this performs well on Intel GPUs (help @notpeter 🙏 )
* [ ] Profile and optimize
Release Notes:
- N/A
---------
Co-authored-by: Junkui Zhang <364772080@qq.com>
This commit adds an example with deep children hierarchy.
The depth of a tree can be tweaked with GPUI_TREE_DEPTH env variable.
With depth=100
<img width="301" height="330" alt="image"
src="https://github.com/user-attachments/assets/844cd285-c5f3-4410-a74e-981bf093ba2e"
/>
With this example, I can trigger a stack overflow at depth=633 (and
higher).
Release Notes:
- N/A
Reverts zed-industries/zed#29718
We've noticed some issues with Zed on Intel-based Macs where typing has
become sluggish, and git bisect has seemed to point towards this PR.
Reverting for now, until we can understand why it is causing this issue.
Closes#18263
Improvements:
• **Batch text rendering** - Combine adjacent cells with identical
styling into single text runs to reduce draw calls
• **Throttle hyperlink searches** - Limit hyperlink detection to every
100ms or when mouse moves >5px to reduce CPU usage
• **Pre-allocate collections** - Use `Vec::with_capacity()` for cells,
runs, and regions to minimize reallocations
• **Optimize background regions** - Merge adjacent background rectangles
to reduce number of draw operations
• **Cache selection text** - Only compute terminal selection string when
selection exists
Release Notes:
- Improved terminal rendering performance.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Currently, the rendering path required creating a texture for each path,
which wasted a large amount of video memory. In our application, simply
drawing some charts resulted in video memory usage as high as 5G.
I removed the step of creating path textures and directly drew the paths
on the rendering target, adding post-processing global multi-sampling
anti-aliasing. Drawing paths no longer requires allocating any
additional video memory and also improves the performance of path
rendering.
Release Notes:
- N/A
---------
Co-authored-by: Jason Lee <huacnlee@gmail.com>
Release Notes:
- N/A
Just make a simple change to avoid crash.
```
thread 'main' panicked at library\std\src\time.rs:436:33:
overflow when subtracting duration from instant
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\std\src\panicking.rs:697
1: core::panicking::panic_fmt
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\panicking.rs:75
2: core::panicking::panic_display
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\panicking.rs:261
3: core::option::expect_failed
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\option.rs:2024
4: core::option::Option::expect
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\option.rs:933
5: std::time::impl$3::sub
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\std\src\time.rs:436
6: data_table::Quote::random
at .\crates\gpui\examples\data_table.rs:54
```
This PR also introduces `Context::processor`, a sibling of
`Context::listener` that takes a strong pointer to entity and allows for
a return result.
Release Notes:
- N/A
Co-authored-by: Mikayla <mikayla@zed.dev>
Follow-up to #24797
This PR ensures some cursor styles do not change for draggable elements
during dragging. The linked PR covered this on the higher level for
draggable divs. However, e.g. the pane divider inbetween two editors is
not a draggable div and thus still has the issue that the cursor style
changes during dragging. This PR fixes this issue by setting the hitbox
to `None` in cases where the element is currently being dragged, which
ensures the cursor style is applied to the cursor no matter what during
dragging.
Namely, this change fixes this for
- non-div pane dividers
- minimap slider and the
- editor scrollbars
and implements it for the UI scrollbars (Notably, UI scrollbars do
already have `cursor_default` on their parent container but would not
keep this during dragging. I opted out on removing this from the parent
containers until #30194 or a similar PR is merged).
https://github.com/user-attachments/assets/f97859dd-5f1d-4449-ab92-c27f2d933c4a
Release Notes:
- N/A
Release Notes:
- N/A
---
This change is used to solve the problem of not being able to respond
correctly in two-layer scrolling (in different directions). This is a
common practical requirement.
As in the example, in actual use, there may be a scene with a horizontal
scroll in a vertical scroll. Before the modification, if we scroll up
and down in the area that can scroll horizontally, it will not respond
(because it is blocked by the horizontal scroll layer).
## Before
https://github.com/user-attachments/assets/e8ea0118-52a5-44d8-b419-639d4b6c0793
## After
https://github.com/user-attachments/assets/aa14ddd7-5596-4dc5-9c6e-278aabdfef8e
----
This change may cause many side effects, causing some scrolling details
to be different from before, and more testing and analysis are needed.
I have tested some existing scenarios of Zed (such as opening the Branch
panel on the Editor and scrolling) and it seems to be correct (but it is
possible that I don’t know some interaction details). Here, the person
who added this line of code before needs to evaluate the original
purpose.
