Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

21–30 of 279 posts

Re: Advice for the next dozen Rust GUIs

#21

Post by favorited »

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit].

I think this is vastly over-stating the technical churn of UI development on macOS.

While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using AppKit. For example, I just verified (`otool -l PATH_TO_APP_BINARY`) that Mail, App Store, Notes, Music, Xcode[1], and Photos all link against AppKit, and none link against SwiftUI (on macOS 12.4 21F79, which I'm running).

There is, in my opinion, approximately zero chance that Apple either:

(A) rewrites all of the UI in all of their apps, replacing AppKit with SwiftUI, in even the medium-term, or

(B) starts treating AppKit apps as second-class citizens by introducing a new design language only available from SwiftUI.

Yes, we're going to keep seeing cool new widgets and features which are only available from Swift. No, the platform's design language is not going change in a way that makes AppKit apps obsolete.

[0]https://developer.apple.com/documentation/Charts

[1]I bet Xcode links SwiftUI somewhere for IDE integration, but I'm specifically referring to the UI implementation, parts of which have been in development since, like, NeXTSTEP and are certainly built using Objective-C & AppKit.

Re: Advice for the next dozen Rust GUIs

#23

Post by kelseyfrog »

pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

Is there an ECS-compatible ontology for UI components?

Re: Advice for the next dozen Rust GUIs

#24

Post by Diggsey »

stephc_int13 wrote: post #9

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…

This approach doesn't work for GUI frameworks IMO. When building an application, you're looking for a GUI library that meets a set of requirements. If it doesn't meet those requirements you're not going to use it: as an application developer you're not going to want to rewrite the fundamentals of the GUI library, so there's no opportunity for that library to improve.

Maybe it would work if there was no other choice, but in the end you can always use bindings to GTK or some other mature non-Rust UI framework, or use web-view based option.

In order for a pure Rust solution to succeed in the general case, it needs to meet all of these constraints from the get-go, but of course that's an insurmountable task.

For that reason, I think the best approach is to not try to "solve" GUI yet, but instead focus on the pre-requisutes:

- Window creation. - Text rendering. - Compositing. - Accessibility. - etc.

ie. all of the things mentioned in the article can be separated out and tackled one at a time. For that reason I think the author has taken exactly the right approach.

Re: Advice for the next dozen Rust GUIs

#25

Post by riquito »

Raphlinus, great post as usual, thanks for sharing your knowledge, is always an interesting read.

I'm loosely following the progress of slint ui (formerly SixtyFPS), anything interesting in their approach or does it strictly matches one of your examples?

Re: Advice for the next dozen Rust GUIs

#26

Post by jolux »

favorited wrote: post #21

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using…

Aren't App Store and Photos Mac Catalyst apps?

Re: Advice for the next dozen Rust GUIs

#27

Post by raphlinus »

stephc_int13 wrote: post #9

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry

I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, would be better. But that is not in fact my goal, it is to yearn for the sea.

I am, quite deliberately, spending a lot of risk points. In addition to using a language which may (see elsethread) not be a good fit for expressing UI at all, I'm building a GPU 2D renderer from scratch, also using compute shader techniques which have not been proven, and I am designing a reactive architecture that is not just a simple adaptation of React. Any of these could fail, as have some of my previous attempts. But I think they will be interesting failures, in that we'll learn something, and if all the pieces do come together, it will be a UI toolkit capable of performance completely untouchable by the existing state of the art. In turn, I'm interested in how that could open up new creative possibilities constrained by current implementations.

So I'm pretty comfortable with my approach. And hey, next time you're in the Bay Area (or perhaps when I'm in your neck of the woods), lemme buy you beer and we can talk about why it gives you satisfaction to dump on other people's work.

Re: Advice for the next dozen Rust GUIs

#28

Post by pcwalton »

modeless wrote: post #16
billconan wrote: post #6

Earlier quoted context omitted.

Also, do you think if multi-channel signed distance field is a good approach for GUI text rendering? I understand, for games, it can support extreme zooming with small textures. But for GUI (for example a text editor), we only occasionally resize fonts. I looked at some of the open source projects (mostly terminal emulators), they simply rasterize fonts onto a texture map using CPU. I wonder if signed distance field…

The best GPU accelerated text rendering I know of is https://sluglibrary.com/ . Not based on distance fields. Unfortunately not open source, though it is a one-man project. Maybe someday one of the big tech companies will pay him a whole ton of money to open source it.

For most text rendering in the 2D UI use case, I'm not sure there is that much to solve anymore. Aggressive caching of rendered glyphs solves almost all the problems in practice. From what I can tell, Slug is targeted at games and 3D, where there are still interesting problems, but those aren't the 2D UI case.

Re: Advice for the next dozen Rust GUIs

#29

Post by jchw »

pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

The thing is, there do exist UI frameworks that prefer composition over inheritance and strictly tree shaped components where data only flows one way: they're all the rage on the web.

And that's great, because they give plenty of useful insight into things that work and don't work when designing UI frameworks this way.

To be fair, it's not exactly like nobody realized this. More than one Rust desktop UI framework is explicitly React inspired, and it's not like FRP-based UI was non-existent prior to being popularized in web frameworks. Still, all the same... I suspect the best answers for how to do good UI in Rust are not far away from this paradigm.

Re: Advice for the next dozen Rust GUIs

#30

Post by mwcampbell »

raphlinus wrote: post #27
stephc_int13 wrote: post #9

I have no business related to Rust, but after reading a few articles from this author, I tend to think that his approach to GUI toolkit design is deeply flawed. He is undoubtedly highly knowledgeable about the subject, but this knowledge may be a curse in his case. A mix of second system syndrome and Architecture Astronaut, trying to satisfy too many constraints can be a deadlock. I think the sensible approach is sta…

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry I will one hundred percent agree with you that my approach is not a good one if you want a pretty good GUI in a reasonable amount of time. For that, an incremental approach, especially adapting some existing successful design, woul…

I think another great counterpoint to dogmatic incrementalism is Gary Bernhardt's classic talk "A Whole New World": https://www.destroyallsoftware.com/talks/a-whole-new-world
Post reply on HN