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

91–100 of 148 posts

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

#91

Post by j45 »

merksoftworks wrote: post #7

So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where you know you need a small amount of immediate visual feedback and tweaking parameters for it to be useful to the end user. Flutter answers questions about more robust UI. It's good that you chose the right tool for the job and more people should know that there…

Appreciate the thoughts about both Flutter and egui.

It's not perfect, but I don't know if there's much on the market that addresses robust UI and single code base as well as Flutter.

Very open to other things that are not more complex than Flutter to accomplish the single codebase to multi platform solution it does provide.

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

#92

Post by nu11ptr »

foobiekr wrote: post #87
nu11ptr wrote: post #51

Earlier quoted context omitted.

Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.

Most of the gRPC implementations force buffering of the whole response for large unary responses. They are not really written by people who care about performance. It’s dumb because the protobuf binary marshaled format is perfectly designed for server-side incremental marshaling.

Performance is relative. gRPC is plenty fast enough for my use case, and for that matter, almost all client/server use cases that work across the Internet. If a Javascript web client against a REST backend is fast enough latency-wise, then a local gRPC connection on a single PC is gonna feel like greased lightning. Of course, there will be a few scenarios where tight coupling of client/server are required for good enough performance, but they are few and far between.

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

#93

Post by nu11ptr »

dvdkon wrote: post #89
nu11ptr wrote: post #64

Earlier quoted context omitted.

Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.

Then you have to deal with port collisions when some other software wants to use that port. And keeping a port open without any authentication is terrible for security, even if it only binds on localhost, so you have to find some secure way to share a key between the client and server. Personally I wish we could just use UNIX sockets for "localhost-only TCP", but software support is just not there.

I don't worry about security too much given it is just bound to localhost, but I do use a simple password (and make it modifiable by the user). Avoiding port collisions in the real world isn't a big issue, just ask an AI for the least assigned default ports and chance of collision is minor (in worst case, also user modifiable). In return, you get free "remotability", which is kind of a big deal IMO.

I do wish gRPC allowed for easy usage of UNIX domain sockets and perhaps named pipes, however. Sometimes all you need is IPC, but in my case, I'm happy to have remote usage builtin.

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

#94

Post by spookie »

ethin wrote: post #88
piker wrote: post #19

Earlier quoted context omitted.

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although t…

Accessibility problems are something both retained-mode and immediate-mode UIs have generally. I've found that you can kind-of hack it together but the best route is to incorporate the actual accessibility frameworks of the operating system(s) your targeting. Egui was doing this at one point I think but I'm pretty sure it's either broken now or just doesn't work all that well.

There are libs that function as a messenger between your "hack" and the OS on this.

You don't lose anything.

This is but my opinion, but toolkits tend to be opinionated piles of **. Talking directly with the GPU to paint stuff is often just saner to me.

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

#95

Post by Animats »

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 things above or to the left to adjust. But originally, that didn't work. You pretty much had to lay out widgets down and to the right. This is fast and simple. Lots of stuff didn't work, such as scrolling text boxes with line wrap.

But users doing ordinary GUI work are demanding more and more layout features, and won't stop until they get browser level layout. Overhead is increasing.[1] This is a problem in Rust game land, which is tiny. At some point, someone may need to fork Egui and create Egui-lite.

[1] https://github.com/emilk/egui/issues/7059

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

#96

Post by halfcat »

pixelpoet wrote: post #31
user____name wrote: post #17

Earlier quoted context omitted.

Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.

I really wish this were built into imgui as a first-class use case instead of requiring a hodgepodge mix of unofficial hacks. I recall the author posting an imgui update saying this will be an officially supported mode, but AFAIK it's still not the case. Otherwise I would be building all my applications with imgui going forward. Re-rendering the screen, even if it's fast, incurs a lot of memory bandwidth to draw ever…

Does ImGui work on mobile? I’ve seen it run in web assembly on mobile but typically none of the keyboard inputs work (the mobile keyboard doesn’t pop up, so effectively it’s not usable, at least in that approach).

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

#97

Post by piker »

nopelynopington wrote: post #59
piker wrote: post #19

Earlier quoted context omitted.

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although t…

I'm also thinking of building a word processor so I'd be interested to see what you're working on if you fancy sharing?

Sure, it's https://tritium.legal/preview

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

#98

Post by dotancohen »

merksoftworks wrote: post #7

So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where you know you need a small amount of immediate visual feedback and tweaking parameters for it to be useful to the end user. Flutter answers questions about more robust UI. It's good that you chose the right tool for the job and more people should know that there…

  > egui is great for projects where the application runtime is short lived
What is good for a long-lived application, such as an email client? I'm looking for something that fits the same place that Qt fits in the Python world.

Accessibility and keyboard shortcuts are of extreme importance.

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

#99

Post by WhyNotHugo »

mort96 wrote: post #13
Aeolun wrote: post #9

Earlier quoted context omitted.

If your UI is fast enough, why not in complex UI’s either? I’d say it gives you good motivation to keep your UI handling code as fast as possible.

Doesn't egui always re-render? I like my idle apps to be doing nothing, I don't want them running their render loop in the background

I suspect (and hope) you can block the main loop if no events are received. This avoids re-rendering if the UI is not visible and no interaction has happened.

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

#100

Post by miki123211 »

ethin wrote: post #88
piker wrote: post #19

Earlier quoted context omitted.

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although t…

Accessibility problems are something both retained-mode and immediate-mode UIs have generally. I've found that you can kind-of hack it together but the best route is to incorporate the actual accessibility frameworks of the operating system(s) your targeting. Egui was doing this at one point I think but I'm pretty sure it's either broken now or just doesn't work all that well.

The problem with immediate mode is that most a11y frameworks expect all UI elements to have a stable identity.

Imagine you have a to-do list of 100 items. What happens when a remote user drags and drops item 100 to lie between items 1 and 2? In retained mode, that's clearly communicated to the UI toolkit; the widget representing that todo is told to change its position in the list. In immediate mode, you can't just destroy and re-create the a11y tree on each render. You need some kind of tree diffing algorithm to figure out that it's one op (move item) instead of ~200 ops (change the name and checkbox state for all items between 2 and 100).

Post reply on HN