Live data from Hacker News

I Switched from Flutter and Rust to Rust and Egui

jdiaz97.github.io

141–148 of 148 posts

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

#141
post #88

Earlier quoted context omitted.

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

> In immediate mode, you can't just destroy and re-create the a11y tree on each render

You don't need to do it each render, just when something structural changes, right?

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

#143
post #90
post #62

Earlier quoted context omitted.

That's not true, it only re-renders if there's an input event or an animation running. This is very easy to see if you just put a `println!` in your UI logic. This is also mentioned in the gui docs here https://github.com/emilk/egui#why-immediate-mode : > egui only repaints when there is interaction (e.g. mouse movement) or an animation, so if your app is idle, no CPU is wasted.

Iiuc, a tiny clock in the top right corner of the screen will trigger O(n) work where n is the number of elements on the entire screen. On every change of the clock, e.g. every second. This may be more if there are smooth animations, e.g. 25 times per second if that is the animation frame rate.

Sure, but it will consume less CPU than an idle instance of Electron. Or the effort it takes to redraw a React app even once.

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

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

I don't see how the bug you linked is relevant? It's a bug that will be presumably fixed; not an increase in overhead due to layout.

Did you just search for bugs containing "CPU usage" and not actually read it?

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

#145
post #86

> A quick Google search with "flutter setstate is not refreshing" reveals a struggle that you will face quite often when running Flutter. It sounds like an easy fix, but the nature of Flutter using a bunch of nested Widgets creates, naturally, lasagna code that makes it hard to reason about this. Can you expand on this OP? I've never had problems with `setState` nor "lasagna code" in Flutter. From a quick search I mo…

State management in flutter can be done in so many ways so I get why it could feel complex, we’ve used Hooks a lot and it simplified a ton of stuff. Can also go the whole BLOC route too. Having issues with setState means you’re doing something that’s an anti-pattern

Yeah I think the point is that you have to become a state management expert in Flutter... even if the end result is not very complex there are so many options and so many pitfalls you still have to do a ton of thinking and learning to get there.

With egui you pretty much don't have to think about it at all.

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

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

Nah, if you've used the old Qt Creator QtWidgets designer there's no way you could say that. Using code is barbaric in comparison.

We aren't talking Dreamweaver here.

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

#147

Earlier quoted context omitted.

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.

Have fun! Note that it is GPL-licensed. Also, note that the "main" branch is for a very old Dart/Flutter version (but it does correspond to what's in the App Store and on the site today).

I've been working on a separate branch, which finally builds (there were 1100+ errors), but I'm still working through iOS/macOS build things for it before merging it to main. (I've sadly had to abandon the Android build, because Google Play was a comparative pain, and FluidSynth upstream kept breaking the Android build I set up for them. But I'm reviving the project for iOS, macOS, and web at least.)

Here's the branch: https://github.com/JonLatane/BeatFlutter/tree/update-to-late...

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

#148
post #93
post #89

Earlier quoted context omitted.

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

You should worry, system users are relied on to effectively separate privileges even in "single-user" desktops. This has led to privilege escalation before, not to mention the potential for browsers to access these ports [0].

That said, a random password should be enough protection, even if it isn't the cleanest solution.

[0]: e.g. https://palant.info/2020/06/22/exploiting-bitdefender-antivi...

Post reply on HN