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.
In Rust, crates and not modules are the unit of compilation. Hot reloading is a whole other problem for the Rust ecosystem. You'd probably have to build it yourself or buy into a whole engine.
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.
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?
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.
If you set up "winit" so it only redraws on events, then you don't trigger an EGUI redraw very often. But if updates that affect the EGUI items are coming in from another source, like the network, you have to explicitly trigger a winit redraw cycle.
Don't know about web. Seems overkill if all you have are GUI widgets. Egui is most useful on top of something more graphical.
Scrolling text is a problem. EGUI isn't good at big text boxes with much offscreen text. That can be worked around.
"egui is not a framework. egui is a library you call into, not an environment you program for."
So I suspect it gives you control on when to redraw and you might eg call it only when user input happens in your app or there's a some other state change that changes what is shown.
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.
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.
Words similarly fail me how much I loathe and detest its GUI (at least on mobile browsers, where I often play the game). As an example, one has to actually _close_ the dictionary popup if you fat finger a letter because the fucking backspace doesn't work, or rather seems to require an incomprehensible number of presses to start deleting letters
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.
Hidpi monitors about about twice as expensive, and the only real advantage is that they look nicer. Maybe on a laptop that's a good use of $$$, especially if the screen is very small, but on desktop you'd almost always rather get a bigger monitor or a second monitor. So low DPI will be with us for a long time.
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.
> 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.
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)
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.
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?
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.
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.
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
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.
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!
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.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
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.
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).
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)
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.
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...
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.
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
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
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.
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.
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.
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.
I feel like hot-reloading would be the fix here, but I'm unsure what the state on that is.
Does anyone have any examples of fun things that use egui?
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.
So it's not a GUI. In my book a GUI only redraws when something changes, to save the user's power.
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?
Then you won't have to waste cycles deciding which random internet comment from a stranger to believe
Don't know about web. Seems overkill if all you have are GUI widgets. Egui is most useful on top of something more graphical.
Scrolling text is a problem. EGUI isn't good at big text boxes with much offscreen text. That can be worked around.
"egui is not a framework. egui is a library you call into, not an environment you program for."
So I suspect it gives you control on when to redraw and you might eg call it only when user input happens in your app or there's a some other state change that changes what is shown.
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...
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)
[0] https://glitchedfactory.com
Words similarly fail me how much I loathe and detest its GUI (at least on mobile browsers, where I often play the game). As an example, one has to actually _close_ the dictionary popup if you fat finger a letter because the fucking backspace doesn't work, or rather seems to require an incomprehensible number of presses to start deleting letters
I mean... pretty much anything you have on desktop but in your browser.
(This is well known by the egui authors, which is a great library!)
Plus modern displays can have all sorts of weird subpixel layouts so it's not as simple as it used to be.
Someone's been naughty for Christmas, forcing option unwrapping instead of pattern matching.
On the mobile version of Brave.
Further back in time: https://news.ycombinator.com/item?id=28166663
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, ...
https://github.com/harfbuzz/rustybuzz
https://github.com/pop-os/cosmic-text
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.
This mechanism can get you there most of the time.
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 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 see widgets that are added to a UI using .add()
https://github.com/emilk/egui/blob/master/crates/egui/src/wi...There appears to be a fluent builder API for these widgets. Is that what makes it "immediate mode"?
[1] https://github.com/emilk/egui#why-immediate-mode
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.
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.
> An error occurred during loading:
> ReferenceError: WebAssembly is not defined
> Make sure you use a modern browser with WebGL and WASM enabled.
As soon as you start hoping to get pixel perfect/complex designs in place, though, it hits a wall.
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.
Obviously that's not a downside from a software developer perspective.
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 mean mobile apps, right? With desktop UIs this has traditionally never been an issue.
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.
[1] QTextEdit, QML TextEdit etc
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.
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.
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.
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
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.