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.
Rust: State of GUI, December 2022
121–130 of 149 posts
Re: Rust: State of GUI, December 2022
#122Earlier 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.
Re: Rust: State of GUI, December 2022
#123Re: Rust: State of GUI, December 2022
#124Anyone 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.
Re: Rust: State of GUI, December 2022
#125Flutter app with rust core works great too.
Re: Rust: State of GUI, December 2022
#126[1] https://azul.rs/
Re: Rust: State of GUI, December 2022
#127One 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…
Re: Rust: State of GUI, December 2022
#128One 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.
Re: Rust: State of GUI, December 2022
#129Earlier 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 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
#130Anyone 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.