[dohdhdaa]

Unless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit. Any custom framework will always feel wrong and out of place.

I use macOS, so apps should be written with AppKit. For Linux they should either be GTK or Qt, depending on desktop. Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.

[virtualritz]

> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.

So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.

Off the top of my head from what I use most of the time: Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode. Not a single one of them uses native Cocoa widgets. And I couldn't care less.

Some of these are top of the line apps for 2D/3D content creation on that platform.

If the vendors of these apps can afford to not care about UI nativeness, why should any single one or small group of developers working their asses off on GUI crates for Rust? Mostly unpaid no less.

[rollcat]

> Not a single one of them uses native Cocoa widgets. And I couldn't care less.

Meanwhile I do care. My main reason being: macOS offers fantastic facilities for inspecting and scripting the native GUIs, think using the web inspector or GreaseMonkey, but across the entire OS - but of course it breaks e.g. on Electron apps. Other people will cite help menu integration, custom key shortcuts, accessibility (not only for the disabled), and - yes, resource usage. I remember being productive on a system with 256M of RAM, and before that - 4M, and before that - 64k. It's frustrating to see so much progress wasted, I shouldn't need to close ALL of the chat apps just to run StableDiffusion more smoothly.

[lelanthran]

> So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.

MacOS apps feel pretty wrong to me.

Some don't remember which screen they should be on, and always go to that screen at a predetermined size and geometry (tkdiff).

Others expand incorrectly to full-screen (macvim) when moved to a different screen.

VSCode doesn't behave like the native apps.

The list goes on, I'm short on time.

> And I couldn't care less.

You caring or not doesn't make the problem go away - native widgets always feel less wrong than non-native widgets.

[hollerith]

>Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode. Not a single one of them uses native Cocoa widgets.

Also Firefox and Chrome and their forks (e.g., Brave).

[bobajeff]

It seems to me Mac users care about using native UI toolkits more so than Linux or even Windows users. I would suppose that has to do with how polished and integrated that platform is.

As a Linux user I really don't care if you use GTK for the UI. I've long given up on customizing the look and feel of my system to the point that application integration matter.

[troad]

For many decades, there have existed commercial apps native to the Apple ecosystem, often from small/mid-sized studios, which would use native UI to signal their premium craftsmanship. I think that for many long-time Mac users, seamless/native UI is still a signal of quality in third-party software. However, this sentiment is moribund. That entire market is now dwarfed by the ecosystem of “cross-platform apps” (formerly Windows ports, now usually web apps) and Unixy OSS tools; all the while the Mac App Store now peddles lots of native-UI apps of deeply questionable quality.

[mistrial9]

long ago, the integrated feeling of Apple MacOS was a great selling point; decades later, daily use of the web, more phone than desktop, Windows low-bar junk and other factors change the equation.

If a smart user here today says that recent network-centric apps are OK with him visually, then maybe they are OK?

[meindnoch]

This. It’s so lame when UI elements can’t hang outside the bounds of the window (i.e. menus, tooltips, dropdowns, popovers) because everything is rendered like a game…

[nicoburns]

There's no reason Rust toolkits can't use separate windows for elements like menus and tooltips, and I know this is planned for at least some of the toolkits discussed in the post.

[bsder]

The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.

Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?

Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.

[Strom]

What you are talking about has nothing to do with custom vs native controls. Instead it's a question of using a single or multiple windows.

There are Rust GUI toolkits like Druid with custom controls that have elements outside the bounds of the main window.

[bitexploder]

The only cross platform toolkit that pulls it off well is Java. IntelliJ feels good on every platform. Qt apps can also feel native if a little effort is put into it. Rust GUI frameworks are one of its weaker areas IMO.

[ptx]

The next time you use a Swing app, look for these examples of how it "pulls it off well":

* The first time any particular window is opened, Swing draws the contents but then changes its mind about the window size, recalculates the layout and then redraws the contents again slightly differently.

* When Swing creates a window, you can sometimes observe how creates it in the wrong spot and then moves it to where it was supposed to be created.

* Alt-tabbing quickly between two windows in a Swing application doesn't always work. It sometimes just glitches and leaves you in the window you started with. (Confirmed just now on Windows 10 with Java 17. The bug has been there for many, many years.)

* When opening a submenu of a menu, Swing does nothing to handle the problem of the menu closing again as you're moving towards it but accidentally mouse over an adjacent item. Platform GUI toolkits solve this either with a delay or by tracking the direction of the movement. IntelliJ implements its own menu bar to make this work.

* Try to find an example of a window that is resizable in only one direction or only up to a certain maximum size. As far as I can tell, this is not possible in Swing, and applications handle this limitation by designing all UIs to be resizable even when it doesn't make any sense.

[chrismorgan]

I have never had anything other than a terrible experience with a Java app, under Windows, Linux (in GNOME 2 and Unity most of a decade ago, i3, or Sway). They always disregard platform conventions in both look and feel to a painful extent. But I will declare that I haven’t ever used IntelliJ, and I have no idea what it uses for its UI. But out of the box, Qt seems vastly better at matching platform look and feel, and generally gives you decent control over matching or not to match your requirements.

[amatheus]

Regarding Java I think that's more of a Jetbrains thing that IntelliJ feels good on every platform than Java per se. Contrast it with Netbeans for a more "pure" Java desktop experience.

[thiht]

When it comes to Java GUIs, Intellij is the exception, not the rule.

[Kwpolska]

It’s mostly an IntelliJ thing. All other Java apps are ugly and weird.

And there are non-native behaviors in IntelliJ too. For example you can’t close windows by double-clicking the window icon on Windows (a feature of Windows since Windows 1?).

[nicoburns]

> Unless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit.

If the toolkit is good enough it's entirely possible that a platform or platforms may adopt it as their native toolkit. In any case, these are really competing with electron which is already non-native. If Rust toolkits can get to electron-like quality but with lower resource usage and better hooks into the underlying platform then I'd consider that a success.

[pjmlp]

With exception of VSCode, the only Electron apps that I use are forced upon me due to work requirements.

All of them I glady ignore on private owned computers, or use the browser version, they are anyway Web apps.

[madeofpalk]

> In any case, these are really competing with electron which is already non-native

Use Electron and you'll get OS-native buttons and other form controls.

[oDot]

Some apps have their own unique look and that works quite well. Doesn't feel out of place for me.

[d12bb]

Depends. Highly specialized apps (Blender comes to mind) fare better using custom toolkits. Anything else probably should use the platform-native one, not only for looks (lots of really great mac-only apps use customized widgets, see Things as example), but feel and integration as well.

[ruph123]

You can write GTK applications in Rust: https://www.gtk.org/docs/language-bindings/rust/

[dpcx]

You can, but its documentation is (was?) a horrid mess of C examples that make it quite difficult to navigate.

[thiht]

> Any custom framework will always feel wrong and out of place

Pretty sure that's the wrong metric. Users don't care if the interface doesn't look exactly like the rest as long as it's good looking and feels familiar.

As a heavy VSCode user for example, I don't think it feels out of place on a mac for example. The UI is consistent in itself, and the UX is consistent with the global UX of the OS (more so than some native mac apps like Finder for instance).

The main reason I hated Java Swing apps was that they were ugly as hell, not that they didn't feel native.

[Klonoar]

I'm the author of cacao, which is the first thing in this blog post - and is a Rust wrapper around native AppKit. Anything built with it feels fine on macOS and gets most things "for free", but the issue is that nobody wants to write AppKit anymore. ;P

You can blame a variety of things for this, but it's the reality. Apple doesn't really make it easier with the newer UI approaches creeping in.

[bryanlarsen]

The first item on the list is cacao, the rust bindings for AppKit. And that is IMO the best option for building MacOS apps in rust.

[silon42]

>For Linux they should either be GTK or Qt, "depending on desktop"

That's bad... ideally there should be a runtime choice between GTK / Qt.

side note... I know many people that would prefer apps on MacOS to behave like Windows/Linux (mostly about the keyboard)... and also the reverse (those are louder to complain, but a minority in my case).

[aaa_aaa]

That will probably be Fuchsia, if it lives.

[pjmlp]

Its official GUI toolkit is Flutter.

[zorr]

I think, now in 2022 it is time to let go of this idea (for cross-platform applications). What you propose means that any app that wants to be available on "all" desktop platforms has to be written at least 4 times (macOS, Windows, GTK, Qt) and few developers or organizations have the resources for that.

> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.

Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.

To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.

There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.

[dmitriid]

> But if we drop this constraint and design widgets with their own consistent style within the same app

Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.

On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.

[cmrdporcupine]

The problem with this is unless you drag in something like Electron, you're inevitably going to end up using (or writing) something that just doesn't have the number of maintainers and quality development as either the native UI or an embedded webview. There's nothing with the level of development of e.g. Qt for Rust.

Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.

Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.

It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.

Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.

[pg999w]

There are plenty of apps written with Electron, which has styles far from "native" UI. But most people should not think of them as wrong.

[rcarr]

There's this:

https://www.redox-os.org