[HN Gopher] Rust cross-platform GPUI components
___________________________________________________________________
Rust cross-platform GPUI components
Author : xvilka
Score : 440 points
Date : 2025-10-27 09:44 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nu11ptr wrote:
| 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, slint, etc.) aren't even the most complete
| component-wise atm as far as I can tell.
|
| UPDATE: This honestly looks incredible and makes huge strides in
| the Rust UI landscape. You can run an impressive widget gallery
| app here showing all their components:
|
| https://github.com/longbridge/gpui-component/tree/main/crate...
|
| Just "cargo run --release"
| airstrike wrote:
| _> 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.
| nu11ptr wrote:
| > 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.
| galangalalgol wrote:
| I think you'll find two definitions of enterprise ready.
| People who make UIs and are comparing a UI crate to see how
| it stacks up, and people who write business logic in rust
| and only care that they were able to make a gui work
| without switching to some other language. I would put my
| org in the second situation. Someone bought the thing and
| didn't complain so good enough I guess. We were using egui.
| nu11ptr wrote:
| Ahh, gotcha. Yeah "enterprise" to me meant: "I can
| write/maintain a UI rich/polished enough to pass as a
| 'shrink wrapped' app to my end users".
|
| Thanks for the reply.
| airstrike wrote:
| FWIW that reply was from a different person :D
|
| In my case I did mean "I can write/maintain a UI
| rich/polished enough to pass as a 'shrink wrapped'"
| galangalalgol wrote:
| The notion of shrink wrapped software dates us I think?
| But to that end, I have elements of so many different
| native looks jumbled around in my head all the way back
| to amiga workbench (deluxe paint was the best), that
| anything without really obvious flaws like off centered
| text or unresponsive buttons feels shrinkwrappable to me.
| By my standard any of these looks is enterprise ready. I
| remember someone at MS looking at a gui made by a team my
| friend was on and mocking it for looking like it was out
| of tron with saturated colors on a black background in
| high contrast instead of "modern" 3d grey buttons. It
| looked a lot more like the linked UI than anything MS was
| producing at the time. So there is the fashion aspect of
| it. You want to stand out, but not too much. I think that
| is the aspect I'm unable to judge. If everything is in
| the first or second place I look, I just won't care.
| andsoitis wrote:
| > I did mean "I can write/maintain a UI rich/polished
|
| FWIW, you wrote that you actually HAVE done so, not just
| that you think you could:
|
| " _but I 've been able to build incredibly rich,
| enterprise-ready UI with Rust today._"
|
| Unless one has actually done so, and maintained/extended
| over a period of time, and not solo but with others, I
| don't know that one can be _certain_ that a UI toolkit is
| good enough; certainly, it would be hard to know what
| surprising edges and ergonomics there are to consider in
| one 's evaluation.
| airstrike wrote:
| 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 meaning of that term, and
| that's fine.
| bbkane wrote:
| Can you provide more details? Links to the implementation
| of available? Framework you used? Pain points?
| airstrike wrote:
| 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
| airstrike wrote:
| I used `iced` but admittedly I also used a lot of elbow
| grease. Custom Theme, custom widgets and lots of passion to
| get it to look Just Right.
| nu11ptr wrote:
| Cool. Any publicly available source code? If not, any
| screenshots at least? I'm curious as what Iced is capable
| of (with extra widgets/themes/etc. like you mentioned).
| criticalfault wrote:
| Cosmic is built on iced, so you could look what they
| achieved.
| chiffaa wrote:
| look into Cosmic Desktop and SniffNet as examples, both
| use Iced and IME are very high quality
| airstrike wrote:
| Unfortunately it's closed source and we're invite-only at
| this point so I can't share, but hopefully in a few weeks
|
| I do share screenshots and screen recordings every now
| and then in the iced Discord but I've so far refrained
| from posting about it on HN which is a much bigger
| audience
|
| I suppose the best description of the UI is a mashup of
| VSCode and Figma
| Boxxed wrote:
| 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.
| airstrike wrote:
| The issue with the documentation is a lack of guides or
| tutorials, but the crate is 100% documented and I think
| the examples cover 100% of what 90% of people need.
| Looking at other apps helps too.
|
| And if you're on Discord, the community is 10/10. I'm
| there all the time and always helping newcomers, and so
| are many others.
| the__alchemist wrote:
| Same! I am building a structural biology CAD-like tool in
| Rust (EGUI + WGPU), and it's a great experience.
| nicce wrote:
| > UPDATE: This honestly looks incredible and makes huge strides
| in the Rust UI landscape. You can run an impressive widget
| gallery app here showing all their components:
|
| > https://github.com/longbridge/gpui-
| component/tree/main/crate...
|
| > Just "cargo run --release"
|
| Very impressive! Only thing I am concerned over is that it uses
| around 900 dependencies. But I don't know whether it much for
| GUI applications.
| nu11ptr wrote:
| That did seem excessive to me as well. I do worry about the
| DX of trying to work on an app with this. After each edit, I
| would expect a solid compile time to simply try your work.
| nicoburns wrote:
| I don't think GPUI has it integrated yet, but Dioxus's
| Subsecond tool [0] implements binary hot-patching for Rust
| apps which can help alieviate this problem.
|
| The other thing you can do (which is popular in the Bevy
| community) is to compiile the "core runtime" into dynamic
| library. Then you don't need to recompile that set of
| crates for incremental builds.
|
| [0]: https://github.com/DioxusLabs/dioxus/tree/main/package
| s/subs...
| nu11ptr wrote:
| > The other thing you can do (which is popular in the
| Bevy community) is to compile the "core runtime" into
| dynamic library. Then you don't need to recompile that
| set of crates for incremental builds.
|
| I'm curious as to what this means exactly. Are you saying
| keep the UI stuff in a separate crate from rest of app or
| ???. And just a separate or an actual dynlib? (wouldn't
| that imply C ABI? would make it a pain to interface with
| it)
| nicoburns wrote:
| An actual dynlib (containing the core framework crates
| that typically dont change between compiles (and which in
| C world might be installed as precompiled system
| libraries)).
|
| It doesn't necessarily require C ABI. Rust doesn't make
| any _guarantees_ about stability of the Rust ABI. But if
| you compile the app and the dynlib with the same compiler
| version then it works in practice (and IIRC there are
| enough things relying on this that this is unlikely to
| break in future).
|
| That does mean you need to recompile the dynlib when you
| upgrade the compiler, but that is probably infrequent
| enough not to be a huge issue. Certainly if your aim is
| fast-recompiles in response to e.g. ui style changes then
| it ought to work.
|
| --
|
| A note on the sort of Rust compile times I see for a
| TodoMVC app using my Rust UI framework (412
| dependencies):
|
| - A clean release build (-O3) is 1m 01s
|
| - An incremental (-03) rebuild is 1.7s
|
| - A clean debug build (-O0) is 35s
|
| - An incremental debug build (-O0) is 1s
|
| That's on a 2021 MacBook M1 Pro which is fairly fast, but
| I hear the M4 machines are ~twice as fast. And that's
| also without any fancy tricks.
| nu11ptr wrote:
| I did some quick research. I knew Rust ABI was unstable,
| but I didn't realize you could create Rust ABI dynlib and
| Rust would automatically dynamically link it. For intra-
| app it would work just fine. Neat. Link:
| https://stackoverflow.com/questions/75903098/dynamic-
| linking...
|
| However, I don't see what advantage this gives. You are
| going to specify that dependency in your Cargo.toml just
| like any statically linked crate. Anything that would
| invalidate the cache for a static crate would invalidate
| it for a dynamic linked crate. Iow, it seems like
| separate crates are the magic here, not the linking type.
| What am I missing?
|
| Thanks for the build stats. Those are helpful. I have an
| M1 Max currently.
|
| UPDATE: Good points below. As a dynlib it would create a
| boundary for sure (no LTO, etc.). Worth playing with,
| thx.
| nicoburns wrote:
| > I don't see what advantage this gives
|
| I believe it may "just" be faster link times. Which may
| seem minor, but link times can often dominate incremental
| compile times because it's a slow and (at least
| historically) serial step which is O(total code size)
| even if the actual compilation is incremental.
|
| See mold's linking benchmarks:
| https://github.com/rui314/mold. It can be the difference
| between multiple 10s of seconds with traditional linkers
| vs <2s with newers ones.
|
| There are few strategies for dealing with this:
|
| 1. Is just to use a faster multi-threaded linker. On
| Linux, lld, mold, and wild on Linux are all _much_ faster
| than the traditional ld /gold (and the latter two another
| step above lld). On macOS, the new built-in ld64 is
| pretty good. Not sure what the state is on Windows:
| possibly lld is best?
|
| 2. Is dynamic linking as above. This seems to be faster
| even though the dynamic links need to resolved at
| runtime. I presume because at least the links wholly
| within the dynlib don't need to be resolved.
|
| 3. Is tools like Subsecond (https://github.com/DioxusLabs
| /dioxus/tree/main/packages/subs...) which effectively
| implement incremental linking by diffing the symbols in
| object files.
| the_duke wrote:
| 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.
| nicoburns wrote:
| 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 new component
| that didn't exist before.
|
| Note that the hotpatching is not enabled by default, you
| have to specify --hotpatch when running dx
| the_duke wrote:
| Ah, thanks for the hint.
|
| I indeed was not enabling it.
|
| I'll give it a try!
| adastra22 wrote:
| Incremental compiles should be fast.
| matu3ba wrote:
| 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 ?
| wiz21c wrote:
| scheduling ??? what's that ? scheduling UI events ? Reversal
| computing ? What's that ? You meant reversible computing ?
| matu3ba wrote:
| 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.
| nathansobo wrote:
| 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.
| matu3ba wrote:
| Thanks. Sounds like a good developer experience attempt.
| swiftcoder wrote:
| > 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
| rtfeldman wrote:
| 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...
| RMPR wrote:
| Iirc Cosmic Desktop uses Iced
| embedding-shape wrote:
| 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?
| michaelmior wrote:
| GPUI yes, but I'm not so sure about GPUI Component which is
| what I assumed the parent was talking about.
| swiftcoder wrote:
| 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
| Buttons840 wrote:
| 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 were just
| excited about a neat system (and in fairness, ECS is neat), but
| they never really wanted to do the things required for a game.
| HelloNurse wrote:
| ECS hype and the traditional make a game/make an engine
| dilemma shouldn't be considered reasons to avoid the Fyrox
| library (or other Rust projects).
|
| Are you trying to tell something more logical? Does the "Rust
| gamedev scene" affect the technical merits of libraries?
| Chris2048 wrote:
| Perhaps you should read the comment again, your questions
| don't follow from it.
| pie_flavor wrote:
| What makes Fyrox better than Bevy? I don't think the hundred
| people commenting under every Bevy point release on HN are
| thinking of the ECS. It has features and it has tools and it
| has games.
| echelon wrote:
| > because Fyrox appears to be the most mature Rust game
| engine, but nobody uses it or cares about it.
|
| Bevy gets all the hype, but Fyrox has more maturity in a lot
| of surface area.
|
| Bevy is led by a large team, and the leadership is ex-Google.
|
| Fyrox is one solo Russian developer with 10x engineering
| output.
|
| Bevy is ECS, Fyrox isn't.
|
| Bevy does a great job marketing itself, it has a foundation
| and a large community, and people are excited to try and use
| ECS.
| zelphirkalt wrote:
| 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.
| diath wrote:
| > 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 that do not actually make games at all.
| Tuna-Fish wrote:
| Why? What does Bevy lack?
| diath wrote:
| There are two primary issues. In game development, for
| developing game features, iteration speed is the most
| important factor, you usually want a higher level
| scripting language in your game engine, so that a
| developer's workflow looks like this: make a simple
| change, hit a reload button, issue a few inputs, go back
| to the editor, make a simple change, repeat. Other
| popular game engines, more or less, solve this problem by
| providing a way to make gameplay features in a higher
| level language (GDScript in Godot, C# in Unity,
| BluePrints in Unreal Engine, often Lua with custom game
| engines), with Bevy, you make a change, and you rebuild
| the code, and often times, making a simple gameplay logic
| change (for a spell, an item, or some NPC interaction),
| will also change the ownership rules in case of Rust,
| because you may want to now access the same item mutably
| in two places or other things, and that requires you to
| restructure your simple script to appease the borrow
| checker, which also brings us to the second issue, in
| game development, a lot of bad practices, become good
| practices, take cyclic references for example, which are
| a common pattern in video games, in other lower level
| languages, or languages that allow embedding a higher
| level language, it's not that big of a deal, in Rust you
| have to do some shenenigans with things like
| RefCell<Vec<Rc<RefCell<Item>>>> which is simply not very
| ergonomic and adds a lot of development friction. A lot
| of people don't realize that game engine and gameplay
| programming are two vastly different things that have
| different requirements, and Rust is a poor fit for the
| latter.
| DarmokJalad1701 wrote:
| Have you tried using Bevy? I have used it for some pretty
| non-trivial use-cases (not open source), and I have found
| that I did _not_ have to use the typical
| "RefCell<Vec<Rc<RefCell<Item>>>>" stuff you talk about.
| There are paradigms in place for safe mutable access to
| the game state without jumping through hoops.
| filleduchaos wrote:
| Of course you no longer have to actually _try_ anything
| and give it a good-faith evaluation before criticising
| it. If it 's different, then it de facto sucks.
|
| This stance is not necessarily wrong - life is short,
| after all, and not every cup of tea has to be drunk from
| - but it does make finding useful criticism in a haystack
| of generic talking points rather difficult.
| Tuna-Fish wrote:
| > in Rust you have to do some shenenigans with things
| like RefCell<Vec<Rc<RefCell<Item>>>> which is simply not
| very ergonomic
|
| The entire raison d'etre of Bevy and the reason it is
| built how it is is that the ECS eliminates that. If your
| Bevy code contains something that looks like that, you
| are using it very wrong. You put the data in the ECS, and
| any gameplay code goes into some system that uses the
| queries to pull the data it needs out of it. If you need
| something like a backreference, you don't add one in an
| unholy tower of refcells, you just use a different query.
|
| If you wanted to argue that a soup of mutually
| referencing objects is easier to deal with than having to
| use a query system, I'd disagree, but you'd have a valid
| argument. What you posted above just highlights that you
| don't know much about bevy.
| embedding-shape wrote:
| > Nobody makes games in Bevy though
|
| Obviously not true, latest Bevy Jam has ~100 submissions!
| They might not be the games you were thinking about, but
| they're games nonetheless.
|
| Beyond the game jams there are definitively people making
| games with Bevy too, but I don't think anyone of them
| gone mainstream (yet?) but it's a bit harsh to say no one
| is making games with Bevy when that's clearly not true.
|
| It takes a long time for a game engine to be ready to
| create the kind of experiences you're probably thinking
| about, and even if everything goes great with Bevy in the
| future, it's still probably years rather than months
| until any big studio will think of start using it for
| something important.
|
| With that said, people are for sure making games in Bevy
| even if the experience is non-optimal. Search on GitHub
| for "bevy" and sort by latest update and you get a
| snapshot of the projects that are on GitHub, then imagine
| there is a magnitude more people working privately.
| diath wrote:
| I judge the viability of a game engine/framework based on
| its commercial success. This may be a bit harsh but the
| truth is that hobby game jams and games with complex
| gameplay features are two different kinds of games and
| the viability of Bevy for one does not automatically make
| it viable for the other. Bevy may be fun to use for a
| simple 30 minute platformer for a game jam, but try re-
| creating any of the big indie hits released in this year
| and you will quickly realize how much friction Bevy/Rust
| create. In fact, of all the 619 successful (>500 reviews)
| games released in 2025 on Steam, can you point out at
| least one of them made in either Bevy or Fyrox?
|
| https://steamdb.info/stats/gameratings/2025/?min_reviews=
| 500...
| embedding-shape wrote:
| > you will quickly realize how much friction Bevy/Rust
| create
|
| For me the experience is completely the opposite. ECS as
| a pattern lets me build way larger games with more
| complicated and interesting gameplay than I could build
| before without ECS. It's something about about easy it
| makes to create de-coupled functions and being able to
| easily put things under automatic testing that makes the
| whole process so much smoother. Before moving to Bevy I
| mostly used Unreal Engine and on two projects Unity,
| FWIW.
|
| > I judge the viability of a game engine/framework based
| on its commercial success. This may be a bit harsh
|
| I don't think it's harsh at all, I'd do the same if I was
| trying to build mainstream games, and I think many other
| peoples do so to.
|
| But that's also very different than "Nobody makes games
| in Bevy though" which is what you said at first, which is
| a lot less charitable than what you wrote in your comment
| now. I understand it's an exaggeration, but it reads as
| you're sour about it, rather than being interested in a
| conversation about it.
| filleduchaos wrote:
| 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/
| the__alchemist wrote:
| Only the ECS.
| filleduchaos wrote:
| 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.
| the__alchemist wrote:
| It's relevant because the post I replied to is misleading
| on its own.
| cultofmetatron wrote:
| > 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.
| debugnik wrote:
| 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.
| dicytea wrote:
| 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.
| the__alchemist wrote:
| This is a bit of a microcosm of Rust OSS libs in general; the
| libraries that get the most PR, articles, popularity are
| often not the best ones. I see this in the rust embedded and
| GPGPU areas as well, for example.
|
| The smell for me is if the library is designed based on a
| plan, or attempting to be _X ecosystem in Rust_ instead of
| built around one or more practical piece of software, and
| evolving to meet the needs of these softwares.
|
| With that in mind: I adore EGUI. I hadn't heared of GPGUI
| before, but because of its origin as being purpose built for
| the Zed editor, this immediately gives it credibility, and
| I'm excited about it!
| theLiminator wrote:
| 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.
| the__alchemist wrote:
| In terms of its state now, how does it compare to EGUI?
| unwind wrote:
| That showcase application (other than Zed) looks awesome, but the
| very fancy-looking home page [1] fails to have a one-liner
| explanation of, uh, what the application _does_. Please consider
| fixing.
|
| [1]: https://longbridge.com/desktop/
| nicce wrote:
| I guess they expect that most people come there from the top
| level domain. (https://longbridge.com)
| ribelo wrote:
| "Multi-platform Support, Professional Market Monitoring" imho
| is a good explanation
| kennydude wrote:
| Looks great for those using Rust - however I do wonder how well
| this works, if at all, under screen readers and other accessible
| tech?
| Oxodao wrote:
| my #1 question each time I see a new UI framework
| jacquesm wrote:
| "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.
| wiz21c wrote:
| at least I think egui has worked on that aspect...
| anthony-eid wrote:
| Accessibility is apart of gpui roadmap.
| pseudalopex wrote:
| > Unfortunately, unless you bake it in from day #1 that's
| not so simple to fix afterwards.
| jeroenhd wrote:
| Haven't tried running the code myself, but their API docs
| mention accessibility at least:
| https://longbridge.github.io/gpui-component/docs/components/...
|
| Assuming the docs are correct, the UI controls seem ARIA
| compliant as long as you bother implementing the necessary
| descriptions and labels.
| andrewl-hn wrote:
| Zed Editor (built on top of GPUI) is opaque to screen readers,
| so I wouldn't have high hopes.
| agluszak wrote:
| I find it sad that a lot of foundational open-source software is
| created/maintained by trading/crypto/money laundering companies.
| But OTOH it's great that they at least contribute _something_ to
| the society!
| baq wrote:
| Bitcoin ethos (as in, the original 'banks are broken, let's fix
| this') is kinda similar to the hacker ethos ('this
| thing/program is broken, let's fix this'), so maybe this
| shouldn't be too surprising? Short term pain for long term gain
| etc.
|
| (disclaimer: I think bitcoin is dumb, but the market disagrees)
| nicce wrote:
| > (disclaimer: I think bitcoin is dumb, but the market
| disagrees)
|
| I believe that market is quite controversial. Most people
| know that bitcoin is a bit dump, but they buy it regardless
| because they believe they profit from it when they do that as
| part of larger group. A very interesting social experiment
| with the mix of market manipulation. It is less about
| stability, independence or usability of the currency, but
| more about the opportunity of profit.
| philipallstar wrote:
| I doubt that a lot of it is.
| bezbac wrote:
| gpui itself is maintained by the folks at https://zed.dev.
|
| Also, Longbridge, who seem to be using this GPUI component
| library for their Longbridge Pro [1] app, look to me like a
| regular online brokerage company. What is your issue with that?
|
| 1: https://longbridge.com/desktop/
| ecshafer wrote:
| zed looks nice, but I am going to wait until the American
| port to use it.
| bezbac wrote:
| May I ask what you mean by this? For all I know, Zed
| Industries Inc is incorporated in the US and funded by US
| venture capital.
|
| BTW, I am not associated with zed in any way.
| ecshafer wrote:
| Its a stupid joke. Americans say Z==Zee, rest of the
| Anglosphere says Z==Zed
| bezbac wrote:
| Thanks for the explanation :)
| ecshafer wrote:
| I don't believe that to be the case. The ecosystems where this
| is most true would be Rust, which has a lot of crypto use, and
| maybe ocaml from Jane Street. But for the most part I have to
| doubt this.
| kgraves wrote:
| > I find it sad that a lot of foundational open-source software
| is created/maintained by trading/crypto/money laundering
| companies. But OTOH it's great that they at least contribute
| _something_ to the society!
|
| React is unfortunately becoming more foundational than this
| project, and with it maintained by a company that was involved
| in the Rohingya genocide in Myanmar, the Cambridge Analytica
| scandal and so on.
|
| This makes crypto / trading companies look like angels compared
| to what Facebook has done even though they made and open
| sourced React.
|
| To that end, I don't see anything morally wrong with the former
| camp of companies supporting open source, (trading/crypto)
| since they didn't participate and amplify an actual genocide.
| UndyingHorse wrote:
| Why is the average binary size 10MB? Does it embed ICU data?
| berkes wrote:
| > By default, Rust optimizes for execution speed, compilation
| speed, and ease of debugging rather than binary size, since for
| the vast majority of applications this is ideal. But for
| situations where a developer wants to optimize for binary size
| instead, Rust provides mechanisms to accomplish this.
|
| https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...
| nicoburns wrote:
| I can't speak for GPUI specifically, but in general for Rust UI
| toolkits I'm seeing about 10-15mb for an O3 build with LTO
| enabled and when including things like ICU data, a WGPU-based
| renderer, SVG rendering support, and a "full fat" async HTTP
| client. More minimal builds with features disabled and/or Os/Oz
| can bring that down to more like 5mb.
|
| (obviously you can also take things much higher by building
| more functionality into your application, but that gives you an
| idea of the kind of "base size" achievable).
| ramon156 wrote:
| Although its still very vertically scoped for zed, I'm way more
| hyped about this UI than iced, dioxus ui, gtk-rs, etc. because of
| how complete it already is in an early stage.
|
| Then again I love zed so I might be biased.
| wongarsu wrote:
| 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 a
| file-open dialog you would still have to pull in something like
| rfd [1] and lose styling consistency
|
| 1: https://docs.rs/rfd/latest/rfd/
| patwoz wrote:
| You should always use the native file picker and not shipping
| your own. That's a good thing.
| nu11ptr wrote:
| Even though most UI libraries now draw their own widgets some
| native integration is almost always used/desired. Those
| integrations are typically: keyboard short cuts, native system
| menu (macOS), native file dialogs, and (sometimes) native
| context menus. I'm sure there are others I'm forgetting, but
| these minimal integrations are a good thing as they give the
| user some sense of familiarity.
| filleduchaos wrote:
| Not just a sense of familiarity; you will simply never build
| the full spectrum of a file explorer's functionality in a
| custom file dialog, that would be a complete waste of
| engineering time. And many more users than you'd expect
| benefit from the fact that native file dialogs are actually
| full-fledged explorers. For example, I fairly often find
| myself quick-previewing a file to be sure it's the correct
| one when I select it.
| tredre3 wrote:
| Thankfully on Macos x and Windows, the file picker isn't
| provided by the UI toolkit (though they usually provide
| abstract methods of calling it, for convenience).
|
| Linux is now working towards that goal as well, in the form
| of XDG Desktop Portal. It puts the Desktop Environment (or
| third party provider) in charge of providing services like
| the file dialog/picker/chooser for better
| integration/coherence. It's not been fully adopted yet, but
| I'm very excited about it because GTK's file chooser is
| just awful and I want to provide my own to those apps!
| berkes wrote:
| > lose styling consistency
|
| Yes. And that is (almost always1) 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.
|
| 1 Obviously some software excepted. E.g. categories like
| "expert software" like Blender, AutoCAD, Photoshop/CS, where
| dialogs must a) be optimized for their niche workflow and b)
| remain consistent for that user when they upgrade their OS or
| move between OSes. But that's an exception. Your TODO-list app
| or PDF reader almost certainly is not that.
| kragen wrote:
| Emacs, which still uses CUI-incompatible keybindings and even
| key names from a keyboard that hasn't been made since the
| 01980s.
|
| Videogames.
|
| Excel still supports MS-DOS Lotus 1-2-3 "/" commands,
| although it certainly doesn't look like Lotus for MS-DOS.
|
| Basically any software people care about is an exception to
| your rule.
| anonymous908213 wrote:
| > 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 Windows
| UI frameworks. Almost every piece of software currently
| running on my computer has custom chrome: the web browser, my
| VPN, VSCode, Discord, Steam, mouse driver, keyboard driver,
| laptop fan driver. The only one that doesn't is qbittorent,
| and it looks like a complete eyesore. It is quite literally
| the odd one out, so much for "consistent with 20+ other
| applications".
|
| Maybe it's different in MacOS land, but from my perspective
| you're 20 years behind if your application is trying to blend
| in with the OS in any regard other than the corner in which
| the X button is located. That way of thinking went out of
| fashion decades ago, and good riddance to it because things
| look much better now. What I mentioned above is a pretty good
| representative sample of my daily use, and the more I think
| about other software I occasionally use, the more I am
| grateful that nobody else still thinks like this. LiveSplit
| and Asesprite come to mind as two applications that strongly
| benefit from having bespoke chrome and wouldn't be nearly as
| nice to use if they looked anything like a native Windows
| application. Of course, my own software uses custom chrome as
| well, because looking nice makes it more pleasant to use,
| wouldn't you know it.
| rafram wrote:
| > Maybe it's different in MacOS land
|
| It is. Windows has always had consistency issues; macOS
| hasn't.
| comex wrote:
| 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.
| Aurornis wrote:
| > But for them consistent means consistent with the 20+ other
| applications they use on a daily base. So native.
|
| This was probably true 20 years ago but is not true today.
|
| The majority of apps your average (non-HN) user uses is
| actually on their phone and not using the native UI widgets.
|
| On their desktop they're using apps like Spotify, Slack, and
| Microsoft Office or Google Docs.
|
| The average user of today is not using a lot of native apps.
| tcfhgj wrote:
| I still want native apps (including proper OS Integration)
| even though I don't get them.
| amelius wrote:
| 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).
| SilverSlash wrote:
| I was expecting something ugly but these actually look beautiful!
| fidotron wrote:
| Is this native as in "not web" or native as in actually using
| native text entry and scrolling widgets? There is quite a huge
| difference as the Java world discovered.
| nu11ptr wrote:
| Pretty sure native as in "not web". AFAIK, everything is drawn
| using the various GPU APIs (GPUI started with Metal on macOS,
| for example).
| mdhb wrote:
| 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.
| nicoburns wrote:
| Rust's definitely well-suited to writing the low-level
| infrastructure pieces (the implementations of the renderer,
| layout, text, etc). You really want something with fast and
| predicatable performance there. Whether it pans out for
| writing actual applications we'll have to see, but a lot of
| big popular applications are written in C++ which is surely
| less suitable.
| keyle wrote:
| 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.
| mdhb wrote:
| I would say the opposite and it sounds like a personal
| preference at which point I think lack of cross platform
| compatibility ceases to anything else other than a major
| major problem.
| saghm wrote:
| > 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.
| written-beyond wrote:
| Yeah but sometimes you don't want to write connectors
| between high performance code and convenient to use UI
| code.
|
| I welcome this, I want to write cross platform lightweight
| UI applications without going to C or C++.
| hsn915 wrote:
| I think it's native as in "native executable".
|
| GPUI is not "native OS widgets".
| meindnoch wrote:
| Native as in "not web". No OS integration.
| _bent wrote:
| 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
| pjmlp wrote:
| 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.
| _bent wrote:
| According to Microsoft WinUi3 and WinUi2 are also native
| https://learn.microsoft.com/en-us/windows/apps/winui/
| pjmlp wrote:
| 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.
| nicoburns wrote:
| iOS and Android definitely have native toolkits too.
| rafram wrote:
| On macOS you now have to account for SwiftUI, which sometimes
| uses AppKit views and sometimes uses its own renderer. Kind
| of similar to UWP.
| brainless wrote:
| This looks very good from the screenshots. I will try this as
| quickly as I can. I have been building with egui and have tried
| Iced, Slint and Makepad.
|
| I built (agentic coded) a stocks viewer app for Indian stock
| market data: https://github.com/brainless/Indistocks. It was a
| fantastic experience as to how easily I could build a GUI app.
|
| My main product also uses egui:
| https://github.com/brainless/nocodo. It used to have a web app
| frontend and I moved to desktop app after the experiment with
| Indistocks. The experience has been really good, also coded with
| agents.
|
| Desktop apps are fun and even on my somewhat old and slow laptop
| (i5 8th gen, 16 GB RAM, 2GB nvidia dedicated graphics), they are
| so much faster than web apps on Chrome (on Linux). I want desktop
| apps to make a big comeback, we could use so many old devices.
| h4x0rr wrote:
| Hola, finally a good rust ui framework that's not dependent on
| web
| Ygg2 wrote:
| You mean outside iced, slint, egui, etc. ?
| h4ch1 wrote:
| GPUI and GPUi components are the two things I'm watching very
| closely while evaluating truly native GUI development.
|
| Still waiting to see more general use before attempting to port
| my Svelte UI for a Tauri application but it honestly looks
| incredible.
|
| Big ups to the guy(s) at Longbridge.
| the_duke wrote:
| Virtualized lists and tables are amazing!
|
| So many UI frameworks don't have these and require building them
| yourself...
| miki123211 wrote:
| 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.
| pacificat0r wrote:
| Yes
| andrewl-hn wrote:
| 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.
| Klonoar wrote:
| 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.
| patrick4urcloud wrote:
| very nice ! what about tauri versus this compoments ?
| georgeburdell wrote:
| 2 hours after it's posted on HN, the repo has its first
| "readme.md typo fix" commit.
| WhyNotHugo wrote:
| 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.
| nu11ptr wrote:
| 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.
| moralestapia wrote:
| Are GTK/Qt memory safe now?
| discreteevent wrote:
| No. What is the likelihood of an attack on a desktop
| program via memory unsafety?
| lesuorac wrote:
| Really high?
|
| What do you run your browser as?
| discreteevent wrote:
| Browser runs complex untrusted code from the internet.
| Most desktop programs don't do anything like that. The
| servo programmers were riding a motorbike. Using Rust for
| a desktop program would be more like wearing a crash
| helmet in a car.
| moralestapia wrote:
| >What is the likelihood of an attack on a desktop program
| via memory unsafety?
|
| Low.
|
| What's the likelihood of someone entering your house if
| it's unlocked?
|
| Also low, and yet you lock it.
| discreteevent wrote:
| A desktop program is already in a locked house - your
| desktop - which I can't login to.
| moralestapia wrote:
| [flagged]
| Chris2048 wrote:
| Do all desktop programs only ever run in "your house"?
| tredre3 wrote:
| > 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, you would want to draw for Wayland or X. GTK and Qt
| themselves don't burden with importing each-other to work,
| for example.
|
| My guess is that they import GTK only to get a title bar on
| GNOME, as GNOME forces applications to render their own. They
| could go custom and cut the dependency but it never looks
| quite right when apps do that.
| phkahler wrote:
| 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...
| dminik wrote:
| Because of GNOME's insistence on not implementing Server Side
| Decorations, you can't not depend on libadwaita. This is what I
| imagine pull in all of the GTK dependencies.
| cmrdporcupine wrote:
| Such is sadly increasingly the way with Rust projects.
| iknowstuff wrote:
| Would you rather have 1000 small, composable, auditable
| dependencies or the same amount of code in a monolithic dump of
| .hpp files?
| phkahler wrote:
| How about a few large dependencies and no little ones?
| iknowstuff wrote:
| 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.
| Keyframe wrote:
| I'm interested in how's the battery life while running a thing
| ilke this. Another thing I'm interested in does it support
| rendering to texture.. usage being used as a texture on an object
| (monitor let's say) in a game or rendered as a texture with
| opacity on a quad/triangle over a screen as a UI layer or a HUD
| daakus wrote:
| A quick check with release build on macOS shows the component
| demo has a non-zero energy impact in the background (per
| activity monitor), but the input example has zero energy impact
| while in the background. This is already better than many new
| from-scratch UI libraries. The foreground impact is harder to
| measure.
| artursapek wrote:
| It seems like trading applications tend to be what demands the
| performance to push R&D like this for Rust GUI. My team at Kraken
| worked on https://iced.rs/ which powers
| https://www.kraken.com/desktop, a very similar application. You
| can definitely feel the difference in a Rust GUI vs. a web view.
| It can maintain high frame rates doing so much on the screen at
| once.
| nu11ptr wrote:
| Are any pieces of this open source by chance? (other than iced
| itself)
| artursapek wrote:
| Unfortunately not
| ruguo wrote:
| It does look pretty solid, but whenever I'm building a desktop
| app with Rust, Tauri is always the first thing that comes to
| mind.
| samiv wrote:
| 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. * Their license is dual license LGPL
| *and* commercial. * 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. * Comparing
| "Syntax Highlighting" makes no sense... QSyntaxHighligther is an
| interface by which you can add your own syntax highlighting to
| any QDocument. You're welcome to use reg exps, parsers (such as
| tree-sitter) or whatever you want there. * QRichText
| supports markdown such as HTML.
| pjmlp wrote:
| 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, even VB pre-VB.NET (yes Windows Forms does support
| layout managers).
| Arch-TK wrote:
| 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.
| pjmlp wrote:
| Easy, similar to Qt.
|
| Don't want to pay upstream? Also don't get to charge money.
|
| Want to pay up stream? Another license can be arranged
| where both parties get to earn money.
| mrec wrote:
| I think you misread the post you're replying to. GP is
| complaining about it being incompatible with "GPLv3-or-
| later" Free Software, not with commercial or permissive
| OSS.
| kinjba11 wrote:
| Yes, and being incompatible with GPLv3-or-later may be
| done on purpose to push folks into a commercial license.
| aryonoco wrote:
| Qt is LGPL 3. Slint is GPL 3. There is a massive
| difference there for a "library "
|
| But to be fair to Slint, they do have a free proprietary
| license which can be used for developing proprietary
| applications as long as it's not considers in the
| "embedded" space.
| pie_flavor wrote:
| GPLv4 could be the MIT license. GPLv3-or-later is a
| statement of arbitrary trust towards the FSF. Corporations
| serious about licensure, like SixtyFPS, aren't fans of
| that. (I don't think I've ever seen GPLv3-or-later in the
| wild from non-GNU/FSF software.)
| tredre3 wrote:
| > * 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.
| samiv wrote:
| 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.
| tredre3 wrote:
| > because those libraries provide you with so much more
| functionality than just the UI.
|
| Comparing GPUI to Qt based only on what they offer gui-wise
| is fair, in my opinion. What QtCore provides is sugar over
| C++: the object model, the signal system, some data types,
| many helpers. But the thing is, all of those things are in
| Rust already. They're even in modern C++.
|
| So comparing a Qt hello world that uses
| QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world
| seems fair to me. It's not like the author also counted
| QtNetwork, QtSQL, QtSVG, QtHTML, etc.
| WD-42 wrote:
| 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.
| samiv wrote:
| That would seem odd.. the QSS is completely orthogonal to the
| code generated by the UI tool.
|
| I accept that sometimes you need to some tricks with it and
| sometimes the layout in the preview is not the same you get
| at runtime which is annoying.
|
| But in my UIs I use hundreds of widgets and I can't even
| begin to think about the useless effort required to write all
| the code by hand vs. spending seconds to drag and drop
| widgets into their place visually in the GUI editor...
| paulddraper wrote:
| WYSIWG and code are almost always if not always not done well
| together.
| fishgoesblub wrote:
| They also note that Qt6 is not themeable which is completely
| wrong.
| sagacity wrote:
| It's interesting to see more people building on top of GPUI. I
| recently also saw https://github.com/Augani/adabraka-ui which
| looks fairly similar.
| nu11ptr wrote:
| This looks great too! Hopefully one or more of these component
| libraries catch on and stay well maintained.
| ape4 wrote:
| A link to toolkit (GPUI) since I don't see it mentioned...
| https://www.gpui.rs/
| ratatoskrt wrote:
| No mobile support. I get that a desktop UI framework doesn't want
| to target smartphones, but I think iPads (and bigger Android
| tablets) can cope well with more traditional desktop paradigms.
| klaussilveira wrote:
| Sad to see that the C++ community is sleeping on this. There are
| no modern GUI components or toolkits, specially under such a
| permissive license.
|
| Excited about the future of Rust GUI development, this is
| fantastic.
| fschuett wrote:
| Azul.rs is making lots of progress now and it'll have decent C
| / C++ / Python bindings (so it won't be Rust-only). But I guess
| for now GPUI is more mature.
| lelanthran wrote:
| > Sad to see that the C++ community is sleeping on this. There
| are no modern GUI components or toolkits, specially under such
| a permissive license.
|
| I'm not sure what you are talking about (there are plenty of
| x-platform C++ GUI toolkits with components). Maybe you mean
| "accelerated toolkits"?
| gnarlouse wrote:
| So how stupid am I for asking how long it is before this is
| available in the browser and all the DOM behavior is WASM?
| cultofmetatron wrote:
| it happens to be my birthday today and this is one hell of a
| birthday present right now. been itching to dive into making a
| desktop app in rust and this looks amazing!
| phkahler wrote:
| Does it support app development in other languages?
| criticalfault wrote:
| Now that we can do a nice toolbar and components, somebody please
| make a document canvas control so we can make a decent office
| suite.
| andai wrote:
| webview.load_url("https://drive.google.com");
| aryonoco wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-27 23:00 UTC)