* eframe: allow hooking into EventLoop building
This enables native applications to add an `event_loop_builder` callback
to the `NativeOptions` struct that lets them modify the Winit
`EventLoopBuilder` before the final `EventLoop` is built and run.
This makes it practical for applications to change platform
specific config options that Egui doesn't need to be directly aware of.
For example the `android-activity` glue crate that supports writing
Android applications in Rust requires that the Winit event loop be
passed a reference to the `AndroidApp` that is given to the
`android_main` entrypoint for the application.
Since the `AndroidApp` itself is abstracted by Winit then there's no
real need for Egui/EFrame to have a dependency on the `android-activity`
crate just for the sake of associating this state with the event loop.
Addresses: #1951
* eframe: defer graphics state initialization until app Resumed
Conceptually the Winit `Resumed` event signifies that the application is
ready to run and render and since
https://github.com/rust-windowing/winit/pull/2331 all platforms now
consistently emit a Resumed event that can be used to initialize
graphics state for an application.
On Android in particular it's important to wait until the application
has Resumed before initializing graphics state since it won't have an
associated SurfaceView while paused.
Without this change then Android applications are likely to just show
a black screen.
This updates the Wgpu+Winit and Glow+Winit integration for eframe but
it's worth noting that the Glow integration is still not able to fully
support suspend and resume on Android due to limitations with Glutin's
API that mean we can't destroy and create a Window without also
destroying the GL context, and therefore (practically) the entire
application.
There is a plan (and progress on) to improve the Glutin API here:
https://github.com/rust-windowing/glutin/pull/1435 and with that change
it should be an incremental change to enable Android suspend/resume
support with Glow later.
In the mean time the Glow changes keep the implementation consistent
with the wgpu integration and it should now at least be possible to
start an Android application - even though it won't be able to suspend
correctly.
Fixes#1951
Since https://github.com/emilk/egui/pull/1919 we can continue
the application after closing the native window. It therefore makes
more sense to call `frame.close()` to close the native window,
instead of `frame.quit()`.
I have gone back and forth on this a bit, but I think the arguments
AGAINST following the system theme are many:
* `dark-light` is a big dependency with problems on Linux.
* Many people prefer the dark mode and ask how to set it as the default
(even though they are using light mode in their OS).
* A developer may be surprised when the app changes theme when
they run it on another computer.
So, the path of least surprise is to make this an opt-in feature
with dark mode as the default mode.
On native, you add the `dark-light` feature to enable it.
On web, you set `WebOptions::follow_system_theme`.
* Use correct FBO to output
* custom_3d_three-d web
* Update .gitignore
* Do not free the FBO
* Use three-d 0.13
* ThreeDApp
* Only construct model and camera once
* Clean-up and docs
* Web build instructions
* Remove unused dependencies
* Update Cargo.lock
* Fix build
* More fixes
* omg
This adds `NativeOptions::run_and_return` with default value `true`.
If `true`, execution will continue after the eframe window is closed. This is a new behavior introduced in this PR.
If `false`, the app will close once the eframe window is closed. The is the old behavior.
This is `true` by default, and the `false` option is only there so we can revert if we find any bugs.
When `true`, [`winit::platform::run_return::EventLoopExtRunReturn::run_return`](https://docs.rs/winit/latest/winit/platform/run_return/trait.EventLoopExtRunReturn.html#tymethod.run_return) is used. The winit docs warns of its usage, recommending `EventLoop::run`, but 🤷
When `false`, [`winit::event_loop::EventLoop::run`](https://docs.rs/winit/latest/winit/event_loop/struct.EventLoop.html#method.run) is used.
This is a really useful feature. You can now use `eframe` to quickly open up a window and show some data or options, and then continue your program after the `eframe` window is closed
My previous attempt at this caused some problems, but my new attempt seems to be working much better, at least on my Mac.
It seems to me like the `pure_glow` example was broken sometime in april because of changes to feature flags. The text simply didn't show up which is due to missing fonts unless you figured out that you needed the `egui/default_fonts` feature flag. This change enforces the use of the `egui/default_fonts` feature flag in this example.
The `custom_3d_three-d` example does not enable a depth buffer since it is only rendering a triangle. However, if it is used as a starting point for other projects, it is highly likely that a depth buffer is actually needed, therefore I propose to enable it by default.
Also see [this](https://github.com/asny/three-d/issues/268) issue for full context.
Robert Bragg
Zoxc
Daniel Buch Hansen
Emil Ernerfeldt
Asger Nyman Christiansen
Zoxc
eranfu
Lorren Biffin
Barugon
Dylan Ancel
Nicolas Musset
YgorSouza
Stanislav
Kubik
quietvoid