* related to #5832
(I want to keep that open and actually update the button to use the new
popup, but this should be enough to fix it for now)
* [X] I have followed the instructions in the PR template
lien -> line
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes <https://github.com/emilk/egui/issues/THE_RELEVANT_ISSUE>
* [ x ] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [x] I have followed the instructions in the PR template
# Overview
This is a small change that supports draggable elements inside a
`Scene`.
When a Scene is initialized with a `Rect::Zero`, following the [example
in the
demo](https://github.com/emilk/egui/blob/master/crates/egui_demo_lib/src/demo/scene.rs#L15),
it will [automatically be reset to the `inner_rect` of the
UI](https://github.com/emilk/egui/blob/master/crates/egui/src/containers/scene.rs#L120-L123).
This centers the scene on the inner-rect contents, however the resulting
`scene_rect` doesn't fill the entire `outer_rect`. This probably isn't
an issue for most users of `Scene`.
However, I want to support draggable elements on a `Scene`, and to do
that I need to map the pointer-position in the window to the scene_rect
position.
As is, the example of draggable elements on Scene works after the user
has modified the scene rect in some way (zoom or pan), when `scene_rect`
is set to `to_global.inverse() * outer_rect`
([here](https://github.com/emilk/egui/blob/master/crates/egui/src/containers/scene.rs#L114-L118)).
Before a user modifies the scene rect, the pointer-position cannot be
reliably mapped to the scene_rect, since the scene_rect doesn't span the
entire window.
This PR just forces that translation to always run after the scene_rect
is reset to `inner_rect`. The practical result is that the scene_rect
will now always span the full outer_rect.
# Example
Here's a small app that demonstrates the functionality I'm trying to
support. I'm new to Egui so there may be better patterns for what I'm
trying to do, but if you run this against `main` and this branch you'll
notice the difference.
```rs
use eframe::egui::*;
/// Map coordinates from the src rect to the target rect
fn map_to_rect(position: Pos2, src_rect: Rect, dest_rect: Rect) -> Pos2 {
let x = (position.x - src_rect.min.x) / (src_rect.max.x - src_rect.min.x)
* (dest_rect.max.x - dest_rect.min.x)
+ dest_rect.min.x;
let y = (position.y - src_rect.min.y) / (src_rect.max.y - src_rect.min.y)
* (dest_rect.max.y - dest_rect.min.y)
+ dest_rect.min.y;
Pos2::new(x, y)
}
pub fn draggable_scene_element(
ui: &mut Ui,
id: Id,
position: &mut Rect,
scene_rect: Rect,
container_rect: Rect,
) -> Response {
let is_being_dragged = ui.ctx().is_being_dragged(id);
if is_being_dragged {
let r = ui.put(*position, |ui: &mut Ui| ui.label("Draggable"));
if let Some(pointer_pos) = ui.ctx().pointer_interact_pos() {
let pointer_pos = map_to_rect(pointer_pos, container_rect, scene_rect);
let delta = pointer_pos.to_vec2() - position.center().to_vec2();
*position = position.translate(delta);
};
r
} else {
let r = ui.put(*position, |ui: &mut Ui| ui.label("Draggable"));
ui
.interact(position.clone(), id, Sense::drag())
.on_hover_cursor(CursorIcon::Grab);
r
}
}
struct MyApp {
scene_rect: Rect,
position: Rect,
}
impl MyApp {
fn new() -> Self {
Self {
scene_rect: Rect::ZERO,
position: Rect::from_min_size(Pos2::new(-50., -50.), Vec2::new(100., 100.)),
}
}
}
impl eframe::App for MyApp {
fn update(&mut self, ctx: &Context, _frame: &mut eframe::Frame) {
CentralPanel::default().show(ctx, |ui| {
let scene_rect = self.scene_rect.clone();
let container_rect = ui.min_rect();
Scene::default().show(ui, &mut self.scene_rect, |ui| {
ui.put(
Rect::from_min_size(Pos2::new(100., 200.), Vec2::new(100., 100.)),
|ui: &mut Ui| ui.label("static element"),
);
ui.put(self.position, |ui: &mut Ui| {
draggable_scene_element(
ui,
Id::from("demo"),
&mut self.position,
scene_rect,
container_rect,
)
});
});
});
}
}
```
# Summary
I need a way to map pointer coordinates to scene coordinates, in order
to support draggable elements in a scene. This patch makes that easier
by ensuring the scene_rect will always be the full size of the
outer_rect.
If you have a better way to accomplish what I'm after, I'm happy to
close this. Thanks!
This is the same change as in #4069 but as this is stale I wanted to
reopen a non stale PR
Modifies ImageLoader's load function to use background threads for the
image decoding work. This avoids blocking the main thread that is
especially noticeable when loading many images at once.
This was modelled after the other loader implementations that also use
threads.
* Closes <https://github.com/emilk/egui/issues/5375>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: lucasmerlin <lucasmeurer96@gmail.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Enabled the `missing_assert_message` lint
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Lucas Meurer <lucasmeurer96@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [x] I have followed the instructions in the PR template
This fixes an issue on android where keyboard input is not registered in
text boxes because `winit` does not fill in the `text` field of the
`KeyEvent`
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Dear emilk,
Programs built with egui on Windows are terminating every hour on
average.
When this commit is applied, it works fine for about 3 to 6 hours on
average.
I've been testing it for over 6 months and have submitted multiple PRs
since 6 months ago,
but they haven't applied it yet.
Thank you.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This removes the `expand(1.0)` on text background colors, since it makes
translucent background colors have bad looking bleeding.
There is probably a smarter solution than disabling the highlighting
entirely, but I don't see a way to do that while keeping the area
consumed consistent between translucent/solid colors, or adding a decent
step up in complexity.
Since this makes it impossible to tell if selected text is highlighted,
this also adds a blanket `0.5` gamma multiply to the text selection
background color. If that is undesirable because it's a bad arbitrary
number choice, or if it's too much of an unexpected change and just the
default values should be changed, please let me know.
These changes cause the tests that use screenshots with highlighted text
to fail, though I am not sure how to update those tests to match the
changes.
<details>
<summary>Comparison Images</summary>
Current:

After changes:

</details>
<details>
<summary>Code used to make comparison images</summary>
```rs
fn color_text_format(ui: &Ui, color: Color32) -> TextFormat {
TextFormat { font_id: FontId::monospace(ui.text_style_height(&egui::TextStyle::Monospace)), background: color, ..Default::default() }
}
fn color_sequence_galley(ui: &Ui, text: &str, colors: [Color32; 3]) -> Arc<Galley> {
let mut layout_job = LayoutJob::default();
for color in colors {
layout_job.append(text, 0.0, color_text_format(ui, color));
}
ui.fonts(|f| f.layout_job(layout_job))
}
fn color_sequence_row(ui: &mut Ui, label_text: &str, text: &str, colors: [Color32; 3]) {
ui.label(label_text);
ui.label(color_sequence_galley(ui, text, colors));
ui.end_row();
}
egui::Grid::new("comparison display").show(ui, |ui| {
ui.ctx().set_pixels_per_point(2.0);
let transparent = Color32::TRANSPARENT;
let solid = Color32::RED;
let solid_2 = Color32::GREEN;
let translucent_1 = Color32::GRAY.gamma_multiply(0.5);
let translucent_2 = Color32::GREEN.gamma_multiply(0.5);
color_sequence_row(ui, "Transparent to Solid:", " ", [transparent, solid, transparent]);
color_sequence_row(ui, "Translucent to Transparent:", " ", [transparent, translucent_1, transparent]);
color_sequence_row(ui, "Solid to Transparent:", " ", [solid, solid_2, solid]);
color_sequence_row(ui, "Solid to Solid:", " ", [solid, transparent, solid]);
color_sequence_row(ui, "Solid to Translucent:", " ", [solid, translucent_1, solid]);
color_sequence_row(ui, "Translucent to Translucent:", " ", [translucent_1, translucent_2, translucent_1]);
color_sequence_row(ui, "Transparent to Solid:", "a", [transparent, solid, transparent]);
color_sequence_row(ui, "Translucent to Transparent:", "a", [transparent, translucent_1, transparent]);
color_sequence_row(ui, "Solid to Transparent:", "a", [solid, solid_2, solid]);
color_sequence_row(ui, "Solid to Solid:", "a", [solid, transparent, solid]);
color_sequence_row(ui, "Solid to Translucent:", "a", [solid, translucent_1, solid]);
color_sequence_row(ui, "Translucent to Translucent:", "a", [translucent_1, translucent_2, translucent_1]);
})
```
</details>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The bug was in `Color32::from_rgba_unmultiplied` and by extension
affects:
* `Color32::from_rgba_unmultiplied`
* `hex_color!`
* `HexColor`
* `ColorImage::from_rgba_unmultiplied`
* All images with transparency (png, webp, …)
* `Color32::from_white_alpha`
The bug caused translucent colors to appear too bright.
## More
Color is hard.
When I started out egui I thought "linear space is objectively better,
for everything!" and then I've been slowly walking that back for various
reasons:
* sRGB textures not available everywhere
* gamma-space is more _perceptually_ even, so it makes sense to use for
anti-aliasing
* other applications do everything in gamma space, so that's what people
expect (this PR)
Similarly, pre-multiplied alpha _makes sense_ for blending colors. It
also enables additive colors, which is nice. But it does complicate
things. Especially when mixed with sRGB/gamma (As @karhu [points
out](https://github.com/emilk/egui/pull/5824#issuecomment-2738099254)).
## Related
* Closes https://github.com/emilk/egui/issues/5751
* Closes https://github.com/emilk/egui/issues/5771 ? (probably; hard to
tell without a repro)
* But not https://github.com/emilk/egui/issues/5810
## TODO
* [x] I broke the RGBA u8 color picker. Fix it
---------
Co-authored-by: Andreas Reich <andreas@rerun.io>
Add an option called `movable_by_window_background` alongside a new
builder method. When set to true, the window is movable by dragging its
background ([Apple
Docs](https://developer.apple.com/documentation/appkit/nswindow/ismovablebywindowbackground))
This is exclusive to macOS systems, similar to `fullsize_content_view`.
* [x] I have followed the instructions in the PR template
* [x] I have followed the instructions in the PR template
This PR implements `AsRef<[u8]>` for `FontData`, allowing it to be
passed into `fontdb`'s
[`Source`](https://docs.rs/fontdb/0.16.2/fontdb/enum.Source.html) type.
This would allow `egui` and `cosmic_text` to share font data with
eachother
Hi !
I'm using egui and egui_extra to build a demo tool for a crate I'm
building. In this crate I load favicons from a lot of websites, and I
have some failures on some .ico files. After tracking this thing down, I
guess there is two issues (kinda), in the image crate,
'image/vnd.microsoft.icon' isn't recognized as the valid mime for an ico
image (I created a [PR](https://github.com/image-rs/image/pull/2434)),
and the code to detect if a given mime type is compatible with the image
crate decoders in this crate do not support multi-mime type formats.
[ImageFormat::to_mime_type](85f2412d55/src/image.rs (L216C12-L216C24))
is only returning one mime for a given format (which is fine), we
compare the result of this method to guess if the format is
valid/enabled. Retriveing the correct format using
[ImageFormat::from_mime_type](85f2412d55/src/image.rs (L166))
would allow more mime to be considered valid since multiple mime can
match the same format.
The same applies to the extension detection, which I also modified to
stay consistent
Thanks
Breaking changes:
- When using the Memory::popup state, it's now required to call
keep_popup_open each frame or the popup will close.
- Usually handled by the `Popup` struct, but required for custom popups
using the state in `Memory` directly
-----
If a popup is abandoned `Memory::popup` would remain `Some`. This is
problematic if, for example, you have logic that checks
`is_any_popup_open`.
This PR adds a new requirement for popups keeping their open state in
`Memory::popup`. They must call `Memory::keep_popup_open` as long as
they are being rendered. The recent changes in #5716 make this easy to
implement.
Supersedes #4697 which had an awkward implementation
These two videos show a case where a context menu was open when the
underlying widget got removed.
Before (`any_popup_open` remains `true`)

After

* Closes https://github.com/emilk/egui/issues/3657
* [x] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
This is not supported on the web and not yet on Wayland.
~~I also had to update `ring` and add an exception for `paste` being
unmaintained.~~ Has since been updated on master.
* [x] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes N/A, but this is part of
https://github.com/emilk/egui/issues/3378
* [x] I have followed the instructions in the PR template
Other text layout libraries in Rust--namely, Parley and Cosmic
Text--have one canonical text cursor type (Parley's is a byte index,
Cosmic Text's also stores the line index). To prepare for migrating egui
to one of those libraries, it should also have only one text cursor
type. I also think simplifying the API is a good idea in and of
itself--having three different cursor types that you have to convert
between (and a `Cursor` struct which contains all three at once) is
confusing.
After a bit of experimentation, I found that the best cursor type to
coalesce around is `CCursor`. In the few places where we need a
paragraph index or row/column position, we can calculate them as
necessary.
I've removed `CursorRange` and `PCursorRange` (the latter appears to
have never been used), merging the functionality with `CCursorRange`. To
preserve the cursor position when navigating row-by-row, `CCursorRange`
now stores the previous horizontal position of the cursor.
I've also removed `PCursor`, and renamed `RowCursor` to `LayoutCursor`
(since it includes not only the row but the column). I have not renamed
either `CCursorRange` or `CCursor` as those names are used in a lot of
places, and I don't want to clutter this PR with a bunch of renames.
I'll leave it for a later PR.
Finally, I've removed the deprecated methods from `TextEditState`--it
made the refactoring easier, and it should be pretty easy to migrate to
the equivalent `TextCursorState` methods.
I'm not sure how many breaking changes people will actually encounter. A
lot of these APIs were technically public, but I don't think many were
useful. The `TextBuffer` trait now takes `&CCursorRange` instead of
`&CursorRange` in a couple of methods, and I renamed
`CCursorRange::sorted` to `CCursorRange::sorted_cursors` to match
`CursorRange`.
I did encounter a couple of apparent minor bugs when testing out text
cursor behavior, but I checked them against the current version of egui
and they're all pre-existing.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes https://github.com/emilk/egui/issues/5507
* [x] I have followed the instructions in the PR template
* [x] I have followed the instructions in the PR template
This PR fixes an issue, where `DragValue` would expand when it enters
editing state. There were 3 contributing problems:
- A workaround introduced in #4276 caused the `DragValue` to report
incorrect outer size.
- The `DragValue` uses `TextEdit` internally and sets both `min_size`
and `desired_width` to the same value - desired width is used **before**
padding is applied - this is in contrast to `Button` (also used
internally by `DragValue`), which only uses `min_size`. This caused the
`DragValue` to expand horizontally by the size of button padding.
- The height of the `TextEdit` is (among other things) determined by the
height of the row, which was not present in `Button`. This caused a
small vertical expansion, when the contents (including padding) were
larger than the `min_size`.

Here the dimensions set in code are:
- padding: 20 x 20 pt
- interact size: 80 x 30 pt
*Note: I do not know what's up with the tests. When I ran the check
script, they were failing because of 3 UI missmatches, so I updated the
snapshots. Now, the updated snapshots cause the same failure in CI, that
appeared locally before the update. Now the locally run tests fail with
`The platform you're compiling for is not supported by winit` and couple
more following errors coming from the same source (`winit 0.30.7`).*
Fixes kinetic scrolling on android (and possibly other touch devices),
by calculating the final velocity before clearing the position history
on PointerGone events.
* Closes#5311
* [X] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
Menus currently have their own style that removes outlines and
backgrounds. This is nice if the menu only contains buttons. However if
the menu contains other widgets, e.g. a drag value, the style change
makes it quite difficult to identify such widgets. This is a simple way
to make this configurable.
* [x] I have followed the instructions in the PR template
* Closes https://github.com/emilk/egui/issues/5789
* [x] I have followed the instructions in the PR template
While this change fixes the TextEdit specific issue, I'm worried that
the underlying problem is more fundamental and could show up in other
widgets, and I'm wondering if there's a more general solution?
* [x] I have followed the instructions in the PR template
* Closes https://github.com/emilk/egui/issues/3734
## Info
This PR addresses an issue where resizing a scroll handle can lead to
unwanted overlap.
It is also happening on the egui-demo.

## Cause
*Note: The following explanation assumes a vertical scroll; however, the
logic applies equally to horizontal scrolling.*
When the scroll handle is positioned at the top or bottom of the scroll
area and the handle is resized to fit the minimum handle size, there is
a risk of overlap. This occurs if the handle’s new size extends beyond
the bounds of the scroll area.
## Proposed Solution
1. Check whether increasing the handle size will cause it to overlap
with the scroll area.
2. If an overlap is detected, adjust the handle’s center position by the
overlap amount, moving it towards the center of the scroll area.
Continuation of #5713
**Silently breaking changes:**
- Menus now close on click by default, this is configurable via
`PopupCloseBehavior`
**Additional additions:**
- `Button::right_text`
- `StyleModifier`
This is a rewrite of the egui menus, with the following goals:
- submenu buttons should work everywhere, in a popup, context menu,
area, in some random Ui
- remove the menu state from Ui
- should work just like the previous menu
- ~proper support for keyboard navigation~
- It's better now but requires further work to be perfect
- support `PopupCloseBehavior`
* Closes#4607
* [x] I have followed the instructions in the PR template
This PR reverts a change introduced in PR
https://github.com/emilk/egui/pull/3660 that caused a regression with
`TextEdit::singleline`. The original PR attempted to fix an issue with
the cursor in `TextEdit` inside `ScrollArea`, but it did so by adding
unnecessary size allocation to `TextEdit`, which breaks the layout when
`TextEdit::singleline` is used outside of `ScrollArea`.

The regression introduced by #3660 is more severe, as it completely
breaks the layout of applications using `TextEdit::singleline`, as shown
in the following issues:
* Closes https://github.com/emilk/egui/issues/5500
* Closes https://github.com/emilk/egui/issues/5597
Furthermore, I was unable to reproduce the original bug from PR #3660 in
the current version of egui using the following code:
```rust
impl eframe::App for MyEguiApp {
fn update(&mut self, ctx: &egui::Context, _: &mut eframe::Frame) {
ctx.set_debug_on_hover(true);
egui::CentralPanel::default().show(ctx, |ui| {
ScrollArea::vertical().max_height(100.0).show(ui, |ui| {
ui.add(TextEdit::multiline(&mut self.text).hint_text("Enter text here..."))
});
});
}
}
```
This code attempts to recreate the layout shown in the video from PR
#3660, using a `ScrollArea` with limited height and a `TextEdit` inside.
However, the cursor hiding issue was not reproducible.

Therefore, I believe the code added in PR #3660 is no longer necessary
and only creates more problems.
* Closes https://github.com/emilk/egui/issues/5500
* Closes https://github.com/emilk/egui/issues/5597
* [x] I have followed the instructions in the PR template
In Rerun, pressing `Cmd+S` brings up a save dialog using `rfd`, but we
get not key-up event for the `S` key (in winit).
This leads to `S` being mistakenly marked as down when we switch back to
the app.
This PR takes the safe route and marks all keys as up when an egui app
loses focus.
* Tested with https://github.com/rerun-io/rerun/pull/9103
This adds a generic way of telling containers to close from their child
`Ui`s.
* Part of #5727
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* [x] I have followed the instructions in the PR template
This PR handles pointer events and focus which did following changes:
- `element_from_point` and focus is now acquired from root node object
by using `get_root_node` from document or a shadow root.
- `TextAgent` is appended individually in each shadow root.
These changes handles pointer events and focus well in a web app that
are running in a shadow dom, or else the hover pointer actions and
keyboard input events are not triggered in a shadow dom.
Helpful for building embeddable/multi-view web-apps.
fixes#5708
Allows the user to disable the automatic tooltip when a Label is elided
* Closes <https://github.com/emilk/egui/issues/5708>
* [x] I have followed the instructions in the PR template
Hi, after upgrading to 0.31.0 all of my beautiful static webp images
started failing to load. I use the image_loader to load those via the
`image` crate.
I noticed that with 0.31.0 there are additions to how animated image
types are handled with frames and such. And with those changes the frame
index is attached to the uri at the end. This was problematic for the
image_loader, because it wasn't updated to handle that frame tag at the
end of the uri, so when looking up the bytes, it would fail to match the
uri in the bytes cache (the bytes were being saved without the frame
index, but attempting to be fetched _with_ the frame index).
This fixes the image_loader for me with webp & gif. They don't load the
animations, but I think that is because I don't have the custom
image_loader set up so I'm not worried about that for myself. I'm not
sure if that part is problematic in general, or if its just the way I
have my features set up.
You can recreate the issue on master by swapping out the dependency
features in the `images` example like this:
```
# egui_extras = { workspace = true, features = ["default", "all_loaders"] }
# env_logger = { version = "0.10", default-features = false, features = [
# "auto-color",
# "humantime",
# ] }
# image = { workspace = true, features = ["jpeg", "png"] }
egui_extras = { workspace = true, features = ["image", "svg"] }
env_logger = { version = "0.10", default-features = false, features = [
"auto-color",
"humantime",
] }
image = { workspace = true, features = ["jpeg", "png", "webp", "gif"] }
```
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: lucasmerlin <lucasmeurer96@gmail.com>
This introduces new `Tooltip` and `Popup` structs that unify and extend
the old popups and tooltips.
`Popup` handles the positioning and optionally stores state on whether
the popup is open (for click based popups like `ComboBox`, menus,
context menus).
`Tooltip` is based on `Popup` and handles state of whether the tooltip
should be shown (which turns out to be quite complex to handles all the
edge cases).
Both `Popup` and `Tooltip` can easily be constructed from a `Response`
and then customized via builder methods.
This also introduces `PositionAlign`, for aligning something outside of
a `Rect` (in contrast to `Align2` for aligning inside a `Rect`). But I
don't like the name, any suggestions? Inspired by [mui's tooltip
positioning](https://mui.com/material-ui/react-tooltip/#positioned-tooltips).
* Part of #4607
* [x] I have followed the instructions in the PR template
TODOs:
- [x] Automatic tooltip positioning based on available space
- [x] Review / fix / remove all code TODOs
- [x] ~Update the helper fns on `Response` to be consistent in naming
and parameters (Some use tooltip, some hover_ui, some take &self, some
take self)~ actually, I think the naming and parameter make sense on
second thought
- [x] Make sure all old code is marked deprecated
For discussion during review:
- the following check in `show_tooltip_for` still necessary?:
```rust
let is_touch_screen = ctx.input(|i| i.any_touches());
let allow_placing_below = !is_touch_screen; // There is a finger below. TODO: Needed?
```
- Enable all-features when generating docs
- Add x11 feature so it builds on Linux
- Add double hashes to the feature comments so document-features
includes them in the docs
* Closes <https://github.com/emilk/egui/issues/5709>
* [x] I have followed the instructions in the PR template
* Closes <https://github.com/emilk/egui/issues/5690>
* [x] I have followed the instructions in the PR template
It still isn't ideal, since you have to remember to call key_up on a
separate frame.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
I got annoyed by all the slightly different variations of "collect
snapshot results and unwrap them at the end of test" I've written, so I
added a struct to make this nice and simple.
One controversial thing: It panics when dropped. I wanted to ensure
people cannot forget to unwrap the results at the end, and this was the
best thing I could come up with. I don't think this is possible via
clippy lint or something like that.
* [x] I have followed the instructions in the PR template
Breaking change!
* `Rounding` -> `CornerRadius`
* `rounding` -> `corner_radius`
This is to:
* Clarify
* Conform to other systems (e.g. Figma)
* Avoid confusion with `GuiRounding`
## Defining what `Rounding` is
This PR defines what `Rounding` means: it is the corner radius of
underlying `RectShape` rectangle. If you use `StrokeKind::Inside`, this
means the rounding is of the outer part of the stroke. Conversely, if
you use `StrokeKind::Outside`, the stroke is outside the rounded
rectangle, so the stroke has an inner radius or `rounding`, and an outer
radius that is larger by `stroke.width`.
This definitions is the same as Figma uses.
## Improving general shape rendering
The rendering of filled shapes (rectangles, circles, paths, bezier) has
been rewritten. Instead of first painting the fill with the stroke on
top, we now paint them as one single mesh with shared vertices at the
border. This has several benefits:
* Less work (faster and with fewer vertices produced)
* No overdraw (nicer rendering of translucent shapes)
* Correct blending of stroke and fill
The logic for rendering thin strokes has also been improved, so that the
width of a stroke of `StrokeKind::Outside` never affects the filled area
(this used to be wrong for thin strokes).
## Improving of rectangle rendering
Rectangles also has specific improvements in how thin rectangles are
painted.
The handling of "Blur width" is also a lot better, and now works for
rectangles with strokes.
There also used to be bugs with specific combinations of corner radius
and stroke width, that are now fixed.
## But why?
With the new `egui::Scene` we end up with a lot of zoomed out shapes,
with sub-pixel strokes. These need to look good! One thing led to
another, and then I became obsessive 😅
## Tessellation Test
In order to investigate the rendering, I created a Tessellation Test in
the `egui_demo_lib`.
[Try it
here](https://egui-pr-preview.github.io/pr/5669-emilkimprove-tessellator)


<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* ~Closes <https://github.com/emilk/egui/issues/THE_RELEVANT_ISSUE>~
(just a quick typo fix)
* [x] I have followed the instructions in the PR template
It used to be that `UPDATE_SNAPSHOTS=true cargo test --all-features`
would stop on the first crate with a failure, requiring you to run it
multiple times, which is annoying, and a waste of time.
This is a breaking change, requiring users to think about wether the
stroke is inside/centered/outside the rect.
When in doubt, add `egui::StrokeKind::Inside` to the function call.
Adds `RectShape::stroke_kind` so you can select if the stroke goes
inside, outside, or is centered on the rectangle.
Also adds `RectShape::round_to_pixels` so you can override
`TessellationOptions::round_rects_to_pixels`.
This is similar to `ScrollArea`, but:
* Supports zooming
* Has no scroll bars
* Has no limits on the scrolling
## TODO
* [x] Automatic sizing of `Scene`s outer bounds
* [x] Fix text selection in scenes
* [x] Implement `fit_rect`
* [x] Document / improve API
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
This pull request fixes a subset of #5492 by saving the application
state when the `suspended` event is received on Android. This way, even
if the user exits the app and closes it manually right after changing
some state, it will be saved since `suspended` gets fired when the app
is exited. It does not fix the `on_exit` function not being fired - this
seems to be a winit bug (the `exiting` function in the winit application
handler trait is not called on exit). Once it gets fixed, it may be
possible to remove logic introduced by this PR (however, I am not sure
how it would handle the app being killed by the system when in the
background, that would have to be tested).
I've tested the logic by:
* Leaving from the app to the home screen, then killing it from the
"recent apps" menu
* Leaving from the app to the "recent apps" menu and killing it
* Restarting the device while the app was running
In all of these instances, the state was saved (the last one being a
pleasant surprise). It was tested on the repository mentioned in #5492
with my forked repository as the source for eframe (I unfortunately am
not able to test it in a larger project of mine due to dependence on
"3rd party" egui libraries (like egui_notify) which do not compile along
with the master branch of eframe (different versions of egui), but I
believe it should work in the same manner in all scenarios). Tests were
conducted on a Galaxy Tab S8 running Android 14, One UI 6.1.1.
CI passed on my fork.
* [x] I have followed the instructions in the PR template
* Closes https://github.com/emilk/egui/issues/5246
Tested on
* [x] Chromium
* [x] Firefox
* [x] Safari
On Chromium and Firefox we get one annoying frame with the wrong size,
which can mess up the layout of egui apps, but this PR is still a huge
improvement, and I don't want to spend more time on this right now.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Remove references to `glium` backend, because it is deprecated since
egui v0.18.0
* [x] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Help on https://github.com/emilk/egui/issues/3653
* [x] I have followed the instructions in the PR template
The next version of the `objc2` framework crates will have a bunch of
default features enabled, see
https://github.com/madsmtm/objc2/issues/627, so this PR pre-emptively
disables them, so that your compile times down blow up once you upgrade
to the next version (which is yet to be released, but will be soon).
* [x] I have followed the instructions in the PR template
`egui:🆔:IdSet` and `egui:🆔:IdMap` were already optimized to not do
additional hashing (because the `Id` already is a hash), but now they
are just type aliases for `nohash_hasher::IntSet/IntMap`.
See https://crates.io/crates/nohash-hasher for more
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
This change discards widgets which are fully covered by another widget
in a higher layer from the hit test algorithm.
* Closes <https://github.com/emilk/egui/issues/5498>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Derive Debug for RichText
* [x] I have followed the instructions in the PR template
[Area::compare_order()](ee4ab08c8a/crates/egui/src/memory/mod.rs (L1174-L1183))
is not a total ordering. If three layers A, B, and C have the same
`order` field but only A and B are present in `order_map`, then `A==C`
and `B==C` but `A!=C`. This can cause a panic in the stdlib sort
function, and does in [my
app](https://github.com/HactarCE/Hyperspeedcube/tree/v2.0) although it's
very difficult to reproduce.
* [x] I have self-reviewed this PR and run `./scripts/check.sh`
* [x] I have followed the instructions in the PR template
Current WebP loader assumes all WebP images to be RGBA, which is the
case if the image is animated (that's what `image` crate assumes at
least). Static images can instead choose to exclude its alpha channel,
though it seems to be more of a default choice to include it, even if
it's not being utilized. Currently, loading a static RGB WebP image will
cause a panic when `ColorImage::from_rgba_unmultiplied` gets called in
the loader
```
thread 'main' panicked at /home/aely/.cargo/git/checkouts/egui-226fc7cdd51201c1/f87219d/crates/epaint/src/image.rs:97:9:
assertion `left == right` failed
left: 29184
right: 21888
```
Previously, `Harness::run` just called `Harness::step` 3 times. If that
wasn't enough, tests would often call run multiple times so all
animations would finish properly.
Also, I introduced `HarnessBuilder::with_step_dt` to customize with how
big of a dt each frame is called. I set the default to 1.0 / 6.0 (~6fps)
so we don't waste cpu in tests waiting on animations.
`HarnessBuilder::max_steps` allows us to control how many steps
`Harness::run` should run before panicing.
The default is 6, so we run for up to 1.0 logical seconds (six frames at
6 fps), which should be enough to finish most animations.
Turns out a lot of snapshots where rendered before fully shown and had a
light opacity, those are now fixed.
* [x] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
Closes <https://github.com/emilk/egui/issues/3862>.
Factoring the `bool` members of `Response` into a bitfield, the size of
`Response` is now 96 bytes (down from 104).
I gave `Sense` the same treatment, however this has no effects on
`Response` due to padding. I've decided not to pursue `PointerState`, as
it is quite large (_many_ members that are sized and aligned to
multiples of 8 bytes), so I don't expect any noticeable benefit from
making handful of `bool`s slightly leaner.
In any case, the changes to `Sense` are already quite a bit more
intrusive than those to `Response`.
The previous implementation overloaded the names of the attributes
`click` and `drag` with similarly named methods that _construct_ `Sense`
with the corresponding flag set. Now, that the attributes can no longer
be accessed directly, I had to introduce methods with new names
(`senses_click()`, `senses_drag()` and `is_focusable()`). I don't think
this is the cleanest solution: the old methods are essentially redundant
now that the named constants like `Sense::CLICK` exist. I did however
not want to needlessly break backwards compatibility.
I am happy to revert it (or go further 🙂) if there are concerns.
[ x ] I have ~~followed~~ _read_ the instructions in the PR template
Unfortunately i had several issues:
- Some snapshot-tests didn't run successfully on osx. diff shows errors
around fonts or missing menu items)
- cargo clippy doesn't run successfully (egui_kittest cannot find `wgpu`
and `image`)
- ./scripts/check.sh had other issues on my system (env: python: No such
file or directory), even if python3 can be called via python in my shell
Is there a system independent, standard way to run these tools (e.g. via
Docker?)
I submit the pr anyway, because there changes are very simple and
shouldn't cause issues.
A user of my Windows application reported a papercut where the
application restores its size on next load, but does not restore its
maximized state. This PR fixes that.
To test, I patched https://github.com/emilk/eframe_template to use my
local code since I knew that template saves/restores window data.
Testing methodology was to simply `cargo run`, maximize the application,
then close the application. `cargo run` again and the application should
start maximized.
Closes#1517.
* [x] I have followed the instructions in the PR template
* * This is mostly true, I had difficulties running `./scripts/check.sh`
for some reason. Possibly a bad Python version?
* Part of https://github.com/emilk/egui/issues/4019
`Frame` now includes the width of the stroke as part of its size. From
the new docs:
### `Frame` docs
The total (outer) size of a frame is `content_size + inner_margin +
2*stroke.width + outer_margin`.
Everything within the stroke is filled with the fill color (if any).
```text
+-----------------^-------------------------------------- -+
| | outer_margin |
| +------------v----^------------------------------+ |
| | | stroke width | |
| | +------------v---^---------------------+ | |
| | | | inner_margin | | |
| | | +-----------v----------------+ | | |
| | | | ^ | | | |
| | | | | | | | |
| | | |<------ content_size ------>| | | |
| | | | | | | | |
| | | | v | | | |
| | | +------- content_rect -------+ | | |
| | | | | |
| | +-------------fill_rect ---------------+ | |
| | | |
| +----------------- widget_rect ------------------+ |
| |
+---------------------- outer_rect ------------------------+
```
The four rectangles, from inside to outside, are:
* `content_rect`: the rectangle that is made available to the inner
[`Ui`] or widget.
* `fill_rect`: the rectangle that is filled with the fill color (inside
the stroke, if any).
* `widget_rect`: is the interactive part of the widget (what sense
clicks etc).
* `outer_rect`: what is allocated in the outer [`Ui`], and is what is
returned by [`Response::rect`].
### Notes
This required rewriting a lot of the layout code for `egui::Window`,
which was a massive pain. But now the window margin and stroke width is
properly accounted for everywhere.
Adds `Marginf` to fill the previous niche.
This is all in a pursuit to shrink the sizes of often-used structs, to
improve performance (less cache misses, less memcpy:s, etc).
* On the path towards https://github.com/emilk/egui/issues/4019
* Part of https://github.com/emilk/egui/issues/4019
As part of the work on adding a custom `Border` to everything, I want to
make sure that the size of `RectShape`, `Frame` and the future `Border`
is kept small (for performance reasons).
This PR changes the storage of the corner radius of rectangles from four
`f32` (one for each corner) into four `u8`. This mean the corner radius
can only be an integer in the range 0-255 (in ui points). This should be
enough for most people.
If you want to manipulate rounding using `f32`, there is a new
`Roundingf` to fill that niche.
This adds `WidgetType::Image` and correctly sets it in the Image widget.
This allows us to query for images in kittest tests and tells accesskit
that a node is an image.
It also adds `Image::alt_text` to set a text that will be shown if the
image fails to load and will be read via screen readers. This also
allows us to query images by label in kittest.
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Adds support for animated WebP images. Used the already existing GIF
implementation as a template for most of it.
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Images with capitalized extensions do not load because the list of
extensions they are checked against is lowercase. The image extension is
now converted to lowercase before comparing
* [x ] I have followed the instructions in the PR template
This makes it easier to hit the corners.
Previously the corner response-area was covered by the response-areas of
the edges.
* Related to https://github.com/emilk/egui/pull/5523
An interactive widget should only be marked hovered if a click/drag
would start an interaction with it.
egui 0.30 introduced a feature where a thin interactive widget could be
hit even if it was partially behind a larger interactive widget.
Unfortunately, this introduced a bug where the top widget would still be
marked as hovered, even though a click would go through to the thin
widget below.
This bug was most notacible when trying to reisize a window by dragging
its corner, which often would result in dragging one of its sides
instead.
This PR fixes this bug.
* Merge this first: https://github.com/emilk/egui/pull/5517
This aligns all rectangles and (horizontal or vertical) line segments to
the physical pixel grid in the `epaint::Tessellator`, making these
shapes appear crisp everywhere.
* Closes https://github.com/emilk/egui/issues/5164
* Closes https://github.com/emilk/egui/issues/3667
This undoes a lot of the explicit, egui-side aligning added in:
* https://github.com/emilk/egui/pull/4943
The new approach has several benefits over the old one:
* It is done automatically by epaint, so it is applied to everything (no
longer opt-in)
* It is applied after any layer transforms (so it always works)
* It makes line segments crisper on high-DPI screens
* All filled rectangles now has sides that end on pixel boundaries
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
Title. This would have helped me debug bugs quicker.
* [x] I have followed the instructions in the PR template
Was a duplicate article in the sentence. Already has "the"
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes <https://github.com/emilk/egui/issues/THE_RELEVANT_ISSUE>
* [ ] I have followed the instructions in the PR template
Native is already delayed by a frame because it calls
`handle_viewport_output` -> `egui_winit::process_viewport_commands`
after drawing. On web however, we process input including viewport
commands separately from drawing.
This adds an arbitrary frame delay mechanism for web and then uses this
with 1 frame delay always
When there are multiple layers (e.g. with custom transforms) close to
each other, the hit test code used to only consider widgets in the layer
directly under the mouse. This can make it difficult to hit thin widgets
just on the outside of a transform layer.
This PR fixes that.
It also prioritizes thin widgets, so that if there is both a thin widget
and a thick widget under the mouse cursor, you will always hit the thin
widgets, even if the thin widgets is layered behind the thick one. This
makes it easier to hit thin resize-handles.
In theory this should allow us to make `resize_grab_radius_side` and
`resize_grab_radius_corner` smaller in a future PR, if we want to.
Hey! I am not sure if this is something that's been considered before
and decided against (I couldn't find any PR's or issues).
This change removes the internal profiling macros in library crates and
the `puffin` feature and replaces it with similar functions in the
[profiling](https://github.com/aclysma/profiling) crate. This crate
provides a layer of abstraction over various profiler instrumentation
crates and allows library users to pick their favorite (supported)
profiler.
An additional benefit for puffin users is that dependencies of egui are
included in the instrumentation output too (mainly wgpu which uses the
profiling crate), so more details might be available when profiling.
A breaking change is that instead of using the `puffin` feature on egui,
users that want to profile the crate with puffin instead have to enable
the `profile-with-puffin` feature on the profiling crate. Similarly they
could instead choose to use `profile-with-tracy` etc.
I tried to add a 'tracy' feature to egui_demo_app in order to showcase ,
however the /scripts/check.sh currently breaks on mutually exclusive
features (which this introduces), so I decided against including it for
the initial PR. I'm happy to iterate more on this if there is interest
in taking this PR though.
Screenshot showing the additional info for wgpu now available when using
puffin

We used to always set the cursor to `Grabbing` when a drag and drop
payload is set, but this shadows user code trying to set an alternative
cursor (e.g. `NoDrop`). This PR no only change the cursor to `Grabbing`
if is way previously set to `Default`.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
Android support is "almost there". This PR pushes it just a bit further
by allowing `eframe` to be used on Android. It works by smuggling the
`AndroidApp` required by `winit` through `NativeOptions`.
The example isn't great because it doesn't leave space on the display
for Android's top status bar or the lower navigation bar. I don't know
what to do about that, yet. This is as far as I've managed to get it
working.
Another problem is that the development environment setup is completely
awful for Android unless you happen to already be a full-time Android
developer with everything configured on your build host. As a Rustacean,
this makes me very sad.
I've had some luck moving all of that mess to a container, adapted from
https://github.com/SergioRibera/docker-rust-android. It takes care of
all of the build dependencies, Android SDK, and the `cargo-apk` patches
for bugs that I hit while getting the example to work on my device. (I
also had to install an adb driver on my host and downloaded the Android
platform-tools to get access to `adb`. An alternative is exposing the
USB device to Docker. On Windows hosts, that means [installing
`usbipd`](https://learn.microsoft.com/en-us/windows/wsl/connect-usb). A
second alternative is using an `mtp` client to upload the APK as a file
with USB file transfer enabled, then manually install it through the
device's file manager.)
I'm not including the docker stuff in this PR, but here are the files
and instructions for future reference (and it will probably simplify
manual testing and CI, FWIW!)
<details><summary><code>Dockerfile</code></summary>
```dockerfile
FROM rust:1.76.0-slim
# Variable arguments
ARG JAVA_VERSION=17
ARG NDK_VERSION=25.1.8937393
ARG BUILDTOOLS_VERSION=30.0.0
ARG PLATFORM_VERSION=android-30
ARG CLITOOLS_VERSION=8512546_latest
# Install Android requirements
RUN apt-get update -yqq && \
apt-get install -y --no-install-recommends \
libcurl4-openssl-dev libssl-dev pkg-config build-essential git python3 wget zip unzip openjdk-${JAVA_VERSION}-jdk && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
# Install android targets
RUN rustup target add armv7-linux-androideabi aarch64-linux-android
# Install cargo-apk
RUN git clone -b fix/bin-targets-workspace-members https://github.com/parasyte/cargo-apk.git /tmp/cargo-apk && \
cargo install --path /tmp/cargo-apk/cargo-apk
# Generate Environment Variables
ENV JAVA_VERSION=${JAVA_VERSION}
ENV ANDROID_HOME=/opt/Android
ENV NDK_HOME=/opt/Android/ndk/${NDK_VERSION}
ENV ANDROID_NDK_ROOT=${NDK_HOME}
ENV PATH=$PATH:${ANDROID_HOME}:${ANDROID_NDK_ROOT}:${ANDROID_HOME}/build-tools/${BUILDTOOLS_VERSION}:${ANDROID_HOME}/cmdline-tools/bin
# Install command line tools
RUN mkdir -p ${ANDROID_HOME}/cmdline-tools && \
wget -qc "https://dl.google.com/android/repository/commandlinetools-linux-${CLITOOLS_VERSION}.zip" -P /tmp && \
unzip -d ${ANDROID_HOME} /tmp/commandlinetools-linux-${CLITOOLS_VERSION}.zip && \
rm -fr /tmp/commandlinetools-linux-${CLITOOLS_VERSION}.zip
# Install sdk requirements
RUN echo y | sdkmanager --sdk_root=${ANDROID_HOME} --install \
"build-tools;${BUILDTOOLS_VERSION}" "ndk;${NDK_VERSION}" "platforms;${PLATFORM_VERSION}"
# Create APK keystore for debug profile
# Adapted from caa806283d/ndk-build/src/ndk.rs (L393-L423)
RUN keytool -genkey -v -keystore ${HOME}/.android/debug.keystore -storepass android -alias androiddebugkey \
-keypass android -dname 'CN=Android Debug,O=Android,C=US' -keyalg RSA -keysize 2048 -validity 10000
# Cleanup
RUN rm -rf /tmp/*
WORKDIR /src
ENTRYPOINT [ "cargo", "apk", "build" ]
```
</details>
<details><summary><code>.dockerignore</code></summary>
```ignore
# Ignore everything, only the Dockerfile is needed to build the container
*
```
</details>
```sh
docker build -t rust-android:latest .
docker run --rm -it -v "$PWD:/src" rust-android:latest -p hello_android
adb install target/debug/apk/hello_android.apk
```
* Part of #2066
* [x] I have followed the instructions in the PR template
This implements web support for taking screenshots in an eframe app (and
adds a nice demo).
It also updates the native screenshot implementation to work with the
wgpu gl backend.
The wgpu implementation is quite different than the native one because
we can't block to wait for the screenshot result, so instead I use a
channel to pass the result to a future frame asynchronously.
* Closes <https://github.com/emilk/egui/issues/5425>
* [x] I have followed the instructions in the PR template
https://github.com/user-attachments/assets/67cad40b-0384-431d-96a3-075cc3cb98fb
This makes it easy to get the current transform of a layer, and uses
consistent naming everywhere.
`Memory::layer_transforms` is now called `Memory::to_global`, because
the old name was ambiguous (transform into what direction?)
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [x] I have followed the instructions in the PR template
This PR makes an area's interact rect intersect its constrain rect. This
fixes an issue where masked areas would still intercept input.
Before:

After:

<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [X] I have followed the instructions in the PR template
I introduced this in #5433.
TL;DR: there are two termination conditions for drag-and-drop
operations:
- ESC
- release mouse
The former _must_ happen at frame start (to properly capture the
keystroke). The latter _must_ happen at end-of-frame (to _not_ shadow
the mouse release event from user code).
This is now properly documented.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [x] I have followed the instructions in the PR template
### Problem
When clicking on a TextEdit sometimes the cursor doesn't appear
immediately which makes it feel like the click was not registered for a
second. This is because the start time for the blinking animation is
only reset on keyboard input, but not on mouse interaction.
It's hard to tell on the video but the cursor doesn't show immediately
after clicking if the blink timer happens to be off.
https://github.com/user-attachments/assets/9f049bd0-0375-4291-b2ef-697777fb854d
### Solution
Reset the click timer every time a `TextEdit` is clicked.
Additionally, the cursor is now correctly painted on the pixel boundary.
IMO we should default to 1px cursor (instead of 2px) but that's not
included in this PR. Happy to make that change too.
https://github.com/user-attachments/assets/6c489414-f2c4-4dc6-85dd-f8bc457edad0
This moves `egui::util::cache` to `egui::cache` (the old path is
deprecated, but still works).
It also adds the `FramePublisher` helper, which can be used to publish a
value which will be retained for this frame and the next:
``` rs
pub type MyPublisher = egui::cache::FramePublisher<MyKey, MyValue>;
// Publish:
ctx.memory_mut(|mem| {
mem.caches.cache::<MyPublisher>().set(key, value);
});
// Retrieve:
let value: Option<MyValue> = ctx.memory_mut(|mem| {
mem.caches
.cache::<MyPublisher>()
.get(key)
.clone()
})
```
* Closes https://github.com/emilk/egui/issues/5423
New output is actionable
```
failures:
---- demo::demo_app_windows::tests::demos_should_match_snapshot stdout ----
thread 'demo::demo_app_windows::tests::demos_should_match_snapshot' panicked at crates/egui_demo_lib/src/demo/demo_app_windows.rs:433:9:
Errors: [
"'demos/Code Example' Image size did not match snapshot. Expected: (402, 574), Actual: (415, 574).
Run `UPDATE_SNAPSHOTS=1 cargo test` to update the snapshots.",
]
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
demo::demo_app_windows::tests::demos_should_match_snapshot
```
This lets users trigger a screenshot from anywhere, and then when they
get back the results they have some context about what part of their
code triggered the screenshot.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to add commits to your PR.
* Remember to run `cargo fmt` and `cargo cranky`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* Closes#1531
### Before
Notice how the cursor hides after third enter and when the line is long.
https://github.com/user-attachments/assets/8e45736e-d6c7-4dc6-94d0-213188c199ff
### After
Cursor is always visible
https://github.com/user-attachments/assets/43200683-3524-471b-990a-eb7b49385fa9
- `ScrollArea` now checks if there's a `scroll_target` in `begin`, if
there is, it saves it because it's not from its children, then restore
it in `end`.
- `TextEdit` now allocates additional space if its galley grows during
the frame. This is needed so that any surrounding `ScrollArea` can bring
the cursor to view, otherwise the cursor lays outside the the
`ScrollArea`'s `content_ui`.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
Title.
* [x] I have followed the instructions in the PR template
* Closes#686
* Closes#839
* #5370 should be merged before this
* [x] I have followed the instructions in the PR template
This adds modals to egui.
This PR
- adds a new `Modal` struct
- adds `Memory::set_modal_layer` to limit focus to a layer and above
(used by the modal struct, but could also be used by custom modal
implementations)
- adds `Memory::allows_interaction` to check if a layer is behind a
modal layer, deprecating `Layer::allows_interaction`
Current problems:
- ~When a button is focused before the modal opens, it stays focused and
you also can't hit tab to focus the next widget. Seems like focus is
"stuck" on that widget until you hit escape. This might be related to
https://github.com/emilk/egui/issues/5359~ fixed!
Possible future improvements:
- The titlebar from `window` should be made into a separate widget and
added to the modal
- The state whether the modal is open should be stored in egui
(optionally), similar to popup and menu. Ideally before this we would
refactor popup state to unify popup and menu
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [X] I have followed the instructions in the PR template
---------
Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.com>
eframe has features for selecting between x11 and wayland. eframe does
not forward the features to glutin. This makes glutin always compile
with both backends enabled. This change forwards the feature. This
allows users of egui to compile less dependencies when they only need
one of x11, wayland.
To understand this change, read the glutin Cargo.toml [1] and the glutin
build.rs [2]. You always have to enable glutin's glx feature with the
x11 feature. The other default features (egl, wgl) stay enabled. This is
intentional so that everything continues to work as before. We could
further minimize when egl and wgl are enabled, but that is not part of
this change. There is little reason to do so because those feature
already only add dependencies when you compile glutin for the right
platform (for example wgl on windows).
[1]
https://github.com/rust-windowing/glutin/blob/v0.32.1/glutin/Cargo.toml
[2]
https://github.com/rust-windowing/glutin/blob/v0.32.1/glutin/build.rs
- fixes https://github.com/emilk/egui/issues/5359
For the test I added a `Harness::press_key` function. We should
eventually add these to kittest, probably via a trait one can implement
for the `Harness` but for now this should do.
As someone who uses "grey" instead of "gray", it is annoying that my
autocomplete can never find any of the "gray" color related things, so
this adds doc aliases for that.
* [x] I have followed the instructions in the PR template
The allows us to pass any state to the ui closure. While it is possible
to just store state in the closure itself, accessing that state after
the harness was created to e.g. read or modify it would require interior
mutability. With this change there are new `Harness::new_state`,
`Harness::run_state`, ... methods that allow passing state on each run.
This builds on top of #5301, which should be merged first
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This adds a `Harness::new_ui`, which accepts a Ui closure and shows the
ui in a central panel. One big benefit is that this allows us to add a
fit_contents method that can run the ui closure with a sizing pass and
resize the "screen" based on the content size.
I also used this to add a snapshot test for the rendering_test at
different scales.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [X] I have followed the instructions in the PR template
I removed the webp supported URI test given that the webp feature would
have to be enabled. I kept that webp is not supported in the other
tests.
There might need to be an additional warning in the changelog that image
support detection is now stricter.
egui never accesses the `FontDefinitions`' member fields mutably, except
in `fonts_tweak_ui` where it cloned the `FontDefinitions` object anyway.
This patch reduces system memory consumption for shared font
definitions.
And also removes some overhead from copying (e.g. for the per
`pixel_per_points` font atlas)
Also it allows to keep a copy of the font definitions outside of egui.
In my App that uses international fonts:
Before:

New:

Note: If `Arc` is not wanted, then it could ofc be abstracted away.
I know this is quite a breaking change API wise, but would like to hear
your opinion.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
The `RawInput::dropped_files` documentation referred to `NativeOptions`,
but the `drag_and_drop` option was moved to `ViewportBuilder` and is now
enabled by default.
Note that drag-and-drop is not *explicitly* enabled by default here, but
rather is enabled by default in winit. We only override winit's default
if the API consumer specifies it. It might be a good idea in general to
provide explicit defaults for everything in `ViewportBuilder` so we're
not relying on winit's behavior, but that's best left for another PR.
* Closes N/A
* [x] I have followed the instructions in the PR template
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [X] I have followed the instructions in the PR template
I am preparing a separate PR that adds support for JXL with `jxl-oxide`,
which is unlikely to be added to the `image` crate anytime soon (more
context will be provided in that PR).
`jxl-oxide` makes use of the
[`array::each_mut`](https://doc.rust-lang.org/stable/std/primitive.array.html#method.each_mut)
API which was stabilized in 1.77, which is the motivation for this MSRV
bump.
Rust 1.77 was officially released to stable on 21 March, 2024.
This adds `egui_kittest::try_image_snapshot_options` and
`egui_kittest::image_snapshot_options`, as well as
`Harness::wgpu_snapshot_options` and
`Harness::try_wgpu_snapshot_options`
* [X] I have followed the instructions in the PR template