This is coming from an outside perspective, and I'm quite prepared to be badly wrong.
I think the Rust language needs to learn a few tricks from Objective C and Swift to really make this possible. In particular the work being done on extensible protocols.
What you can do, is build a 'Rust-flavored' GUI library. But this isn't what users want: they want a native app, while developers want to write once-run anywhere.
This requires a kind of double decoupling, where UI intent is expressed as an abstraction, and is realized as an OS-native control — but one which itself will dynamically update, insofar as possible, as the OS evolves.
This calls for a kind of API wizardry which Objective C always got right, and C++ never really did. I see that dichotomy extending into Swift and Rust, but it isn't inevitable, Rust hasn't painted itself into that particular corner.
Anyway, it's encouraging to see this work happening, I wish you good fortune in 2021 and beyond.
Check out Raph's retrospective on his xi editor project [1], particularly the section "There is no such thing as native GUI", for his take on why using platform-provided ("native") controls isn't always practical, at least for the applications he's developing. Anyway, cross-platform wrappers over native controls have been done in other languages, e.g. wxWidgets in C++ and SWT in Java, and that approach has enough limitations that AFAIK most developers of complex applications avoid it now.
I will miss dearly the good old days of Cocoa GUIs that adhered to Apple's Human Interface Guidelines (and when HIG itself was about usability, not looks). They all supported all the little things of Cocoa (like click-hold-drag on popup menus activating items on mouseup, or proxy icons that gave quick access to files of documents in any window, or search pasteboard).
Nowadays native apps on Mac are dead. Even Apple is giving up. There are still native-code-running .app bundles, but they're Qt, Electron, or Catalyst that are like knock-off brands of Mac apps. Even if they bother to have vaguely Mac-like skin, they lack all of the nice little details that made Cocoa apps great.
I know you’re saying that in a subjective way, and definitely the percentage of non-Cocoa apps have gone up, but I’m not sure if they’re dead. In fact, I feel that they are thriving once again in 2020 — a lot of indie devs that care about making Mac-assed Mac apps[0] are present and are releasing great apps and replacing ones that were filled with Electron.
Some examples that pop up in my mind: NetNewsWire 5[1] (an RSS feed reader), Shrungs[2] (a Cocoa Slack client), MimeStream[3] (a Gmail email reader), Chime[4] (a Go IDE that’s entirely Cocoa! I seriously considered learning Go because of this app), ProxyMan[5], and I can go on and on...
My feeling is that Electron got a bit of traction in like 2014~6 but people started to realize they really do like Cocoa better.
Agreed. I'm one of the rare folks around here who, despite decades of deep Unix experience, prefer decent GUIs to the command line, and Cocoa really is the best you can get in general use today. The decreasing number of native apps and the increasing number of apps that don't have all the nice little affordances makes me sad.
Same here, that is why I am so critic of those that use 25 inch screens to organize xterms and nothing else, I was doing that in 1994 with twm on IBM X terminals, something better is to be expected in 2020.
> that is why I am so critic of those that use 25 inch screens to organize xterms and nothing else, I was doing that in 1994 with twm on IBM X terminals, something better is to be expected in 2020.
Seems weird to criticize people for working in a way they like to work. The "something better" might just be improved command line tools. I think there's room for both, and different people prefer different types of interfaces.
I haven't used a Mac in ages, so I'm unfamiliar with any unique features of Cocoa over what one gets with e.g. GTK+; what would you say the features that make it better are?
I'm usually a bit skeptical of current-generation GUIs (but then again, I'm ignorant of the Mac world) largely because it's usually so much more painful to extend and compose them. To pick a perhaps slightly unfair example (since it's basically about text processing), I use Weechat for chat rather than Pidgin, since the UI inconvenience of it being a CLI is outweighed by how easy it is to process my chat history, programmatically interact with notifications, and how much more functional Mosh/SSH are than X11 forwarding.
Speaking as a user, I don't particularly care if the widgets are native or reimplemented - what I care is whether they look and feel native. E.g. on Windows, a Qt or even a Tcl/Tk app can easily look "native enough" that nobody will care.
On macOS the native UI language is very consistent and it’s very easy to decide whether an app looks and feels native. And AFAIK Qt is the only production-ready cross-platform toolkit that even comes close to native on macOS.
On Windows there are like at least three or four kinds of “native”, I don’t even know what’s “native enough” there.
I can only think of two kinds of "native" on Windows when it comes to look & feel - Win32 apps, and WinRT apps. Ideally, a modern GUI framework would have backends for both.
(Stuff like WPF still has a Win32 L&F, even if it draws the widgets itself, same as Qt.)
In my opinion there's more than two kinds of native if you pay attention to the details.
Themes: Unstyled Win32, styled Win32, WinForms (which is part Win32 and part custom controls), WPF (which sorta imitates Win32 and doesn't quite look like it), and UWP.
Fonts: Microsoft Sans Serif, Tahoma, Segoe UI, and non-English fonts.
I think the Rust language needs to learn a few tricks from Objective C and Swift to really make this possible. In particular the work being done on extensible protocols.
What you can do, is build a 'Rust-flavored' GUI library. But this isn't what users want: they want a native app, while developers want to write once-run anywhere.
This requires a kind of double decoupling, where UI intent is expressed as an abstraction, and is realized as an OS-native control — but one which itself will dynamically update, insofar as possible, as the OS evolves.
This calls for a kind of API wizardry which Objective C always got right, and C++ never really did. I see that dichotomy extending into Swift and Rust, but it isn't inevitable, Rust hasn't painted itself into that particular corner.
Anyway, it's encouraging to see this work happening, I wish you good fortune in 2021 and beyond.