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

71–80 of 149 posts

Re: Rust: State of GUI, December 2022

#71

Post by dpcx »

ruph123 wrote: post #70
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/

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

Re: Rust: State of GUI, December 2022

#72

Post by amatheus »

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.

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.

Re: Rust: State of GUI, December 2022

#73

Post by Strom »

meindnoch wrote: post #54
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.

This. It’s so lame when UI elements can’t hang outside the bounds of the window (i.e. menus, tooltips, dropdowns, popovers) because everything is rendered like a game…

What you are talking about has nothing to do with custom vs native controls. Instead it's a question of using a single or multiple windows.

There are Rust GUI toolkits like Druid with custom controls that have elements outside the bounds of the main window.

Re: Rust: State of GUI, December 2022

#74

Post by mistrial9 »

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.

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?

Re: Rust: State of GUI, December 2022

#75

Post by virtualritz »

lelanthran wrote: post #59
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…

> 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 screen with two code editors, mini map & folders + terminal on screen two. But that's it.

But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.

But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.

I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].

Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.

Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.

They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.

IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.

[1] https://github.com/emilk/egui/issues/88

Re: Rust: State of GUI, December 2022

#76

Post by yencabulator »

zozbot234 wrote: post #8
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

Isn't that what the windows-rs crate is for? Doesn't seem abandoned.

It sure is abandoned: https://github.com/microsoft/windows-app-rs#this-repository-...

Re: Rust: State of GUI, December 2022

#77

Post by Strom »

phkahler wrote: post #45

KAS will never be popular so long as it can only be used with Rust apps. It's still nice to see how Rust can be used in this context, but maybe make it into a wrapper for something more flexible.

This seems like a bad take on popularity. What exactly is the criteria here? Is Qt not popular because it's not a JavaScript framework?

I think it's much more valuable to look at this from the viewpoint of the Rust GUI ecosystem, and not compare absolute numbers where nothing comes close to JavaScript .

Re: Rust: State of GUI, December 2022

#78

Post by pjmlp »

onphonenow wrote: post #41
pjmlp wrote: post #7

Earlier quoted context omitted.

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

Yeah, if you browse around the public repos, and occasional community calls, it really seems that whoever is still around has no idea (experience) of what are the features of the frameworks they are trying to replace, and asking for yet another rewrite on top of all of those done since Windows 8 is trivial.

Anyone that is still around beyond WinDev themselves just has too much sunk down cost into WinUI to switch for something else, even pre-Windows 8 stacks.

Re: Rust: State of GUI, December 2022

#79

Post by anon23anon »

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.

Does Dioxus run in a webview on mobile? That's how I'm reading the docs.

Re: Rust: State of GUI, December 2022

#80

Post by pjmlp »

nicoburns wrote: post #58
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.

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

With exception of VSCode, the only Electron apps that I use are forced upon me due to work requirements.

All of them I glady ignore on private owned computers, or use the browser version, they are anyway Web apps.

Post reply on HN