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

Rust: State of GUI, December 2022

kas-gui.github.io

Post reply on HN
Print view View original

81–90 of 149 posts

Re: Rust: State of GUI, December 2022

#81

Post by drkhn1234 »

bobajeff wrote: post #66
dohdhdaa wrote: post #46

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.

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.

No post body was provided.

Re: Rust: State of GUI, December 2022

#82

Post by zorr »

dohdhdaa wrote: post #46

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.

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.

Re: Rust: State of GUI, December 2022

#83

Post by d12bb »

oDot wrote: post #51
dohdhdaa wrote: post #46

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.

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

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.

Re: Rust: State of GUI, December 2022

#84

Post by cmrdporcupine »

amatheus wrote: post #72
bitexploder wrote: post #53

Earlier quoted context omitted.

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.

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.

I've been an JetBrains (IntelliJ and these days CLion) user since about 2004 and what I'd say is this was a hard fought and slow incremental advancement. Back in the 00s, IDEA's UI experience was really sub-par and its foreign nature on the platform was very very clear.

It's amazing the amount of work JetBrains has put into this.

Re: Rust: State of GUI, December 2022

#85

Post by twoodfin »

mistrial9 wrote: post #74
bobajeff wrote: post #66

Earlier quoted context omitted.

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.

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?

I think Apple made a strategic error when they failed to embrace DOM/browser engine-based toolkits like Electron on the Mac. If they had applied their leverage, of which they have plenty, the technical challenges of better native integration and support for the wide range of traditional Mac affordances would seem to have been quite manageable.

Re: Rust: State of GUI, December 2022

#86

Post by dmitriid »

zorr wrote: post #82
dohdhdaa wrote: post #46

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.

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 wid…

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

Re: Rust: State of GUI, December 2022

#87

Post by ptx »

bitexploder wrote: post #53
dohdhdaa wrote: post #46

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.

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.

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.

Re: Rust: State of GUI, December 2022

#88

Post by cmrdporcupine »

zorr wrote: post #82
dohdhdaa wrote: post #46

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.

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 wid…

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.

Re: Rust: State of GUI, December 2022

#89

Post by mroche »

d12bb wrote: post #83
oDot wrote: post #51

Earlier quoted context omitted.

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

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.

I feel like it's a spectrum. The simpler the app, the more likely it's better to try an integrate with a closer to native look. I always found the issue of "native" to be a bit funny to me as someone coming from the 3D/VFX space, since all of the applications are built to be multiplatform and don't give a hoot about "native". Consistency of the application experience across platforms trumps all. The number of people I've seen complain about this? Zero. Usually the only issues arise around file pickers (some have custom ones, others use platform ones which have differences).

Granted these applications boast a ridiculous amount of features and are incredibly complex putting them on the opposite end of the spectrum compared to simple GUIs and chat/productivity applications.

To me, it's nice that platforms provide native toolkits* to provide this level of integration. But I don't view any app as "native" unless it comes from the party making the platform, as they are really the only ones that actually have to adhere to their human interface guidelines to the fullest extent.

* On Linux this is more up-in-the-air. I personally don't consider GTK and Qt as native toolkits, but the foundational pairing for things like libadwaita and KDE Frameworks which provide the associated platform widgets and HIG. Using the toolkits directly is fine and will mostly work, but it's not the same as a "native" application.

Re: Rust: State of GUI, December 2022

#90

Post by thiht »

dohdhdaa wrote: post #46

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.

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

Post reply on HN