1
0
mirror of https://github.com/emilk/egui.git synced 2026-08-30 21:30:03 -04:00

Remove egui_web and epi (#1545)

* Remove integration name (it is always eframe)

* Remove egui_web crate

* Move egui_web/CHANGELOG.md into eframe/CHANGELOG.md

* Remove all mentions of egui_web

* Remove epi crate and absorb into eframe

* egui_glow: only use puffin on native

* Remove WASM doc from CI (we don't generate it anyways!)

* Remove eframe::epi and improve eframe docs
This commit is contained in:
Emil Ernerfeldt
2022-04-30 10:44:35 +02:00
committed by GitHub
parent 18d529203a
commit bb421c7e8a
41 changed files with 244 additions and 447 deletions

View File

@@ -17,9 +17,7 @@ For how to use `egui`, see [the egui docs](https://docs.rs/egui).
---
`eframe` is a very thin crate that re-exports [`egui`](https://github.com/emilk/egui) and[`epi`](https://github.com/emilk/egui/tree/master/epi) with thin wrappers over the backends.
`eframe` uses [`egui_web`](https://github.com/emilk/egui/tree/master/egui_web) for web and [`egui_glow`](https://github.com/emilk/egui/tree/master/egui_glow) for native.
`eframe` uses [`egui_glow`](https://github.com/emilk/egui/tree/master/egui_glow) for rendering, and on native it uses [`egui-winit`](https://github.com/emilk/egui/tree/master/egui-winit).
To use on Linux, first run:
@@ -34,6 +32,22 @@ You need to either use `edition = "2021"`, or set `resolver = "2"` in the `[work
`eframe` is not the only way to write an app using `egui`! You can also try [`egui-miniquad`](https://github.com/not-fl3/egui-miniquad), [`bevy_egui`](https://github.com/mvlabat/bevy_egui), [`egui_sdl2_gl`](https://github.com/ArjunNair/egui_sdl2_gl), and others.
## Problems with running egui on the web
`eframe` uses WebGL (via [`glow`](https://crates.io/crates/glow)) and WASM, and almost nothing else from the web tech stack. This has some benefits, but also produces some challenges and serious downsides.
* Rendering: Getting pixel-perfect rendering right on the web is very difficult.
* Search: you cannot search an egui web page like you would a normal web page.
* Bringing up an on-screen keyboard on mobile: there is no JS function to do this, so `eframe` fakes it by adding some invisible DOM elements. It doesn't always work.
* Mobile text editing is not as good as for a normal web app.
* Accessibility: There is an experimental screen reader for `eframe`, but it has to be enabled explicitly. There is no JS function to ask "Does the user want a screen reader?" (and there should probably not be such a function, due to user tracking/integrity concerns).
* No integration with browser settings for colors and fonts.
* On Linux and Mac, Firefox will copy the WebGL render target from GPU, to CPU and then back again (https://bugzilla.mozilla.org/show_bug.cgi?id=1010527#c0), slowing down egui.
In many ways, `eframe` is trying to make the browser do something it wasn't designed to do (though there are many things browser vendors could do to improve how well libraries like egui work).
The suggested use for `eframe` are for web apps where performance and responsiveness are more important than accessibility and mobile text editing.
## Companion crates
Not all rust crates work when compiled to WASM, but here are some useful crates have been designed to work well both natively and as WASM:
@@ -44,5 +58,4 @@ Not all rust crates work when compiled to WASM, but here are some useful crates
## Name
The _frame_ in `eframe` stands both for the frame in which your `egui` app resides and also for "framework" (`frame` is a framework, `egui` is a library).