egui: an easy-to-use immediate mode GUI in pure Rust

Last update: May 24, 2022

πŸ–Œ egui: an easy-to-use GUI in pure Rust

github Latest version Documentation unsafe forbidden Build Status MIT Apache

egui is a simple, fast, and highly portable immediate mode GUI library for Rust. egui runs on the web, natively, and in your favorite game engine (or will soon).

egui aims to be the easiest-to-use Rust GUI library, and the simplest way to make a web app in Rust.

egui can be used anywhere you can draw textured triangles, which means you can easily integrate it into your game engine of choice.

Sections:

Quick start

If you just want to write a GUI application in Rust (for the web or for native), go to https://github.com/emilk/eframe_template/ and follow the instructions there!

If you want to integrate egui into an existing engine, go to the Integrations section.

If you have questions, use Discussions. If you want to contribute to egui, please read the Contributing Guidelines

Demo

Click to run egui web demo (works in any browser with WASM and WebGL support). Uses egui_web.

To test the demo app locally, run cargo run --release -p egui_demo_app.

The native backend is egui_glium (using glium) and should work out-of-the-box on Mac and Windows, but on Linux you need to first run:

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

On Fedora Rawhide you need to run:

dnf install clang clang-devel clang-tools-extra speech-dispatcher-devel libxkbcommon-devel pkg-config openssl-devel

NOTE: This is just for the demo app - egui itself is completely platform agnostic!

Example

ui.heading("My egui Application");
ui.horizontal(|ui| {
    ui.label("Your name: ");
    ui.text_edit_singleline(&mut name);
});
ui.add(egui::Slider::new(&mut age, 0..=120).text("age"));
if ui.button("Click each year").clicked() {
    age += 1;
}
ui.label(format!("Hello '{}', age {}", name, age));

Goals

  • The easiest to use GUI library
  • Responsive: target 60 Hz in debug build
  • Friendly: difficult to make mistakes, and shouldn't panic
  • Portable: the same code works on the web and as a native app
  • Easy to integrate into any environment
  • A simple 2D graphics API for custom painting (epaint).
  • No callbacks
  • Pure immediate mode
  • Extensible: easy to write your own widgets for egui
  • Modular: You should be able to use small parts of egui and combine them in new ways
  • Safe: there is no unsafe code in egui
  • Minimal dependencies: ab_glyph ahash atomic_refcell, nohash-hasher

egui is not a framework. egui is a library you call into, not an environment you program for.

NOTE: egui does not claim to have reached all these goals yet! egui is still work in progress.

Non-goals

  • Become the most powerful GUI library
  • Native looking interface
  • Advanced and flexible layouts (that's fundamentally incompatible with immediate mode)

Who is egui for?

egui aims to be the best choice when you want a simple way to create a GUI, or you want to add a GUI to a game engine.

If you are not using Rust, egui is not for you. If you want a GUI that looks native, egui is not for you. If you want something that doesn't break when you upgrade it, egui isn't for you (yet).

But if you are writing something interactive in Rust that needs a simple GUI, egui may be for you.

egui vs Dear ImGui

The obvious alternative to egui is imgui-rs, the Rust wrapper around the C++ library Dear ImGui. Dear ImGui is a great library (and the main inspiration for egui), with a lot more features and polish. However, egui provides some benefits for Rust users:

  • egui is pure Rust
  • egui is easily compiled to WASM
  • egui lets you use native Rust string types (imgui-rs forces you to use annoying macros and wrappers for zero-terminated strings)
  • Writing your own widgets in egui is simple

egui also tries to improve your experience in other small ways:

  • Windows are automatically sized based on their contents
  • Windows are automatically positioned to not overlap with each other
  • Some subtle animations make egui come alive

So in summary:

  • egui: pure Rust, new, exciting, work in progress
  • Dear ImGui: feature rich, well tested, cumbersome Rust integration

State

egui is in active development. It works well for what it does, but it lacks many features and the interfaces are still in flux. New releases will have breaking changes.

Features

  • Widgets: label, text button, hyperlink, checkbox, radio button, slider, draggable value, text editing, combo box, color picker
  • Layouts: horizontal, vertical, columns, automatic wrapping
  • Text editing: multiline, copy/paste, undo, emoji supports
  • Windows: move, resize, name, minimize and close. Automatically sized and positioned.
  • Regions: resizing, vertical scrolling, collapsing headers (sections)
  • Rendering: Anti-aliased rendering of lines, circles, text and convex polygons.
  • Tooltips on hover
  • More

Light Theme:

How it works

Loop:

  • Gather input (mouse, touches, keyboard, screen size, etc) and give it to egui
  • Run application code (Immediate Mode GUI)
  • Tell egui to tessellate the frame graphics to a triangle mesh
  • Render the triangle mesh with your favorite graphics API (see OpenGL example) or use eframe, the egui framework crate.

Integrations

egui is build to be easy to integrate into any existing game engine or platform you are working on. egui itself doesn't know or care on what OS it is running or how to render things to the screen - that is the job of the egui integration. The integration needs to do two things:

  • IO: Supply egui with input (mouse position, keyboard presses, …) and handle egui output (cursor changes, copy-paste integration, …).
  • Painting: Render the textured triangles that egui outputs.

Official

There are three official egui integrations made for apps:

If you making an app, consider using eframe, a framework which allows you to write code that works on both the web (egui_web) and native (using egui_glium).

3rd party

Missing an integration for the thing you're working on? Create one, it is easy!

Writing your own egui integration

You need to collect egui::RawInput, paint egui::ClippedMesh:es and handle egui::Output. The basic structure is this:

let mut egui_ctx = egui::CtxRef::default();

// Game loop:
loop {
    let raw_input: egui::RawInput = my_integration.gather_input();
    let (output, shapes) = egui_ctx.run(raw_input, |egui_ctx| {
        my_app.ui(egui_ctx); // add panels, windows and widgets to `egui_ctx` here
    });
    let clipped_meshes = egui_ctx.tessellate(shapes); // create triangles to paint
    my_integration.paint(clipped_meshes);
    my_integration.set_cursor_icon(output.cursor_icon);
    // Also see `egui::Output` for more
}

For a reference OpenGL backend, see the egui_glium painter, the egui_glow painter, or the egui_web WebGL painter.

Debugging your integration

Things look jagged

  • Turn off backface culling.

My text is blurry

  • Make sure you set the proper pixels_per_point in the input to egui.
  • Make sure the texture sampler is not off by half a pixel. Try nearest-neighbor sampler to check.

My windows are too transparent or too dark

  • egui uses premultiplied alpha, so make sure your blending function is (ONE, ONE_MINUS_SRC_ALPHA).
  • Make sure your texture sampler is clamped (GL_CLAMP_TO_EDGE).
  • Use an sRGBA-aware texture if available (e.g. GL_SRGB8_ALPHA8).
    • Otherwise: remember to decode gamma in the fragment shader.
  • Decode the gamma of the incoming vertex colors in your vertex shader.
  • Turn on sRGBA/linear framebuffer if available (GL_FRAMEBUFFER_SRGB).
    • Otherwise: gamma-encode the colors before you write them again.

Why immediate mode

egui is an immediate mode GUI library, as opposed to a retained mode GUI library. The difference between retained mode and immediate mode is best illustrated with the example of a button: In a retained GUI you create a button, add it to some UI and install some on-click handler (callback). The button is retained in the UI, and to change the text on it you need to store some sort of reference to it. By contrast, in immediate mode you show the button and interact with it immediately, and you do so every frame (e.g. 60 times per second). This means there is no need for any on-click handler, nor to store any reference to it. In egui this looks like this: if ui.button("Save file").clicked() { save(file); }.

A more detailed description of immediate mode can be found in the egui docs.

There are advantages and disadvantages to both systems.

The short of it is this: immediate mode GUI libraries are easier to use, but less powerful.

Advantages of immediate mode

Usability

The main advantage of immediate mode is that the application code becomes vastly simpler:

  • You never need to have any on-click handlers and callbacks that disrupts your code flow.
  • You don't have to worry about a lingering callback calling something that is gone.
  • Your GUI code can easily live in a simple function (no need for an object just for the UI).
  • You don't have to worry about app state and GUI state being out-of-sync (i.e. the GUI showing something outdated), because the GUI isn't storing any state - it is showing the latest state immediately.

In other words, a whole lot of code, complexity and bugs are gone, and you can focus your time on something more interesting than writing GUI code.

Disadvantages of immediate mode

Layout

The main disadvantage of immediate mode is it makes layout more difficult. Say you want to show a small dialog window in the center of the screen. To position the window correctly the GUI library must first know the size of it. To know the size of the window the GUI library must first layout the contents of the window. In retained mode this is easy: the GUI library does the window layout, positions the window, then checks for interaction ("was the OK button clicked?").

In immediate mode you run into a paradox: to know the size of the window, we must do the layout, but the layout code also checks for interaction ("was the OK button clicked?") and so it needs to know the window position before showing the window contents. This means we must decide where to show the window before we know its size!

This is a fundamental shortcoming of immediate mode GUIs, and any attempt to resolve it comes with its own downsides.

One workaround is to store the size and use it the next frame. This produces a frame-delay for the correct layout, producing occasional flickering the first frame something shows up. egui does this for some things such as windows and grid layouts.

You can also call the layout code twice (once to get the size, once to do the interaction), but that is not only more expensive, it's also complex to implement, and in some cases twice is not enough. egui never does this.

For "atomic" widgets (e.g. a button) egui knows the size before showing it, so centering buttons, labels etc is possible in egui without any special workarounds.

CPU usage

Since an immediate mode GUI does a full layout each frame, the layout code needs to be quick. If you have a very complex GUI this can tax the CPU. In particular, having a very large UI in a scroll area (with very long scrollback) can be slow, as the content needs to be layed out each frame.

If you design the GUI with this in mind and refrain from huge scroll areas (or only lay out the part that is in view) then the performance hit is generally pretty small. For most cases you can expect egui to take up 1-2 ms per frame, but egui still has a lot of room for optimization (it's not something I've focused on yet). You can also set up egui to only repaint when there is interaction (e.g. mouse movement).

If your GUI is highly interactive, then immediate mode may actually be more performant compared to retained mode. Go to any web page and resize the browser window, and you'll notice that the browser is very slow to do the layout and eats a lot of CPU doing it. Resize a window in egui by contrast, and you'll get smooth 60 FPS at no extra CPU cost.

IDs

There are some GUI state that you want the GUI library to retain, even in an immediate mode library such as egui. This includes position and sizes of windows and how far the user has scrolled in some UI. In these cases you need to provide egui with a seed of a unique identifier (unique within the parent UI). For instance: by default egui uses the window titles as unique IDs to store window positions. If you want two windows with the same name (or one window with a dynamic name) you must provide some other ID source to egui (some unique integer or string).

egui also needs to track which widget is being interacted with (e.g. which slider is being dragged). egui uses unique id:s for this awell, but in this case the IDs are automatically generated, so there is no need for the user to worry about it. In particular, having two buttons with the same name is no problem (this is in contrast with Dear ImGui).

Overall, ID handling is a rare inconvenience, and not a big disadvantage.

FAQ

Also see GitHub Discussions.

Can I use egui with non-latin characters?

Yes! But you need to install your own font (.ttf or .otf) using Context::set_fonts.

Can I customize the look of egui?

Yes! You can customize the colors, spacing and sizes of everything. By default egui comes with a dark and a light theme.

What about accessibility, such as screen readers?

There is experimental support for a screen reader. In the web demo you can enable it in the "Backend" tab.

Read more at https://github.com/emilk/egui/issues/167.

What is the difference between egui and eframe?

egui is a 2D user interface library for laying out and interacting with buttons, sliders, etc. egui has no idea if it is running on the web or natively, and does not know how to collect input or show things on screen. That is the job of the integration or backend.

It is common to use egui from a game engine (using e.g. bevy_egui), but you can also use egui stand-alone using eframe. eframe has integration for web and native, and handles input and rendering. 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).

Why is egui_web using so much CPU in Firefox?

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

Why does my web app not fill the full width of the screen?

To alleviate the above mentioned performance issues the default max-width of an egui web app is 1024 points. You can change this by overriding the fn max_size_points of epi::App.

How do I render 3D stuff in an egui area?

egui can't do 3D graphics itself, but if you use a 3D library (e.g. glium using egui_glium, or miniquad using egui-miniquad) you can render your 3D content to a texture, then display it using ui.image(…). You first need to convert the native texture to an egui::TextureId, and how to do this depends on the integration you use (e.g. register_glium_texture).

There is an example for showing a native glium texture in an egui window at https://github.com/emilk/egui/blob/master/egui_glium/examples/native_texture.rs.

Other

Conventions and design choices

All coordinates are in screen space coordinates, with (0, 0) in the top left corner

All coordinates are in "points" which may consist of many physical pixels.

All colors have premultiplied alpha.

egui uses the builder pattern for construction widgets. For instance: ui.add(Label::new("Hello").text_color(RED)); I am not a big fan of the builder pattern (it is quite verbose both in implementation and in use) but until Rust has named, default arguments it is the best we can do. To alleviate some of the verbosity there are common-case helper functions, like ui.label("Hello");.

Instead of using matching begin/end style function calls (which can be error prone) egui prefers to use FnOnce closures passed to a wrapping function. Lambdas are a bit ugly though, so I'd like to find a nicer solution to this.

Inspiration

The one and only Dear ImGui is a great Immediate Mode GUI for C++ which works with many backends. That library revolutionized how I think about GUI code and turned GUI programming from something I hated to do to something I now enjoy.

Name

The name of the library and the project is "egui" and pronounced as "e-gooey". Please don't write it as "EGUI".

The library was originally called "Emigui", but was renamed to "egui" in 2020.

Credits

egui author and maintainer: Emil Ernerfeldt (@emilk).

Notable contributions by:

egui is licensed under MIT OR Apache-2.0.

Default fonts:

GitHub

https://github.com/emilk/egui
Comments
  • 1. File dialogs and drag-and-drop of files

    Tracking issue for

    • [x] File browser dialog for native (rfd now works since https://github.com/emilk/egui/pull/631)
    • [ ] File browser dialog for egui_web ("Select a file to upload")
    • [x] Drag-and-drop files onto egui_web andegui_glium` (https://github.com/emilk/egui/pull/637)
    Reviewed by emilk at 2021-04-02 08:22
  • 2. Add egui_glow backend as alternative to egui_glium

    I have opened this draft PR to move discussion about egui_glow from #93 to keep conversation focused. As of latest commit, this fork no longer builds. This is because of issues with lifetimes that I will need to fix.

    Feel free to give feedback, but keep in mind that a lot of things are still subject to change.

    TODOs:

    • [x] Get it working
    • [x] Use SRGB to match egui_glium
    • [x] Fix remaining lifetime issues
    • [x] Ensure there are no OpenGL resource leaks
    • [x] Detect OpenGL version for GLSL shaders
    • [x] Fix graphical glitch as shown in screenshot below (black rectangle in top left corner) image
    • [ ] Move egui_glow into its own directory, once reviewing is complete

    Closes #93.

    Reviewed by AlexApps99 at 2021-08-29 22:54
  • 3. Dynamic sized strips, tables, and date picker

    A (dynamic) grid and table layout widget which allows a mixed use of size constraints:

    • Absolute sizing
    • Relative sizing: relative to available size in dimension
    • Remainder: The remaining space is distributed evenly to all cells using Remainder Sizing
    • Relative/Remainder with minimum size

    Also contains a date picker button which is based on the dynamic grid.

    This is early in development and has definitely lots of bugs and rough edges.

    I didn't want to wait longer as I love the results so far and I wanted to show it and open it up for discussion!

    TODO

    I added many TODO comments in the code which I want as a minimum to get this released, like:

    • [ ] Positioning of date picker popup
    • [ ] Colors on date picker popup
    • [x] Internationalization/locale of date picker button/popup
    • [x] Padding in table/grid should be worked over/switched to a more egui like approach
    • [x] Is having two extra crates really needed? I developed it in extra grades but would not mind having it integrated into the main crate. I would prefer some integration into egui repository over maintaining external crates.

    Screenshots:

    Reviewed by elwerene at 2021-12-17 17:48
  • 4. Context menu

    (updated 8.9.21)

    • ContextMenuSystem: Stored by the Context, stores menu state across frames

    • context_menu can be called on Response. It checks if a context menu should be shown and takes a builder closure for the context menu's contents:

    ui.horizontal(|ui| {
        ui.label("title:");
        ui.text_edit_singleline(title);
    })
    .response
    .context_menu(|ui| {
        if ui.button("Clear..").clicked() {
            *title = String::new();
            ui.close();
        }
    });
    
    • the Ui is extended to support creating and closing of menus via the menu and close methods. When menu is called from within a Ui for a menu, it creates a button with an expandable sub-menu, otherwise it creates an inline drop-down menu. Calling close clears the internal menu state.
    .response
    .context_menu(|ui| {
        if ui.button("Open...").clicked() {
            ui.close();
        }
        ui.menu("SubMenu", |ui| {
            ui.menu("SubMenu", |ui| {
                if ui.button("Open...").clicked() {
                    ui.close();
                }
                let _ = ui.button("Item");
            });
            if ui.button("Item").clicked() {
                ui.close();
            }
        });
    });
    

    Peek 2021-08-28 11-45

    To-Do:

    • [x] respect click context (i.e. clicked element)
    • [x] add more extensive examples to demo
    • [x] improve submenu navigation with more forgiving mouse movement paths
    • [x] unify with egui::menu
    • [x] fix hover failing at edge between context menus #577
    • [x] disable hover effect on other menu items when moving towards open submenu
    • [x] define useful Response for SubMenu::show: InnerResponse<Option<Response>>
    • [x] improve styling
    • [x] #547 or #578
    • [x] optimize menu item and submenu API (~MenuUi~)
    • [x] sometimes context menus applied to panels trigger when clicking on a window covering the panel

    Needs new PR:

    • is the shadow of the sub-menu on the parent menu fine?
    • widgets still show hover visuals when cursor moves over them while submenu is open #684
    • items don't adjust to width of larger items when they are added after them #606
    • #683

    Let me know if you have any suggestions or find any problems :)

    Reviewed by mankinskin at 2021-07-03 15:14
  • 5. Replace Glium

    Glium is a convenient choice, but is a rather big dependency which compiles slowly, and uses build.rs. It is also no longer actively maintained.

    The ideal choice for compiling Egui natively would be something simple that compiles quickly. I'm not sure there is such an alternative though.

    One alternative worth investigating is pure glutin (which Glium depend on). It is a bit lower level compared to Glium, and requires use of unsafe, but it looks easy enough to use: https://gist.github.com/matthewjberger/9da00592b472b50ec1e6b3238719264b

    Reviewed by emilk at 2021-01-04 09:33
  • 6. [Linux] Frequent crashes when starting application, X-related

    Hi,

    recently I'm having plenty of (non-deterministic) crashes when starting my egui-based application.

    [xcb] Unknown sequence number while processing queue
    [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
    [xcb] Aborting, sorry about that.
    megra_rs: xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
    

    Not really sure what this means. Usually I have to try two or three times, then the application starts. Any hints ?

    I'm on Arch, Xorg, AwesomeWM

    Best, N

    Reviewed by the-drunk-coder at 2021-05-28 16:21
  • 7. Move keyboard focus with tab to any interactive widget

    It would be great to have support for keyboard only navigation (i.e a concept of focused widget and the ability to move focus to another one) that would allow "tab" key for example to move to the next widget and "return" would act as press, etc.

    This in return would make it quite easy to add gamepad support as it would just behave as a subset of a regular keyboard.

    Reviewed by emoon at 2020-10-25 14:13
  • 8. Everything is super dark in epiphany

    Describe the bug The demo web app is super dark in epiphany. See screenshot below.

    To Reproduce Steps to reproduce the behavior:

    1. Open the demo web app in epiphany.

    Expected behavior Should look like it does in other web browsers (e.g. Firefox).

    Screenshots Screenshot from 2021-10-13 10-49-04

    Desktop (please complete the following information):

    • OS: Fedora 34
    • Browser: Epiphany
    • Version: 40.3
    Reviewed by Barugon at 2021-10-13 17:56
  • 9. Basic multi touch support (issue #279)

    I guess I should open a draft PR before this gets too big. It would be great to get some feedback, @emilk .

    Done:

    • [x] Created an Event::Touch variant
    • [x] egui_glium creates touch events (but I am not able to test this as it turns out that winit does not recognize my apple trackpad as a touch device)
    • [x] egui_web creates touch events
    • [x] Added a map of TouchStates to the InputState struct (need a map because, technically there can be more than one touch device, identified by individual IDs)
    • [x] Implemented TouchState::ui() (used in InputState::ui()), so touch events can be manually tested with egui_demo_lib on a mobile device. This can be tested with the link mentioned below, but you need a device with a touch surface (otherwise you will see no change). Open the Inspection window and expand the Input collapsible. You should see a collapsible labelled "Touch State [device 0]".
    • [x] Implemented the first prototype of a pinch/zoom gesture ~~This is realized with a Gesture trait object and a control loop capable of managing an arbitrary number of individual Gesture implementations. (Got this idea from studying ctk::Gesture)~~
    • [x] implement Zoom and Rotate, including a test window for egui_demo_lib (can be tested at the demo link below)
    • [x] having consumed two gestures in a demo app, decide on the final API for applications The proposal of having just a simple input.zoom() method returning the zoom factor is charming, but we may need more flexibility (for example the starting position (center point) and current position of the gesture). β†’ I implemented the API as proposed by emilk in his initial comment (except that touches.count() is still missing).
    • [x] add support for more than 2 fingers, and for determining the number of fingers on the surface

    Out of scope of this PR (should I create issues?):

    • [ ] return the touch info in the Response of ui.interact(), but only if the start position of the touch gesture is inside the rect area. (Not sure if this needs a deeper integration with Sense.)
    • [ ] discuss whether the synthetic generation of pointer events from touch events, as it is currently implemented in egui_web, could be moved to egui. Advantage: backends don't have to care about this, any more.

    Link to online demo for this branch: https://quadruple-output.github.io/egui/ – remember that you need a touch screen (e.g. mobile phone or tablet) for testing.

    Closes https://github.com/emilk/egui/issues/279.

    Reviewed by quadruple-output at 2021-04-13 18:57
  • 10. IME Support

    Update (April 2021): Since this issue was initially opened, good progress has been made on IME support. #258 Implemented proper candidate window positioning for egui_web #278 Implemented IME composition events for egui as well as logic to fire them for egui_web This means egui_web, as well as coreegui, now has IME support. (Thanks @n2 !)

    However, eframe on native targets still DOES NOT have IME support. And with egui-glium (and many other winit-based egui backends), it is unlikely support will land any time in the near future. This is not an egui issue but rather an upstream issue. The biggest blocker is https://github.com/rust-windowing/winit/issues/1497. winit currently does not have IME support, which means most of the Rust ecosystem does not have IME support. Glium/glutin are no exception.

    egui-miniquad, despite not relying on winit, also has a similar issue because sokol-app, miniquad's windowing library of choice, doesn't have IME support either. The only egui backend listed in the README that would be able to support IMEs is egui_sdl2_gl. I opened an issue there.


    Original issue: Describe the bug

    There are no events available for IME composition, nor do text inputs display IME composition strings. The candidate window is not shown in the appropriate location.

    To Reproduce Steps to reproduce the behavior:

    1. See that https://docs.rs/egui/0.10.0/egui/enum.Event.html does not have any IME-related events.
    2. Open up any egui program, regardless of the backend impl, and observe the lack of IME support.

    Expected behavior There are events available for when the IME composition string/state changes, and text inputs display said string/state correctly. The candidate window should be shown right below the cursor.

    Screenshots N/A

    Desktop (please complete the following information): N/A

    Smartphone (please complete the following information): N/A

    Additional context IME support is a(n often overlooked) must for many people around the world in any sort of production GUI.

    Reviewed by lunabunn at 2021-03-24 18:03
  • 11. Widget Gallery

    Hello and Happy upcoming New Year!

    I am doing integration between EGUI and our game engine Dotrix. We don't have our UI crate yet and I am about to use EGUI for an editor for now. Results looks like this so far Snímek obrazovky 2020-12-30 v 23 31 59

    My question if there is already some widget gallery maybe as an image with widgets and their names? Or should I just refer this list https://docs.rs/egui/0.6.0/egui/widgets/index.html ?

    Reviewed by Lowentwickler at 2020-12-31 16:05
  • 12. Painter Galley Crashing

    First look if there is already a similar bug report. If there is, add a comment to it instead!

    Please also check if the bug is still present in latest master! Do so by adding the following lines to your Cargo.toml:

    Describe the bug Frozen crashing/crashy egui window

    To Reproduce fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) { egui::CentralPanel::default().show(ctx, |ui| { ui.painter().galley(Pos2::new(10.0, 10.0), ctx.fonts().layout(String::from("hi"), FontId::monospace(10.0), Color32::BLACK, 0.0)); }); }

    Expected behavior Paint my text at my position

    Screenshots image

    Desktop (please complete the following information):

    • OS: Arch Linux
    Reviewed by MalekiRe at 2022-05-24 05:59
  • 13. Wrong transparency?!

    Describe the bug

    I'm loading a simple psd with the psd crate (see below) with a few transparent layers, the loaded layers are rendered using egui.

    stickman

    But as you see I'm getting a bunch of weird white stripes, the image is white in these areas but have alpha equal to 0.

    psd__load_glich

    I tested with miniquad (egui-miniquad = "0.11.0") and winit/wgpu (egui-winit = "0.18.0" and egui-wgpu = "0.18.0") backends with the same result.

    Inspecting the frame with RenderDoc shows the images here loaded correctly and have alpha == 0 in the white areas. render_doc

    Why the alpha isn't working? Maybe I'm doing something wrong. I give a quick inspection in the shaders used in both miniquad and wgpu backends but didn't spot anything worng.

    Desktop

    • OS: Windows 10
    • Version: egui 1.8.1
    Reviewed by lassade at 2022-05-23 23:31
  • 14. Add some padding to the egui-wgpu uniform buffer for WebGL

    I'm using egui-wgpu with the wgpu's WebGL backend. At the moment I get the following error on Chromium:

    [.WebGL-0x38140334e800] GL_INVALID_OPERATION: It is undefined behaviour to use a uniform buffer that is too small.
    

    with nothing rendering. I've encountered this issue before and have added some padding to the UniformBuffer struct. There is now no warning and it renders normally.

    Reviewed by expenses at 2022-05-23 16:01
  • 15. Update the wgsl syntax used in egui-wgpu

    This should only be merged when a new wgpu release is made

    I'm using the git version of naga and currently egui-wgpu panics during shader processing with that because it expects a different syntax for decorations, so I needed to make these changes to get it to work.

    Reviewed by expenses at 2022-05-23 15:53
  • 16. DragValue default layout is annoing and cant be modified easily

    I'm talking about why it is centered if not focused, and why it go left aligned while focused.

    https://user-images.githubusercontent.com/707007/169659157-94ab48b3-486c-4649-9c54-1adc7c65060a.mp4

    but for example, shaderlab demo looks like this:

    https://user-images.githubusercontent.com/707007/169659301-986e6f50-a4f7-4111-9d53-b3b84eb369ca.mp4

    The reason of such behaviour is that DragValue render Button if not focused. and the button centering text regarding of current layout. SO it works that way in shaderlab because its wrapped in ui.columns. to achieve this behavior I need

            let mut oo = Layout::top_down_justified(Align::LEFT);
    
            ui.with_layout(oo, |ui| {
                ui.vertical(|ui| {
                    ui.add(inp);
                })
            });
    

    Do exist something better? can we change DragValue to configure its by some flag and not layout?

    Reviewed by enomado at 2022-05-21 15:54
  • 17. requesting default focus

    I'm playing with dialog prompts in egui. It would be nice to be able to request that a widget receives "default focus" upon appearing, so the user can just press enter to activate the default button without pressing tab first. (e.g. when a window first appears, focus the "ok" button)

    I tried this pattern, which works ok, though there's weirdness (see the end of this comment).

    let button = ui.button("OK");
    {
        let mut memory = ui.memory();
        if memory.focus() == None {
            memory.request_focus(button.id);
        }                      
    }
    

    A method like ui.memory().default_focus(widget.id) that sets focus only if it's not already set, may work well as a starting point for this.

    I think one alternative is tracking a "first open" flag somewhere in my own code for each UI container that cares about default focus, however that may not handle something like a multi-page wizard where the contents change without creating a new container.

    Weirdness with my memory approach:

    1. Clicking in a background section will flash the widget's focus for a frame. (I think I'd prefer in this case that clicking on the UI background doesn't affect tab focus, but it's probably more nuanced than that, e.g. input boxes?)
    2. Clicking any other button unsets the focus afterwards, which re-focuses the default button and flashes both buttons for a frame.
    Reviewed by lunixbochs at 2022-05-21 11:46
The bindings to the Nuklear 2D immediate GUI library.

nuklear-rust The bindings to the Nuklear 2D immediate GUI library. Currently beta. Drawing backends: gfx-pre-ll for GFX 3D drawing engine (examples: O

May 12, 2022
Egui node graph is a featureful, customizable library to create node graph applications using egui
Egui node graph is a featureful, customizable library to create node graph applications using egui

Egui node graph is a featureful, customizable library to create node graph applications using egui. The library takes care of presenting a node graph to your users, and allows customizing many aspects of the interaction, creating the semantics you want for your specific application.

May 23, 2022
A simple GUI version of the pH calibration tool written in egui, based on the eframe template.

caliphui A simple GUI version of the pH calibration tool written in egui, based on the eframe template. Usage Native binaries are provided under relea

Dec 29, 2021
An easy-to-use, 2D GUI library written entirely in Rust.

Conrod An easy-to-use, 2D GUI library written entirely in Rust. Guide What is Conrod? A Brief Summary Screenshots and Videos Feature Overview Availabl

May 24, 2022
Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.
Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.

libui: a portable GUI library for C This README is being written. Status It has come to my attention that I have not been particularly clear about how

May 28, 2022
This project attempts to allow the creation of reusable egui-themes

egui stylist Note this project is considered to be experimental and -- while used in personal projects -- may have API breaking changes without warnin

May 19, 2022
FLTK frontend for Egui WGPU backend.

Egui FLTK Frontend FLTK Frontend for Egui WGPU Backend On linux Debian/Ubuntu, make sure to install the latest main requirements: sudo apt-get update

May 24, 2022
D3D11 backend for egui library. Presumably for mods/cheats development
D3D11 backend for egui library. Presumably for mods/cheats development

D3D11 backend for egui library. Presumably for mods/cheats development. Currently few features from egui are missing. WIP.

May 2, 2022
Egui bindings for miniquad

egui bindings for miniquad native On Linux you first must run apt install libx11-dev libxi-dev libgl1-mesa-dev (miniquad dependencies). cargo run --re

Apr 9, 2022
Egui bindings for macroquad

egui bindings for macroquad This is the easiest way to use egui. Just two functions! Web demo. Usage You need to call ui when you need to get informat

Apr 30, 2022
A simple, cross-platform GUI automation module for Rust.

AutoPilot AutoPilot is a Rust port of the Python C extension AutoPy, a simple, cross-platform GUI automation library for Python. For more information,

May 13, 2022
Rust bindings for the FLTK GUI library.
Rust bindings for the FLTK GUI library.

fltk-rs Rust bindings for the FLTK Graphical User Interface library. The FLTK crate is a crossplatform lightweight gui library which can be statically

May 25, 2022
Idiomatic, GTK+-based, GUI library, inspired by Elm, written in Rust
Idiomatic, GTK+-based, GUI library, inspired by Elm, written in Rust

Relm Asynchronous, GTK+-based, GUI library, inspired by Elm, written in Rust. This library is in beta stage: it has not been thoroughly tested and its

May 18, 2022
Clear Coat is a Rust wrapper for the IUP GUI library.

Clear Coat Clear Coat is a Rust wrapper for the IUP GUI library. IUP uses native controls and has Windows and GTK backends. A macOS backend has been o

Feb 13, 2021
A cross-platform GUI library for Rust, inspired by Elm
A cross-platform GUI library for Rust, inspired by Elm

Iced A cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm. Features Simple, easy-to-use, batteries-included AP

May 26, 2022
Truly cross platform, truly native. multiple backend GUI for rust
Truly cross platform, truly native. multiple backend GUI for rust

WIP: Sauron-native a rust UI library that conquers all platforms ranging from desktop to mobile devices. An attempt to create a truly native, truly cr

May 28, 2022
A cross-platform GUI library for Rust focused on simplicity and type-safety
A cross-platform GUI library for Rust focused on simplicity and type-safety

A cross-platform GUI library for Rust, inspired by Elm

May 23, 2022
A simple news reading GUI app built in Rust
A simple news reading GUI app built in Rust

Headlines [WIP] A native GUI app built with Rust using egui. Uses newsapi.org as the source to fetch news articles. This is a WIP and the current stat

May 17, 2022
Build GUI applications with minimal dependencies in Rust

winapi-app-windows A crate to build applications' windows in Windows using WinAPI. This would be less confusing if the operating system was called som

Jan 7, 2022