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

81–90 of 148 posts

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

#81

Post by jcelerier »

mhast wrote: post #76
rubymamis wrote: post #10

Honestly, nothing beats QML for UI development. Such an underrated technology.

After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind. Spreading your code over multiple languages means you now have a bunch new fun edge cases to deal with when things get stuck and don't update correctly. With everything in one language that means all debuggers and other tools work the same regardless of where in the app I'm debugging. I've found it fascinating…

> After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.

this is completely unrelated to what QML is.

QML is a complete language which allows to build both the application logic and the layout, which extends javascript with native reactive data binding. QML+QtQuick is equivalent to Dart+Flutter, or JS+HTML+CSS+React for instance.

https://www.qt.io/product/qt6/qml-book/ch04-qmlstart-qml-syn...

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

#82

Post by eviks »

jenadine wrote: post #30
alerighi wrote: post #25

Earlier quoted context omitted.

In the end the WYSIWYG would produce an XML file that you can put under version control. All depends on the UI of the thing your are building, if what you are building only needs to be functional and nobody cares about the UI (that is always the case of internal use software, that needs to have a good UX but who cares if it has the Windows 95 style controls, like machine HMIs, ERP software, etc.) WYSIWYG (like Visual…

But those files are often hard to read and merge. If WYSIWYG really worked well, why aren't more big projects or popular frameworks using it? Why do you think it's become less popular over time?

Because it's much harder to do better design, so often over technological soft good things fall through the cracks.

Like, why aren't more big projects use accessibility as hot reloading if those are so great?

Or, a simple illustration to your reliability point - part of the reason the files are hard to read is because XML is an atrocious format. And also tools like VS aren't even smart to preserve user formatting, so you can't even manually make it easier to read. Why hasn't it been changed in so many years?

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

#83

Post by bunderbunder »

zigzag312 wrote: post #11
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…

Is there any technical limitation that accessibility support is usually lacking in immediate mode GUIs? Or it's just a lot of work? Flutter, which does its own rendering of controls, needs to implement a lot of accessibility features by itself.

Just shooting from the hip, it's a lot of work, but even more importantly it's running slightly counter to the core motive behind many immediate mode GUI toolkits, which is to be as minimalist and easy to work with as possible.

For my part I have some accessibility needs that typically aren't well supported by immediate mode GUIs. And my personal take is, this is 100% fine. If you're working on a thing where an immediate mode GUI toolkit is even a realistic option, you're probably also in a situation where it's exceedingly unlikely that making your hobby project or prototype or whatever harder to work on will cause a net increase in humanity's overall sense of wellbeing.

And if something comes up and you do end up needing to make changes for someone else's benefit, hey, good news, immediate mode GUIs are really, really easy to hack on.

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

#84

Post by [deleted] »

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…

[deleted]

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

#86

Post by doawoo »

paldepind2 wrote: post #12

> 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

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

#87

Post by foobiekr »

nu11ptr wrote: post #51
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…

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.

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

#88

Post by ethin »

piker wrote: post #19
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…

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.

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

#89

Post by dvdkon »

nu11ptr wrote: post #64
klabb3 wrote: 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.

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.

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

#90

Post by amelius »

Boxxed wrote: post #62
mort96 wrote: post #20

Earlier quoted context omitted.

I agree that this is not a necessary downside to immediate mode GUIs, but we're talking about egui specifically here. AFAIK, egui always redraws at some relatively high rate even when nothing is happening. (I'm having trouble finding documentation about what that rate is though.)

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.
Post reply on HN