Egui – An immediate mode GUI written in Rust
egui.rs
egui.rs
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 mean... pretty much anything you have on desktop but in your browser.
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 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)
(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, ...
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()
"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"?
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.
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.
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.
You mean mobile apps, right? With desktop UIs this has traditionally never been an issue.
[1] QTextEdit, QML TextEdit etc
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.
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.
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.
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.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.
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