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

181–190 of 225 posts

Re: Rust cross-platform GPUI components

#181

Post by theLiminator »

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…

For better or for worse fyrox is not something too novel/new. So people don't really see a reason to use it over godot or other engines.

Doesn't mean bevy is better or anything, just that because it's so different people tend to flock to it.

Re: Rust cross-platform GPUI components

#182

Post by iknowstuff »

phkahler wrote: post #166
iknowstuff wrote: post #152

Earlier quoted context omitted.

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?

No advantage to it. Worse quality code to gain what? A smaller number hiding ultimately the same amount of code? Also, since the unit of compilation is a crate, fewer opportunities for concurrent compiling.

Re: Rust cross-platform GPUI components

#183

Post by filleduchaos »

the__alchemist wrote: post #180
filleduchaos wrote: post #172

Earlier quoted context omitted.

I'm not sure what exactly you're expecting from a game engine that is not even yet six years from its first commit , but nevertheless - while it came out in 2024, not 2025, Tiny Glade[0] is built with Bevy. https://steamdb.info/app/2198150/

Only the ECS.

I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of.

And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor in Pounce Light building a custom renderer.

Re: Rust cross-platform GPUI components

#184

Post by debugnik »

diath wrote: post #129
zelphirkalt wrote: post #128

Earlier quoted context omitted.

That's OK though. Other people will then be able to use Bevy for actually making a game. And to be fair, not every great engineer is a great writer, artist, composer, or any other role one might like to have on board for making a game.

> Other people will then be able to use Bevy for actually making a game. Nobody makes games in Bevy though, Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games. Even the biggest title out there, Tiny Glade, is just a level editor with precisely zero gameplay features. Bevy's "popularity" (on social media, not among game developers) is entirely hype-driven by people…

Tiny Glade is a great sandbox that must not have been easy to implement, game or not.

However, it doesn't even use Bevy's renderer, but their own: the devs mostly just care about its ECS. So it definitely isn't the showcase Bevy is looking for.

Re: Rust cross-platform GPUI components

#185

Post by the__alchemist »

filleduchaos wrote: post #183
the__alchemist wrote: post #180

Earlier quoted context omitted.

Only the ECS.

I fail to see how that's particularly relevant, considering that this discussion started with the implication that ECS specifically is a neat fad that Bevy users will eventually get bored of. And again, I am not sure what exactly people are expecting of a game engine that started development in 2019. Development of Tiny Glade itself started less than three years after Bevy's first commit, which was an obvious factor…

It's relevant because the post I replied to is misleading on its own.

Re: Rust cross-platform GPUI components

#186

Post by pseudalopex »

anthony-eid wrote: post #148
jacquesm wrote: post #17

Earlier quoted context omitted.

"Let's get the volume first, then worry about accessibility" That's the typical answer to these questions. Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.

Accessibility is apart of gpui roadmap.

> Unfortunately, unless you bake it in from day #1 that's not so simple to fix afterwards.

Re: Rust cross-platform GPUI components

#187

Post by airstrike »

bbkane wrote: post #175
airstrike wrote: post #123

Earlier quoted context omitted.

I have built it. It hasn't existed for long enough for me to say I've maintained it for an extended period of time, but then again I did not claim that. Nor did I use the word "certain". There's no certainty in life. I hear your point, but it's important to note I'm not making those claims and I don't think all of that needs to be true for it to be some value of "enterprise-ready". You and I may disagree on the meani…

Can you provide more details? Links to the implementation of available? Framework you used? Pain points?

I used the `iced` framework and I can't link to it because it's not available to the general public yet.

Pain points were learning to think in The Elm Architecture early on and creating very complex custom widgets of my own (think a spreadsheet editor, for example)

I made some tiny apps available on my github as I was learning Rust and the library. None really meet the enterprise grade hurdle but show some of what's possible with little code. If you spend a little while longer you can make them much more polished, obviously. I kept them "unpolished" so they would be even easier for beginners to follow

https://github.com/airstrike/iced_receipts

https://github.com/airstrike/pathfinder

Re: Rust cross-platform GPUI components

#188

Post by matu3ba »

nathansobo wrote: post #163
matu3ba wrote: post #154

Earlier quoted context omitted.

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.

Thanks. Sounds like a good developer experience attempt.

Re: Rust cross-platform GPUI components

#189

Post by comex »

rafram wrote: post #137
anonymous908213 wrote: post #67

Earlier quoted context omitted.

> Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native. I don't think what you posit is true at all, at least not in 2025. Windows itself has abandoned consistency between its native applications, with more custom and modern styling that looks nothing like what you get out of the box with…

> Maybe it's different in MacOS land It is. Windows has always had consistency issues; macOS hasn't.

macOS doesn't have (many) consistency issues in the OS itself or first-party apps. But when it comes to the third-party apps people use? Totally inconsistent. Most of them are either webapps accessed through the browser (Google Docs), webapps accessed through Electron shells (Discord, Slack, Zoom, 1Password), or non-webapps that nevertheless have their own bespoke UI (Adobe, Microsoft Office, browsers themselves other than Safari). I'm not a fan of the situation, but that's the way it is.

I do fully admit these consistency issues were less bad in the past.

Re: Rust cross-platform GPUI components

#190

Post by aryonoco »

Really interesting, and look forward to playing with it

However I find it bizarre that in the comparison table, Qt’s licensing is described as “Commercial”. Yes Qt is available under a commercial license but it’s also available under LGPL 3.

Yes that means you can even build proprietary applications linking against the LGPL license.

That makes that table misleading and borderline FUD.

Post reply on HN