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

41–50 of 148 posts

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

#41

Post by the__alchemist »

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…

I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.

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

#42

Post by the__alchemist »

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 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, or have a per penalty from constant renders. Or try something else to be clever. (Maybe have it update at a low rate if not focused? I think that's the move...)

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

#43

Post by newswangerd »

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 via the flutter FFI that takes in a binary array and then converts it to a protobuf object. This gives me a nice separation of concerns between my business logic and frontend while also providing easy to use objects for the front and backend.

Not sure that I'd recommend this approach to everyone. Protobuf code generation can be finicky to set up, but I'm doing it so that I can access go's rich array of libraries in my app.

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

#44

Post by mtndew4brkfst »

ogoffart wrote: post #28
airstrike wrote: post #23

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs

Since others are sharing Rust GUI libraries, I’ll mention Slint [ https://slint.rs ] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

Anyone considering it will need to decide for themselves how to feel about it, but I think it's important to prospective users to highlight that the current licensing model for Slint requires either GPL3-compatible licensing of your work, advertising for Slint within your own software, or paying ongoing licensing fees and/or royalties.

https://github.com/slint-ui/slint/blob/master/FAQ.md#licensi...

I only mention this because those constraints are notably more restrictive than the vast majority of the Rust crate ecosystem.

I take no particular stance on whether this is a fair or good practice or about the technical suitability of Slint beyond this concern, I just think it's a hurdle for most people so they should be made aware early and often.

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

#45

Post by mgerdts »

dark__paladin wrote: post #39

I'm not a UI dev but I have messed with Qt some. Does egui or some other rust framework the same native look that Qt does?

From https://github.com/emilk/egui?tab=readme-ov-file#non-goals

Non-goals

* Become the most powerful GUI library

* Native looking interface

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

#46

Post by turtlebro »

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…

That's a perfectly fine approach, Protobuf strength is exactly these kind of use cases.

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

#47

Post by airstrike »

lazypenguin wrote: post #40

There’s a big advantage to having your whole application in one language. I’m not sure the experience of egui on mobile though but egui is great to use as a developer Pros - Solid widget set - Easy to get started - Less state management - Easy to make custom widgets - Active community and crates (e.g docking view, tables, etc.) - Fast to build new Ui Cons - Harder to do layouts (has multipass and some flexbox crates…

iced now has hot reloading :tada:

https://github.com/iced-rs/iced/pull/3000

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

#48

Post by alkonaut »

jenadine wrote: post #24
feverzsj wrote: 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.

WYSIWYG doesn't necessarily mean you are limited to using some designer and can't edit code. It's enough (and better) to have a live preview, than a full designer. It just means you see live what the code does, at the point when you write it, not later when you run it.

When hand-writing XAML or similar, it's great to see the UI created live. Like editing markdown and seeing the preview, versus editing markdown and not seeing the preview.

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

#49

Post by the__alchemist »

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…

Hah yea. I just did a deep dive into protobufs and RPC for an embedded application. Left learning a lot, and with a headache. Part of it was because this was using heapless, and I got errors until I configured the generator to use the right Vec sizes.

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

#50

Post by the__alchemist »

ogoffart wrote: post #28
airstrike wrote: post #23

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs

Since others are sharing Rust GUI libraries, I’ll mention Slint [ https://slint.rs ] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

I love how y'all target embedded. I love EGUI for PC applications, but will try Slint next time I'm doing an embedded device that has a display.
Post reply on HN