Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

Post reply on HN
Print view View original

111–120 of 148 posts

Re: I Switched from Flutter and Rust to Rust and Egui

#111

Post by inferiorhuman »

ogoffart wrote: post #28
airstrike wrote: post #23

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs

Since others are sharing Rust GUI libraries, I’ll mention Slint [ https://slint.rs ] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

A few months ago I was working on a debugger for some oddball VM. Slint suffered from the same issue most (all?) rust GUI toolkits seem to suffer from: immaturity. Either the widgets I was looking for weren't there or customizing them was a huge endeavor. With Slint specifically it was the inability to style text.

For my use case it was easier to get up and running with a TUI toolkit (ratatui in my case). Plenty of limitations there too alas and I finally landed on Qt…

Re: I Switched from Flutter and Rust to Rust and Egui

#112

Post by jayd16 »

jenadine wrote: post #24
feverzsj wrote: post #5

I still prefer good old GUI frameworks with WYSIWYG designers.

WYSIWYG designers seem convenient, but they're not that popular anymore for a reason. Writing UI in code is more flexible, easier to maintain, and works better as projects grow.

Wah? WYSIWYG rules the world. Web, mobile, desktop, game dev (The UI the user sees anyway). Anything where visuals matters, WYSIWYG and predefined layouts are used.

IMGUIs are almost always relegated to debug UIs and single devs because its actually terrible to maintain something that binds presentation and business logic like IMGUIs often do (and when they don't they lose the simplicity).

Re: I Switched from Flutter and Rust to Rust and Egui

#113

Post by hoppp »

andsoitis wrote: post #71
the__alchemist wrote: post #42

Earlier quoted context omitted.

I think the default behavior is to only re-render if the window is active/focused. You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention. This can be problematic, e.g. some of the sensor interfaces I have, I want to always display correct data, even if not focused. So, I have to decide if I want to have old data shown in the background misleading users,…

> You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention. sounds analogous to manual memory management

Which is completely fine. There are bugs but unlike with memory management, render bugs are more in your face.

Re: I Switched from Flutter and Rust to Rust and Egui

#114

Post by nathcd »

k__ wrote: post #58
ar-nelson wrote: post #36

Earlier quoted context omitted.

I really like Mithril.js ( https://mithril.js.org/ ), which is, IMO, as close as it gets to web IMGUI. It looks a lot like React, but rendering happens manually, either on each event or with a manual m.redraw() call.

I think, similar to Preact, Mithril skips the VDOM, which makes it "more immediate" than React. However, updating the DOM and then turning the DOM to an image (i.e., rendering it) still has an indirection that using canvas/webgl/etc. don't have.

> I think, similar to Preact, Mithril skips the VDOM, which makes it "more immediate" than React.

Both Mithril and Preact use virtual DOMs:

https://mithril.js.org/vnodes.html

https://preactjs.com/tutorial/01-vdom

Re: I Switched from Flutter and Rust to Rust and Egui

#115

Post by airstrike »

osa1 wrote: post #75
airstrike wrote: post #23

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs

I don't have too much experience in GUIs and I've been looking at iced and gpui recently for a new GUI application. iced has some nice looking apps written using it, but they all seem "laggy" on my high-end Linux box somehow. I'm wondering if this is a limitation of the immediate mode GUIs, or something related to my system, or an issue in the apps? For example, drag-and-drops or selecting text with mouse lag behind…

iced is not immediate mode

which apps are laggy? iced is fast AF. try running the game of life example on release and crank to max speed. there is literally no lag

could be something wrong with your GPU. join the Discord and we'll help you debug.

EDIT: I'm told you could be having vsync issues. try `ICED_PRESENT_MODE=immediate`

Re: I Switched from Flutter and Rust to Rust and Egui

#116

Post by airstrike »

bit1993 wrote: post #109

The nice thing about Flutter is that its cross-platform, write once run anywhere, I use Rust for the back-end. Personally I try not to use FFI because it adds complexity and ugly code, tracking object pointers, I'd rather just write pure Dart code.

iced is cross platform, there's even WASM support. lots of Rust crates are.

mobile and desktop are not different platform but different devices altogether that warrant separate designs IMHO

Re: I Switched from Flutter and Rust to Rust and Egui

#117

Post by bunderbunder »

Animats wrote: post #104
piker wrote: post #101

Earlier quoted context omitted.

Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit. I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience mig…

> I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors. To some extent, yes. Here's an example.[1] So many features have been added that the unit tests were taking too long. So tests were switched to use a faster allocator. That won't even compile for cross-compilation from Linux to Windows. Because tests won't run, chas…

It reminds me a little bit of the inescapable lifecycle of a ticketing system:

  1. People love it because it's lightweight and fast.
  2. More and more people use it.
  3. Feature requests start to roll in.
  4. It becomes bloated and slow.
  5. People get fed up and start to hate it.
  6. Create a new ticketing system and return to step 1.

Re: I Switched from Flutter and Rust to Rust and Egui

#118

Post by troupo »

Animats wrote: post #95

I use Egui, in a game-type application. I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time. Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get t…

> Originally, Egui was completely one pass.

Originally HTML was one-pass. Until they added tables. And tables require at least two passes to lay out.

There's only so far that you can take one pass rendering

Re: I Switched from Flutter and Rust to Rust and Egui

#119

Post by diggan »

bunderbunder wrote: post #117
Animats wrote: post #104

Earlier quoted context omitted.

> I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors. To some extent, yes. Here's an example.[1] So many features have been added that the unit tests were taking too long. So tests were switched to use a faster allocator. That won't even compile for cross-compilation from Linux to Windows. Because tests won't run, chas…

It reminds me a little bit of the inescapable lifecycle of a ticketing system: 1. People love it because it's lightweight and fast. 2. More and more people use it. 3. Feature requests start to roll in. 4. It becomes bloated and slow. 5. People get fed up and start to hate it. 6. Create a new ticketing system and return to step 1.

Maybe we should just learn to live with that sort of things, and build a tool/product that works with that cycle in mind and offers it as a feature.

Re: I Switched from Flutter and Rust to Rust and Egui

#120

Post by troupo »

Philpax wrote: post #27
strogonoff wrote: post #4

Immediate mode GUIs are cool but it seems that accessibility support is somewhat lacking. In native frameworks you often get it for free, on the Web you can follow ARIA and get it for free, but with immediate mode GUIs it seems that it is always a bit of an afterthought. For example, it seems that egui supports AccessKit, but not when used on the Web. With Dear ImGui it seems worse, there is some effort in that direc…

The lack of accessibility on the web is less an immediate mode problem and more of a problem with eschewing the web's native UI stack and rendering everything yourself. There are ways to signal to the browser what the content of your custom rendering is, but they very much do not come for free and require much more integration than AccessKit does on native.

> more of a problem with eschewing the web's native UI stack and rendering everything yourself.

Because web's "native UI stack" is almost non-existent for actual UIs. This has started to turn for the better only very recently: https://open-ui.org/

Post reply on HN