egui/crates/eframe
Matt Campbell e1f348e4b2
Implement accessibility APIs via AccessKit (#2294)
* squash before rebase

* Update AccessKit, introducing support for editable spinners on Windows and an important fix for navigation order on macOS

* Restore support for increment and decrement actions in DragValue

* Avoid VoiceOver race condition bug

* fix clippy lint

* Tell AccessKit that the default action for a text edit (equivalent to a click) is to set the focus. This matters to some platform adapters.

* Refactor InputState functions for AccessKit actions

* Support the AccessKit SetValue for DragValue; this is the only way for a Windows AT to programmatically adjust the value

* Same for Slider

* Properly associate the slider label with both the slider and the drag value

* Lazily activate egui's AccessKit support

* fix clippy lint

* Update AccessKit

* More documentation, particularly around lazy activation

* Tweak one of the doc comments

* See if I can get AccessKit exempted from the 'missing backticks' lint

* Make PlatformOutput::accesskit_update an Option

* Refactor lazy activation

* Refactor node mutation (again)

* Eliminate the need for an explicit is_accesskit_active method, at least for now

* Fix doc comment

* More refactoring of tree construction; don't depend on Arc::get_mut

* Override a clippy lint; I seem to have no other choice

* Final planned refactor: a more flexible approach to hierarchy

* Last AccessKit update for this PR; includes an important macOS DPI fix

* Move and document the optional accesskit dependency

* Fix comment typo

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>

* reformat

* More elegant code for conditionally creating a node

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>

* Set step to 1.0 for all integer sliders

* Add doc example for Response::labelled_by

* Clarify a TODO comment I left for myself

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
2022-12-04 19:17:12 +01:00
..
src Implement accessibility APIs via AccessKit (#2294) 2022-12-04 19:17:12 +01:00
Cargo.toml Implement accessibility APIs via AccessKit (#2294) 2022-12-04 19:17:12 +01:00
CHANGELOG.md Implement accessibility APIs via AccessKit (#2294) 2022-12-04 19:17:12 +01:00
README.md Fix broken GitHub source links due to #1940 2022-08-20 15:18:02 +02:00

eframe: the egui framework

Latest version Documentation unsafe forbidden MIT Apache

eframe is the official framework library for writing apps using egui. The app can be compiled both to run natively (cross platform) or be compiled to a web app (using WASM).

To get started, see the examples. To learn how to set up eframe for web and native, go to https://github.com/emilk/eframe_template/ and follow the instructions there!

There is also a tutorial video at https://www.youtube.com/watch?v=NtUkr_z7l84.

For how to use egui, see the egui docs.


eframe uses egui_glow for rendering, and on native it uses egui-winit.

To use on Linux, first run:

sudo apt-get install libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev libspeechd-dev libxkbcommon-dev libssl-dev

You need to either use edition = "2021", or set resolver = "2" in the [workspace] section of your to-level Cargo.toml. See this link for more info.

You can opt-in to the using egui_wgpu for rendering by enabling the wgpu feature and setting NativeOptions::renderer to Renderer::Wgpu.

Alternatives

eframe is not the only way to write an app using egui! You can also try egui-miniquad, bevy_egui, egui_sdl2_gl, and others.

You can also use egui_glow and winit to build your own app as demonstrated in https://github.com/emilk/egui/blob/master/crates/egui_glow/examples/pure_glow.rs.

Problems with running egui on the web

eframe uses WebGL (via 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:

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).