[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.

[smoldesu]

Maybe Apple should write libraries for their GUI toolkits, then. It's awfully hard to beg people to write native apps for you when people need to learn a new language to do it.

[worik]

And when that new language is Swift. Coming from Rust Swift is hard to take.

[smoldesu]

That's more-or-less what I'm getting at. Apple can't replace Objective-C with Swift and expect people to not cock their head. They can either support a pre-existing language (like Microsoft with Rust) or home-bake something suitable for low-level development. Telling developers to not use the stuff they want to use sorta leaves their hands tied.

[pjmlp]

Microsoft's Rust support is basically non-existing for GUI applications, Rust/WinRT is miles away from achiving C++/WinRT parity, even more so with C#.

In its current state is only useful for CLI or services, unless you feel like doing WinUI team's work for free.

[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.

[virtualritz]

My main counter argument would be that most of the tasks I do on macOS require/are better done full screen.

And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have. But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it.

But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.

But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.

I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].

Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.

Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.

They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.

IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.

[1] https://github.com/emilk/egui/issues/88

[zamadatix]

On that tangent what are the top alternative window managers people here use on macOS? The native window management does indeed drive me up the wall.

[homarp]

>newer paradigmns for UX that evolved in recent years.

can you provide some examples on desktop? Touch maybe, but that is not used on desktop, afaik.

[virtualritz]

I should probably have said patterns, not paradignms but this beside the point.

I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.

Off the top of my head:

Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).

Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).

There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices. This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).

Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ```<language for syntax highlighting> ...```.

In Slack ``` works but ```<lang> doesn not (but does in Discord, used to work in Slack in the past, I think).

I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.

But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.

Even if the platform itself doesn't provide a ready-made widget for each such case.

Hope that makes sense and explains what I meant.

[vvillena]

A good "tiling helper" is Rectangle Pro. The basic version does enough, but the paid one is a game changer.

[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).