Egui 0.27 – easy-to-use immediate mode GUI for Rust
github.com
github.com
I am using EGUI for visualizing electron wave functions, configuring and viewing status of UAV flight controllers and peripherals, and as an interface for locating nearby RF devices.
I will say the main negatives are that the `egui`/`eframe` etc split is confusing, and the API rapidly changes in a breaking way. Although part of that is from companion libs like walkers, for maps, that are making their own changes while trying to keep up.
That being said, that's an aesthetic choice; and apps provided in it are better than nothing.
99% of the users of said platform have both installed on their machine and would prefer either over the janky non-native ones in electron and egui apps.
What is native in windows? Win32, UWP, Windows.forms, MFC etc? Because even Microsoft has a bunch of electron (or equivalent) apps now.
So there are two. And both are native, yes.
It's extremely hard to make a proper cross-platform kit. Because every platform has a gazillion little (and not-so-little) conventions about what's expected, behaviours, and even control placements. Even Qt struggles there and they have been doing it for over 30 years.
Furthermore, even they seem to have thrown in the towel and made the QtQuick (GPU rendered, non native looking widgets) as an alternative to the traditional QtWidgets.
It would definitely benefit from a more "neutral" style though, or even better a few style choices. GTK2 used to have a ton of actually attractive styles available back in the day.
That’s a design problem, not egui one. The reason UI went to shit is because no margin for creativity anymore, same design, same icons, same charts, same shit, I bet everyone in here can tell a site is using bootstrap css from the first 3 seconds..
Consequently, I wish more sites used Bootstrap. As an end user I don’t care a whole lot about a brand’s identity or style. I don’t want to have to guess and check to figure out what’s a tab or a menu or how to access settings. The number of custom layouts I’ve had to memorize is staggering and often gets invalidated when someone gets promoted and decides the site or app needs a new design.
Desktop window frameworks may have been bland, but they were based on actual usability studies and I think we gave that up too readily.
Innovations should remove friction.
They rarely do.
I also respect the fact that this is just a statement of a personal preference.
However I don't think most people care.
Good applications with thoughtful UX and useful functionality will succeed whether they choose native widgets or not.
Literally millions of people use applications like VSCode, Blender, OBS Studio. I bet the vast majority of them don't think what this here application needs is more native widgets.
Heck, no one cares that Figma is a web app. From what I can see it beat out all similar desktop native competitors.
Furthermore, in my prior comment, I acknowledge that you are expressing a personal preference/opinion and that I respect that.
I think everyone cares, whether they know it or not. Which sounds like an oxymoron. But my point is that inconsistent UX might not be glaringly noticeable, but it can still give a feeling of messiness and add to cognitive load.
"Native widgets" is just a way to achieve "consistent widgets". A good tradeoff IMO is to at handle as many things with native UX (e.g. window decorations, menus, etc.), as possible without compromising on function.
To avoid the latter, custom GUI is arguably necessary, as is the case with Blender, while OBS arguably doesn't need its own handling of the menu / window decoration.
These things matter very much to some people, as consistency affects how well certain accessibility tooling can understand the contents of applications. UI customization also matters for similar reasons. Certain things like scaling or theming, might rely on native GUI libraries.
To summarize, if the discussion is what is "best", and you don't have a functional reason to justify custom UX, and you disregard development cost, then the best solution is a consistent UX, i.e. native widgets.
My company Rerun.io is entirely built on egui so that we get the same high-performance UI on the web as on native. Give it a spin at https://app.rerun.io/
I'm sort of hoping high-dpi screens will make this a moot point very soon :)
Is there any good examples for this, the examples (not unreasonably), mostly seem to do fairly trivial work.
The very simplest way to do it might be for the UI thread to send the work thread an Arc<AtomicBool>. The work thread can set the bool to true when the work is finished. The UI thread can branch on the value of the bool each frame to decide what to draw. Job done.
If I wanted to build a back office/admin site for an hobby project in egui, would it by default be hard to use on a phone?
It would mostly consist of tables and buttons for managing features, data fetched by websockets.
For app.rerun.io we mostly need to work on making the app friendly for small screens.
Edit to add: At the risk of self-promoting a bit more, I gave a talk about AccessKit at RustConf last September, and I used egui in the first demo. https://www.youtube.com/watch?v=LRBKb6McgqA
Is it an ongoing effort? I couldn't find a lot of pointers in the repo on how one could try to contribute to move this along.
It works very well in games, where it allows creation of complex completely custom UIs, with GPU rendering.
However, egui is an odd choice for desktop applications. It's completely non-native. Even "windows" in egui are custom widgets confined to its canvas, not real OS windows.
I happened to immediately (pun intended) stumble with an example of this. Just by chance, I went straight to test the ComboBox (https://www.egui.rs/), and I have the tendency of not just clicking to make the drop-down appear; instead, I click and hold, and only release after selecting the desired choice.
This doesn't work at all on egui: the ComboBox doesn't show its choices until the mouse button is released, not upon the initial mousedown press.
I guess there must be a thousand cuts like this, which is understandable, given that all functionality is implemented from scratch trying to imitate the native widgets we all know and use since forever.
Accessibility always ends up on people's "I'll think about that later" bucket, and it's terrible.
I might put some effort in if developing on Mac (but even Apple just does whatever), but on Windows and Linux, the components are a free for all. If even Microsoft won’t respect their own UI, why should I?
I’m not advocating for breaking usability in your apps, just saying that we are well past not using this for desktop.
If I have no choice, I'll use one of these apps. But if there's an alternative with a native UI, I'll switch in a heartbeat. Basically, the same as I feel about most electron apps.
For which user? I prefer non-native apps. It makes me feel more immersed in the tool, and gives the developer complete control over their design, whether by choosing a GUI toolkit they like, or rolling their own from scratch to perfectly fit the domain.
They are entitled to. Just as you're entitled to use different software if you don't like it.
As sibling implies, it’s a thousand small differences that build up, creating friction that foster the push to native GUI’s being the preferred, if not nearly mandatory, solution.
> 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.
I've found multi-pass imgui to work totally fine, and I use it for one of my apps [1]. I can support (nested) hstack and vstack layouts which IIRC egui can't. There is added expense of calling the "draw" code again, but it's negligible in my profiles (doing the actual layout calculations is more expensive, so I only invalidate the cached layout when the data model changes). It wasn't particularly complex to implement: each ui function simply does different things if you are doing a layout pass vs a draw pass.
You don't have the native look but for Rust developers that don't have this requirement you should definitely give it a try.
I often wonder how much effort it would take to make one of the popular eguis framework and, rather than make it looks "like a native" app, you could get away with making it look "like a browser". (everyone style buttons/ inputs / etc... but they have a general "default" feeling that people are probably used to, at this point ?)
Skinning at least close to native (colors, fonts) should be good enough.
(Not that it’s impossible to do a near-perfect emulation—IE 5&6, VB 6, and Office 97 all use completely custom widget toolkits, and apart from the funky menus and common file dialogs in Office people rarely complained about mismatches with the platform.)
I really feel like I live in some alternate universe sometimes. Most people around me use very classic desktop apps for their day-to-day work - blender, kicad, adobe illustrator, qt creator, telegram desktop, krita, ableton live, libreoffice ... none of these are browsers in disguise.
It feels dated, and I'm not sure if that's a reflection on me or the toolkit, but it makes me want to reach for something that has better default aesthetics. I'm not even sure if it's possible to fix in Egui or not; if it is, I didn't figure out how in the time I spent on the site.
It is definitely fixable. Take a look at https://github.com/emilk/egui/issues/996 for some examples of how others have styled egui, or try out https://app.rerun.io/
Styling is done with `ctx.set_style`, but creating a nice style isn't very easy at the moment (basically you'll have to tweak constants in code, and then recompile). I'm working on making it easier as we speak though!
Making it easier to create styles is definitely a good idea, but I wonder if it wouldn't be enough for many people to have a library of styles they can choose from? In my own case, I think that would be plenty... honestly I just need the one. That one. ;-)
EDIT: I think this is the relevant code: https://github.com/rerun-io/rerun/blob/4636188996038f4be913f...
I wouldn't use it for more serious apps, as I think the immediate mode paradigm makes battery killer websites on laptops and mobile, since unless you are really careful about not making the app re-render, it'll be running your loop at 60fps which isn't great when you leave your site on your phone or laptop.
Edit to plug https://github.com/emilk/eframe_template from the same author: it gets you a rust/wasm webapp hosted in github pages in minutes after cloning + changing a few things, with full CI/CD and everything.
I'm choosing to believe that the egui (library) name is the "positive egui" form[0]. ;)
https://legion.stanford.edu/prof-viewer/?url=https://sapling...
When I did GUIs in Android native, I didn't enjoy it at all.
I have loosely played with Qt Quick but I didn't know C++ so I was clueless how to encode user behaviour into a program that implemented the behaviour. My immediate mode Javascript canvas work is far simpler.
LLMs are already generating web GUIs (such as vercel's v0 and others) and we can encode mapping of current state tokens to next behaviour tokens. Hopefully we can specify all the interactions and what should happen due to them.
React vdom refreshes the whole tree changed nodes for recomputation, LLMs could generate the new tree and use an animating library to transform between states - the difference in the trees.
Immediate mode GUIs lend themselves well to this; you just generate/rerender everything.
What I'm interested in is a novel desktop paradigm alternative to windows, mousing and drag and drop.
Intellisense and LSP lets us see the types of what an operation has. But computer GUIs are inherently synchronous unless you're writing a script or program. I would like to click through operations and transform and map from one kind of things to another type of things. This would queue operations up and the computer can schedule them efficiently.
Haskells knows the type of a pipeline at each stage of processing.
I would like to do "algebra with behaviour" and have built in transformations such as joins, swapping, queries and scheduling. If you can map a problem into something you understand based on position, you can do algebraic transformations between states such as binpacking or path finding.
"Break these files into batches, compress+encrypt them, keep them synchronized between these machines and back them up"
I am interested in immediate mode GUIs but I think we need a different paradigm for GUIs that is less synchronous from a user perspective.
Encoding behaviour in GUI code is complex due to state management and complexity. See jQuery.
In most GUIs as a user you do an operation and wait for it to complete (direct manipulation). You can't queue operations unless you code. I haven't seen macro recording done well.