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.
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.
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.
Readit News
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.
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, ...
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.