Fixes#7378
Includes a regression test that previously failed and now succeeds.
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Lucas Meurer <hi@lucasmerlin.me>
* Closes <https://github.com/emilk/egui/issues/7353>
Currently `ui.put` moves the cursor after the placed widget. In my
opinion that is a bit unexpected and counterproductive in most cases
where `ui.put` makes sense.
The following example breakes with the current behavior and looks right
with my change:
```rs
ui.horizontal(|ui| {
let custom_button_id = Id::new("custom_button");
let response = Button::new((
Atom::custom(custom_button_id, Vec2::splat(18.0)),
"Look at my mini button!",
))
.atom_ui(ui);
if let Some(rect) = response.rect(custom_button_id) {
ui.put(rect, Button::new("🔎").frame_when_inactive(false));
}
let custom_button_id = Id::new("custom_button");
let response = Button::new((
Atom::custom(custom_button_id, Vec2::splat(18.0)),
"Look at my mini button!",
))
.atom_ui(ui);
if let Some(rect) = response.rect(custom_button_id) {
ui.put(rect, Button::new("🔎").frame_when_inactive(false));
}
});
ui.add_space(10.0);
let response = ui.button("Notifications");
ui.put(
Rect::from_center_size(response.rect.right_top(), Vec2::splat(12.0)),
|ui: &mut Ui| {
Frame::new()
.fill(Color32::RED)
.corner_radius(10.0)
.show(ui, |ui| {
ui.label(RichText::new("11").size(8.0).color(Color32::WHITE));
}).response
},
);
ui.button("Some other button");
```
<img width="253" height="86" alt="Screenshot 2025-07-14 at 10 58 30"
src="https://github.com/user-attachments/assets/fca56e60-e3c0-4b59-8e2d-0a39aefea9f9"
/>
<img width="361" height="107" alt="Screenshot 2025-07-14 at 10 58 51"
src="https://github.com/user-attachments/assets/85e2fbf9-9174-41e0-adaa-60c721b16bf6"
/>
I had a look at reruns source code and there are no uses of `ui.put`
that would break with this change (very little usages in general).
## Alternatives
Instead of a breaking change we could of course instead introduce a new
metheod (e.g. `Ui::place`?).
* Recently CI runs started to hang randomly:
https://github.com/emilk/egui/actions/runs/17427449210/job/49477714447?pr=7359
This fixes the deadlock and adds the basic deadlock detection we also
added to Mutexes in #7468.
Also, interestingly, the more sophisticated deadlock detection (behind
the deadlock_detection feature) didn't catch this for some reason. I
wonder why it exists in the first place, when parking_lot also has built
in deadlock detection? It also seems to make tests slower, widget_tests
usually needs ~30s, with the deadlock detection removed its only ~12s.
I'm trying to debug a suspected deadlock in the CI for
https://github.com/emilk/egui/pull/7467
Since we use our own mutex wrappers, we can just panic if the lock is
too slow. Ugly and effective :)
This is the same issue that was fixed for the http bytes loader in
239ade9a59
* [x] I have followed the instructions in the PR template
----------------
Funnily, [this
comment](https://github.com/emilk/egui/issues/3747#issuecomment-1872192997)
describes exactly how I encountered this issue:
> That assert is wrong if something calls forget between the start of
the request and the end of it.
I'm displaying lots of images in a scrolling grid (20 or so visible at a
time). It seems like image textures are never freed up automatically so
it stacks up a lot meaning I have to unload the image textures manually
with `egui::Context::forget_image()` in each `eframe::App::update()`
call for the images that are no longer shown when scrolling.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The line breaks are now replaced by spaces, matching the usual behavior
of text fields in HTML.
* Closes <https://github.com/emilk/egui/issues/7389>
* [x] I have followed the instructions in the PR template
Co-authored-by: Lucas Meurer <hi@lucasmerlin.me>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/main/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!
-->
Adds a check for `ui.is_enabled()` when displaying the SubMenu items.
There were a few places the condition could be placed, but I figured
there was simplest. The inner button will already not be able to be
clicked due to ui being disabled.
cc @lucasmerlin
* [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/main/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!
-->
Hey, I added an event listener on the [`popstate`
event](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event).
That fixed my issue
https://github.com/user-attachments/assets/a621dac9-b7c3-426a-968b-dc73c5702eea
* Closes https://github.com/emilk/egui/issues/7402
* [x] I have followed the instructions in the PR template
If the ScrollArea's contents are smaller than the inner rect, but the
scrollbar is set to always visible, clicking on it led to a remap from
an empty range to calculate the new offset, which triggered a debug
assertion in the remap function, because the result is indeterminate.
Since in this case there is no need to scroll, we just skip the remap
and set the offset to 0 directly.
* Closes <https://github.com/emilk/egui/issues/7362>
* [x] I have followed the instructions in the PR template
The override_text_color is now used when rendering text from a String or
&str. This is consistent with the RichText variant and makes the option
behave as advertised, taking precedence over WidgetVisuals and
overriding the color for all text unless explicitly changed for a single
widget (via RichText or LayoutJob).
* Closes <https://github.com/emilk/egui/issues/7367>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Fixes manually created popups (via `Popup::new`) not closing, since
widget_clicked_elsewhere was always false.
This example would never close:
```rs
let mut open = true;
eframe::run_simple_native("My egui App", options, move |ctx, _frame| {
egui::CentralPanel::default().show(ctx, |ui| {
let response = egui::Popup::new(
Id::new("popup"),
ctx.clone(),
PopupAnchor::Position(Pos2::new(10.0, 10.0)),
LayerId::new(Order::Foreground, Id::new("popup")),
)
.open(open)
.show(|ui| {
ui.label("This is a popup!");
ui.label("You can put anything in here.");
});
if let Some(response) = response {
if response.response.should_close() {
open = false;
}
}
});
})
```
I also noticed that the Color submenu in the popups example had a double
arrow (must have been broken in the atoms PR):
<img width="248" height="110" alt="Screenshot 2025-08-07 at 13 42 28"
src="https://github.com/user-attachments/assets/a4e0c267-ae71-4b2c-a1f0-f53f9662d026"
/>
Also fixed this in the PR.
* Closes <https://github.com/emilk/egui/issues/7397>
* [X] I have followed the instructions in the PR template
I do admit I got a peak NixOS `RequestDeviceError` and deemed it
entirely not worth it to think about that.
https://github.com/emilk/egui/pull/5411 broke rotation of multi-line
`TextShape`s because `PlacedRow::pos` was no longer being rotated, so
let's rotate it.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Lucas Meurer <hi@lucasmerlin.me>
* Follow up to #7146
Previously when galleys were splitted, each exept the last had an extra
empty row that had to be removed when they were concated. This changes
it to remove the `\n` from the layout jobs when splitting.
* Closes #7037
* Closes#7297
This deprecates all popup-related function in `Memory`, replacing them
with the new `egui::Popup`.
The new API is nicer in all ways, so we should encourage people to use
it.
Previously a single-negative rectangle (where `min.x > max.x` XOR `min.y
> max.y`) would return a negative area, while a doubly-negative
rectangle (`min.x > max.x` AND `min.y > max.y`) would return a positive
area. Now both return zero instead.
There was a bug in how we decide where to place a `Tooltip` (or other
`Popup`), which could lead to tooltips jumping around every frame,
especially if it changed size slightly.
The new code is simpler and bug-free.
* [x] I have followed the instructions in the PR template
Splitting this out from the Parley work as requested. This removes
`FontImage` and makes the font atlas use a `ColorImage`. It converts
alpha to coverage at glyph-drawing time, not at delta-upload time.
This doesn't do much now, but will allow for color emoji rendering once
we start using Parley.
I've changed things around so that we pass in `text_alpha_to_coverage`
to the `Fonts` the same way we do with `pixels_per_point` and
`max_texture_side`, reusing the existing code to check if the setting
differs and recreating the font atlas if so. I'm not quite sure why this
wasn't done in the first place.
I've left `ImageData` as an enum for now, in case we want to add support
for more texture pixel formats in the future (which I personally think
would be worthwhile). If you'd like, I can just remove that enum
entirely.
* part of https://github.com/emilk/egui/issues/7264
* removes SelectableLabel (Use `Button::selectable` instead)
* updates `Ui::selectable_value/label` with IntoAtoms support
Had to make some changes to `Button` since the SelecatbleLabel had no
frame unless selected.
I thought about this - so we have two options here:
1. adding it to `SnapshotOptions`
2. adding it to every function which I do not like as this would be a
huge breaking change
## Summary
This pull request introduces a new feature to the `SnapshotOptions`
struct in the `egui_kittest` crate, allowing users to specify a
permissible percentage of pixel differences (`diff_percentage`) before a
snapshot comparison is considered a failure. This feature provides more
flexibility in handling minor visual discrepancies during snapshot
testing.
### Additions to `SnapshotOptions`:
* Added a new field `diff_percentage` of type `Option<f64>` to the
`SnapshotOptions` struct. This field allows users to define a tolerance
for pixel differences, with a default value of `None` (interpreted as 0%
tolerance).
* Updated the `Default` implementation of `SnapshotOptions` to
initialize `diff_percentage` to `None`.
### Integration into snapshot comparison logic:
* Updated the `try_image_snapshot_options` function to handle the new
`diff_percentage` field. If a `diff_percentage` is specified, the
function calculates the percentage of differing pixels and allows the
snapshot to pass if the difference is within the specified tolerance.
[[1]](diffhunk://#diff-6f481b5866b82a4fe126b7df2e6c9669040c79d1d200d76b87f376de5dec5065R204)
[[2]](diffhunk://#diff-6f481b5866b82a4fe126b7df2e6c9669040c79d1d200d76b87f376de5dec5065R294-R301)
* Closes <https://github.com/emilk/egui/issues/5683>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: lucasmerlin <hi@lucasmerlin.me>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This is a really small PR so I am skipping the issue (based on
contributing.md). This change adds an optional field and thus non
breaking for the API.
I ran into an issue during my development of an alerts manager widget
([see PR](https://github.com/blackberryfloat/egui_widget_ext/pull/2))
where I needed a scrollable overlay that did not block clicking areas of
a parent widget when my alerts did not take up the entire parent. To
achieve this I detect the sizing pass via the invisible flag and only
render the alerts content and then on the next pass I add the scroll bar
in around the alert content. Whenever the alert content changed though I
would need to create a new Area with a new id to get proper sizing. That
is a memory leak so I wanted to reset the size state to trigger a sizing
pass. Memory is rightfully protected enough that the path to remove
memory was dropped and I just added a hook to set a resize flag.
I am sure there are better ways but this is what made sense to me.
Looking forward to thoughts.
~~Logistics wise, I have proposed it as a patch because I was based off
0.31.1 for testing. I was also thinking it could be released quickly. I
am happy to cherry pick onto main after. If that is not allowed I can
rebase to main and pull against that.~~ (rebased on main)
---------
Co-authored-by: Wesley Murray <murraywj97@gmail.com>
I need to scroll in a snapshot test in my app, and kittest had no
utilities for this. Event::MouseWheel is error prone. This adds support
for some accesskit scroll actions, and uses this in kittest to add
helpers to scroll to a node / scroll the scroll area surrounding a node.
The accesskit code says down/up/left/right `Scrolls by approximately one
screen in a specific direction.`. Unfortunately it's difficult to get
the size of a "screen" (I guess that would be the size of the containing
scroll area)where I implemented the scrolling, so for now I've hardcoded
it to 100px. I think scrolling a fixed amount is still better than not
scrolling at all.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
