Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

121–130 of 148 posts

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

#121
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…

While I agree that the maintainers of any project have to know when to say no.

If your UI lib is not doing scrolling text boxes with line wrap, can't have different alignments, doesn't have a solution for context menus, then what good is it?

I remember that I essentially had to code it myself a few years ago, but I can't remember if it was egui or imgui.

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

#122
post #119

Earlier quoted context omitted.

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.

This doesn't strike me as the kind of challenge a tool/product can address.

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

#123
post #13
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

You typically set it up so that it does not re-render when it's idle. Or at least not at 60fps.

By the way once upon a time, visual studio code I think it was, was using like 20% cpu when idle just because of the blinking cursor, fun.

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

#124
post #118
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

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

Right. The whole point of Egui was supposed to be that it was a game renderer, a text and button overlay on the game graphics. Not the entire screen. That's why it's immediate mode. It's supposed to redraw on every game frame. Most UI programs don't need or want that.

But it was better at the basics than anything else in Rust, so it caught on for routine non-game programs. And here we are.

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

#125
post #5

I still prefer good old GUI frameworks with WYSIWYG designers.

Funny you should say that. I remember using a Microsoft product back in the '90s that featured WYSIWYG forms. As a programmer, though, you couldn't imagine my joy at discovering I could define and configure the UI in code instead! It felt magical and far more powerful.

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

#126

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

> iced is cross platform

How well does it integrate with Androids APIs or even IOS, can I make a full blown app with it. I believe the main reason why people use FFI to interface Rust and Dart/Flutter for mobile development is because Rust does not have an Android/IOS framework with the higher level APIs it just has native APIs (fs, io..)

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

#127
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…

Not a rust developer, but this seems like an opportunity for Egui to have switchable layout engines.

If you want a simple, one pass layout that super fast, you use the fast-and-dumb-on-purpose-engine. If you want a fancy dynamic scaling layout with breakpoints and blah blah blah, you use the whole-damn-browser-engine.

Thinking along the lines of geometry managers in Tk. Or wxWidgets Sizers.

https://wiki.tcl-lang.org/page/Geometry+Managers

Maybe I am missing something basic and this won't work/doesn't address the problem.

But maybe there's good prior art to learn from here.

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

#128

I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function…

I don't understand what you mean by frontend and backend when you mention ffi. Is this backend in a remote server or just on the same app? I used proto buf with rust, I had a rust client that spoke to my flutter frontend via dbus. The rust client connected to my remote server via a web socket and all messages were wrapped in protobuf and sent as binary. Made everything a lot more concrete... But it basically forced m…

I guess a better term for it would be frontend and business logic. On iOS and Android the business logic (backend) is run using go mobile bindings and are imported directly into the native framework. For Windows, Mac and Linux, it runs as a gRPC daemon in the background. You could use C bindings for PC, but those seemed like a hassle, and I need a daemon anyway.

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

#129
post #51

I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function…

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.

Yeah! I'm using a gRPC daemon on PC and go mobile bindings on mobile.

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

#130
post #55
post #53

Earlier quoted context omitted.

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges. I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.

Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.

I've never heard of ConnectRPC before! Will check it out.
Post reply on HN