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

161–170 of 225 posts

Re: Rust cross-platform GPUI components

#161

Post by dicytea »

Buttons840 wrote: post #107
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…

Fyrox is such a blackpill for me (makes me doubt the Rust gamedev scene), because Fyrox appears to be the most mature Rust game engine, but nobody uses it or cares about it. Instead everyone is excited about the Entity-Component-System in Bevy, but once all the rough edges of Bevy are smoothed out, people excited about the ECS are going to realize they don't actually want to make art, or create game mechanics, they w…

I mean I get this in theory.

But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).

On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.

But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.

Re: Rust cross-platform GPUI components

#162

Post by Klonoar »

andrewl-hn wrote: post #90
miki123211 wrote: post #53

Does this implement accessibility at all? This is often a problem with Rust UI frameworks, they may look beautiful, but the moment accesibility becomes a requirement, the whole app needs to be scrapped and rewritten in something more mature.

Not really. This UI toolkit is based on GPUI library build by Zed editor team, and while they improve accessibility over time (like, improving contrast and stuff), it's opaque to screen readers. At the moment if you want to have good accessibility story you should probably look at Slint or Qt (via cxx-qt, for example). And since System 76 picked up Iced for their UI it should receive a11y-related updates, too.

System76 runs their own fork of Iced and commits things back to Iced, but in practice this hasn’t been as much as people seem to think.

Accessibility falls under this: to my knowledge Cosmic has it, Iced does not.

Re: Rust cross-platform GPUI components

#163

Post by nathansobo »

matu3ba wrote: post #154
wiz21c wrote: post #92

Earlier quoted context omitted.

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

Scheduling means to generate enumerations/combinations of possible ui events. If interleaving events are possible and to what degree, then providing a notion of that and/or at least documentation would be helpful. Yeah, although I would define "reversible computing" as how to deterministically undo some computation(s)/effect(s) etc without recording the control-flow and I do not like the notation of "time-reversibili…

GPUI has a mature scheduling story, letting you “block” the main thread on spawned tasks with async/await. It also comes with a deterministic random test scheduler for driving out timing bugs.

Re: Rust cross-platform GPUI components

#164

Post by pjmlp »

_bent wrote: post #158
pjmlp wrote: post #88

Earlier quoted context omitted.

Win32 is the native way, MFC and Windows Forms build on top Win32, UWP is also native as thin layer above Win32 and COM (with some extras). WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.

According to Microsoft WinUi3 and WinUi2 are also native https://learn.microsoft.com/en-us/windows/apps/winui/

Naturally, they build on top of UWP.

There are some details on what that exactly means, but I am on the go for lengthy comments.

Re: Rust cross-platform GPUI components

#165

Post by phkahler »

nu11ptr wrote: post #61
WhyNotHugo wrote: post #59

The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.

I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.

No. On Wayland all of that should be in the compositor. Window sizing and positioning can not be done by the apps, so it makes sense that the controls for that are drawn and handled by the WM. But Gnomes gotta gnome...

Re: Rust cross-platform GPUI components

#166

Post by phkahler »

iknowstuff wrote: post #152
WhyNotHugo wrote: post #59

The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.

Would you rather have 1000 small, composable, auditable dependencies or the same amount of code in a monolithic dump of .hpp files?

How about a few large dependencies and no little ones?

Re: Rust cross-platform GPUI components

#170

Post by the__alchemist »

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…

In terms of its state now, how does it compare to EGUI?
Post reply on HN