This adds `Ui::interact_opt` which is a version of `Ui::interact` that
lets you specify that if this widget already exists, it should be moved
to the top of the interaction stack.
This lets you easily more easily "read a response from the future", by
simply calling interact twice, instead of calling
`Context::read_response`.
* Closes https://github.com/emilk/egui/issues/7749
## What
In our hit test code we have special handling for thin widgets, to make
them easier to hit.
The widths of our scroll bars are animated.
Together, the heuristic would trigger as the scroll bars were shrinking,
leading to the scroll bars being _hovered_ which lead them being too
wide, making the heuristic fail, which would again make them shrink,
causing the bug.
## Bonus
Now the scroll bar is only shown as hovered if the mouse is actually
hovering them and nothing else. Previously they would show as long as
the cursor were in the general area (but maybe actually hovering
something else).
Previously, when loading a variable font (e.g. via
`egui::FontData::from_static`),
the font was rendered using the default (often the lightest) weight,
ignoring any preferred weight configuration.
This change applies the specified weight to skrifa's `Location` for the
`wght` axis,
ensuring that variable fonts are rendered with the intended font weight.
## Summary
Fixes variable font weight not being applied during rendering. The
`FontData::weight()` method now properly configures the font variation
axis.
## Changes
- Add `location: Location` field to `FontFace` to store variation
coordinates
- Pass `location` parameter through to glyph rendering functions
- Apply weight to skrifa's `LocationRef` in `DrawSettings` and
`HintingInstance`
## Weight Priority
1. `preferred_weight` from `FontData::weight()`
2. OS/2 table's `us_weight_class`
3. Variable font's fvar default value
4. `Location::default()`
## Related Issue
- #3218 : Not follow font id, but goal would be same
## Todo
* [x] Apply preferred font weight when loading variable fonts
* [ ] Add small size variable fonts for docs and egui (need discussion)
<!--
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!
-->
I am having an issue loading this image
"https://stacks.stanford.edu/image/iiif/wy534zh7137/SULAIR_rosette/full/400,/0/default.jpg".
It has a mime type of "image/jpeg; charset=utf-8", which is not common.
The code doesn't parse the full string that includes the optional
parameter "charset=utf-8" to create the jpeg image format.
A line is added to take only the mime type in the media type before the
";" and ignore the optional parameters.
* Closes <https://github.com/emilk/egui/issues/7738>
* [x] I have followed the instructions in the PR template
Co-authored-by: leungkkf <leungkkf@gmail.com>
* Part of https://github.com/emilk/egui/issues/5113
* Part of https://github.com/emilk/egui/issues/3524
## What
This deprecates `eframe::App::update` and replaces it with two new
functions:
```rs
pub trait App {
/// Called just before `ui`, and in the future this will
/// also be called for background apps when needed.
fn logic(&mut self, ctx: &egui::Context, frame: &mut Frame) { }
/// Show your user interface to the user.
fn ui(&mut self, ui: &mut egui::Ui, frame: &mut Frame);
…
}
```
Similarly, `Context::run` is deprecated in favor of `Context::run_ui`.
`Plugin`s are now handed a `Ui` instead of just a `Context` in
`on_begin/end_frame`.
## TODO
…either in this PR or a later one
* [x] Deprecate `App::update`
* [x] Deprecate `Context::run`
* [x] Change plugins to get a `Ui`
* [x] Update kittest
* [x] Change viewports to get UI:s (`show_viewport_immediate` etc)
- https://github.com/emilk/egui/pull/7779
## Later PRs
* [ ] Deprecate `Panel::show`
* [ ] Deprecate `CentralPanel::show`
* [ ] Deprecate `CentralPanel` ?
* Part of https://github.com/emilk/egui/issues/3524
This is a breaking change, as it changes the how embedded viewports
work.
Before it was up to the user to display a `egui::Window` if they wanted.
Now egui creates an `egui::Window` for you, so you only need to add the
contents.
To signal this change in behavior, `ViewportClass::Embedded` is gone and
is now called `ViewportClass::EmbeddedWindow`.
* [x] I have followed the instructions in the PR template
- Some typos/grammos
- Attempt to finish incomplete comment
- Broken link
- I understand the colon is a convention for pluralizing symbol names,
but it seems redundant in the presence of other punctuation
---------
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!
-->
* Closes N/A
* [x] I have followed the instructions in the PR template
I'll probably come back to this and clean it up a bit. This PR
reimplements ab_glyph's functionality on top of Skrifa, a somewhat
lower-level font API that's being used in Chrome now.
Skrifa doesn't perform rasterization itself, so I'm using
[vello_cpu](https://github.com/linebender/vello) from the Linebender
project for rasterization. It's still in its early days, but I believe
it's already quite fast. It also supports color and gradient fills, so
color emoji support will be easier.
Skrifa also supports font hinting, which should make text look a bit
nicer / less blurry.
Here's the current ab_glyph rendering:
<img width="1592" height="1068" alt="image"
src="https://github.com/user-attachments/assets/2385b66e-23f8-4c6e-b8c2-ea90e0eea4e4"
/>
Here's Skrifa *without* hinting--it looks almost identical, but there
are some subpixel differences, probably due to rasterizer behavior:
<img width="1592" height="1068" alt="image"
src="https://github.com/user-attachments/assets/a815f3e9-65ac-4940-bc00-571177bef53d"
/>
Here's Skrifa *with* hinting:
<img width="1592" height="1068" alt="image"
src="https://github.com/user-attachments/assets/d6cc0669-3537-4377-bba9-ed5ef09664db"
/>
Hinting does make the horizontal strokes look a bit bolder, which makes
me wonder once again about increasing the font weight from "light" to
"regular".
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
### What
From the [lint
description](https://rust-lang.github.io/rust-clippy/master/index.html?search=or_fu#or_fun_call):
> The function will always be called. This is only bad if it allocates
or does some non-trivial amount of work.
But also:
> If the function has side-effects, not calling it will change the
semantic of the program, but you shouldn’t rely on that.
>
> The lint also cannot figure out whether the function you call is
actually expensive to call or not.
Still worth it to keep our happy paths clean, imo.
* [x] I have followed the instructions in the PR template
Adding periods to the end of sentences and fixes a grammar mistake on
documentation for the drag-and-drop code to become consistent with the
rest of the documentation.
The documentation for `Ui::dnd_drop_zone` could've used the word "its"
instead of "the" to replace "it", but I think "the" more clearly refers
to the `Frame` since "its" has been used to refer to the drop-zone
already.
* Closes https://github.com/emilk/egui/issues/7647
This collects SnapshotResults within the Harness and adds a check to
enforce snapshot results are merged in case multiple Harnesses are
constructed within a test.
This should make snapshot updates via kitdiff/accept_snapshots.sh way
more useful since it should now always update all snapshots instead of
only the first one per test.
When using option + arrow keys (Mac) or ctrl + arrow keys (Windows), you
navigate a full word.
Previously egui would ignore `.` in the text, so that `www.example.com`
would be considered a full word.
This is inconsistent with how the rest of macOS works.
With this PR, cursor navigation in `www.example.com` will move the
cursor between the dots.
This makes editing code with egui a lot nicer.
* Part of https://github.com/emilk/egui/issues/3524
Adds `Context::run_ui` as a convenience wrapper around `Context::run`.
This on the path to deprecate `run` and use a top-level `Ui` as the
entry-point for all of egui.
We're phasing out top-level panels (panels that use `Context` directly,
instead of being inside another `Ui`).
As a first step, stop using them in our demo library and application.
* Part of https://github.com/emilk/egui/issues/3524
This combines `SidePanel` and `TopBottomPanel` into a single `Panel`.
The old types are still there as type aliases, but are deprecated.
`.min_width(…)` etc are now called `.min_size(…)` etc.
Again, the old names are still there, but deprecated.
(edited by @emilk)
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This fixes calls to `ui.response().interact(Sense::click())` being
flakey. Since egui checks widget interactions at the beginning of the
frame, based on the responses from last frame, we need to ensure that we
always call `create_widget` on `interact` calls, otherwise there can be
a feedback loop where the `Sense` egui acts on flips back and forth
between frames.
Without the fix in `interact`, both the asserts in the new test fail.
Here is a video where I experienced the bug, showing the sense switching
every frame. Every other click would fail to be detected.
https://github.com/user-attachments/assets/6be7ca0e-b50f-4d30-bf87-bbb80c319f3b
Also note, usually it's better to use `UiBuilder::sense()` to give a Ui
some sense, but sometimes you don't have the flexibility, e.g. in a `Ui`
callback from some code external to your project.
* Closes https://github.com/emilk/egui/issues/5889
See the above issue for motivation.
To use glow instead, disable the default features of `eframe` and opt-in
to `glow`.
This also changes egui.rs to use wgpu, which means WebGPU when
available, and WebGL otherwise
This PR enables users of `egui-wgpu` to render `epaint` primitives
without having to bring in the complete `egui` crate and all it's
dependencies.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The double negative of not undefined conflicted with the example given
in parens, This just removes the double negative to agree with the rest
of the doc line. I have *not* audited to see if this ordering actually
is strictly forced elsewhere. (Apologies for the smallest documentation
pull request ever)
* [x] I have followed the instructions in the PR template
Sometimes when moving a window, having a tooltip attached to the mouse
pointer, or scrolling a `ScrollArea`, you would see this disturbing
effect:
This is caused by us rounding many visual elements (lines, rectangles,
text, …) to physical pixels in order to keep them sharp. If the
window/tooltip itself is not rounded to a physical pixel, then you can
get this behavior.
So from now on the position of all
areas/windows/tooltips/popups/ScrollArea gets rounded to the closes
pixel.
* Unlocked by https://github.com/emilk/egui/pull/7709
