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

131–140 of 148 posts

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

#131

Post by newswangerd »

pseudocomposer wrote: post #52
newswangerd wrote: post #43

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…

This is what I did for BeatScratch! https://beatscratch.io My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.

This is very cool! I'm going to take a look at your code.

I've been playing with the idea of creating a "protobuf db" library that would allow you define schemas in protobuf and then query them with something akin to an ORM. It wouldn't make any sense for large databases, but for embedded applications that only need to store a few MB of data, it would be perfect.

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

#132

Post by lukeh »

pseudocomposer wrote: post #52
newswangerd wrote: post #43

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…

This is what I did for BeatScratch! https://beatscratch.io My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.

We do something similar for the UI for our audio hardware product. AES70 control messages are sent over Flutter platform channels to a Swift backend. The glue is open source - GitHub.com/PADL/FlutterSwift.

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

#133

Post by andsoitis »

hoppp wrote: post #113
andsoitis wrote: post #71

Earlier quoted context omitted.

> 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.

which is why, I think, it is better to not have to do that manual rendering gymnastics when retained mode does it for you.

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

#134

Post by Klonoar »

troupo wrote: post #118
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

Consider me ignorant: why do you need two passes for table layout?

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

#135

Post by merksoftworks »

dotancohen wrote: post #98
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.

Some of the QT people have forked off and started working on slint[1], iced[2] is the most mature gui in the rust ecosystem right now (in my opinion), but still lacking in some ways, including portability to mobile and component libraries are sort of against the design principle so it's allergic to network effects. Iced is built on some pretty orthodox elm architecture principles by some very talented and devs - but they leave very little room for impurity.

[2] https://iced.rs/ [1] https://slint.dev/demos

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

#136

Post by mort96 »

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

Breaking: software development require developers to understand what the system does, more at 11

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

#137

Post by mort96 »

andsoitis wrote: post #133
hoppp wrote: post #113

Earlier quoted context omitted.

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

which is why, I think, it is better to not have to do that manual rendering gymnastics when retained mode does it for you.

Let's not pretend that retained mode is somehow easy. Procedurally changing the system's state in response to events gets pretty complex. A philosophy which approximates the II as a function of state is tempting, in a lot of ways. As someone with a fair amount of experience of both retained mode and immediate mode UIs, I can't confidently say that retained mode requires less "mental gymnastics" than immediate mode.

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

#138

Post by monocasa »

Animats wrote: post #124
troupo wrote: post #118

Earlier quoted context omitted.

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

> 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.

Seriously. The main tale I think is how awful Rust's story on GUIs are such that most Rust users prefer a pretty awful GUI library because it's somehow better than everything else. And that's coming from someone who's favorite language is easily Rust.

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

#139

Post by airstrike »

bit1993 wrote: post #126
airstrike wrote: post #116

Earlier quoted context omitted.

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..)

iced targets all major desktop platforms, not mobile

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

#140

Post by jlokier »

Klonoar wrote: post #134
troupo wrote: post #118

Earlier quoted context omitted.

> 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

Consider me ignorant: why do you need two passes for table layout?

In a HTML table, unless given a fixed width, the width of each column depends on the natural widths of all the columns, and those widths depend on the content of every cell in the column, and those cell natural widths depend on word-wrapped layout as well as other layout of content in each cell, including nested tables recursively.

In other words, with default styling you have to calculate natural widths of every cell in the whole table before you can begjn layout out even the first cell of the table.

There are style settings you can use which change this, and allow layout of early cells or rows to complete without depending on later cells.

(Also the height of each row can depend on the height of the content of every cell in the row. But that's local to each row so it's a relatively small dependency.)

Post reply on HN