On multiple-monitor systems, eframe was incorrectly selecting first ones
dimensions for centering
Would also appretiate releasing 0.28.2 with fix included on crates.io
<!--
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 PR
- adds a pipeline to check the ios build
- removes the iOS WaitUntil workaround, which doesn't seem to be
necessary anymore after the winit update (and caused the build for iOS
to fail again because of a missing self
- ~removes a iOS workaround for window size which doesn't seem necessary
anymore~
Turns out it was still needed (but you need to actually restart the app
for the issue to show up, so I didn't catch it first)
- fixes some cargo check errors in run.rs
I've done all these changes in a single PR because otherwise the
pipeline doesn't run but I can also split them in separate PRs if that
makes it easier to review
* Fixes#3959
There are two bugs racing each other here, which is why it sometimes
crashes and sometimes the app just silently exists
Bug 1
When the window is recreated a Destroyed event arrives (due to the Drop
of the old window). The code that receives this event does not look to
see if its the main viewport or a secondary one and unconditionally
closes the app. The code path for other platforms is slightly different
and does check.
I have moved the code that handles the destroy to be in the same place
and have the same behavior as the other platforms.
Bug 2
At recreate time the window and winit entries of the viewport are set to
None (forcin g them to be recreated). But the surface is still bound to
the old window, this causes the next context switch to fail. So I simply
added a viewport.gl_surface = None too,
This is my first egui PR so I hope I have not broken anything. If
nothing else I understand a little better how egui works.
This updates winit to 0.30.5.
https://github.com/emilk/egui/pull/4849 Had to pin the version to
0.30.2, as a Winit patch changed the behavior of selecting a theme.
Winit 0.30.5 reverts this, so we could stick with `window.theme()`, but
the newly added `ActiveEventLoop::system_theme` is more like what egui
wants anyway, as individual windows can have theme overrides.
Also bump `smithay-clipboard` to prevent some now duplicate
dependencies.
* Some initial progress towards #4490
This PR just moves `Theme` and the "follow system theme" settings to
egui and adds `RawInput.system_theme`.
A follow-up PR can then introduce the two separate `dark_mode_style` and
`light_mode_style` fields on `Options`.
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* 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
### Breaking changes
The options `follow_system_theme` and `default_theme` has been moved
from `eframe` into `egui::Options`, settable with `ctx.options_mut`
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Closes https://github.com/emilk/egui/issues/1918
* Closes https://github.com/emilk/egui/issues/4437
* Closes https://github.com/emilk/egui/issues/4709
* [x] I have followed the instructions in the PR template
Hiya,
I need new winit for a specific fix for a android_native_actvity. There
are already two PRs, but both don't seem to have a lot of movement, or
are entirely complete:
https://github.com/emilk/egui/pull/4466
Seems to have gone stale & is missing some bits.
https://github.com/emilk/egui/pull/4702
Also seems stale (if less so), and is missing a refactor to
run_on_demand. I also *think* the accesskit integration has a mistake
and can't be enabled. I've marked them as a co-author on this as I
started from this branch. (I think! Haven't done that on git before...).
Sorry for the wall of text but just dumping some details / thoughts
here:
- There's an issue with creating child windows in winit 0.30.1 and up on
macOS. The multiple_viewports, "create immediate viewport" example
crashes on anything later 0.30.1, with a stack overflow in unsafe code.
I've create [a winit
issue](https://github.com/rust-windowing/winit/issues/3800), it *might*
already be fixed in 0.31.0 but I can't test as 0.31 will likely require
another refactoring. For now I have just pinned things to 0.30.0 exatly.
- Winit has deprecated run_on_demand, instead requiring the
ApplicationHandler interface. In 0.31.0 run_on_demand is removed. I've
refactored both the integration and the WinitApp trait to follow this
pattern. I've left user_events a bit more opaque, as it seems 0.31.0 is
doing a rework of UserEvents too.
- I've used the new lazy init approach for access kit from this branch
https://github.com/mwcampbell/egui/tree/accesskit-new-lazy-init and
marked Matt as co-author, thanks Matt!
- There was very similair but not quite the same code for run_and_return
and run_and_exit. I've merged them, but looking at the github issues
graveyard it seems vey finnicky. I *hope* this is more robust than
before but it's a bit scary.
- when receiving new_events this also used to check the redraw timing
dictionary. That doesn't seem necesarry so left this out, but that is a
slight behaviour change?
- I have reeneabled serial_windows on macOS. I wondered whether it was
fixed after this PR and does seem to be! However, even before this PR it
seems to work, so maybe winit has sorted things out before that...
Windows also works fine now without the extra hack.
- I've done a very basic test of AccessKit on Windows and screen reader
seems ok but I'm really not knowleadgable enough to say whether it's all
good or not.
- I've tested cargo tests & all examples on Windows & macOS, and ran a
basic Android app. Still, testing native platforms is wel... hard so if
anyone can test linux / iOs / older mac versions / windows 10 would
probably be a good idea!
- For consistencys sake I've made all event like functions in WinitApp
return a `Result<EventResult>`. There's quite a bit of Ok-wrapping now,
maybe too annoying? Not sure.
Thank you for having a look!
# Tested on
* [x] macOS
* [x] Windows
* [x] Wayland (thanks [SiebenCorgie](https://github.com/SiebenCorgie))
* [x] X11 (thanks
[crumblingstatue](https://github.com/crumblingstatue)!,
[SiebenCorgie](https://github.com/SiebenCorgie))
# TODO
* [x] Fix "follow system theme" not working on initial startup (winit
issue, pinning to 0.30.2 for now).
* [x] Fix `request_repaint_after`
---------
Co-authored-by: mwcampbell <mattcampbell@pobox.com>
Co-authored-by: j-axa <josef.axa@gmail.com>
Co-authored-by: DataTriny <datatriny@gmail.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* [x] I have followed the instructions in the PR template
Clarified that `eframe::run_simple_native()` does in fact save some
state (if persistence is enabled) but does not allow user to save state.
Improved `change_gl_context()`
**Before:**
Create a new `not_current_glcontext`.
**After:**
If `not_current_glcontext` exists, apply it. Otherwise, create it.
This will make the program smoother when dragging, etc.
* Fixes https://github.com/rerun-io/rerun/issues/6638
* Related? https://github.com/emilk/egui/issues/4563
This improves how an eframe canvas works inside of a larger web page,
and how it works when there are multiple eframe apps in the same page.
`eframe` will set `tabindex="0"` on the canvas automatically, making it
focusable.
It will also set `outline: none` on the CSS, so the focused canvas won't
have an ugly outline.
## Breaking changes
You may wanna add this to your `index.html` to give the canvas focus on
startup:
```js
document.getElementById("the_canvas_id").focus();
```
## Test setup
```sh
./scripts/build_demo_web.sh
./scripts/start_server.sh
open http://localhost:8888/multiple_apps.html
```
Then open the "Input Event History" and "Text Edit" windows
## Tested
* Chromium
* [x] drag-and-drop of files
* Test both when a `TextEdit` is focused and when it is not:
* [x] `Event::Key`
* [x] `Event::Text`
* [x] copy-cut-paste
* [x] Wheel scroll
* [x] `Event::PointerGone`
* [x] Mouse drag
* [x] Mouse click
* [x] Mouse right-click
* [x] Defocus all eframe canvas, and then start typing text
* [x] Firefox (all of the above)
* [x] Desktop Safari (all of the above)
* [x] Mobile Safari
## Future work (pre-existing issues)
* https://github.com/emilk/egui/issues/4723
* https://github.com/emilk/egui/issues/4724
* https://github.com/emilk/egui/issues/4725
* https://github.com/emilk/egui/issues/4726
`directories-next` was created because `directories` was not maintained
at the time. However, `directories` has gotten active maintainership
since, and it has received more updates than `directories-next`.
`directories` also has more recent downloads than its `next`
counterpart, so it might make sense to switch to it, to avoid
unnecessary duplicate dependencies, where a project depends transitively
on both `directories` and `directories-next`.
The main question is whether we depend on any specific behavior from
`directories-next`.
- Closes https://github.com/emilk/egui/issues/4060 - no longer aligned
to top
- Closes https://github.com/emilk/egui/issues/4479 - `canvas.style` is
not set anywhere anymore
- Closes https://github.com/emilk/egui/issues/2231 - same as #4060
- Closes https://github.com/emilk/egui/issues/3618 - there is now one
`<input>` per `eframe` app, and it's removed transitively by
`WebRunner::destroy -> AppRunner::drop -> TextAgent::drop`
This PR improves the text agent to make fewer assumptions about how
`egui` is embedded into the page:
- Text agent no longer sets the canvas position
- There is now a text agent for each instance of `WebRunner`
- The input element is now moved to the correct position, so the OS can
display the IME window in the correct place. Before it would typically
be outside of the viewport
The best way to test this is to build & server the web demo locally:
```
scripts/build_demo_web.sh && scripts/start_server.sh
```
Then open the EasyMark editor, and try using IME to input some emojis:
http://localhost:8888/#EasyMarkEditor
To open the emoji keyboard use:
- <kbd>win + .</kbd> on Windows
- <kbd>ctrl + cmd + space</kbd> on Mac
Tested on:
- [x] Windows
- [x] Linux
- [x] MacOS
- [x] Android
- [x] iOS
## Migration guide
The canvas no longer controls its own size/position on the page. This
means that those properties can now be controlled entirely via HTML and
CSS, and multiple separate `eframe` apps can coexist better on a single
page.
To match the old behavior, set the `canvas` width and height to 100% of
the `body` element:
```html
<html>
<body>
<canvas></canvas>
</body>
</html>
```
```css
/* remove default margins and use full viewport */
html, body {
margin: 0;
width: 100%;
height: 100%;
}
canvas {
/* match parent element size */
width: 100%;
height: 100%;
}
```
Note that there is no need to set `position: absolute`/`left: 50%;
transform: translateX(-50%)`/etc., and setting those properties may
poorly affect the sharpness of `egui`-rendered text.
Because `eframe` no longer updates the canvas style in any way, it also
means that on mobile, the canvas no longer collapses upwards to make
space for a mobile keyboard. This should be solved in other ways:
https://github.com/emilk/egui/issues/4572
The closure passed to `eframe::run_native` now returns a `Result`,
allowing you to return an error during app creation, which will be
returned to the caller of `run_native`.
This means you need to wrap your `Box::new(MyApp::new(…))` in an
`Ok(…)`.
* Closes https://github.com/emilk/egui/issues/4474
The closure is now stored in `WebRunner` and dropped in the next
`request_animation_frame` instead of being "leaked" via `forget`
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Currently, if the size of the canvas element changes independently of
the size of the browser window (e.g. due to its parent element
shrinking), then no repaints are scheduled.
This PR replaces the `resize` event with a `ResizeObserver`, which
ensures that _any_ resize of the canvas element (including those caused
by browser window resizes) trigger a repaint. The repaint is done
synchronously as part of the resize event, to reduce any potential
flickering.
The result seems to pass the rendering tests on most platform+browser
combinations. We tested:
- Chrome, Firefox, Safari on macOS
- Chrome, Firefox on Linux (ubuntu and arch, both running wayland)
- Chrome, Firefox on Windows
Firefox still has some antialiasing issues on Linux platforms, but this
antialiasing also happens on `master`, so this PR is not a regression
there.
The code setting `canvas.style.width` and `canvas.style.height` at the
start of `AppRunner::logic` was also removed - the canvas _display_ size
is now fully controlled by CSS, e.g. by setting `canvas { width: 100%;
height: 100%; }`.
The approach used here is described in
https://webglfundamentals.org/webgl/lessons/webgl-resizing-the-canvas.html
Note: The only remaining place where egui updates the style of the
canvas it is rendering to is some of the IME/mobile input handling code.
Fixing that is out of scope for this PR, and will be done in a followup
PR.
This allows customizing the persistence path in NativeOptions.
Previously, persistence wouldn't work with android because
directories-next doesn't support android so eframe would just fail to
find a place where it could store its config.
* Closes#4098 (android users can now specify a path that works with
android, by e.g. using app_dirs2, which supports android)
<!--
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 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!
-->
Related to #3482
Not sure what the "best practice" is, to me it seems like one should
import from "the original location" if possible, but now it should at
least be possible to not re-export ahash without any breakage in the
egui code base (but possibly in projects using egui, so one should
probably deprecate it if one would like to go that path). It also seems
like epaint re-exports ahash.
For integrations: just emit `egui::Event::MouseWheel` (like before).
egui will interpret that as zoom or pan.
On the way towards https://github.com/emilk/egui/issues/4401
<!--
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 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!
-->
Inspired by:
44d65f41ac/Cargo.toml (L65)
I took the liberty of removing that comment since I *think* that I got
all "relevant" ones (showing up more than once, sort of).
Emil Ernerfeldt
VinTarZ
Nicolas
lucasmerlin
pm100
Arthur Brussee
Tau Gärtli
Ardocrat
Arthur Brussee
Tyler Stevens
Salman Abuhaimed
Jan Procházka
rustbasic
Jonas Wagner
Owen Diehl
crumblingstatue
Oscar Gustafsson