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

61–70 of 149 posts

Re: Rust: State of GUI, December 2022

#61

Post by chrismorgan »

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.

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.

Re: Rust: State of GUI, December 2022

#62

Post by silon42 »

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.

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

Re: Rust: State of GUI, December 2022

#63

Post by silon42 »

chrismorgan wrote: post #61
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.

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, an…

SWT was pretty good in my experience.

Re: Rust: State of GUI, December 2022

#65

Post by josephg »

chrismorgan wrote: post #61
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.

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, an…

I use intellij on Linux and macos.

It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.

So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.

Re: Rust: State of GUI, December 2022

#66

Post by bobajeff »

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.

Re: Rust: State of GUI, December 2022

#67

Post by ink404 »

bryanlarsen wrote: post #37

Shout out to Dioxus. It's a react clone that provides a really nice experience and can run a web GUI faster than React can. That's quite the accomplishment given the disadvantage of having to use shims to access the DOM. If you want to choose a single language that can create native GUI's, Rust is probably your best or only choice. Other languages are lacking a good story for either the web or for iOS but Rust works…

kotlin is a decent choice as well

Re: Rust: State of GUI, December 2022

#68

Post by Strom »

madeofpalk wrote: post #60
nicoburns wrote: post #58

Earlier quoted context omitted.

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

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

Can you provide any source/documentation on how to achieve this?

As far as I know Electron is based on Chromium. And Chromium doesn't use native controls, it has its own custom controls that sometimes look similar to native controls.

Re: Rust: State of GUI, December 2022

#69

Post by fnord123 »

rtpg wrote: post #23

A pretty fun Rust GUI experienc is vgtk[0], which is doing a bunch of macro magic to give a "we're coding in React" vibe to GTK+. I don't really have a specific thing I want to code in a native GUI at the moment but if I did I think this would be the most tempting for me. [0]: https://github.com/bodil/vgtk/

Relm4 is similar.

https://relm4.org/

Re: Rust: State of GUI, December 2022

#70

Post by ruph123 »

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.

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