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

101–110 of 149 posts

Re: Rust: State of GUI, December 2022

#101

Post by bryanlarsen »

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

Re: Rust: State of GUI, December 2022

#102

Post by tristan957 »

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/

FYI the project is called GTK, not GTK+, these days. They dropped it late in the 3.X cycle if I remember correctly.

Re: Rust: State of GUI, December 2022

#103

Post by rollcat »

twoodfin wrote: post #85
mistrial9 wrote: post #74

Earlier quoted context omitted.

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.

There's some reason to your proposition. Directly integrating/"embracing" foreign toolkits/web engines is the last thing Apple would ever do, but exposing more of the underlying machinery to allow third parties to integrate better - yeah, sounds good.

On the topic of Rust GUIs on Mac, this was recently in the news:

https://github.com/emilk/egui/commit/e1f348e4b24c2fa83d25c6a...

Re: Rust: State of GUI, December 2022

#104

Post by terhechte »

mritchie712 wrote: post #42
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…

have you built anything with it? We're using Tauri, but Dioxus looks very interesting.

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

Re: Rust: State of GUI, December 2022

#105

Post by terhechte »

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!

Re: Rust: State of GUI, December 2022

#106

Post by homarp »

virtualritz wrote: post #75
lelanthran wrote: post #59

Earlier quoted context omitted.

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

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

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

Re: Rust: State of GUI, December 2022

#107

Post by hollerith »

virtualritz wrote: post #55
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.

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

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

Re: Rust: State of GUI, December 2022

#108

Post by ianpurton »

terhechte wrote: post #104
mritchie712 wrote: post #42

Earlier quoted context omitted.

have you built anything with it? We're using Tauri, but Dioxus looks very interesting.

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?

Re: Rust: State of GUI, December 2022

#109

Post by bitexploder »

thiht wrote: post #92
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.

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

Ahh, well, it is the only one I use so, just a slight bias there :-D

Re: Rust: State of GUI, December 2022

#110

Post by zamadatix »

virtualritz wrote: post #75
lelanthran wrote: post #59

Earlier quoted context omitted.

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

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

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.
Post reply on HN