Live data from Hacker News

Rust: State of GUI, December 2022

kas-gui.github.io

121–130 of 149 posts

Re: Rust: State of GUI, December 2022

#121
post #94

Earlier quoted context omitted.

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

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

Re: Rust: State of GUI, December 2022

#122
post #121

Earlier quoted context omitted.

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.

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.

Re: Rust: State of GUI, December 2022

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

Re: Rust: State of GUI, December 2022

#125
post #25

Flutter app with rust core works great too.

Yep, to be honest I don't think Rust has the manpower that Flutter has when it comes to writing a fully cross platform GUI. I simply don't expect anyone to be able to match Flutter or other similar frameworks like Qt without spending a lot of time and a lot of money.

Re: Rust: State of GUI, December 2022

#127

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

Re: Rust: State of GUI, December 2022

#128

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.

It looks like the author of wxRust is attempting another go at bindings with https://github.com/kenz-gelsoft/wxRust2.

Re: Rust: State of GUI, December 2022

#129
post #106

Earlier quoted context omitted.

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.

I should probably have said patterns, not paradignms but this beside the point.

I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.

Off the top of my head:

Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).

Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).

There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices. This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).

Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ``` ...```.

In Slack ``` works but ``` doesn not (but does in Discord, used to work in Slack in the past, I think).

I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.

But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.

Even if the platform itself doesn't provide a ready-made widget for each such case.

Hope that makes sense and explains what I meant.

Re: Rust: State of GUI, December 2022

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

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/

Post reply on HN