Fixes#5174.
The drag velocity was not being updated unless the cursor counted as
"dragging", which only happens when it's in motion. This effectively
guarantees that the drag velocity will never be zero, even if the cursor
is not moving, and results in spurious scroll velocity being applied
when the cursor is released.
Instead, we update the velocity only when the drag is stopped, which is
when the kinetic scrolling actually needs to begin. Note that we
immediately *apply* the scroll velocity on the same frame that we first
set it, to avoid a 1-frame gap where the scroll area doesn't move.
I believe that *not* setting `scroll_stuck_to_end` and `offset_target`
when the drag is released is the correct thing to do, as they should
apply immediately once the user stops dragging. Should we maybe clear
the drag velocity instead if `scroll_stuck_to_end` is true or
`offset_target` exists?
* Closes#5174
* [x] I have followed the instructions in the PR template
This adds a new `Ui::unique_id` used in `Ui::response`.
I'll make a follow-up PR where the old `id` is renamed `stable_id`, and
deprecate `fn id` to force users to think through which `id` they want.
* Closes https://github.com/emilk/egui/issues/5190
Since ui's initial sound is a "y", it should be "a ui", not "an ui".
Replaced case-sensitively using regex `([aA])n ([uU][iI])` replacement
`$1 $2`
* [x] I have followed the instructions in the PR template
This will allow disabling the animation that occurs during
`scroll_to_row` calls. Follows the same coding style as the other scroll
options in `TableBuilder`.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
It cannot be made const with the current version of Rust, and that is
counterintuitive since it does compile-time checks, so we make that
clear in the documentation. It might be possible to make it const once
MSRV is bumped to 1.82.
* See <https://github.com/emilk/egui/issues/5160>
* [x] I have followed the instructions in the PR template
Affects `.on_hover_text(…)` with dynamic content (i.e. content that
changes over time).
* Closes https://github.com/emilk/egui/issues/5167
`.on_hover_ui` with dynamic content can still hit the shrinking problem.
The general solution depends on solving
https://github.com/emilk/egui/issues/5138 but a work-around is to add
this to your tooltips:
```diff
response.on_hover_ui(|ui| {
+ ui.set_max_width(ui.spacing().tooltip_width);
// …
});
```
* Closes https://github.com/emilk/egui/pull/5106
* Closes https://github.com/emilk/egui/issues/5084
Protect against rounding errors in egui layout code.
Say the user asks to wrap at width 200.0.
The text layout wraps, and reports that the final width was 196.0
points.
This than trickles up the `Ui` chain and gets stored as the width for a
tooltip (say).
On the next frame, this is then set as the max width for the tooltip,
and we end up calling the text layout code again, this time with a wrap
width of 196.0.
Except, somewhere in the `Ui` chain with added margins etc, a rounding
error was introduced,
so that we actually set a wrap-width of 195.9997 instead.
Now the text that fit perfectly at 196.0 needs to wrap one word earlier,
and so the text re-wraps and reports a new width of 185.0 points.
And then the cycle continues.
So this PR limits the text wrap-width to be an integer.
Related issues:
* https://github.com/emilk/egui/issues/4927
* https://github.com/emilk/egui/issues/4928
* https://github.com/emilk/egui/issues/5163
---
Pleas test this @rustbasic
A very common usability issue on egui-wgpu callbacks is that `paint`
can't access any data that doesn't strictly outlive the callback
resources' data. E.g. if the callback resources have an `Arc` to some
resource manager, you can't easily pull out resources since you
statically needed to ensure that those resource references outlived the
renderpass, whose lifetime was only constrained to the callback
resources themselves.
Wgpu 22 no longer has this restriction! Its (render/compute-)passes take
care of the lifetime of any passed resource internally. The lifetime
constraint is _still_ opt-out since it protects from a common runtime
error of adding commands/passes on the parent encoder while a previously
created pass wasn't closed yet.
This is not a concern in egui-wgpu since the paint method where we have
to access the render pass doesn't even have access to the encoder!
<!--
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
Adds support for mipmaps in the `glow` backend.
Should be possible to implement for `wgpu` in the future as well, but
requires a custom compute kernel.
This adds preview deployments that will deploy a version of
egui_demo_app for each pull request, making things easier to review /
test.
Some notes on security:
The preview deployment is split in two workflows, preview_build and
preview_deploy.
`preview_build` runs on pull_request, so it won't have any access to the
repositories secrets, so it is safe to
build / execute untrusted code.
`preview_deploy` has access to the repositories secrets (so it can push
to the pr preview repo) but won't run
any untrusted code (it will just extract the build artifact and push it
to the pages branch where it will
automatically be deployed).
To set this up, a DEPLOY_KEY secret needs to be added, which allows the
action to push the compiled artifacts into this repository:
https://github.com/egui-pr-preview/pr
The deploy key is the private key part of a key generated via
ssh-keygen. The public key is set as a deploy key in that repo.
I have created the repo on a separate github org, so it won't be
directly associated with emil or egui in case someone pushes something
naughty.
I have set this up in my fork of egui to show how this works:
- I created a PR: https://github.com/lucasmerlin/egui/pull/2
- The code will be compiled and pushed to the egui-pr-preview/pr repo
and deployed via github pages
- The bot leaves a comment on the pr with a link to the preview
- The preview is available at
https://egui-pr-preview.github.io/pr/2-pr-preview-demo/
(It's unfortunately only available a couple seconds after the bot writes
the comment, because the pages deployment action is run independently on
the other repository)
- Once the PR is merged / closed the preview will be cleaned up
(unfortunately the empty folder will remain, it seems like it's not
possible to remove that via the JamesIves/github-pages-deploy-action
action I use, but I don't think that it's a big issue)
I'll leave the PR in draft until the DEPLOY_KEY is set up
<!--
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
Hi, I've made an integration that allows egui to be embedded as a widget
inside of a GTK application. I'm planning to use it to draw interactive
plots via `egui_plot`, as I haven't found comparable plotting widgets in
GTK. I hope others will find this integration useful as well.
The library doesn't do its own rendering, it instead relies on
`egui_glow` to render inside of a GTK-provided OpenGL drawing area.
It is published on [crates.io](https://crates.io/crates/gtk-egui-area).
<!--
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#5053
* [x] I have followed the instructions in the PR template
This fixes#5053 by adding a Sense parameter to UiBuilder, using that in
Context::create_widget, so the Widget is registered with the right Sense
/ focusable. Additionally, I've added a ignore_focus param to
create_widget, so the focus isn't surrendered / reregistered on
Ui::interact_bg.
The example from #5053 now works correctly:
https://github.com/user-attachments/assets/a8a04b5e-7635-4e05-9ed8-e17d64910a35
<details><summary>Updated example code</summary>
<p>
```rust
ui.button("I can focus");
ui.scope_builder(
UiBuilder::new()
.sense(Sense::click())
.id_source("focus_test"),
|ui| {
ui.label("I can focus for a single frame");
let response = ui.interact_bg();
let t = if response.has_focus() {
"has focus"
} else {
"doesn't have focus"
};
ui.label(t);
},
);
ui.button("I can't focus :(");
```
</p>
</details>
---
Also, I've added `Ui::interact_scope` to make it easier to read a Ui's
response in advance, without having to know about the internals of how
the Ui Ids get created.
This makes it really easy to created interactive container elements or
custom buttons, without having to use Galleys or
Painter::add(Shape::Noop) to style based on the interaction.
<details><summary>
Example usage to create a simple button
</summary>
<p>
```rust
use eframe::egui;
use eframe::egui::{Frame, InnerResponse, Label, RichText, UiBuilder, Widget};
use eframe::NativeOptions;
use egui::{CentralPanel, Sense, WidgetInfo};
pub fn main() -> eframe::Result {
eframe::run_simple_native("focus test", NativeOptions::default(), |ctx, _frame| {
CentralPanel::default().show(ctx, |ui| {
ui.button("Regular egui Button");
custom_button(ui, |ui| {
ui.label("Custom Button");
});
if custom_button(ui, |ui| {
ui.label("You can even have buttons inside buttons:");
if ui.button("button inside button").clicked() {
println!("Button inside button clicked!");
}
})
.response
.clicked()
{
println!("Custom button clicked!");
}
});
})
}
fn custom_button<R>(
ui: &mut egui::Ui,
content: impl FnOnce(&mut egui::Ui) -> R,
) -> InnerResponse<R> {
let auto_id = ui.next_auto_id();
ui.skip_ahead_auto_ids(1);
let response = ui.interact_scope(
Sense::click(),
UiBuilder::new().id_source(auto_id),
|ui, response| {
ui.style_mut().interaction.selectable_labels = false;
let visuals = response
.map(|r| ui.style().interact(&r))
.unwrap_or(&ui.visuals().noninteractive());
let text_color = visuals.text_color();
Frame::none()
.fill(visuals.bg_fill)
.stroke(visuals.bg_stroke)
.rounding(visuals.rounding)
.inner_margin(ui.spacing().button_padding)
.show(ui, |ui| {
ui.visuals_mut().override_text_color = Some(text_color);
content(ui)
})
.inner
},
);
response
.response
.widget_info(|| WidgetInfo::new(egui::WidgetType::Button));
response
}
```
</p>
</details>
https://github.com/user-attachments/assets/281bd65f-f616-4621-9764-18fd0d07698b
---------
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!
-->
* Closes#5121
* [x] I have followed the instructions in the PR template
This unifies the code paths in `update_texture` somewhat, so that the
texture sampler and bind group are always replaced.
Not sure whether removing and reinserting the texture from and into the
`textures` map, or creating a new bind group, has much of a performance
impact. An alternative, as described in #5121, would be to split the
functionality for updating a texture's data from updating its options,
so that we don't have to unconditionally update the bind group (or do
something like store the options to check if they're changed).
Fix: `Event::Copy` and `Event::Cut` behave as if they select the entire
text when there is no selection.
It's unexpected and disconcerting that this behavior occurs when there
is no selected area.
Fix: panic when dragging window between monitors of different
pixels_per_point
This will continue to help us as we develop `egui`.
I hope you agree with my defense of `panic`.
* Relate #3959
* Relate #4088
* Closes#4178
* Closes#4179
There is also a way to add log if necessary.
```
log::debug!("Anti-panic behavior occurs");
```
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
When using a `DragValue`, there are three common modes of range clamping
that the user may want:
A) no clamping
B) clamping only user input (dragging or editing text), but leave
existing value intact
C) always clamp
The difference between mode B and C is:
```rs
let mut x = 42.0;
ui.add(DragValue::new(&mut x).range(0.0..=1.0));
// What will `x` be here?
```
With this PR, we now can get the three behaviors with:
* A): don't call `.range()` (or use `-Inf..=Inf`)
* B) call `.range()` and `.clamp_existing_to_range(false)`
* C) call `.range()`
## Slider clamping
Slider clamping is slightly different, since a slider always has a
range.
For a slider, there are these three cases to consider:
A) no clamping
B) clamp any value that the user enters, but leave existing values
intact
C) always clamp all values
Out of this, C should probably be the default.
I'm not sure what the best API is for this yet. Maybe an `enum` 🤔
I'll take a pass on that in a future PR.
## Related
* https://github.com/emilk/egui/pull/4728
* https://github.com/emilk/egui/issues/4881
* https://github.com/emilk/egui/pull/4882
Nicolas
lucasmerlin
valadaptive
Emil Ernerfeldt
GiGaGon
rustbasic
Ethan Post
YgorSouza
Andreas Reich
Christofer Nolander
Swarkin
Ilya Zlobintsev