winit::Window::inner_size returns size of safe area on iOS. use
winit::Window::outer_size on iOS
The dimensions of outer_size include the title bar and borders, but as
far as I know there is no way to actually display the title bar or
borders on iOS so it should be fine.
<!--
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!
-->
* Closes#3547
* [X] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Closes https://github.com/emilk/egui/issues/4976
* Part of #4378
* Implements parts of #843
### Background
Some widgets (like `Grid` and `Table`) needs to know the width of future
elements in order to properly size themselves. For instance, the width
of the first column of a grid may not be known until all rows of the
grid has been added, at which point it is too late. Therefore these
widgets store sizes from the previous frame. This leads to "first-frame
jitter", were the content is placed in the wrong place for one frame,
before being accurately laid out in subsequent frames.
### What
This PR adds the function `ctx.request_discard` which discards the
visual output and does another _pass_, i.e. calls the whole app UI code
once again (in eframe this means calling `App::update` again). This will
thus discard the shapes produced by the wrongly placed widgets, and
replace it with new shapes. Note that only the visual output is
discarded - all other output events are accumulated.
Calling `ctx.request_discard` should only be done in very rare
circumstances, e.g. when a `Grid` is first shown. Calling it every frame
will mean the UI code will become unnecessarily slow.
Two safe-guards are in place:
* `Options::max_passes` is by default 2, meaning egui will never do more
than 2 passes even if `request_discard` is called on every pass
* If multiple passes is done for multiple frames in a row, a warning
will be printed on the screen in debug builds:

### Breaking changes
A bunch of things that had "frame" in the name now has "pass" in them
instead:
* Functions called `begin_frame` and `end_frame` are now called
`begin_pass` and `end_pass`
* `FrameState` is now `PassState`
* etc
### TODO
* [x] Figure out good names for everything (`ctx.request_discard`)
* [x] Add API to query if we're gonna repeat this frame (to early-out
from expensive rendering)
* [x] Clear up naming confusion (pass vs frame) e.g. for `FrameState`
* [x] Figure out when to call this
* [x] Show warning on screen when there are several frames in a row with
multiple passes
* [x] Document
* [x] Default on or off?
* [x] Change `Context::frame_nr` name/docs
* [x] Rename `Context::begin_frame/end_frame` and deprecate the old ones
* [x] Test with Rerun
* [x] Document breaking changes
<!--
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!
-->
I removed (I hope so) all wildcard imports I found.
For me on my pc this improved the build time:
- for egui -5s
- for eframe -12s
* [x] I have followed the instructions in the PR template
* 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>
Fix: Changed the handling method of `Ime::Preedit(_, None)`
Fix: backspace fail after ime input
* Related #4358
* Related #4430
* Related #4436
* Related #4794
* Related #4896
* Closes#4908
Issues: backspace fail after ime input
* #4908 (Chinese)
Changed the handling method of `Ime::Preedit(_, None)`
* 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>
* Part of https://github.com/emilk/egui/issues/3653
<!--
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!
-->
It was surprising to me that this key wasn't sending `Event::Key` events
(only `Event::Text`), so I added a `Key` for it.
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 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
resolves https://github.com/emilk/egui/issues/4081 (see discussion
starting from
https://github.com/emilk/egui/issues/3653#issuecomment-1962740175 for
extra context)
this partly restores event-emitting behaviour to the state before #3649,
when shortcuts such as `Ctrl` + `C` used to work regardless of the
active layout. the difference is that physical keys are only used in
case of the logical ones' absence now among the named keys.
while originally I have only limited this to clipboard shortcuts
(Ctrl+C/V/X), honestly it felt like a half-assed solution. as a result,
I decided to expand this behaviour to all key events to stick to the
original logic, in case there are other workflows and hotkeys people
rely on or expect to work out of the box. let me know if this is an
issue.
Added clamp_size_to_monitor_size field on ViewportBuilder, which means
whether clamp the window's size to monitor's size. (default to `true`)
* Closes https://github.com/emilk/egui/issues/3389
### simple example
```rust
pub struct MyApp {}
impl MyApp {
pub fn new() -> MyApp {
MyApp {}
}
}
impl eframe::App for MyApp {
fn update(&mut self, ctx: &Context, frame: &mut eframe::Frame) {
egui::CentralPanel::default()
.frame(Frame::none().fill(Color32::DARK_GRAY))
.show(ctx, |ui| {
if ctx.input(|i| i.key_pressed(Key::Escape)) {
ctx.send_viewport_cmd(ViewportCommand::Close);
}
});
}
}
pub fn main() {
let option = eframe::NativeOptions {
viewport: ViewportBuilder::default()
.with_position([10.0, 10.0])
.with_inner_size([3000.0, 2000.0])
.with_clamp_size_to_monitor_size(false),
..Default::default()
};
eframe::run_native(
"a large window app",
option,
Box::new(|ctx| Box::new(MyApp::new())),
).unwrap();
}
```
It works on my windows (with 3 monitors), but I don't have a test
environment for macos
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Closes#4354
Fix: can't repeat input chinese words
AND
For Windows :
ImeEnable
ImeDisable
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
### Motivation
We want to offer our users a context menu with `Cut`, `Copy` and `Paste`
actions. `Paste` is not possible out of the box.
### Changes
This PR adds `ViewportCommand::RequestCut`,
`ViewportCommand::RequestCopy` and `ViewportCommand::RequestPaste`. They
are routed and handled after the example of
`ViewportCommand::Screenshot` and result in the same code being executed
as when the user uses `CTRL+V` style keyboard commands.
### Reasoning
In our last release we used an instance of
`egui_winit:📋:Clipboard` in order to get the `Paste`
functionality.
However Linux users on Wayland complained about broken clipboard
interaction (https://github.com/mikedilger/gossip/issues/617). After a
while of digging I could not find the issue although I have found
references to problems with multiple clipboards per handle before
(https://gitlab.gnome.org/GNOME/mutter/-/issues/1250) but I compared
mutter with weston and the problem occured on both.
So to solve this I set out to extend egui to access the clipboard
instance already present in egui_winit. Since there was no trivial way
to reach the instance of `egui_winit::State` I felt the best approach
was to follow the logic of the new `ViewportCommand::Screenshot`.
### Variations
It could make sense to make the introduced `enum ActionRequested` a part
of crates/egui/src/viewport.rs and to then wrap them into one single
`ViewportCommand::ActionRequest(ActionRequested)`.
### Example
```Rust
let mut text = String::new();
let response = ui.text_edit_singleline(&mut text);
if ui.button("Paste").clicked() {
response.request_focus();
ui.ctx().send_viewport_cmd(ViewportCommand::RequestPaste);
}
```
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* Closes#4254
Changes egui-winit so that it calls `window.set_ime_cursor_area` when
the IME rect changes or the user interacts with the application instead
of calling it every time the app is rendered. This works around a winit
bug that causes the app to continuously repaint under certain
circumstances on Wayland.
Tested on Wayland and on X11 using the text edit in the egui_demo_app -
no changes in IME functionality as far as I can tell. Untested on
non-Linux platforms.
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Not sure about the api, currently I've mapped the whole XWindowType
enum, but maybe there's something more sensible to do?
* Closes <https://github.com/emilk/egui/issues/4150>
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
I believe that the underlying issue that caused the stuck modifier keys
was resolved in the 0.29 winit keyboard refactor.
This probably needs to tested on other desktop platforms however since I
am only able to test this on windows 11.
* Closes <https://github.com/emilk/egui/issues/2332>
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
<!--
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.
The `egui_winit::State` contains both the `clipboard` and `allow_ime`,
but these are both private fields. In our implementation we use
`egui_winit` to do most of the lifting, but it would come really in
handy if we could access these values.
Instead of making the fields `pub` we opted for separate get/set
functions, that way calling side can't freely replace any of the values
fully and it's more in line with the style of the rest of the codebase.
---------
Co-authored-by: Marijn Suijten <marijn@traverseresearch.nl>
Co-authored-by: Marijn Suijten <marijns95@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!
-->
This breaking change seems to have snuck in during #3649. Previously it
would never consume these, today it consumes them unconditionally, and
with this change it'll ~~only consume them if egui wants text input~~
never consume them.
This is a blocker for updating our application, sadly :(
* 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.
<!--
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)
<!--
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!
-->
Since accesskit_winit version 0.15.0, it is necessary to call
`Adapter::process_events` to let AccessKit fire up window focus events
on Unix and macOS. Furthermore this has always been needed on Unix (X11
only) to let AccessKit know about the window bounds, which is needed to
perform hit-testing on nodes.
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.
This appears to have been 'consumed' by the viewport changes at one
point (by updating `viewport_info`), but this is no longer the case. We
should avoid marking this as 'consumed', so that applications know to
continue processing this event after passing it to egui.
<!--
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!
-->