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

71–80 of 148 posts

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

#71

Post by andsoitis »

the__alchemist wrote: post #42
mort96 wrote: post #13

Earlier quoted context omitted.

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

> 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

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

#72

Post by written-beyond »

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…

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 me to build my own much shittier version of gRPC. Since, if the wan for your network was every killed the client was notified too late and you'd end up with missing messages if the network buffer got filled. We added a message id and acknowledgement process with sqlite backing up each message.

I still have nightmares about why I built that.

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

#73

Post by ogoffart »

mtndew4brkfst wrote: post #44
ogoffart wrote: post #28

Earlier quoted context omitted.

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

We're building Slint as a business. It takes a lot of time and effort to maintain and improve it. We're not looking to support users who want to use it in proprietary software and give absolutely nothing back, not even a small credit. That doesn’t feel like too much to ask. (Even the MIT license requires including a copyright notice.)

Honestly, it’s a bit sad that for some, using libraries for free isn't enough, they also expect to do so without even mentioning the project.

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

#74

Post by mhast »

mattmanser wrote: post #34
jenadine wrote: post #30

Earlier quoted context omitted.

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 editors stopped trying to do WYSIWYG. It's not that the demand isn't there. They stopped trying about the time monitors went from a couple of quite similar fixed widths of 600/768 to more. Then smart phones came along and really killed the WYSWIG editor. I worked with Silverlight for a year in the late 2000s, and even by then WYSWYG editors were struggling. You sorta still had some for flash and stuff. They w…

On Android (and I'm pretty sure iOS) you have WYSIWYG editors for UI layouts for jetpack compose and flutter (and on iOS it would be Swift UI).

These all go direct to code instead of XML or some other extra layer of code.

What I would probably focus on is better integration with Figma and similar tools. Use that to do the WYSIWYG part and then generate corresponding code (possibly with LLMs).

The biggest limitation you tend to have in WYSWIG is that at some point you really need to have the true data the user sees to ensure everything looks good. That becomes a bigger hassle than coding the UI manually. (Particularly when doing multi-platform things.)

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

#75

Post by osa1 »

airstrike wrote: post #23

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

I don't have too much experience in GUIs and I've been looking at iced and gpui recently for a new GUI application.

iced has some nice looking apps written using it, but they all seem "laggy" on my high-end Linux box somehow. I'm wondering if this is a limitation of the immediate mode GUIs, or something related to my system, or an issue in the apps?

For example, drag-and-drops or selecting text with mouse lag behind the mouse cursor.

I'm wondering if I'm not holding it right somehow?

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

#76

Post by mhast »

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 to see UI building come full circle. I started in code (C), then using various XML schemes and now back in code (Kotlin, Flutter, Swift). But a big part of why it's nice now is because C is a pretty horrid language for making modern applications.

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

#77

Post by taeric »

feverzsj wrote: post #5

I still prefer good old GUI frameworks with WYSIWYG designers.

I will forever harp on the idea that we really set web design back by putting so much focus on the HTML. Dreamweaver sites were not great, to be sure. But they had more creativity and design than the majority of what we seem to create nowadays.

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

#79

Post by taeric »

mattmanser wrote: post #34
jenadine wrote: post #30

Earlier quoted context omitted.

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 editors stopped trying to do WYSIWYG. It's not that the demand isn't there. They stopped trying about the time monitors went from a couple of quite similar fixed widths of 600/768 to more. Then smart phones came along and really killed the WYSWIG editor. I worked with Silverlight for a year in the late 2000s, and even by then WYSWYG editors were struggling. You sorta still had some for flash and stuff. They w…

Agreed with your general push here, I think.

I would add that a large part of the push away from it came from not having dedicated design and development teams. Is, I think, why industries such as gaming have stuck to a lot of these workflows. You have art designers creating the assets and hand them off to an integration team that will get them into the game. Tooling is specifically made to integrate the art and the program.

In the web, we seem to have tried to converge all of that tooling into the symbolic text. Works great when it can work. But it greatly limits what you can graphically do. And is largely why we don't design things graphically anymore.

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

#80

Post by mhast »

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…

From what I've seen immediate mode seems suitable for less fancy UI requirements. If you want to start having a framework solve things like animations and such then you'll probably end up with some form of retained mode.

Over my years making UIs I've found most of the bugs you get is due to incorrect state handling in applications. Having a framework you use which is opinionated and helps you solve that is pretty nice. (If your UI requirements are such that you need it.)

Post reply on HN