- Introduces `WidgetType::ProgressIndicator` and maps it to the
corresponding AccessKit role.
- A `Spinner` is now exposed as a widget indicating a progress for which
a completion state is not known.
- On the other hand, a `ProgressBar` reports a completion state and can
possibly be labeled. Note that a label is not used if not explicitly
asked by the user, as it would be redundant information. Assistive
technologies prefer the numerical value so they can, for instance, emit
beeps of which the frequency rise as the completion state increase. I
had to call `floor` on the progression as it seems all the ATs I tested
would round the value, hence reporting something different than what is
displayed on the label.
* Closes https://github.com/emilk/egui/issues/4113
Previously the `Id` of the menu `Area` was using the same id as the
thing that was clicked (i.e. the button opening menu), which lead to id
clashes
We plan to store input data for creating automated tests, hence the need
for more serde derives on input related structs.
---------
Co-authored-by: Georg Weisert <georg.weisert@freshx.de>
I often write constants at the top of my widget files, as a "config". I
kept writing stuff like that :
```rust
const DEFAULT_INNER_MARGIN: Margin = Margin { left: 17., right: 17., top: 7., bottom: 7. };
```
So I prefixed constructors for `Margin`, `Rounding` and `Shadow` const.
No code was changed.
I also added a `Shadow::new()` for similar reasons.
Raw mouse movement is unaccelerated and unclamped by screen boundaries,
and does not relate to any position on the screen.
It is useful in certain situations such as draggable values and 3D
cameras, where screen position does not matter.
https://github.com/emilk/egui/assets/1700581/1400e6a6-0573-41b9-99a1-a9cd305aa1a3
Added `Event::MouseMoved` for integrations to supply raw mouse movement.
Added `Response:drag_motion` to get the raw mouse movement, but will
fall back to delta in case the integration does not supply it.
Nothing should be breaking, but third-party integrations that can send
`Event::MouseMoved` should be updated to do so.
Based on #1614 but updated to the current version, and with better
fallback behaviour.
* Closes#1611
* Supersedes #1614
* Closes https://github.com/emilk/egui/issues/3936
* Closes https://github.com/emilk/egui/issues/3923
* Closes https://github.com/emilk/egui/pull/4058
The interaction code is now done at the start of the frame, using stored
`WidgetRect`s from the previous frame.
The intention is that the new interaction code should be more accurate,
making it easier to hit widgets, and better respecting the rules of
overlapping widgets.
There is a new `style::Interaction::interact_radius` controlling how far
away from a widget the cursor can be and still hit it. This helps big
fat fingers hit small widgets on touch screens.
This PR adds a new `Context::read_response` which lets you read the
`Response` of a `Widget` _before_ you create the widget. This can be
used for styling, or for reading the result of an interaction early (to
prevent frame-delay) for a widget you add late (so it is on top of other
widgets).
# ⚠️ BREAKING CHANGES
`Memory::dragged_id`, `Memory::set_dragged_id` etc have been moved to
`Context`.
The semantics for `Context::dragged_id` is slightly different: a widget
is not considered dragged until egui it is sure this is not a
click-in-progress. For a widget that is only sensitive to drags, that is
right away, but for widgets sensitive to both clicks and drags it is not
until the mouse has moved a certain distance.
# TODO
* [x] Fix panel resizing
* [x] Fix scroll hover weirdness
* [x] Fix Resize widget
* [x] Fix drag-and-drop
* [x] Test all of egui_demo_app
* [x] Change `is_dragging` API
* [x] Consistent naming of start/stop or begin/end drag
* [x] Test `egui_tiles`
* [x] Test Rerun
* [x] Document
* [x] Document breaking changes in PR description
* [x] Test one final time
# Saving for a later PR
* [ ] Fix https://github.com/emilk/egui/issues/4047
* [ ] Specify what the response order for e.g. `ui.horizontal` is
I think both these can be fixed if each `Ui` registers themselves as a
`WidgetRect`, with the possibility to interact with it later, as if the
interaction was under all widgets on top of it.
⚠️ Removes `Context::translate_layer`, replacing it with a sticky
`set_transform_layer`
Adds the capability to scale layers.
Allows interaction with scaled and transformed widgets inside
transformed layers.
I've also added a demo of how to have zooming and panning in a window
(see the video below).
This probably closes#1811. Having a panning and zooming container would
just be creating a new
`Area` with a new id, and applying zooming and panning with
`ctx.transform_layer`.
I've run the github workflow scripts in my repository, so hopefully the
formatting and `cargo cranky` is satisfied.
I'm not sure if all call sites where transforms would be relevant have
been handled. This might also be missing are transforming clipping
rects, but I'm not sure where / how to accomplish that. In the demo, the
clipping rect is transformed to match, which seems to work.
https://github.com/emilk/egui/assets/70821802/77e7e743-cdfe-402f-86e3-7744b3ee7b0f
---------
Co-authored-by: tweoss <fchua@puffer5.stanford.edu>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This PR short-circuits `Response::interact()` when the `Response` has
already been sufficiently "sensed" already. In some circumstance, this
can avoid unnecessarily registering another widget rect that may mask
some other widget.
One such instance is Rerun's `ListItem`. Calling `context_menu()` on its
response would call `interact` and, in turn, mask its sub-widget
(collapsing triangle, show/hide buttons, etc.).
Despite their being an actual `egui::Margin` struct, Textedit has a
`margin()` builder function that supports only `Vec2` types and thereby
only symmetric margins. This PR changes the function to accept
`egui::Margin` type instead making it more congruent with overall egui
logic as well as supporting asymmetric margins.
P.S: I tried to run all checks but I had to modify `./rust-toolchain` to
1.67.0 to get the checks to run on macOS.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
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!
-->
* Closes <https://github.com/emilk/egui/issues/3990>
`winit` supports up to F35, so thought it was better to just add them
all.
Exposes support in both glow and wgpu for texture wrap modes
This would be breaking for manual creations of TextureOptions but would
work with the current TextureOptions::NEAREST and LINEAR without change,
keeping those clamp to edge
I wasn't sure how best to expose the options to the user and added
consts for LINEAR_REPEAT LINEAR_MIRRORED_REPEAT NEAREST_REPEAT
NEAREST_MIRRORED_REPEAT
This does not include wrap mode clamp to border as it worked fine with
glow but with wgpu it panics due to Features
Features(ADDRESS_MODE_CLAMP_TO_BORDER) are required but not enabled on
the device, and I thought it was probably best not to try to enable that
feature, but happy to include that functionality also if that is okay to
be toggled
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Basic version of https://github.com/emilk/egui/issues/3931
This adds `Context::repaint_causes` which returns a `Vec<RepaintCause>`,
containing the `file:line` of the call to `ctx.request_repaint()`.
If your application is stuck forever repainting, this could be a useful
tool to diagnose it.
* Closes https://github.com/emilk/egui/issues/3941
Workspace dependencies can be annoying.
If you don't set them to `default-features=false`, then you cannot opt
out of their default features anywhere else, and get warnings if you
try.
So you set `default-features=false`, and then you need to manually opt
in to the default features everywhere else.
Or, as in my case, don't.
I don't have the energy to do this tonight, so I'll just revert.
* Part of https://github.com/emilk/egui/issues/1485
This adds a `rayon` feature to `epaint` and `egui` to parallelize
tessellation of large shapes, such as high-resolution plot lines.
With this PR, if a widget moves or repaints, egui will automatically
repaint.
Usually this is what you want: if something is moving we should repaint
until it stops moving.
However, this could potentially create false positives in some rare
circumstances, so there is an option to turn it off with
`Options::repaint_on_widget_change`.
Hi everyone! It's a great pleasure to work with such a library. It feels
like a breath of fresh air!
**Problem:**
The current implementation of `context_menu` consumes `self` and returns
it. However, the underlying `menu::context_menu` requires only a
reference to `self`, so it is safe to change the `context_menu`
signature.
**Fix:**
1. Change signature to take a ref to `self`.
2. Return the `Option<InnerResponse<()>>` from the underlying method
call
**Pros:**
1. No `let response = response.context_menu(|| {...})` pattern
2. Better consistency with other `show`-like methods, as it is in the
`Window::show`
3. Less ownership gymnastics
**Cons:**
1. Breaking change
2. Smth else what I don't see ?
**Additional info:**
- This method is also addressed in [this
PR](https://github.com/emilk/egui/pull/857).
- `check.sh` fails only on `cargo check --quiet -p eframe
--no-default-features --features wgpu` with `"The platform you're
compiling for is not supported by winit"` error, should it be launched
at all ?
* Closes https://github.com/emilk/egui/issues/3882
This adds several methods to make drag-and-drop more ergonomic in egui.
In particular, egui can now keep track of _what_ is being dragged for
you (the _payload_).
Low-level:
* `egui::DragAndDrop` hold the payload during a drag
Mid-level:
* `Response::dnd_set_drag_payload` sets it for drag-sources
* `Response::dnd_hover_payload` and `Response::dnd_release_payload`
reads it for drop-targets
High-level:
* `ui.dnd_drag_source`: make a widget draggable
* `ui.dnd_drop_zone`: a container where things can be dropped
The drag-and-drop demo is now a lot simpler:
https://github.com/emilk/egui/blob/emilk/drag-and-drop/crates/egui_demo_lib/src/demo/drag_and_drop.rs
---------
Co-authored-by: Antoine Beyeler <abeyeler@ab-ware.com>
Previously the `Frame` API only supported picking colors once, and then
adding widgets.
But what if you want to add widgets first, and THEN pick the colors for
the frame? Now you can!
```rs
let frame = Frame::default().inner_margin(4.0).begin(ui);
{
frame.content_ui.label("Inside the frame");
frame.content_ui.label("This too");
}
let response = frame.allocate_space(ui);
if response.hovered() {
frame.frame.stroke = Stroke::new(2.0, Color32::WHITE);
}
frame.paint(ui);
```
If a widgets sense both clicks and drags, we don't know wether or not a
mouse press on it will be a short click or a long drag.
With this PR, `response.dragged` and `response.drag_started` isn't true
until we know it is a drag and not a click.
If the widget ONLY senses drags, then we know as soon as someone presses
on it that it is a drag.
If it is sensitive to both clicks and drags, we don't know until the
mouse moves a bit, or stays pressed down long enough.
This PR also ensures that `response.clicked` and is only true for
widgets that senses clicks.
This can be useful for creating simple plugins for egui.
The state can be stored in the egui data store, or by the user.
An example plugin for painting debug text on screen is provided.
This adds smooth scrolling in egui. This makes scrolling in a
`ScrollArea` using a notched mouse wheel a lot nicer.
`InputState::scroll_delta` has been replaced by
`InputState::raw_scroll_delta` and `InputState::smooth_scroll_delta`.
* Closes https://github.com/emilk/egui/issues/3816
Turn off with `style.interaction.multi_widget_text_select`.
There is an API for this in `LabelSelectionState`, but it's pretty
bare-bones.
This became really hairy implementation-wise, but it works decently
well.
# Limitations
* Drag-select to scroll doesn't work
* A selection disappears if you scroll past one of its end-points
* Only the text of labels and links are selectable
## TODO
* [x] An option to turn it off
* [x] An API for querying about the selected text, and to deselect it.
* [x] Scrolling past selection behaves weird
* [x] Shift-click to select a range
This PR adds the following APIs, which I found to be missing while
working on https://github.com/rerun-io/rerun/pull/4879:
- `Response::decidedly_dragged()`: tests if the corresponding widget is
being decidedly dragged
- `Memory::dragged_id()`: returns the ID of the dragged widget, if any
* Closes https://github.com/emilk/egui/issues/3841⚠️ Breaking change!
This defines `response.hovered()` to never be true if any other widget
is being dragged.
If you want to detect if a widget is being hovered while another widget
is being dragged, use the new `response.contains_pointer` instead. This
is necessaert for things like drag-and-drop targets.
Overall, this removes special-casing of non-interactive widgets.
How text editing behaves depends on what OS we are running on.
`target_os` is a compile-time check, but `ctx.os()` is a runtime check,
that works also on web.
This broke in https://github.com/emilk/egui/pull/3172
Since 0.24.1, `stable_dt` has been fixed at 1/60s, which is a little bit
_too_ stable.
The code issue was the logic for asking "Is this the result of an
immeditate repaint?" was completely broken (always returning false).
* Closes https://github.com/emilk/egui/issues/3830
* Closes https://github.com/emilk/egui/issues/3804
Add ability to select the text in labels with mouse-drag, double-click,
and keyboard (once clicked).
Hit Cmd+C to copy the text. If everything of a label with elided text is
selected, the copy command will copy the full non-elided text. IME and
accesskit _should_ work, but is untested.
You can control wether or not text in labels is selected globally in
`style.interaction.selectable_labels` or on a per-label basis in
`Label::selectable`. The default is ON.
This also cleans up the `TextEdit` code somewhat, fixing a couple
smaller bugs along the way.
This does _not_ implement selecting text across multiple widgets. Text
selection is only supported within a single `Label`, `TextEdit`, `Link`
or `Hyperlink`.
## TODO
* [x] Test
Add option to use the scroll input from both directions to scroll the
enabled direction if scrolling is enabled for only one direction. This
can be used to allow horizontal scrolling without pressing shift if
vertical scrolling is disabled.
Closes <https://github.com/emilk/egui/issues/3624>.
This feels awful, @emilk why does this have to be an Arc?
Should the Arc be replaced with a new one when set_undoer is called, or
should it just replace the undoer inside the Arc?
Closes#3436
As described in #576, the method `Memory::layer_id_at` expands the
hit-testing region for every `Area` slightly. This is necessary so that,
when the user clicks to resize a `Window`, the mouse input isn't routed
to a different `Window`.
For non-resizable `Area`s (such as dropdown menus, context menus, date
pickers, and any non-resizable `Window`), this causes them to be
surrounded by a "dead zone" where any underlying widgets can't be
hovered or clicked. The effect is particularly noticeable in menu bars.
This commit adds a persisted `edges_padded_for_resize` property to
`Area`, which is `true` when the `Area` belongs to a resizable `Window`
and `false` for all other `Area`s. The hit-testing region is only
expanded when this property is `true`.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This PR replaces an old one with many problems (no collapse icon, the
header background was not funny colored, ugly...). It fixes those
problems.
It implements the highlight of the header to the focused window. And
allows the rest of the application to know the selected window. It
allows, for instance, to display multiple windows with images and some
additional meta information about those images on the side panel of the
main window. The side panel updates itself according to the selected
image window.
* Added a theme color for the selected window header.
* Added a function to retrieve the LayerId of the focused window.
* Implemented a simple demo of this function in the demo app where a
message states if the Option window is focused (at the bottom of the
Options window).
A technical point:
The header color is applied with a transparency of 125 so the
collapsible button becomes visible.
The reason is that the collapsible button is rendered before the rest of
the header and before the header size is known.
We cannot draw the background before knowing this value, so rendering
with transparency is a solution to see the collapsible button through
the header background.
This PR has been sponsored by my company, which left me to do it during
my work time.
This is part of an evil plan to convince them to switch to rust for new
projects :)
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The minimum filled width is adapted to the radius and the animation is
disabled so it renders correctly.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This tiny change removes the trigger for a submenu to close if the mouse
is no longer hovering over it or one of its children. Now, the menu
stays open until a different menu item is selected. This aims to address
<https://github.com/emilk/egui/issues/2853>.
I suspected that a new trigger would need to be implemented so that
multiple menu items don't remain open simultaneously, but after some
testing, this does not appear to occur.
This change leaves `MenuState::hovering_current_submenu` and
`MenuState::close_submenu` as dead code in case they might be useful
later.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Added some DragValue widgets in the color_picker widget as input fields
for managing the RGBA values.
In case the provided values result in a not valid premultiplied alpha
RGBA color, a button will appear next to the input fields, to be used to
multiply the values with the alpha channel.
Closes <https://github.com/emilk/egui/issues/2716>.
---------
Co-authored-by: IVANMK-7 <68190772+IVANMK-7@users.noreply.github.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Co-authored-by: Brian Janssen <tosti007@users.noreply.github.com>
<!--
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.
* 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!
-->
* Closes https://github.com/emilk/egui/issues/3626
Basically, egui now ignores extra SHIFT and ALT pressed when matching
keyboard shortcuts.
This is because SHIFT and ALT are often requires to produce some logical
keys.
For instance, typing `+` on an English keyboard requires pressing `SHIFT
=`,
so the keyboard shortcut looking for `CTRL +` should ignore the SHIFT
key.
@abey79 You reported problem using `Cmd +` and `Cmd -` to zoom - does
this fix it for you?
You can run with `RUST_LOG=egui_winit=trace cargo run` to see a printout
of how winit reports the logical and physical keys, and how egui
interprets them.
Weirdly, on Mac winit reports `SHIFT =` as `+`, but `CMD SHIFT =` as `=`
(on an English keyboard) so things are… difficult.
* Closes https://github.com/emilk/egui/issues/3766
Add support for type in CompositionEnd only characters without trigger
CompositionStart first.
This usually works with no-latin character input.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This fixes a bug where the context menu would open when dragging with
the secondary mouse button.
Now the context menu requires a click to open.
This is important for things like plots, where right-click and
right-drag means different things.
<!--
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.
* 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!
-->
This adds the missing variant described in below issue.
Closes <https://github.com/emilk/egui/issues/3748>.
If you wish - or even desired - I could look into implement the From
conversion between ResizeDirection and CursorInfo in a seperate PR.
I ran into an issue then running `check.sh` however it seems unrelated
to this PR.
For clarity I'm running Linux, with a wayland compositor.
```bash
~/dev/rust/egui ❯ cargo clean [add-missing-resizedirection ≡]
~/dev/rust/egui ❯ ./scripts/check.sh [add-missing-resizedirection ≡]
+ cargo install --quiet cargo-cranky
+ cargo install --quiet typos-cli
+ export 'RUSTFLAGS=--cfg=web_sys_unstable_apis -D warnings'
+ RUSTFLAGS='--cfg=web_sys_unstable_apis -D warnings'
+ export 'RUSTDOCFLAGS=-D warnings'
+ RUSTDOCFLAGS='-D warnings'
+ typos
+ ./scripts/lint.py
./scripts/lint.py finished without error
+ cargo fmt --all -- --check
+ cargo doc --quiet --lib --no-deps --all-features
+ cargo doc --quiet --document-private-items --no-deps --all-features
+ cargo cranky --quiet --all-targets --all-features -- -D warnings
+ ./scripts/clippy_wasm.sh
+ export CLIPPY_CONF_DIR=scripts/clippy_wasm
+ CLIPPY_CONF_DIR=scripts/clippy_wasm
+ cargo cranky --quiet --all-features --target wasm32-unknown-unknown --target-dir target_wasm -p egui_demo_app --lib -- --deny warnings
+ cargo check --quiet --all-targets
+ cargo check --quiet --all-targets --all-features
+ cargo check --quiet -p egui_demo_app --lib --target wasm32-unknown-unknown
+ cargo check --quiet -p egui_demo_app --lib --target wasm32-unknown-unknown --all-features
+ cargo test --quiet --all-targets --all-features
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 4 tests
i...
test result: ok. 3 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 14 tests
..............
test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s
running 1 test
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.52s
Testing demo_with_tessellate__realistic
Success
Testing demo_no_tessellate
Success
Testing demo_only_tessellate
Success
Testing label &str
Success
Testing label format!
Success
Testing Painter::rect
Success
Testing text_layout_uncached
Success
Testing text_layout_cached
Success
Testing tessellate_text
Success
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 1 test
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 7 tests
.......
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 23 tests
.......................
test result: ok. 23 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.20s
Testing single_dashed_lines
Success
Testing many_dashed_lines
Success
Testing tessellate_circles_100k
Success
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
+ cargo test --quiet --doc
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 4 tests
....
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.26s
running 146 tests
........................................................................................ 88/146
i.........................................................
test result: ok. 145 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 108.27s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
running 5 tests
iiii.
test result: ok. 1 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 3.65s
running 5 tests
.....
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 11.99s
running 2 tests
..
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.06s
running 5 tests
ii...
test result: ok. 3 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out; finished in 2.53s
running 11 tests
...........
test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.38s
running 5 tests
i....
test result: ok. 4 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 1.01s
+ cd crates/eframe
+ cargo check --quiet --no-default-features --features glow
+ cd crates/eframe
+ cargo check --quiet --no-default-features --features wgpu
error: The platform you're compiling for is not supported by winit
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/platform_impl/mod.rs:67:1
|
67 | compile_error!("The platform you're compiling for is not supported by winit");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0432]: unresolved import `self::platform`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/platform_impl/mod.rs:26:15
|
26 | pub use self::platform::*;
| ^^^^^^^^ could not find `platform` in `self`
error[E0432]: unresolved import `crate::platform_impl::PlatformIcon`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/icon.rs:1:5
|
1 | use crate::platform_impl::PlatformIcon;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `PlatformIcon` in `platform_impl`
error[E0433]: failed to resolve: could not find `DeviceId` in `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event.rs:616:42
|
616 | DeviceId(unsafe { platform_impl::DeviceId::dummy() })
| ^^^^^^^^ could not find `DeviceId` in `platform_impl`
error[E0433]: failed to resolve: could not find `WindowId` in `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:99:42
|
99 | WindowId(unsafe { platform_impl::WindowId::dummy() })
| ^^^^^^^^ could not find `WindowId` in `platform_impl`
error[E0433]: failed to resolve: could not find `Window` in `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:513:28
|
513 | platform_impl::Window::new(&window_target.p, self.window, self.platform_specific)?;
| ^^^^^^ could not find `Window` in `platform_impl`
error[E0412]: cannot find type `OsError` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/error.rs:28:27
|
28 | error: platform_impl::OsError,
| ^^^^^^^ not found in `platform_impl`
|
help: there is an enum variant `crate:🪟:BadIcon::OsError`; try using the variant's enum
|
28 | error: crate:🪟:BadIcon,
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0412]: cannot find type `OsError` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/error.rs:62:76
|
62 | pub(crate) fn new(line: u32, file: &'static str, error: platform_impl::OsError) -> OsError {
| ^^^^^^^ not found in `platform_impl`
|
help: there is an enum variant `crate:🪟:BadIcon::OsError`; try using the variant's enum
|
62 | pub(crate) fn new(line: u32, file: &'static str, error: crate:🪟:BadIcon) -> OsError {
| ~~~~~~~~~~~~~~~~~~~~~~
error[E0412]: cannot find type `DeviceId` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event.rs:602:47
|
602 | pub struct DeviceId(pub(crate) platform_impl::DeviceId);
| ^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `KeyEventExtra` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event.rs:787:50
|
787 | pub(crate) platform_specific: platform_impl::KeyEventExtra,
| ^^^^^^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `EventLoop` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event_loop.rs:41:43
|
41 | pub(crate) event_loop: platform_impl::EventLoop<T>,
| ^^^^^^^^^ not found in `platform_impl`
|
help: consider importing this struct
|
10 + use calloop::EventLoop;
|
help: if you import `EventLoop`, refer to it directly
|
41 - pub(crate) event_loop: platform_impl::EventLoop<T>,
41 + pub(crate) event_loop: EventLoop<T>,
|
error[E0412]: cannot find type `EventLoopWindowTarget` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event_loop.rs:52:34
|
52 | pub(crate) p: platform_impl::EventLoopWindowTarget<T>,
| ^^^^^^^^^^^^^^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `PlatformSpecificEventLoopAttributes` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event_loop.rs:62:50
|
62 | pub(crate) platform_specific: platform_impl::PlatformSpecificEventLoopAttributes,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `platform_impl`
error[E0433]: failed to resolve: could not find `EventLoop` in `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event_loop.rs:128:40
|
128 | event_loop: platform_impl::EventLoop::new(&mut self.platform_specific)?,
| ^^^^^^^^^ could not find `EventLoop` in `platform_impl`
|
help: consider importing this struct
|
10 + use calloop::EventLoop;
|
help: if you import `EventLoop`, refer to it directly
|
128 - event_loop: platform_impl::EventLoop::new(&mut self.platform_specific)?,
128 + event_loop: EventLoop::new(&mut self.platform_specific)?,
|
error[E0412]: cannot find type `EventLoopProxy` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/event_loop.rs:394:38
|
394 | event_loop_proxy: platform_impl::EventLoopProxy<T>,
| ^^^^^^^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `VideoMode` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/monitor.rs:18:43
|
18 | pub(crate) video_mode: platform_impl::VideoMode,
| ^^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `MonitorHandle` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/monitor.rs:104:38
|
104 | pub(crate) inner: platform_impl::MonitorHandle,
| ^^^^^^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `VideoMode` in this scope
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/platform_impl/mod.rs:31:15
|
31 | Exclusive(VideoMode),
| ^^^^^^^^^ not found in this scope
|
help: consider importing this struct
|
1 + use crate::monitor::VideoMode;
|
error[E0412]: cannot find type `MonitorHandle` in this scope
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/platform_impl/mod.rs:32:23
|
32 | Borderless(Option<MonitorHandle>),
| ^^^^^^^^^^^^^
|
::: /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/monitor.rs:103:1
|
103 | pub struct MonitorHandle {
| ------------------------ similarly named struct `RootMonitorHandle` defined here
|
help: a struct with a similar name exists
|
32 | Borderless(Option<RootMonitorHandle>),
| ~~~~~~~~~~~~~~~~~
help: consider importing this struct
|
1 + use crate::monitor::MonitorHandle;
|
error[E0412]: cannot find type `Window` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:55:39
|
55 | pub(crate) window: platform_impl::Window,
| ^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `WindowId` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:85:47
|
85 | pub struct WindowId(pub(crate) platform_impl::WindowId);
| ^^^^^^^^ not found in `platform_impl`
error[E0412]: cannot find type `PlatformSpecificWindowBuilderAttributes` in module `platform_impl`
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:123:50
|
123 | pub(crate) platform_specific: platform_impl::PlatformSpecificWindowBuilderAttributes,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `platform_impl`
error[E0282]: type annotations needed
--> /home/dbuch/.cargo/registry/src/index.crates.io-6f17d22bba15001f/winit-0.29.4/src/window.rs:537:17
|
537 | builder.build(event_loop)
| ^^^^^ cannot infer type of the type parameter `T` declared on the method `build`
|
help: consider specifying the generic argument
|
537 | builder.build::<T>(event_loop)
| +++++
Some errors have detailed explanations: E0282, E0412, E0432, E0433.
For more information about an error, try `rustc --explain E0282`.
error: could not compile `winit` (lib) due to 23 previous errors
~/dev/rust/egui ❯ [add-missing-resizedirection ≡]
```
The comment added in commit 8a0bc97e ("[egui_glium] Fix paste") seems to
assume that `winit` "should have translated" common "paste" keyboard
combos to a `Cut`/`Copy`/`Paste` "KeyCode", but completely glossed over
the fact that this `KeyCode` (now also `NamedKey`) maps to a special key
dedicated to this purpose found on some keyboards and OSes. Make sure
that this key is still handled in addition to the combo that is
detected.
---
Note that this PR does not compile as it is (and I have hence not tested
this nor even ran into this limitation), just noticed this inconsistency
while failing to understand a code comment. We'd have to decide if the
variants should be added to `egui::Key` or if these helper functions
need to take `winit` keys (`ScanCode` or `NamedKey`) directly?
I should have an old keyboard with a physical paste key in a drawer
somewhere. And on Android there are special copy/paste events that can
be sent by a virtual keyboard or the debug shell, so that this can be
properly tested before it is merged.
(Except that the current `clipboard` implementation is not supported on
Android)
This PR fixes an issue where a bad pivot stored in app state would
override the pivot actually set from code. The root code of this issue
if the `Window`'s `State` containing `pivot` in the first place, as
`pivot` is not part of a state to be tracked. It makes the `State`
structure more ergonomic though, so this PR leaves the `pivot` field but
always overrides it with the value provided by user code.
#### Repro of the original issue
This issue can be reproduced using the `re_ui_example` app from the
Rerun repo, at this commit:
fb5add0047.
By using this `app.ron` file, the bug will appear:
```
{
"egui": "(
areas:{
((0)):(
areas:{
(13430889033718688666):(pivot_pos:(x:565.5,y:328.0),pivot:((Min,Min)),size:(x:364.0,y:75.5),interactable:true),
},
)
}
)",
}
```
The modal is entered based on it's top-left corner even though the code
actually specifies a center-center pivot:
<img width="1312" alt="image"
src="https://github.com/emilk/egui/assets/49431240/6df1a8bb-d1ea-4e15-866c-5f14138dda0e">
With this PR, the centring is correct even with the "poisoned"
`app.ron`:
<img width="1312" alt="image"
src="https://github.com/emilk/egui/assets/49431240/7f50b2d4-9245-48f3-91de-c747bbc8c40e">
This introduces a special `Color32::PLACEHOLDER` which, during text
painting, will be replaced with `TextShape::fallback_color`.
The fallback color is mandatory to set in all text painting. Usually
this comes from the current visual style.
This lets users color only parts of a `WidgetText` (using e.g. a
`LayoutJob` or a `Galley`), where the uncolored parts (using
`Color32::PLACEHOLDER`) will be replaced by a default widget color (e.g.
blue for a hyperlink).
For instance, you can color the `⚠️`-emoji red in a piece of text red
and leave the rest of the text uncolored. The color of the rest of the
text will then depend on wether or not you put that text in a label, a
button, or a hyperlink.
Overall this simplifies a lot of complexity in the code but comes with a
few breaking changes:
* `TextShape::new`, `Shape::galley`, and `Painter::galley` now take a
fallback color by argument
* `Shape::galley_with_color` has been deprecated (use `Shape::galley`
instead)
* `Painter::galley_with_color` has been deprecated (use
`Painter::galley` instead)
* `WidgetTextGalley` is gone (use `Arc<Galley>` instead)
* `WidgetTextJob` is gone (use `LayoutJob` instead)
* `RichText::into_text_job` has been replaced with
`RichText::into_layout_job`
* `WidgetText::into_text_job` has been replaced with
`WidgetText::into_layout_job`
Update `resvg` from v0.28 to v0.37.
Remove related, unnecessary entries from `deny.toml`.
⚠ In example `images` ferris is scaled differently, but I guess that now
it scales in expected way (takes all available space; before this PR it
takes up to space that, was available at first render- it does not
upscale).
This PR is minimal adaptation to new `resvg` api and small related
simplification, however it should be considered to update loaders
(currently if svg image initially was small and was scaled up it will be
blurred, see https://github.com/emilk/egui/issues/3501). As svg image
now scales over render size, problem will be more often seen now.
(currently `SvgLoader` theoretically should rerender for different sizes
(but I guess it will result in memory leak in that case), but refreshing
is stopped earlier in `DefaultTextureLoader`).
I have initial version of loaders update, that will fix issue with svg
scaling (and also enable e.g. reloading image if file has been changed),
I will submit these changes in separate PR once this one is merged.
Closes <https://github.com/emilk/egui/issues/3652>.
<!--
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.
* 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!
-->
This is a very simple change so you don't have to do this:
https://github.com/zeozeozeo/egui-keybind/blob/master/src/bind.rs#L149-L172
It required some ugly code in `egui-winit` in order to fix this without
breaking sem-ver (I want this to land in a 0.24.1 patch release). I'll
clean up in time for 0.25.
There is still a font rendering bug when using immediate viewports
across multiple viewports, but that's harder to fix.
We were using [`tts`](https://github.com/ndarilek/tts-rs) for the
web-only screen reader. This was overkill, to say the least. It is now
replaced with ten lines of `web-sys` calls.
* Closes https://github.com/emilk/egui/issues/3602
You can now zoom any egui app by pressing Cmd+Plus, Cmd+Minus or Cmd+0,
just like in a browser. This will change the current `zoom_factor`
(default 1.0) which is persisted in the egui memory, and is the same for
all viewports.
You can turn off the keyboard shortcuts with `ctx.options_mut(|o|
o.zoom_with_keyboard = false);`
`zoom_factor` can also be explicitly read/written with
`ctx.zoom_factor()` and `ctx.set_zoom_factor()`.
This redefines `pixels_per_point` as `zoom_factor *
native_pixels_per_point`, where `native_pixels_per_point` is whatever is
the native scale factor for the monitor that the current viewport is in.
This adds some complexity to the interaction with winit, since we need
to know the current `zoom_factor` in a lot of places, because all egui
IO is done in ui points. I'm pretty sure this PR fixes a bunch of subtle
bugs though that used to be in this code.
`egui::gui_zoom::zoom_with_keyboard_shortcuts` is now gone, and is no
longer needed, as this is now the default behavior.
`Context::set_pixels_per_point` is still there, but it is recommended
you use `Context::set_zoom_factor` instead.
* Closes#1974
<!--
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.
* 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 you PR, but my time is limited!
-->
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
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.
* 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!
-->
Closes <https://github.com/emilk/egui/issues/3576>.
Introduced in the recent multi-viewports work, we accidentally recreated
the wgpu surfaces every frame. This is now fixed.
I found this while improving the profiling of `eframe`
* Part of https://github.com/emilk/egui/issues/3556
This PR replaces a bunch of options in `eframe::NativeOptions` with
`egui::ViewportBuilder`. For instance:
``` diff
let options = eframe::NativeOptions {
- initial_window_size: Some(egui::vec2(320.0, 240.0)),
- drag_and_drop_support: true,
+ viewport: egui::ViewportBuilder::default()
+ .with_inner_size([320.0, 240.0])
+ .with_drag_and_drop(true),
centered: true,
..Default::default()
};
```
* Part of https://github.com/emilk/egui/issues/3556
## In short
You now almost never need to use `eframe::Frame` - instead use
`ui.input(|i| i.viewport())` for information about the current viewport
(native window), and use `ctx.send_viewport_cmd` to modify it.
## In detail
This PR removes most commands from `eframe::Frame`, and replaces them
with `ViewportCommand`.
So `frame.close()` becomes
`ctx.send_viewport_cmd(ViewportCommand::Close)`, etc.
`frame.info().window_info` is now also gone, replaced with `ui.input(|i|
i.viewport())`.
`frame.info().native_pixels_per_point` is replaced with `ui.input(|i|
i.raw.native_pixels_per_point)`.
`RawInput` now contains one `ViewportInfo` for each viewport.
Screenshots are taken with
`ctx.send_viewport_cmd(ViewportCommand::Screenshots)` and are returned
in `egui::Event` which you can check with:
``` ust
ui.input(|i| {
for event in &i.raw.events {
if let egui::Event::Screenshot { viewport_id, image } = event {
// handle it here
}
}
});
```
### Motivation
You no longer need to pass around the `&eframe::Frame` everywhere.
This also opens the door for other integrations to use the same API of
`ViewportCommand`s.
<!--
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.
* 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!
-->
Closes <https://github.com/emilk/egui/issues/3474>.
Was a bit confused why the max_size API isn't exposed on `Window`, when
it's perfectly functional in `Resize`. Anyway here's the main thing that
it affects:
```rs
let screen = ctx.available_rect();
let size = screen.size();
egui::Window::new(self.name())
.resizable(true)
.resize(|resize| resize.max_size(size)) // Before
.max_size(size) // After
.show(ctx, |ui| todo!());
```
I also added some other relevant helpers for consistency.
This PR doesn't change any logic, only forwards along some helper
functions that are already public for consistency.
* 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>
Emil Ernerfeldt
Varphone Wong
rustbasic
Arnold Loubriat
Antoine Beyeler
Georg Weisert
0Qwel
Mike Tsao
Giantblargg
vincent-sparks
Francis Chua
YgorSouza
bu5hm4nn
Oscar Gustafsson
AnotherNathan
Dan Lock
Aufar Zakiev
Bruno
lucasmerlin
hinto-janai
Mike Krüger
untbu
LoganDark
Fleabit
Guillaume Schmid
Danny Stoll
Ivan
Fredrik Fornwall
Frank Lee
Daniel Buch Hansen
Marijn Suijten
Wybe Westra
PingPongun
zeozeozeo
Brian Janssen
libertyteeth
Zach Bateman
arduano
Konkitoman
