Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 0.27.2 - bug fixes #4304

Closed
wants to merge 22 commits into from
Closed

Release 0.27.2 - bug fixes #4304

wants to merge 22 commits into from

Conversation

emilk
Copy link
Owner

@emilk emilk commented Apr 2, 2024

Changelogs

egui

  • Fix tooltips for non-interactive widgets #4291
  • Fix problem clicking the edge of a TextEdit #4272
  • Fix incorrect Response::interact_rect for Area/Window #4273
  • Fix: Response::clicked_elsewhere takes clip rect into account #4274
  • Allow disabling animations on a ScrollArea #4309 (thanks @lucasmerlin!)

eframe

  • Fix blurry rendering in some browsers #4299
  • Correctly identify if browser tab has focus #4280
  • Fix continuous repaint on Wayland when TextEdit is focused or IME output is set #4269 (thanks @white-axe!)
  • Remove a bunch of unwrap() #4285

egui_plot

  • Allow zoom/pan a plot as long as it contains the mouse cursor #4292
  • Prevent plot from resetting one axis while zooming/dragging the other #4252 (thanks @YgorSouza!)
  • Fix the same plot tick label being painted multiple times #4307

egui-winit

  • Fix continuous repaint on Wayland when TextEdit is focused or IME output is set #4269 (thanks @white-axe!)

emilk and others added 18 commits March 29, 2024 12:29
This was broken in cases where the ui wasn't waking up, i.e. when
nothing else was happening.
The edges were rather arbitrarily chosen anyway, and I'm not sure who it
was supposed to help.
Fixes a problem in egui.rs where the back-button would not work to
switch between the top-level tabs
Before, when setting the `zoom_factor`, the website was already
enlarged, but the zoom was ignored when calculating the logical window
size and mouse position, causing an offset between the actual cursor and
selected elements. That is addressed here

---------

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
It was wrong for any `Area` or `Window` that was being moved or whose
position was constrained
`clicked_elsewhere` now checks against the clipped `interact_rect` of
the widget instead of the full `rect`.

In practice this shouldn't change much since the function is mostly used
for windows and areas, which aren't clipped.
…put is not None (#4269)

* Closes #4254

Changes egui-winit so that it calls `window.set_ime_cursor_area` when
the IME rect changes or the user interacts with the application instead
of calling it every time the app is rendered. This works around a winit
bug that causes the app to continuously repaint under certain
circumstances on Wayland.

Tested on Wayland and on X11 using the text edit in the egui_demo_app -
no changes in IME functionality as far as I can tell. Untested on
non-Linux platforms.

---------

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The fewer unwraps, the fewer panics
…4291)

At least all those above any interactive widget.

* Closes #4286

I feel there is still more thinking to be done about what is considered
`hovered` and how it relates to `contains_pointer`, but this PR at least
fixes tooltips for uninteractive widgets
This is a fix meant mostly for Rerun, where we sometiems paint a
vertical time-line over the plot (which is interactive). Before this PR
you couldn't zoom or pan the plot while hovering that line, which was
really annoying.
* Closes #4241

I would love some more testers of this.

I'm not sure if we really need the round-to-even code, but I'm hesitant
to out-right revert #151 when I cannot
reproduce its problem. Keeping it seems quite safe though.

---
# Testing
Checkout the branch and run:

* `./scripts/start_server.sh`
* `./scripts/build_demo_web.sh` and then open
`http://localhost:8888/index.html#Rendering`
* `./scripts/build_demo_web.sh --wgpu` and then open
`http://localhost:8888/index.html#Rendering`

Check the "Rendering test" that the squares in the pixel alignment test
are perfectly sharp, like this:

<img width="576" alt="Screenshot 2024-04-01 at 13 27 20"
src="https://github.com/emilk/egui/assets/1148717/fb6c4824-9e25-4304-bc0c-3c50fbd44a52">

If it looks something like this, something is WRONG:
<img width="488" alt="Screenshot 2024-04-01 at 13 29 07"
src="https://github.com/emilk/egui/assets/1148717/04bd93ff-2108-40c5-95f6-76e3bcb9cd7f">


Please try it on different zoom levels in different browsers, and if
possible on different monitors with different native dpi scaling. Report
back the results!


### Mac
I have tested on a high-DPI Mac:
* Chromium (Brave): ✅ Can reproduce problem on `master`, and it's now
fixed
* Firefox:  ✅ Can reproduce problem on `master`, and it's now fixed
* Safari: ❌ Can't get it to work; giving up for now
@emilk emilk marked this pull request as draft April 2, 2024 10:51
@YgorSouza
Copy link
Contributor

I think #4252 wasn't included in 0.27.1. Could it be included in this one?

@lucasmerlin
Copy link
Contributor

lucasmerlin commented Apr 2, 2024

Could we also include some fix for #4295 because it's blocking me from updating egui_infinite_scroll and egui_virtual_list. I'm happy to make a PR, but I'd like some hints of what the api should look like (should there be e.g. scroll_to_rect_animated functions that take a bool / enum whether they should be animated, or should it be handled via Style, or something else?)

Edit: I've opened a PR: #4305
I guess adding a new field to Style would be a breaking change though, right? Maybe we could leave that away for the bug fix release and only including the _animation functions, just using ScrollAnimation::default() otherwise.

@emilk
Copy link
Owner Author

emilk commented Apr 2, 2024

@lucasmerlin Yes, adding a new field to Style is a breaking change. I also don't wan't to pick too big of changes into a patch release, since they carry more risk. Maybe you can make a smaller fix by just adding a new builder method to ScrollArea, i.e. scroll_area.animate(false) or whatever.

But I need to push this patch release out very soon so I can focus on other stuff.

…#4307)

Usually this isn't visible (the same label being painted on top of
itself), but it will be visible if the user has a custom formatter (e.g.
`y_axis_formatter`) that choses a different format based on
`GridMark:step_size` (e.g. using fewer decimals for thicker ticks).
@lucasmerlin
Copy link
Contributor

@emilk I opened a small PR with a builder function: #4309

lucasmerlin and others added 2 commits April 2, 2024 17:54
<!--
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 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!
-->

Adds a flag to ScrollArea that disables animations for the scroll_to_*
functions
@emilk emilk closed this Apr 2, 2024
@emilk
Copy link
Owner Author

emilk commented Apr 2, 2024

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants