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

131–140 of 149 posts

Re: Rust: State of GUI, December 2022

#131

Post by joshka »

kevin_thibedeau wrote: post #124
joshka wrote: post #120

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.

Qt is the most mature system for running on a framebuffer.

That's pretty much the conclusion I'd come to when doing initial research. Good to know that others think the same. Mostly this is for the somewhere in the future type project we all have.

Re: Rust: State of GUI, December 2022

#132

Post by joshka »

eYrKEC2 wrote: post #130
kevin_thibedeau wrote: post #124

Earlier quoted context omitted.

Qt is the most mature system for running on a framebuffer.

I second this. I wrote an internal Qt/QML app that ran on Windows, Linux, Android, and Raspberry Pis. We had ~20 Raspberry Pi's running this app in kiosk mode. If only KDAB/cxx-qt[1] were ready then, I would have done as much as possible in rust . - [1] https://github.com/KDAB/cxx-qt/

Neat. Thanks!

Re: Rust: State of GUI, December 2022

#133

Post by nu11ptr »

smasher164 wrote: post #127
nu11ptr wrote: post #114

Earlier quoted context omitted.

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

I agree that GUIs have gotten more complicated nowadays, but I don't think the existence of platform-specific APIs is mutually exclusive with cross-platform abstractions. If anything, you should be able to specialize behavior for a certain platform.

I agree, but no one has done it successfully either. In wxWidgets any non-native widgets look very out of place. Some of the ones on Qt do as well. Neither of them that I've seen try to map to the more exotic widgets, but invent some of their own.

Re: Rust: State of GUI, December 2022

#134

Post by dfgdfgffd »

fsloth wrote: post #40
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

win32 api is pretty good. I don't see why you would want anything else for native app development. If you want to use the modern stuff it's far better to develop the UI frontend using Microsoft tools in C# and then use Rust as the backend. In this sense Rust story is not worse than C++ or C. If a person wants a native gui I guess QT would be worth investigating as well (unless one is concerned by the license).

There ist at least some support for XAML via C++.

But yes, it means C# UI with cumbersome Rust interop, if you rely on a Rust SDK.

Re: Rust: State of GUI, December 2022

#135

Post by dfgdfgffd »

yenhoo wrote: post #6
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

Sadly? I prefer desktop Windows programs to be gdi/win32, they are often the most thought out and optimized for actual desktop paradigms (i.e mouse+keyboard+high res screen) without giant margins, padding and whitespace everywhere and makes use of proper desktop class widgets like treeviews, listviews, tabs, etc.

Windows offers multiple and mixed paradigms though, so ideally the UI needs to be able to adapt to and handle these paradigms

Re: Rust: State of GUI, December 2022

#136

Post by bsder »

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…

The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.

Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?

Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.

Re: Rust: State of GUI, December 2022

#137

Post by pjmlp »

smoldesu wrote: post #122
worik wrote: post #121

Earlier quoted context omitted.

And when that new language is Swift. Coming from Rust Swift is hard to take.

That's more-or-less what I'm getting at. Apple can't replace Objective-C with Swift and expect people to not cock their head. They can either support a pre-existing language (like Microsoft with Rust) or home-bake something suitable for low-level development. Telling developers to not use the stuff they want to use sorta leaves their hands tied.

Microsoft's Rust support is basically non-existing for GUI applications, Rust/WinRT is miles away from achiving C++/WinRT parity, even more so with C#.

In its current state is only useful for CLI or services, unless you feel like doing WinUI team's work for free.

Re: Rust: State of GUI, December 2022

#138

Post by pjmlp »

aaa_aaa wrote: post #48
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.

Its official GUI toolkit is Flutter.

Re: Rust: State of GUI, December 2022

#139

Post by pjmlp »

dfgdfgffd wrote: post #134
fsloth wrote: post #40

Earlier quoted context omitted.

win32 api is pretty good. I don't see why you would want anything else for native app development. If you want to use the modern stuff it's far better to develop the UI frontend using Microsoft tools in C# and then use Rust as the backend. In this sense Rust story is not worse than C++ or C. If a person wants a native gui I guess QT would be worth investigating as well (unless one is concerned by the license).

There ist at least some support for XAML via C++. But yes, it means C# UI with cumbersome Rust interop, if you rely on a Rust SDK.

There is, for those that enjoy editing IDL files without any kind of VS tooling support, and manually merging generated code.
Post reply on HN