Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust cross-platform GPUI components

github.com

Post reply on HN
Print view View original

91–100 of 225 posts

Re: Rust cross-platform GPUI components

#91

Post by tredre3 »

samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

> * Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using.

In my experience that point is absolutely correct. Qt is good but big. You usually end up with 30-40MB of it.

Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of those. Maybe 2.

Yes you could build Qt yourself with various flags, or possibly do a static build with LTO might help. But that's not the typical way Qt is used.

Re: Rust cross-platform GPUI components

#92

Post by wiz21c »

matu3ba wrote: post #42
nu11ptr wrote: post #2

This looks to be one of the most complete Rust UI creates (in terms of available widgets/components), but unfortunately has almost no usage (yet). I do see their docs are coming along now. Another very complete one is fyrox-ui used by the fyrox game engine: https://crates.io/crates/fyrox-ui . Again, not really used/known outside of fyrox. The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus…

Since you think the UI scene is maturing: Where do I find 1. design docs and 2. debugging infra docs (Validation, Testing, Stepping, Logging, Tracing, Recording, Scheduling, Reversal Computing as typical ones) and/or how to apply them ?

scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?

Re: Rust cross-platform GPUI components

#93

Post by saghm »

keyle wrote: post #49
mdhb wrote: post #28

Earlier quoted context omitted.

Same model as Flutter which is a million times more pleasant to write and mature at this particular use case which I don’t actually think Rust is well suited to generally speaking.

I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.

> I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform.

I must have a very different understanding of the word "arguably" than you. To me, it's arguable whether Swift itself is a viable cross-platform language today. SwiftUI, on the other hand, supports literally zero devices not manufactured by Apple.

Is it really arguable that when people say "cross plaform" when referring to a GUI framework, they aren't counting "both macOS and iOS, but not any of Windows, Android, Linux, web"? It might be accurate from an pedantic standpoint, but I have trouble imagining a context where someone would bother using that phrase as a qualifier if they understood it that broadly.

Re: Rust cross-platform GPUI components

#95

Post by samiv »

tredre3 wrote: post #91
samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

> * Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using. In my experience that point is absolutely correct. Qt is good but big. You usually end up with 30-40MB of it. Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of those. Maybe 2. Yes you could build Qt yourself with various flags, or possibly do a stati…

Yes and no.

I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.

I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.

Re: Rust cross-platform GPUI components

#97

Post by WD-42 »

samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

In my experience QT designer was awful to use. It’s probably fine if you are doing super vanilla layouts and widgets but as soon as my team started implementing custom css (or whatever the qt equivalent is called) things went off the rails. We pretty quickly abandoned to the tool completely to write the ui files by hand. They ended up much smaller and cleaner as a result. For some reason the designer seemed to add loads of unnecessary cruft.

So yea I can understand why they aren’t a priority.

Re: Rust cross-platform GPUI components

#98

Post by paulddraper »

samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

WYSIWG and code are almost always if not always not done well together.

Re: Rust cross-platform GPUI components

#99

Post by Arch-TK »

pjmlp wrote: post #87
samiv wrote: post #82

Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore? One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow. Secondarily this comparison table has several problems when it comes to Qt. * The…

They do, but you have to look into the right ones, from ex-Qt employees, https://slint.dev/ You can make use of Figma integration for something similar to Qt Design Studio. Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be. You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, ev…

The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.

Re: Rust cross-platform GPUI components

#100

Post by Boxxed »

nu11ptr wrote: post #14
airstrike wrote: post #8

Earlier quoted context omitted.

> The Rust UI scene is maturing, but the most popular options (iced, egui, dioxus, slint, etc.) aren't even the most complete component-wise atm as far as I can tell. I think part of the issue is that they're still changing so much as we speak. But there's real momentum here and n=1 but I've been able to build incredibly rich, enterprise-ready UI with Rust today.

> I've been able to build incredibly rich, enterprise-ready UI with Rust today. Which UI crate did you use? The word "enterprise" caught my eye. So far I haven't found a Rust UI crate that I found rich enough, so I'm curious your experience.

I've had a lot of success with egui. We've needed to do some weird stuff and I've always been pleasantly surprised to see that the API is expressive enough that we're always able to work within the bounds of the library. Great documentation too.

I have a feeling iced would work similarly well but the documentation situation wasn't as good last I checked.

Post reply on HN