I have just used it yesterday to better understand a math problem and found that the edit-compile-run cycle of rust with this framework was prohibitively long.
I only had a single file calling into this lib - maybe I could have improved on it with splitting the project up to some modules? Could anyone comment on their experience? Because usually I have found rust compile times okay, but this really made it hard to iterate.
What linker are you using? I've gotten really significant speedup over the default linker by using lld or mold.
Modules wouldn't fix this afaik.
I feel like hot-reloading would be the fix here, but I'm unsure what the state on that is.
I'm afraid that until browsers provide APIs to help render fonts with sub-pixel rendering (note: that would add fingerprinting bits), canvas-based UI rendering libraries will always have a big disadvantage (vs DOM-based) on all but the high pixel density devices.
(This is well known by the egui authors, which is a great library!)
I'm not sure. Phones and Macs are already all high density enough. Apparently it's been removed on Mac. Probably not too long before even cheap windows laptops and Chromebooks have hidpi screens.
Plus modern displays can have all sorts of weird subpixel layouts so it's not as simple as it used to be.
You tend to use the web platform for maximum portability, even for people not having high-end devices. If you only need to target people with a higher-density screen, then of course my comment is moot. I posit that it will still be a problem for large enough number of people, for a long time.
Even if you are using Retina 5k 27", the subpixel rendering is still necessary to get sharper fonts.
Apple dropped support for sub pixel rendering in MacOS years ago.
Why would that add fingerprint bits if everybody uses the same algorithm to render this?
The correct subpixel rendering depends on your monitor's pixel layout.
Demo pages like this are fun, and technically impressive when compiled to a browser environment. But I suffer from a lack of imagination so these widget demos don't really help me envision what an egui-powered app can do or might look like.
Does anyone have any examples of fun things that use egui?
I use it in Sharpview. It's really for GUI programs, not web pages. It redraws everything on every frame, so it's most useful for 2D overlays on 3D game-type programs. For that, it's pretty good.
It's one pass. As a result, layouts which are ordered left to right and top to bottom work well, but ones which displace or resize items above or to the left don't work well. Egui tries to fix things up on the next frame, thereby getting the effect of a multipass layout system, but sometimes that results in mis-positioning and jitter on alternate frames. As long as you respect that limitation, good results can be obtained.
It needs some kind of dialog builder tool so that you don't have to write code for each dialog box. Someone was working on that about two years ago. Should find that project again. Meanwhile, lots of repetitive code to write.
Note that winit, wgpu, egui, and their friends all have to advance in version lockstep. All those projects routinely make breaking API changes, and when this happens, it takes a month or two before all the others catch up. Again, as long as you know this, it's not too bad. It would be nice to see some of those packages reach version 1.0.
> It redraws everything on every frame, so it's most useful for 2D overlays on 3D game-type programs.
So it's not a GUI. In my book a GUI only redraws when something changes, to save the user's power.
If it’s used as a game ui, games typically render everything at 60fps - so the energy cost from ui layer would be neglible.
Afaik nobody is forcing to rerender the ui layer if nothing changes, though. Just render it to a texture and compose … no need to put everything to the same render target?
Well I guess your book needs a new edition. The type of gui you're referencing is typically referred to as a retained mode gui.
The point is, I don't want people to see "GUI library" and think it's okay to use this for your random phase-of-the moon application that has no good reason to redraw at 2400 fps or whatever the enthusiasts want these days.
Just click on the link and you can easily see it only redraws when something on the screen changes. It's amazing how quickly people will dismiss something these days based on their own made up reasons.
The poster above me explained to me that it's not like that?
Click the link, open the backend tab, and look where it says "Only running UI code when there are animations or input."
Then you won't have to waste cycles deciding which random internet comment from a stranger to believe
It's really good for scrappy prototypes, e.g. here's a water simulation demo I was using to learn Rust [1]. See the "view" menu for more windows.
The code for that is all contained in a single file [2], and IMO it's pretty small for what it does. It was really easy to add/change things while developing, a new button is just a single new line.
[1] https://andreivasiliu.github.io/cybersub/
[2] https://github.com/andreivasiliu/cybersub/blob/master/src/ui...
The Bevy Engine in Rust has an integration (https://docs.rs/bevy_egui/latest/bevy_egui/) that supports egui, for use in making UIs in games written against the Bevy Engine. Here's a webapp example of a 2d drawing showcase that uses egui as a UI provider: https://vladbat00.github.io/bevy_egui_web_showcase/index.htm...
https://rerun.io the one that sponsors them and the author's app is one example
Here's my plasmid editor, using EGUI: https://github.com/David-OConnor/plascad
I also use it for the GUI for 3D rendering computational chemistry and gravity sims.
I also use it for configuring embedded devices on PC, and/or viewing their telemetry. (e.g. for drones, drone parts etc)
I find it really practical to create a quick ui. For example i used to do glitch art with a friend that didn’t know how to use a cli, so i created a gui for him to use [0]. Egui is perfect for this use case, you create quickly lightweights softwares, than can be compiled to many different OS.
[https://truncate.town/](https://truncate.town/) is all egui (after the main menu)
I use egui to draw the overlay UI for game hacks I write. It's easy to use.
Photo editors, CADs etc.
I mean... pretty much anything you have on desktop but in your browser.
Or just in your desktop app. You don’t have to run in a browser.
I don't but I can. Which a very nice thing to have if you don't want to use Windows VM for a CAD, for example.
Egui is great for quickly getting prototypes or GUIs that don't need to be visually impressive up and running.
As soon as you start hoping to get pixel perfect/complex designs in place, though, it hits a wall.
Cool, but the input response is super slow. Like, when I’m typing fast on my phone (yeah, I’m that crazy Gen-Z who types a thousand words per minute on mobile), it just can’t keep up. Instead of ‘This is a test,’ I got ‘his i aes.’ It’s probably an architectural bottleneck that’s hard to fix. Also, I noticed you can’t select and copy text, which is a major headache for custom GUI implementation. Happy holidays and good vibes to everyone!
> panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/glow-0.16.0/src/web_sys.rs:282:78: called `Option::unwrap()` on a `None` value
Someone's been naughty for Christmas, forcing option unwrapping instead of pattern matching.
On the mobile version of Brave.
At the very least, one should use `expect` over `unwrap` so the error is useful.
I just opened https://github.com/grovesNL/glow/pull/331 to do exactly that.
Recent discussion: https://news.ycombinator.com/item?id=39837045
Further back in time: https://news.ycombinator.com/item?id=28166663
Limited internationalization support. For example, trying to paste in مرحبًا (Arabic for "hello") just gives me tofu squares.
It's being worked on. Merry Christmas! https://github.com/emilk/egui/issues/3378
Text shaping is anything but easy. Harfbuzz is probably the state of the art open source solution - https://github.com/harfbuzz/harfbuzz
Used in in Android, Chrome, ChromeOS, Firefox, GNOME, GTK+, KDE, Qt, LibreOffice, OpenJDK, XeTeX, PlayStation, Microsoft Edge, Adobe Photoshop, Illustrator, InDesign, Godot Engine, Unreal Engine, ...
For egui, it will be rustybuzz, which is used directly by cosmic-text
I thought Photoshop, Illustrator, and InDesign were very good at producing https://notarabic.com/ (at least the author calls out Adobe products in the description)
How do you debug these interfaces in a web browser, as can be done in javascript or even c++ web assembly for that matter(https://chromewebstore.google.com/detail/cc++-devtools-suppo...)?
How is this "immediate mode"?
I see widgets that are added to a UI using .add()
"You should put this widget in a ui with `ui.add(widget);"
There appears to be a fluent builder API for these widgets. Is that what makes it "immediate mode"?
They go into a good amount of detail[1] as to what they mean by "immediate mode" (this is linked from one of the windows when you open the page).
The logic is called every frame
There seem to be some problems with resizing windows.
In the "Highlighting" example, half the time when I click the grab area in the bottom right corner, my diagonal arrow mouse immediately switches to a vertical arrow mouse, so I can only resize vertically (which fails, see next point).
In the "Highlighting" example, it acts like it can resize vertically (vertical arrow mouse appears), but it won't actually let me resize it vertically.
In the other default examples, there's a grab area in the bottom right corner that makes me think I should be able to resize it both vertically and horizontally at the same time. But none of them let me resize them vertically.
Looks impressive, especially considering how fast is loads. One nitpick of my is the blurry font rendering. I suppose getting sharp and clear fonts is quite complicated task.
The font rendering looks about right on Safari. Is it blurry, or is it just doing Mac-style antialiasing?
It probably looks ok on HiDPI, unfortunately a lot of these hipster tools not supporting legacy but well trodden text rendering implementations are LoDPI unfriendly. https://github.com/zed-industries/zed/issues/7992
This looks really cool. Unfortunately, a sample demo UI page is using 2 cores of my CPU at 100% all the time just by doing nothing. I suppose there are many optimization tricks that can be applied to bring this down significantly.
I've been using this a bit lately. It's very easy to throw a basic working prototype together and doesn't require that much boilerplate in order to get widgets on a screen, which is great. On the other hand layout management is a bit of a pain and there is apparently no easy way to say, for example, "these three widgets should take up 60%, 25% and 15% of the available horizontal space, respectively". I think that is just a consequence of being immediate mode.
Drag values are amazing to use on mobile! Great demo, combines feature showcase and a great starter template.
A common problem of immediate mode GUI is how to make the parent component's size dynamically determined by child component's content (2-phase dynamic layout). Does Egui solve this issue?
You can instruct egui to discard a frame. That way you can perform this two phase layout across two frames without showing an unfinished UI.
This mechanism can get you there most of the time.
Take the Code Example demo initially opened: drag age up to 120, then press the Increment button, and watch the label “Arthur is 120” briefly blip to “Arthur is 121” (while the DragValue still shows 120!) before being dragged back down to 120 presumably by rerendering and egui::DragValue::new(age).range(0..=120) clamping it.
That’s… eww. It probably doesn’t often cause real problems—though it surely could, as it’s allowing temporary rendering with out-of-bounds values that a developer might have expected to be clamped—but it’s still very eww, the idea that mutating data leads to parts of a frame being rendered with different data.
I’m currently on mobile, where I couldn’t reproduce this.
I agree, that shouldn’t happen and it might be a bug, because the input is handled after drawing the initial frame and should be clamped before starting to draw the next frame. Drag events are tricky though, because they come with a frame delay by default (you have to recognize the drag).
Does this reproduce reliably on desktop? If so then I can create an issue for this.
I was unable to find a global font-size option, isn't there any? I can modify the fonts individually, but that's not what I want.
I also wish for a global contrast option (preferably where the day/night toggle is). The default night theme is too low contrast for me right now, coming from a brightness that is perfect for HN.
https://docs.rs/egui/latest/egui/struct.Context.html#method....
Maybe you want to scale all the UI elements? This has the same zooming effect as pressing Ctrl-+. Otherwise why not loop and set all the font sizes you want?
https://docs.rs/egui/latest/egui/style/struct.Visuals.html
I don't recall there being a high contrast option or slider, so your best bet might be trying to modify the values in this struct, or if that's not enough, then the values in the `widgets` field of it. You can customize every color in the UI.
Insanely snappy on mobile, very cool
On mobile I get
> An error occurred during loading:
> ReferenceError: WebAssembly is not defined
> Make sure you use a modern browser with WebGL and WASM enabled.
WebAssembly isn't even a modern feature anymore, even iOS Safari (which traditionally drags its feet when it comes to web standard support) has WASM support since around 2017.
EGUI owns. It's my go-to for writing GUI PC programs.
I have things I use every day that I wrote in egui. It has its quirks but has been great for years. Thanks emilk.
Is it common for rust to use serbian domains?
Yes.
Seems like a recipe for supply chain attacks
With Serbia being run by the mafia and all, or?
Hungry ghost gui
For serious use, they need a WYSIWYG designer. Otherwise, the iteration will be slow and painful.
Looks awesome !
Can you debug it in browser?
Am I the only one that has a problem with all non dom/html renderers that I can't copy the text on mobile? The same with flutter etc, it's such a regression in my eyes but nobody prioritizes it.
You generally can't copy text in native UIs unless the app author goes to extra effort to allow it. It's really the web that is the odd one out here because it was originally intended for documents.
It also means worse accessibility, less introspection, automation, worse/impossible adblocking, etc.
Selecting text can be useful, but it can also become its own usability problem.
I recently created a touch interface using a websocket/browser based stack and one of the problem was that users kept selecting the text on buttons because they expected some action while holding the button.
https://caniuse.com/user-select-none + pointer-events + touch-action : )
I currently have the same issue while building a canvas web app. Safari shows a small magnifier glass on double tap/long press and none of the css properties will suppress it.
I think you can work around it by listening on the touchstart event on your element and calling e.preventDefault(). Don't have an iPhone handy to test it right now, but I believe that's how I fixed that issue in my web game.
Thank you for the suggestion. This is also what is discussed in some stackoverflow threads on that topic. I simply do not get why javascript is required to stop the browser from interfering with user actions. Calling preventDefault also messes with element focus and other events.
Yeah, I am not the biggest fan of iOS Safari because of things like these. In my case, disabling most default interactions was a desirable property because I wanted to handle all the UI myself - but I understand that may not always be a good solution.
This is what I used
> worse/impossible adblocking
Obviously that's not a downside from a software developer perspective.
I’m a software developer, and it seems like a positive to me? Why wouldn’t you want the ability to post-facto manipulate with script the interfaces you are presented with?
Because if I added ads to my application, I want those ads to be shown to user, so I can have my money.
I think this we’ve discovered the inflection point between the traditional hackers and the SV growth hackers that HN tries to court both of.
As long as someone else is paying the bills.
which ads are all about, someone else paying devs to manipulate their users into buying stuff from someone else
What you mean is from a capitalist perspective. Not all software developers are focused on exploiting their users.
For applications developed by communist developers, it matters not if ads could be blocked or not.
I also would argue that extensibility adds overhead to support. For example I had issue with one website where user reported that they can't see some function which clearly was there. Turned out that their adblock mistakenly removed that element because of some generic CSS class name. I'd prefer for user to receive my application in the way I planned it, not in the altered way.
> You generally can't copy text in native UIs
You mean mobile apps, right? With desktop UIs this has traditionally never been an issue.
Desktop UIs only started adding that around 2000 or so (Gtk2?), it generally hadn't been possible before in the Windows/Linux world. Even today it still doesn't work as well as the Web, as the select ability is limited to a single widget, e.g. you can't copy&paste the complete text of the About box in Gimp in a single go and many other widget with text don't allow text selection at all.
That said, even on the Web it often feels like an afterthought. What text gets selected when you cross over multiple boxes in a layout often feels completely arbitrary, e.g. dragging the mouse to the left will select text at the top.
Ah, I misunderstood! You are absolutely right.
Most desktop apps are games and I can't think of a single game where you can copypaste text.
Counter Strike 2
Never an issue in what sense? In my own experience, it's not been issue because there wasn't an expectation that this should be possible. For example, text in Tcl/Tk label widgets cannot be copied (at least not by default). There must be a way to extract text using an a11y interface, but I haven't encountered that in practice.
No, I mean with desktop UIs too. Try copying from a traditional win32 GUI or Qt or Gtk.
Care to explain? All text editable widgets in Qt[1] supports text selection and copying.
[1] QTextEdit, QML TextEdit etc
In dedicated widgets yes, but widgets that aren't specifically dedicated for text editing don't usually let you select the text.
Try selecting explanatory text, or text associated to checkboxes in a Qt app: it won't work. There are exceptions, for example you can select text in the right side file metadata pane in the Dolphin file manager. But even this is limited: you cannot cross cells. Should you copy-paste all the metadata, you'd need to do it cell by cell.
Gotcha, yeah the developer needs to implement text selection himself. I wrote how I implemented text selection between discrete blocks in a ListView in my block editor on my blog post: https://rubymamistvalove.com/block-editor
The conversation isn't about text inputs but about text labels.
On the web you can usually select any text. Paragraphs? No problem. Form labels? Sure, easy.
But desktop and mobile apps don't allow that. You can only select text in editable fields.
I'm not sure about other smartphones but for the past years I've been using a godsend feature that allows me to copy any text in any app (including text on images). It's in the app switching mode in Android (or at least Pixels), the mode where you see your opened apps after pressing home for 1 second dragging up
I ran into this recently in the emulator… it seems to be using a very half-baked OCR engine that can't even recognize default Android's default font correctly.
This is an amazing feature! Thank you for sharing it!!
Wow that is a very neat feature, thanks!
The crux of the issue and it's the argument I always reach for when someone on HN says HTML is the worst UI scheme we have. It's the best, being text first and equipped with a heavy focus on accessibility.
On latest Android, long-pressing home activates the Google Assistant overlay, which allows you to select any text on screen (and translate and search region).
Yeah, but it still only uses OCR, right?
correct and it looks like it tries to do some autocorrect, not great when you need to copy some random characters password (like it was the case in the share WiFi password in previous android version, where you couldn't copy displayed password natively)
I'm currently building a GUI framework which have a flutter-like native render but that renders to DOM when targeting web. Announcement coming soon!
For Rust?
Yep!
Would be very interested in evaluating it now for some early feedback. Currently working on a CAD/CAM application and having to make some tough choices about multi platform native UI support. My email is in my profile if you want to reach out.
This is trivial to do in Flutter if the developer wants to: https://api.flutter.dev/flutter/material/SelectableText-clas...
Yes but it's not the default like it is for the web, so most text is not selectable.
Anything that is rendering to opengl/vulkan has this issue ... The issue is that there is not a good way to solve it with out hackery ... The one I saw for native android / opengl was writing to a hidden text field and selecting that with code for copy to the os clipboard...
also swipe to go back and cursor control with long press space is not working on ios. i would guess screen readers are also non functional for such apps
There are websites that disable copying, so I assume some would consider this a feature. :/
I summon Google Assistant and press the what's on my screen button, that one usually allows me to select text even when the apps don't.
The layers of extreme complexity in this situation are astounding.
The app has some text internally, it renders it by rasterizing fonts to a bitmap, the OS takes the bitmap and composites it within the wider UI. Google Assistant grabs a screenshot of the fully composited, post-processed OS UI, sends it over the internet to a server, which uses an OCR model to read all the text, and a different model to work out which is the relevant text, which is then sent back over the internet and displayed on the device.
All so the user can copy some text.
I used to be upset at such absurdities. Now I try to appreciate what a relatively universal interface images are instead! :D It doesn’t matter how text gets drawn if we OCR it. (Though I feel better when we do so on device.)
On Android it more or less just uses the accessibility APIs to grab the actual text, you can do it without using Google Assistant even by selecting text inside an app's thumbnail window from the Recent Apps screen.
It doesn't. You can try running it when your keyboard is open and see what an absolute trainwreck the OCR makes of that.
No, you're not the only one. I really would like to understand the people that implement that, look at it and find that good. I have the impression that the vast majority of developers are idiots.
Conversely, whenever I have to use a web app, if I click on something and it selects the text (outside of lineedit and text areas), it just feels unfinished and unprofessional - and a big turn-off for that app in general.
The worst are the ones when you can literally drag your mouse across the whole screen and it will start selecting text from entirely random places in the app's ui
That depends. To me, if you are developing an actual app, you should not be able to select text by default - its too easy to do by accident. If you're doing editing or there's an error message, those are exceptions and of course you should be able to copy those.
If what you're doing is an interactive website with texts like an article or a story, I think you should be able to copy by default, but UI elements like buttons should not have it enabled.
C-c, C-v works for me here.
egui is an immediate mode GUI library written in Rust. egui runs both on the web and natively on . On the web it is compiled to WebAssembly and rendered with WebGL. Everything you see is rendered as textured triangles. There is no DOM, HTML, JS or CSS. Just Rust.
egui is designed to be easy to use, portable, and fast.> on mobile