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

41–50 of 149 posts

Re: Rust: State of GUI, December 2022

#41

Post by onphonenow »

pjmlp wrote: post #7
dfgdfgffd wrote: post #3

Sadly Rust for WinUI3/UWP/XAML for Windows GUI - actually modern UIs on Windows - was abandoned or explicitly removed from Rust API bindings by MS. The listed library only uses the ancient win32 api

Doesn't surprise me, the folks behind it are the same that caused the deprecation from C++/CX, the very first time that Microsoft had something comparable to C++ Builder in productivity for C++ RAD GUI development. It got replaced with C++/WinRT, which basically requires one to code like in the good old days of Visual C++ 6.0 alongside ATL, editing IDL files without any kind of VS tooling support and manually merging…

Which is a massive bummer because win ui stuff w designer etc used to be great and performed better than a lot of electron stuff and was easy to develop - but they have seriously trashed their ecosystem there

Re: Rust: State of GUI, December 2022

#42

Post by mritchie712 »

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.

Re: Rust: State of GUI, December 2022

#43

Post by jbk »

Strom wrote: post #17
jbk wrote: post #15

How many of those actually look and behave like native and support accessibility correctly?

What even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.

Many of those are native enough, meaning they inherit the style from the desktop (and not just emulate it), do they support accessibility and so on.

For example, QtWidgets is native and qml is not. WxWidgets is, electron is not.

Re: Rust: State of GUI, December 2022

#44

Post by jbk »

zackbrown wrote: post #27
jbk wrote: post #15

How many of those actually look and behave like native and support accessibility correctly?

This is a core design goal for Pax. https://www.pax-lang.org Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web. This approach also enables a lean runtime footprint ( Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ and https://…

It does not answer the native styling though…

Re: Rust: State of GUI, December 2022

#46

Post by dohdhdaa »

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.

Re: Rust: State of GUI, December 2022

#48

Post by aaa_aaa »

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.

That will probably be Fuchsia, if it lives.

Re: Rust: State of GUI, December 2022

#49

Post by bryanlarsen »

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 have, but nothing used by more than 3 people.

Re: Rust: State of GUI, December 2022

#50

Post by zackbrown »

jbk wrote: post #44
zackbrown wrote: post #27

Earlier quoted context omitted.

This is a core design goal for Pax. https://www.pax-lang.org Pax composites a layer of native text and form elements on top of a canvas drawing layer. This solves accessibility across platforms, as well SEO on the Web. This approach also enables a lean runtime footprint ( Still early days — have made very little noise thus far; it's pre-alpha — but you can see what's cooking at https://docs.pax-lang.org/ and https://…

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) for each target platform, in the spirit of React Native

Or any mix of the above.

Post reply on HN