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
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>
Previously, any frames in flight (`requestAnimationFrame`) on web were
not being cancelled (`cancelAnimationFrame`) when `WebRunner::destroy`
was called. If a user called `destroy`, then immediately removed the
canvas from the DOM, eframe could panic with a "failed to find (canvas)
element by id" error message.
This PR changes two things:
- The canvas element is directly referenced everywhere it's needed
instead of being looked up by `canvas_id`[^1]
- The RAF handle is stored in `WebRunner` and `cancelAnimationFrame` is
called on it inside of `WebRunner::destroy`[^2]
[^1]: The WebGL/WGPU backends were already holding onto the canvas (and
associated GPU context), so the change is just converting all the
`get_element_by_id` lookups to retrieve the canvas from the web runner
handle.
[^2]: There is only ever one frame in flight, so we store it directly as
a scalar field.
Update modifier state from web mouse events. This allows modifiers to be
correctly updated when the window is not in focus but the mouse is still
moving over the window.
* Follow-up to https://github.com/emilk/egui/pull/3621 and
https://github.com/emilk/egui/pull/3513
To work around a Safari limitation, we run the app logic in the event
handler of copy, cut, and mouse up and down.
Previously the output of that frame was discarded, but in this PR it is
now saved to be used in the next requestAnimationFrame.
The result is noticeable more distinct clicks on buttons (one more frame
of highlight)
Bonus: also fix auto-save of a sleeping web app
* Closes <https://github.com/emilk/egui/issues/3480>
I've tested this on Safari and Chrome on macOS Sonoma 14.0.
Could be improved to only call `event.preventDefault()` if
`runner.logic()` actually performed a copy, but I don't see a way to get
that information out with the current API.
* Closes#1044
---
(new PR description written by @emilk)
## Overview
This PR introduces the concept of `Viewports`, which on the native
eframe backend corresponds to native OS windows.
You can spawn a new viewport using `Context::show_viewport` and
`Cotext::show_viewport_immediate`.
These needs to be called every frame the viewport should be visible.
This is implemented by the native `eframe` backend, but not the web one.
## Viewport classes
The viewports form a tree of parent-child relationships.
There are different classes of viewports.
### Root vieport
The root viewport is the original viewport, and cannot be closed without
closing the application.
### Deferred viewports
These are created with `Context::show_viewport`.
Deferred viewports take a closure that is called by the integration at a
later time, perhaps multiple times.
Deferred viewports are repainted independenantly of the parent viewport.
This means communication with them need to done via channels, or
`Arc/Mutex`.
This is the most performant type of child viewport, though a bit more
cumbersome to work with compared to immediate viewports.
### Immediate viewports
These are created with `Context::show_viewport_immediate`.
Immediate viewports take a `FnOnce` closure, similar to other egui
functions, and is called immediately. This makes communication with them
much simpler than with deferred viewports, but this simplicity comes at
a cost: whenever tha parent viewports needs to be repainted, so will the
child viewport, and vice versa. This means that if you have `N`
viewports you are poentially doing `N` times as much CPU work. However,
if all your viewports are showing animations, and thus are repainting
constantly anyway, this doesn't matter.
In short: immediate viewports are simpler to use, but can waste a lot of
CPU time.
### Embedded viewports
These are not real, independenant viewports, but is a fallback mode for
when the integration does not support real viewports. In your callback
is called with `ViewportClass::Embedded` it means you need to create an
`egui::Window` to wrap your ui in, which will then be embedded in the
parent viewport, unable to escape it.
## Using the viewports
Only one viewport is active at any one time, identified wth
`Context::viewport_id`.
You can send commands to other viewports using
`Context::send_viewport_command_to`.
There is an example in
<https://github.com/emilk/egui/tree/master/examples/multiple_viewports/src/main.rs>.
## For integrations
There are several changes relevant to integrations.
* There is a [`crate::RawInput::viewport`] with information about the
current viewport.
* The repaint callback set by `Context::set_request_repaint_callback`
now points to which viewport should be repainted.
* `Context::run` now returns a list of viewports in `FullOutput` which
should result in their own independant windows
* There is a new `Context::set_immediate_viewport_renderer` for setting
up the immediate viewport integration
* If you support viewports, you need to call
`Context::set_embed_viewports(false)`, or all new viewports will be
embedded (the default behavior).
## Future work
* Make it easy to wrap child viewports in the same chrome as
`egui::Window`
* Automatically show embedded viewports using `egui::Window`
* Use the new `ViewportBuilder` in `eframe::NativeOptions`
* Automatically position new viewport windows (they currently cover each
other)
* Add a `Context` method for listing all existing viewports
Find more at https://github.com/emilk/egui/issues/3556
---
<details>
<summary>
Outdated PR description by @konkitoman
</summary>
## Inspiration
- Godot because the app always work desktop or single_window because of
embedding
- Dear ImGui viewport system
## What is a Viewport
A Viewport is a egui isolated component!
Can be used by the egui integration to create native windows!
When you create a Viewport is possible that the backend do not supports
that!
So you need to check if the Viewport was created or you are in the
normal egui context!
This is how you can do that:
```rust
if ctx.viewport_id() != ctx.parent_viewport_id() {
// In here you add the code for the viewport context, like
egui::CentralPanel::default().show(ctx, |ui|{
ui.label("This is in a native window!");
});
}else{
// In here you add the code for when viewport cannot be created!
// You cannot use CentralPanel in here because you will override the app CentralPanel
egui::Window::new("Virtual Viewport").show(ctx, |ui|{
ui.label("This is without a native window!\nThis is in a embedded viewport");
});
}
```
This PR do not support for drag and drop between Viewports!
After this PR is accepted i will begin work to intregrate the Viewport
system in `egui::Window`!
The `egui::Window` i want to behave the same on desktop and web
The `egui::Window` will be like Godot Window
## Changes and new
These are only public structs and functions!
<details>
<summary>
## New
</summary>
- `egui::ViewportId`
- `egui::ViewportBuilder`
This is like winit WindowBuilder
- `egui::ViewportCommand`
With this you can set any winit property on a viewport, when is a native
window!
- `egui::Context::new`
- `egui::Context::create_viewport`
- `egui::Context::create_viewport_sync`
- `egui::Context::viewport_id`
- `egui::Context::parent_viewport_id`
- `egui::Context::viewport_id_pair`
- `egui::Context::set_render_sync_callback`
- `egui::Context::is_desktop`
- `egui::Context::force_embedding`
- `egui::Context::set_force_embedding`
- `egui::Context::viewport_command`
- `egui::Context::send_viewport_command_to`
- `egui::Context::input_for`
- `egui::Context::input_mut_for`
- `egui::Context::frame_nr_for`
- `egui::Context::request_repaint_for`
- `egui::Context::request_repaint_after_for`
- `egui::Context::requested_repaint_last_frame`
- `egui::Context::requested_repaint_last_frame_for`
- `egui::Context::requested_repaint`
- `egui::Context::requested_repaint_for`
- `egui::Context::inner_rect`
- `egui::Context::outer_rect`
- `egui::InputState::inner_rect`
- `egui::InputState::outer_rect`
- `egui::WindowEvent`
</details>
<details>
<summary>
## Changes
</summary>
- `egui::Context::run`
Now needs the viewport that we want to render!
- `egui::Context::begin_frame`
Now needs the viewport that we want to render!
- `egui::Context::tessellate`
Now needs the viewport that we want to render!
- `egui::FullOutput`
```diff
- repaint_after
+ viewports
+ viewport_commands
```
- `egui::RawInput`
```diff
+ inner_rect
+ outer_rect
```
- `egui::Event`
```diff
+ WindowEvent
```
</details>
### Async Viewport
Async means that is independent from other viewports!
Is created by `egui::Context::create_viewport`
To be used you will need to wrap your state in `Arc<RwLock<T>>`
Look at viewports example to understand how to use it!
### Sync Viewport
Sync means that is dependent on his parent!
Is created by `egui::Context::create_viewport_sync`
This will pause the parent then render itself the resumes his parent!
#### ⚠️ This currently will make the fps/2 for every sync
viewport
### Common
#### ⚠️ Attention
You will need to do this when you render your content
```rust
ctx.create_viewport(ViewportBuilder::new("Simple Viewport"), | ctx | {
let content = |ui: &mut egui::Ui|{
ui.label("Content");
};
// This will make the content a popup if cannot create a native window
if ctx.viewport_id() != ctx.parent_viewport_id() {
egui::CentralPanel::default().show(ctx, content);
} else {
egui::Area::new("Simple Viewport").show(ctx, |ui| {
egui::Frame::popup(ui.style()).show(ui, content);
});
};
});
````
## What you need to know as egui user
### If you are using eframe
You don't need to change anything!
### If you have a manual implementation
Now `egui::run` or `egui::begin` and `egui::tessellate` will need the
current viewport id!
You cannot create a `ViewportId` only `ViewportId::MAIN`
If you make a single window app you will set the viewport id to be
`egui::ViewportId::MAIN` or see the `examples/pure_glow`
If you want to have multiples window support look at `crates/eframe`
glow or wgpu implementations!
## If you want to try this
- cargo run -p viewports
## This before was wanted to change
This will probably be in feature PR's
### egui::Window
To create a native window when embedded was set to false
You can try that in viewports example before:
[78a0ae8](78a0ae879e)
### egui popups, context_menu, tooltip
To be a native window
</details>
---------
Co-authored-by: Konkitoman <konkitoman@users.noreply.github.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Pablo Sichert <mail@pablosichert.com>
* Detect panics during initialization and show them to the user
* PanicHandler now also logs the panics
* Add example of how to call into your app from JS
* Refactor: break out AppRunner and AppRunnerRef to own files
* Hide AppRunner
* Simplify user code
* AppRunnerRef -> WebRunner
* Better docs
* Don't paint until first animation frame
* Update multiple_apps.html
* Update web demo
* Cleanup and fixes
* left-align panic message in html
* Refactor: remove extra store of events
* Remove unnecessary extra function
* Refactor: simplify event registering
* Store panic summary
* egui_demo_app: move web-part to own module
* index.html: await
* Properly unsubscribe from events on panic
* Better error handling
* Demo app html: hide the wasm canvas and show an error message on panic
* egui_demo_app: add panic button to test panic response on web
* fix typo
* Use a constructor to create WebHandle
* Refactor: less use of locks in the interfaces
* More consistent naming
* Refactor repaint logic
* request_repaint_after also fires the request_repaint callback
* Bug fixes
* Add test to egui_demo_app
* build_demo_web: build debug unless --release is specified
* Fix the web backend too
* Run special clippy for wasm, forbidding some types/methods
* Remove wasm_bindgen_check.sh
* Fix typos
* Revert "Remove wasm_bindgen_check.sh"
This reverts commit 92dde25344.
* Only run cranky/clippy once
* Replace tracing crate with log
It's just so much simpler to use
* Add `bacon wasm` job
* eframe: add a WebLogger for piping log events to the web console
* Add raw mouse wheel event
The event is sent as it comes from the backend, so it will follow
different conventions depending on the target, and it is up to the user
code to deal with that. The goal is to allow advanced users to implement
alternative UI controls, e.g., using Ctrl to scroll the plot
horizontally instead of zooming, or use Shift to scroll faster instead
of changing direction.
* Change Pixel to Point for consistency
Apply suggestions from code review by emilk
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Inline mouse wheel raw event closure
It was meant only to be able to use the same variable names without
shadowing the rest of the code, but a simple block accomplishes the same
thing.
* Use wildcard on wheel event match
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Flip mouse wheel delta sign on web to match native
* Use wheel event data to generate scroll event
To avoid doing the same match and sign conversion twice.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* React to ThemeChanged event from winit
* React to theme change using media query change event in WASM
* Share conversion from bool -> Theme
* Suppress too_many_arguments warning
* Document limitations of automatically following the dark vs light mode preference
* Simplify expression
* Conditionally compile code to prevent unused item warnings
* Remove needless borrow
* Remove another needless borrow
* Make associated functions to standalone
* Request repaint after theme has changed
* Only install event listener when `follow_system_theme` is enabled
* Remove dark-light feature gate
* Detect system theme using winit
* Update documentation
* Fix typos
* fix warning about unused argument
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Deprecate egui_glium - looking for new maintainer
egui_glium was the first backend of egui, and it served us well for
a long time, but we have long since moved on to glow and wgpu.
Not egui_glium is holding back an update to latest winit.
Since development on glium has long since been discontinued I will
therefore deprecate egui_glium with this PR.
The code is still there in the repository for a while longer,
but is no longer compiled.
If there is any interest in maintaining egui_glium, then fork it and
make a PR to remove the last egui_glium from this repository.
I will give you publish rights on crates.io.
* update glutin 0.30.2 -> 0.30.3
* cargo update -p backtrace
Updating crates.io index
Updating addr2line v0.17.0 -> v0.19.0
Updating backtrace v0.3.66 -> v0.3.67
Updating gimli v0.26.2 -> v0.27.1
Removing miniz_oxide v0.5.4
Updating object v0.29.0 -> v0.30.3
* cargo deny: allow duplicates of windows-sys, wayland-sys, and nix
* cargo-deny whitelist tiny-skia
* basic working wgpu @ webgl on websys
* fix glow compile error
* introduced WebPainter trait, provide wgpu renderstate
* WebPainterWgpu destroy implemented
* make custom3d demo work on wgpu backend
* changelog entry for wgpu support eframe wasm
* remove temporary logging hack
* stop using pollster for web
we're actually not allowed to block - this only worked because wgpu on webgl doesn't actually cause anything blocking. However, when trying webgpu this became an issue
* revert cargo update
* compile error if neither glow nor wgpu features are enabled
* code cleanup
* Error handling
* Update changelog with link
* Make sure --all-features work
* Select best framebuffer format from the available ones
* update to wasm-bindgen 0.2.83
* Fix typo
* Clean up Cargo.toml
* Log about using the wgpu painter
* fixup wgpu labels
* fix custom3d_wgpu_shader ub padding
* remove duplicated uniforms struct in wgsl shader for custom3d
* Update docs: add async/await to the web 'start' function
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
