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

151–160 of 225 posts

Re: Rust cross-platform GPUI components

#151

Post by the_duke »

nicoburns wrote: post #116
the_duke wrote: post #68

Earlier quoted context omitted.

Even in Dioxus the usefulness is somewhat limited right now though. (dioxus-7-rc.3) It usually only works when reordering elements, or changing static values (styles, attributes, etc). Which, to be fair, does speed things up a lot when tinkering with small details. But 70%+ or so of my changes still result in recompiles.

Are talking about the "hotreloading" or the "hotpatching"? (There are two separate mechanisms) The hotreloading just does RSX and assets, and is very fast, the hotpatching is a recompile (no getting around compiling Rust code), but it should be a faster one, and in many cases it should be able to maintain application state. I've been able to get the hotpatching to work for use cases like "extract some UI code" into a…

Ah, thanks for the hint.

I indeed was not enabling it.

I'll give it a try!

Re: Rust cross-platform GPUI components

#152

Post by iknowstuff »

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?

Re: Rust cross-platform GPUI components

#154

Post by matu3ba »

wiz21c wrote: post #92
matu3ba wrote: post #42

Earlier quoted context omitted.

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 ?

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-reversibility", because distinguishing between "reversible computing with known timings" and "reversible computing with unknown timings" becomes very confusing. So I'd phrase it somewhat differently, but did not come up with better naming yet. Context: https://en.wikipedia.org/wiki/Reversible_computing and https://en.wikipedia.org/wiki/Time_reversibility.

Re: Rust cross-platform GPUI components

#155

Post by swiftcoder »

michaelmior wrote: post #149
swiftcoder wrote: post #105

Earlier quoted context omitted.

> but unfortunately has almost no usage gpui itself is spun out of the zed editor, so I'd say it probably has more real-world usage than the majority of rust UI crates

GPUI yes, but I'm not so sure about GPUI Component which is what I assumed the parent was talking about.

I don't know that it's all that meaningful to discuss the component library as if it were its own UI framework. None of the other rust UI frameworks have distinct component libraries with distinct usage data either

Re: Rust cross-platform GPUI components

#156

Post by amelius »

berkes wrote: post #36
wongarsu wrote: post #11

Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them. This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like…

> lose styling consistency Yes. And that is (almost always¹) a good thing. Only the designers of an app, product-owners etc. want their app to "look consistent over platforms". 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. ¹ Obviously some software excepted. E.g. categories like "e…

Actually users think functionality is 1000x more important than what it looks like. Since making things look nice takes away dev time from functionality, what it looks like doesn't matter much (above some minimum expectation of course).

Re: Rust cross-platform GPUI components

#157

Post by cultofmetatron »

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…

> Bevy is just a very good, modern graphics tech demo, not something suitable for developing actual games.

I would agree with you that bevy is not fit for making a commercial game. but not because its not capable. Its just NEW. we are only now starting to see commercial games come out with godot and thats 11 years old. bevy came out what, late 2021? give it some time. It still needs more workflow tools, a level editor stable documentation and a bunch of other things.

It will get there. it just takes time.

Re: Rust cross-platform GPUI components

#158

Post by _bent »

pjmlp wrote: post #88
_bent wrote: post #48

Earlier quoted context omitted.

macOS is the only OS you can write native applications for. On Linux there are with GTK and QT two different GUI frameworks that could be considered native on some distros. And on Windows there are so many different frameworks and approaches used by MS for the shell that even a Webview could be considered native

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/

Re: Rust cross-platform GPUI components

#160

Post by embedding-shape »

RMPR wrote: post #144
rtfeldman wrote: post #131

Earlier quoted context omitted.

As of August 2025, Zed had 150K monthly active users. That was before it supported Windows; the number is much higher now (although not publicly reported). I'd be very surprised to learn that any other Rust UI crate has more real-world usage than GPUI! Source: https://sequoiacap.com/article/partnering-with-zed-the-ai-po...

Iirc Cosmic Desktop uses Iced

Kraken seems to have a desktop application for trading made in Iced as well.

I wonder if there are more Cosmic Desktop + Kraken desktop users than Zed Editor users?

Post reply on HN