<!--
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!
-->
* [X] I have followed the instructions in the PR template
I am preparing a separate PR that adds support for JXL with `jxl-oxide`,
which is unlikely to be added to the `image` crate anytime soon (more
context will be provided in that PR).
`jxl-oxide` makes use of the
[`array::each_mut`](https://doc.rust-lang.org/stable/std/primitive.array.html#method.each_mut)
API which was stabilized in 1.77, which is the motivation for this MSRV
bump.
Rust 1.77 was officially released to stable on 21 March, 2024.
- closes#3491
- closes#3926
This adds a testing library to egui based on
[kittest](https://github.com/rerun-io/kittest). Kittest is a new
[AccessKit](https://github.com/AccessKit/accesskit/)-based testing
library. The api is inspired by the js
[testing-library](https://testing-library.com/) where the idea is also
to query the dom based on accessibility attributes.
We made kittest with egui in mind but it should work with any rust gui
framework with AccessKit support.
It currently has support for:
- running the egui app, frame by frame
- building the AccessKit tree
- ergonomic queries via kittest
- via e.g. get_by_name, get_by_role
- simulating events based on the accesskit node id
- creating arbitrary events based on Harness::input_mut
- rendering screenshots via wgpu
- snapshot tests with these screenshots
A simple test looks like this:
```rust
fn main() {
let mut checked = false;
let app = |ctx: &Context| {
CentralPanel::default().show(ctx, |ui| {
ui.checkbox(&mut checked, "Check me!");
});
};
let mut harness = Harness::builder().with_size(egui::Vec2::new(200.0, 100.0)).build(app);
let checkbox = harness.get_by_name("Check me!");
assert_eq!(checkbox.toggled(), Some(Toggled::False));
checkbox.click();
harness.run();
let checkbox = harness.get_by_name("Check me!");
assert_eq!(checkbox.toggled(), Some(Toggled::True));
// You can even render the ui and do image snapshot tests
#[cfg(all(feature = "wgpu", feature = "snapshot"))]
egui_kittest::image_snapshot(&egui_kittest::wgpu::TestRenderer::new().render(&harness), "readme_example");
}
```
~Since getting wgpu to run in ci is a hassle, I'm taking another shot at
creating a software renderer for egui (ideally without a huge dependency
like skia)~ (this didn't work as well as I hoped and it turns out in CI
you can just run tests on a mac runner which comes with a real GPU)
Here is a example of a failed snapshot test in ci, it will say which
snapshot failed and upload an artifact with the before / after and diff
images:
https://github.com/emilk/egui/actions/runs/11183049487/job/31090724606?pr=5166
This adds preview deployments that will deploy a version of
egui_demo_app for each pull request, making things easier to review /
test.
Some notes on security:
The preview deployment is split in two workflows, preview_build and
preview_deploy.
`preview_build` runs on pull_request, so it won't have any access to the
repositories secrets, so it is safe to
build / execute untrusted code.
`preview_deploy` has access to the repositories secrets (so it can push
to the pr preview repo) but won't run
any untrusted code (it will just extract the build artifact and push it
to the pages branch where it will
automatically be deployed).
To set this up, a DEPLOY_KEY secret needs to be added, which allows the
action to push the compiled artifacts into this repository:
https://github.com/egui-pr-preview/pr
The deploy key is the private key part of a key generated via
ssh-keygen. The public key is set as a deploy key in that repo.
I have created the repo on a separate github org, so it won't be
directly associated with emil or egui in case someone pushes something
naughty.
I have set this up in my fork of egui to show how this works:
- I created a PR: https://github.com/lucasmerlin/egui/pull/2
- The code will be compiled and pushed to the egui-pr-preview/pr repo
and deployed via github pages
- The bot leaves a comment on the pr with a link to the preview
- The preview is available at
https://egui-pr-preview.github.io/pr/2-pr-preview-demo/
(It's unfortunately only available a couple seconds after the bot writes
the comment, because the pages deployment action is run independently on
the other repository)
- Once the PR is merged / closed the preview will be cleaned up
(unfortunately the empty folder will remain, it seems like it's not
possible to remove that via the JamesIves/github-pages-deploy-action
action I use, but I don't think that it's a big issue)
I'll leave the PR in draft until the DEPLOY_KEY is set up
Note this will break people depending on eframe or egui-wgpu with
--no-default-features.
I don't know what to do about that to be honest.
* Closes#4914
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Andreas Reich <r_andreas2@web.de>
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
This PR
- adds a pipeline to check the ios build
- removes the iOS WaitUntil workaround, which doesn't seem to be
necessary anymore after the winit update (and caused the build for iOS
to fail again because of a missing self
- ~removes a iOS workaround for window size which doesn't seem necessary
anymore~
Turns out it was still needed (but you need to actually restart the app
for the issue to show up, so I didn't catch it first)
- fixes some cargo check errors in run.rs
I've done all these changes in a single PR because otherwise the
pipeline doesn't run but I can also split them in separate PRs if that
makes it easier to review
This allows license checking tools to omit the OFL and UFL licenses when
`default_fonts` are turned off.
There was some discussion of versioning on the original issue; I have
chosen to label this version as `0.28.1` to match the other crates.
Happy to adjust the version as needed.
<!--
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 <https://github.com/emilk/egui/issues/2321>
* [X] I have followed the instructions in the PR template
---------
Co-authored-by: Alex Pinkus <pinkus@amazon.com>
0.20 has a bunch of bugs that will be fixed by:
* https://github.com/gfx-rs/wgpu/pull/5681
At Rerun, we don't want to wait for the wgpu 0.20.1 patch release before
we update egui, so we will temporarily downgrade to wgpu 0.19
After reverting I'll open a new PR that will update to 0.20 again, with
the intention of merging that once 0.20.1 is released.
updates the wgpu version to 0.20 and changes the API calls accordingly.
I had to update wasm-bindgen to "0.2.92". Otherwise, I got this error
for the demo app:
```
error: failed to select a version for `wasm-bindgen`.
... required by package `js-sys v0.3.69`
... which satisfies dependency `js-sys = "^0.3.69"` of package `eframe v0.27.2 (/home/user/Projects/egui/crates/eframe)`
... which satisfies path dependency `eframe` (locked to 0.27.2) of package `confirm_exit v0.1.0 (/home/user/Projects/egui/examples/confirm_exit)`
versions that meet the requirements `^0.2.92` are: 0.2.92
all possible versions conflict with previously selected packages.
previously selected package `wasm-bindgen v0.2.90`
... which satisfies dependency `wasm-bindgen = "=0.2.90"` of package `egui_demo_app v0.27.2 (/home/user/Projects/egui/crates/egui_demo_app)`
failed to select a version for `wasm-bindgen` which could resolve this conflict
```
Why is it locked to this version right now?
I ran the tests, checked the web demo and my own projects, and
everything seems to work fine with wgpu 0.20.
---------
Co-authored-by: Andreas Reich <r_andreas2@web.de>
Motivation: I want to replace `cargo-cranky` with workspace lints, first
available in Rust 1.74.
However, `cargo doc` would hange on `wgpu` and `wgpu-core` on 1.74 and
1.75… so now we're on 1.76.
I think this is fine - when 1.78 is released next week we're still two
versions behind the bleeding edge.
…and the branch name is just wrong 🤦
The goal is to host the egui web-demo on its own `gh-pages` branch, and
have the CI build and publish a new demo on each merged CI.
Let's see if I can get this to work…
* eframe README: explain how to enable copy/paste
* Implement Debug for a couple of structs
* Code cleanup
* Better docs
* profile ron serialization
* CI: Allow "exclude from changelog" as the only label
* Add syntax highlighing feature to egui_extras
Enable "syntect" feature for great syntax highlighting of any language.
If not a simple fallback is used that works fine for C++, Rust, Python
* Check --no-default-features of egui_extras on CI
* spelling
* Fix building egui_extras without additional features
The following updates are performed:
* update actions/checkout to v3
* replace unmaintained actions-rs/toolchain by dtolnay/rust-toolchain
* replace unmaintained actions-rs/cargo by direct invocation of cargo
* Refactor repaint logic
* request_repaint_after also fires the request_repaint callback
* Bug fixes
* Add test to egui_demo_app
* build_demo_web: build debug unless --release is specified
* Fix the web backend too
* Run special clippy for wasm, forbidding some types/methods
* Remove wasm_bindgen_check.sh
* Fix typos
* Revert "Remove wasm_bindgen_check.sh"
This reverts commit 92dde25344.
* Only run cranky/clippy once
Instead of depending on android-activity directly, this exposes the
android-native-activity and android-game-activity features from Winit.
This ensures that applications can choose what android-backend they use
while also relying on Winit to decide what version of android-activity to
use - without increasing the risk of a version conflict by having a direct
dependency.
_(NB: Egui doesn't currently use the android-activity API itself)_
Since android-activity provides the `android_main()` entry point for
Android applications it's not possible to link in multiple version of
the android-activity crate and so it's particularly important to
avoid unnecessary direct dependencies that could cause a version
conflict in the future.
To help avoid the need for applications to directly depend on
android-activity the Winit crate re-exports the android-activity API
and exposes features to configure the backend so that application crates
can instead rely on Winit to pull in a compatible version of
android-activity. (This way version bumps for android-activity only
need to be synchronized with the Winit crate).
CI now enables the `android-native-activity` feature for testing.
Fixes: #2829Fixes: #2720Closes: #2834
