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

111–120 of 149 posts

Re: Rust: State of GUI, December 2022

#111

Post by jeroenhd »

dpcx wrote: post #71
ruph123 wrote: post #70

Earlier quoted context omitted.

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

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

This was my experience as well. Simple windows with a button that increments a number are nice and understandable but if you try to get more complex controls working, you run into docs.

With C code often being unreadable, I found that Vala applications often have readable examples of how to use UI components. However, tooling support for Vala is extremely limited so experimenting with existing code may be a annoying. That said, I've had good experiences with opening these projects in Gnome Builder (once it got updated to work on my computer again).

If your component of choice doesn't have a Vala example, I'd resort to reading the documentation. Reverse engineering the API from the docs is often quite doable if you first look at how a component you do understand.

I've had similar problems, but worse, when I tried mixing Rust and Qt. I've never used Qt before so that doesn't help, but I found the API even less predictable in many cases, with some docs and examples several versions out of date.

I'd seriously consider just shipping a WINE'd Windows binary (using a tool like https://winepak.github.io/) for Linux targets with the current state of Rust GUI platforms. The amount of game UI/custom UI libraries out there is impressive but they all feel terribly wrong when I try to use them, in the same way most Flutter apps are terrible to use on desktop.

Re: Rust: State of GUI, December 2022

#112

Post by zamadatix »

zackbrown wrote: post #50
jbk wrote: post #44

Earlier quoted context omitted.

It does not answer the native styling though…

Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode: 1. Conditional templating, like: if $is_android { //Only render the back button for Android } /* ... */ 2. Dynamic properties where Rust logic checks for the target platform, like: 3. Maintain a separate codebase (or different specific components)…

Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?

Re: Rust: State of GUI, December 2022

#113

Post by Lichtso »

terhechte wrote: post #105
Lichtso wrote: post #32

Shameless self promotion plug, I developed a GPU accelerated 2D rendering framework in Rust as well. It even comes with an experimental UI framework on top, which you can try in the browser if you have WebGPU enabled: https://github.com/Lichtso/contrast_renderer

Hey, I just ran the showcase locally. That looks super cool! Awesome project!

Thanks!

You can also checkout the "feature/ui" branch in GIT [1] to get the UI framework prototype.

[1]: https://github.com/Lichtso/contrast_renderer/tree/feature/ui

Re: Rust: State of GUI, December 2022

#114

Post by nu11ptr »

smasher164 wrote: post #10

One thing I'd like to see are Rust bindings for wxWidgets. Contrary to the prevailing opinion, I think wrappers over native toolkits are a fine approach for cross-platform development.

I think after years of agreeing with you I might actually disagree in 2022. I also prefer native widgets, but the problem is native programs have changed. It used to be they all looked very sterile and had 80-90% of the same widgets as every other OS, but if you look at apps today they are all much more media centric. Whether electron or native it is very common to have things like a "side bar" and other very specific widgets. These don't translate well to cross platform native widgets. I think Flutter might have the right approach with its fluent UI and macos libraries. I suspect the resulting app would look much more native in this day and age.

Re: Rust: State of GUI, December 2022

#115

Post by smoldesu »

rollcat wrote: post #94
virtualritz wrote: post #55

Earlier quoted context omitted.

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

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

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.

Re: Rust: State of GUI, December 2022

#116

Post by zackbrown »

zamadatix wrote: post #112
zackbrown wrote: post #50

Earlier quoted context omitted.

Pax does solve this, but we're now discussing a different problem than element-level look-and-feel or accessibility. Three ways you can slice this with Pax, ft. pseudocode: 1. Conditional templating, like: if $is_android { //Only render the back button for Android } /* ... */ 2. Dynamic properties where Rust logic checks for the target platform, like: 3. Maintain a separate codebase (or different specific components)…

Does this actually render a native Android back button to the canvas or are you simply saying Pax solves this by not restricting the user from making their own solution to the problem?

Pax's Android chassis isn't built yet — but a Pax `` will render an actual native Android button to a layer on top of a separate canvas layer where vector drawing occurs.

That native Android button will be affine-transformed, clipped, and occluded so that the two layers together act as a single coherent screen, and the developer can simply position / transform / layout that `` alongside, on top of, or underneath virtual / drawn elements as if they were on the same canvas.

This "dual layer" approach is already implemented for Pax's `` element on macOS (native SwiftUI `Text`) and Web (native `` + HTML text) — see: https://docs.pax-lang.org/intro-example.html

Re: Rust: State of GUI, December 2022

#117

Post by terhechte »

ianpurton wrote: post #108
terhechte wrote: post #104

Earlier quoted context omitted.

I recently build this side project with Dioxus: https://terhechte.github.io/twitvault/ Here's a review of the experience of using it: https://www.reddit.com/r/rust/comments/zegv2e/comment/izb6nl...

Can you let me know about incremental compile times? Basically with the HTML frameworks that use macros I'm getting incremental builds 10 seconds or more. Did you experience the same?

Incremental compile times were quite fast, I'd say in the 1-2 seconds. I also have another project where I'm using Dioxus-web for a web application. When building a web app, it also has hot code reloading and I'd say reloads take under a second (though I just started this app so it only has a couple hundred lines of code).

I have an M1 Pro Max though, which is quite a fast machine.

Re: Rust: State of GUI, December 2022

#118

Post by troad »

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.

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.

Re: Rust: State of GUI, December 2022

#119

Post by ptx »

silon42 wrote: post #63
chrismorgan wrote: post #61

Earlier quoted context omitted.

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.

SWT is even better now.

First of all, up-to-date official packages are now published to Maven Central as part of the release process, so you can just add it as a dependency as easily as with any other library. Until recently you would have had to either fiddle around with Eclipse's alternative package management system, download it manually or use someone's unofficial Maven artifact. But that's now resolved.

Secondly, if you bundle a Java runtime customized with jlink (as is recommended these days), an SWT application is actually smaller than a Swing application. When you don't use Swing, you can exclude the entire "java.desktop" module, which is slightly larger than the SWT libraries.

Re: Rust: State of GUI, December 2022

#120

Post by joshka »

Anyone have a recommendation of what they'd use to run on a raspberry pi with a touch screen? My preference would be booting direct to the gui and having no other things running (i.e. X11 / etc.) as well as having a good development story for macOS. Is there something decent that enables this for rust? Bonus points for github example repos.
Post reply on HN