Get the top HN stories in your inbox every day.
nu11ptr
swiftcoder
> 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
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...
zemo
users is a finicky metric. When Palia came out, a game you most likely have never heard of, I wrote a desktop installer for it with Druid, which a few million people downloaded and used to install and run Palia. Only a handful of people worked on this codebase, maybe three or four while I was there, but principally me and one other engineer.
The more salient metrics would be things like how many people know how to use the framework, the variety of use-cases its good for solving, how easy it is to hire or get help with it, etc. As for Druid, Druid is already officially unmaintained, its core developer having moved on to work on Xilem instead. (my experience, for the record, was positive, I very much enjoyed working with Druid.)
RMPR
Iirc Cosmic Desktop uses Iced
hoppp
Oh thats why it looked so familiar.
I actually tried to create a UI kit using zed's code for a personal project, but gave up.
nice to see I was not the only one with the idea and it can get some usage now. The example app looks awesome.
michaelmior
GPUI yes, but I'm not so sure about GPUI Component which is what I assumed the parent was talking about.
swiftcoder
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
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.
the__alchemist
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!
zelphirkalt
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
> 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.
echelon
> 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.
pie_flavor
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.
HelloNurse
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
Perhaps you should read the comment again, your questions don't follow from it.
theLiminator
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.
undefined
dicytea
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.
airstrike
> 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
> 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
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.
Boxxed
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
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.
the__alchemist
Same! I am building a structural biology CAD-like tool in Rust (EGUI + WGPU), and it's a great experience.
nicce
> 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
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
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/packages/subs...
adastra22
Incremental compiles should be fast.
matu3ba
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
scheduling ??? what's that ? scheduling UI events ? Reversal computing ? What's that ? You meant reversible computing ?
matu3ba
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.
rayiner
I downloaded the Longbride app they made with it. It looks like a real application! Fits in pretty well on Mac. Runs much more smoothly than Electron!
zaphirplane
I’m so tempted to find out if Claude and friends can work with it, cause it’s new, rust and and unique
embedding-shape
With the right workflow you can work with any language and library, by managing the context carefully and "showing-not-telling". I've worked with Claude Code and Codex on lots with Rust and Clojure, seems to not have any more issues than when I use Python.
the__alchemist
In terms of its state now, how does it compare to EGUI?
agluszak
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!
bezbac
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?
baq
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
> (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.
kgraves
> 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.
ecshafer
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.
philipallstar
I doubt that a lot of it is.
WhyNotHugo
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.
dminik
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.
WhyNotHugo
You can very much draw a border on a windows and a "close" button without any libraries.
Usually, I'd understand if you're lazy and can't be bothered and just pull in some dependency to do it for you, but if you're implementing a toolkit, this is the kind of thing that is SHOULD provide.
nu11ptr
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.
tredre3
> 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.
WhyNotHugo
> They could go custom and cut the dependency but it never looks quite right when apps do that.
This is literally what the GNOME devs advocate: that each application draw their own borders and titles. You might consider that it doesn't look quite right, but that's the design choice they're going with.
phkahler
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...
moralestapia
Are GTK/Qt memory safe now?
discreteevent
No. What is the likelihood of an attack on a desktop program via memory unsafety?
cmrdporcupine
Such is sadly increasingly the way with Rust projects.
iknowstuff
Would you rather have 1000 small, composable, auditable dependencies or the same amount of code in a monolithic dump of .hpp files?
phkahler
How about a few large dependencies and no little ones?
iknowstuff
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.
samiv
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
They do, but you have to look into the right ones, from ex-Qt employees,
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
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.
pie_flavor
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.)
pjmlp
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.
wolvesechoes
This is just meant to show how awesome their toolkit is, without the goal of having fair comparison. They list chart widget, but they do not list 3D chart widget, because then they would need to show that they do not have it, but Qt does. Same for equivalent of QGraphicScene etc.
Truth is Rust doesn't have, and will not have anytime soon anything comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in Rust" disclaimers is going to change that.
tredre3
> * 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
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
> 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.
tracker1
I would think you could absolutely create something like that with a few steps on top of a relatively complete component library like linked.
You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.
fishgoesblub
They also note that Qt6 is not themeable which is completely wrong.
WD-42
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
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
WYSIWG and code are almost always if not always not done well together.
kennydude
Looks great for those using Rust - however I do wonder how well this works, if at all, under screen readers and other accessible tech?
jeroenhd
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
Zed Editor (built on top of GPUI) is opaque to screen readers, so I wouldn't have high hopes.
Oxodao
my #1 question each time I see a new UI framework
jacquesm
"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.
anthony-eid
Accessibility is apart of gpui roadmap.
wiz21c
at least I think egui has worked on that aspect...
fidotron
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.
_bent
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
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
According to Microsoft WinUi3 and WinUi2 are also native https://learn.microsoft.com/en-us/windows/apps/winui/
rafram
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.
nicoburns
iOS and Android definitely have native toolkits too.
nu11ptr
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
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.
keyle
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.
nicoburns
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.
written-beyond
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
I think it's native as in "native executable".
GPUI is not "native OS widgets".
meindnoch
Native as in "not web". No OS integration.
miki123211
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.
andrewl-hn
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
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.
tracker1
You might want to consider Dioxus if you want better accessibility in a Rust app... though afaik, there's no component library as complete as this one available.
pacificat0r
Yes
wongarsu
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
berkes
> 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 "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
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.
berkes
> E.g. categories like "expert software"
As pointed out.
amelius
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).
berkes
Not entirely.
I care a lot if an app on my android suddenly opens an IOS date picker.
Because I don't care about date pickers. I don't care about how it looks. All I care about is picking a date and doing that fast.
But now I have to learn a -to me- unfamiliar interface, spend cognitive load on something unrelated to what I was trying to do (e.g. schedule a date with a friend)
Aurornis
> 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
I still want native apps (including proper OS Integration) even though I don't get them.
rayiner
> On their desktop they’re using apps like Spotify, Slack, and Microsoft Office or Google Docs
I don’t know anyone who doesn’t hate these apps.
anonymous908213
> 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.
berkes
What you describe is an old and common problem with Microsoft Windows. Hell, even Windows applications built by microsoft itself, even within the same team, are inconsistent often.
This is a problem. One that end-users may not recognize, but the cognitive load and learning curve this brings is real and costly.
It is one of the many reasons people like Mac. It's also one of the reasons people feel awkward on e.g. Ubuntu (or just linux). Because eventhough GTK is highly consistent, the apps that don't follow this consistency (Libre office, Gimp, Firefox, Thunderbird, etc) are more common than the ones that do.
rafram
> Maybe it's different in MacOS land
It is. Windows has always had consistency issues; macOS hasn't.
nu11ptr
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
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
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!
patwoz
You should always use the native file picker and not shipping your own. That’s a good thing.
the_duke
Virtualized lists and tables are amazing!
So many UI frameworks don't have these and require building them yourself...
artursapek
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
Are any pieces of this open source by chance? (other than iced itself)
artursapek
Unfortunately not
unwind
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.
nicce
I guess they expect that most people come there from the top level domain. (https://longbridge.com)
ribelo
"Multi-platform Support, Professional Market Monitoring" imho is a good explanation
ramon156
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.
Get the top HN stories in your inbox every day.
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"