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

81–90 of 279 posts

Re: Advice for the next dozen Rust GUIs

#81

Post by int_19h »

wmf wrote: post #45
overgard wrote: post #34

I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). A…

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…

But this kind of branding wasn't as prevalent before web apps invaded the desktop. Now the users are pretty much conditioned to expect every app to do its own thing.

Re: Advice for the next dozen Rust GUIs

#82

Post by epage »

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…

I'm glad Rust* is forcing us out of a rut in UI toolkit design. All of these spell hard-to-debug problems.

* Yes, I know elm-derive UIs are also a thing and have laid a lot of ground work in this area.

btw I've had great experience 10 or so years ago doing composition-based UI design in GTK with Python. When Maemo switched from GTK to Qt, the requirements on inheritance were one of my points of frustration and I got away with creating a couple adapter classes to avoid most of it.

Re: Advice for the next dozen Rust GUIs

#84

Post by xyzzy_plugh »

tacotacotaco wrote: post #38
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…

I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.

This is an extreme exaggeration. The shit you can do with MFC is still frightening, even today.

Re: Advice for the next dozen Rust GUIs

#85

Post by raphlinus »

aaaaaaaaaaab wrote: post #77
raphlinus wrote: post #61

Earlier quoted context omitted.

I'll have a lot more to say about this as I gather quantitative performance data. But it's a good question. I expect the big wins are: fast 2D (vector with blends and so on) rendering with compute shaders, multithreaded creation of expensive resources like image decompression and text layout, pushing incremental reactivity all the way from app logic to GPU (as opposed to needlessly redoing work), and of course just u…

What do you mean by “pushing incremental reactivity all the way from app logic to GPU (as opposed to needlessly redoing work)”?

From a computation perspective, UI is fundamentally an incremental computation engine. Most elements are not changing from frame to frame, so you can either recompute and re-render, or be smarter about only propagating deltas. I'd like to propagate those deltas all the way to the GPU, so you reuse lots of things from the previous frame if they haven't been invalidated. I'll be writing about this in considerably more detail; stay tuned.

Re: Advice for the next dozen Rust GUIs

#87

Post by msbarnett »

int_19h wrote: post #81
wmf wrote: post #45

Earlier quoted context omitted.

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…

But this kind of branding wasn't as prevalent before web apps invaded the desktop. Now the users are pretty much conditioned to expect every app to do its own thing.

> But this kind of branding wasn't as prevalent before web apps invaded the desktop.

This is ahistorical. App branding now doesn’t hold a candle to the late-90’s mania for every app having its own skin engine. App-vs-platform UI deviation is a lot tamer nowadays.

Re: Advice for the next dozen Rust GUIs

#88

Post by favorited »

jreese wrote: post #66
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…

On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit. Similar to the Carbon/Cocoa split, I'm sure we'll see AppK…

That's totally fair, but I think the point that "every 'new' macOS app from Apple ... has been written in either SwiftUI or Catalyst" isn't really surprising. New features are probably going to rely more on newer technologies – especially in places like Shortcuts & System Settings, where the legacy approaches had non-trivial security implications. And, at least so far, we've only seen Catalyst apps from Apple when either:

(A) an app was being ported from iOS because it didn't already have a native Mac counterpart (e.g., TV, News, Podcasts), or

(B) the Mac version was significantly behind its iOS counterpart from a feature perspective (e.g., Messages).

I had written a diatribe earlier about how I don't see this as equivalent to the Cocoa/Carbon situation, but deleted it because I'm being long-winded enough already. It boiled down to the fact that Carbon existed specifically to help port apps from a legacy OS to what Apple was loudly declaring to be the future: OS X. Carbon was a way for apps to get off the sinking ship that was the "classic" MacOS. I mean, they had a funeral for it! https://i.imgur.com/KjFh63u.jpg

20 years from now, will Apple's macOS apps contain more Swift+SwiftUI than Objective-C+AppKit, probably! But I'm not worried about AppKit being a "dead end" until they rewrite Mail, Keynote, and Xcode – because they have significantly more invested in those apps than I have in my AppKit apps.

(For the record, I love SwiftUI, and use it whenever I can! I just have no expectations that AppKit is going away any time soon.)

Re: Advice for the next dozen Rust GUIs

#89

Post by favorited »

jolux wrote: post #68
favorited wrote: post #39

Earlier quoted context omitted.

Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link ag…

Interesting, I thought I had heard that App Store was Catalyst now for some reason.

It does kinda look like a Catalyst app, with its navigation stack, whitespace, etc.

Re: Advice for the next dozen Rust GUIs

#90

Post by rvz »

CrimsonVoid wrote: post #40

I know this is going to be a controversial opinion considering how much everyone seems to love Rust, but does anyone else find Rust incredibly painful to work with, even for simple tasks? Like I'm no stranger to unmanaged languages, and to some extent I cut my teeth on C, but doing anything with Rust always feels like the most aggravating exercise in needless verbosity and the "Lombok problem" doesn't help either. (F…

It is good for some use cases, but the hard fact of the matter is, it is not useful as a way for creating cross-platform scalable GUI apps.

I have heard all the arguments for using Rust in GUI apps, but realistically they seem to be very weak to convince a serious team of developers to choose between the alternatives.

Post reply on HN