Rust: State of GUI, December 2022

Can you let me know about incremental compile times?

Basically with the HTML frameworks that use macros I'm getting incremental builds 10 seconds or more. Did you experience the same?

It's beautiful!

OT: it seemed like an awesome application so I ran it but a few seconds into importing I got

"Rate limit for Tweet Replies reached. Waiting 18446744072038294844 seconds"

I'm not going to live nearly long enough for that!

ADD: and there's no cancel button or anyway way to stop it.

In theory it doesn't have to. In practice, yes.

My comment said that rust had a great cross-platform story, not Dioxus. If I was doing cross-platform rust I'd use cacao for iOS, Dioxus for web front end, et cetera.

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.

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.

Nah, still quite good, although I personally would go with WPF, Forms is also quite good for what still matters on Windows desktop, just note that on the new runtime (.NET Core) there are still some issues with the out of process designer.

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

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.

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

I think Apple made a strategic error when they failed to embrace DOM/browser engine-based toolkits like Electron on the Mac. If they had applied their leverage, of which they have plenty, the technical challenges of better native integration and support for the wide range of traditional Mac affordances would seem to have been quite manageable.

Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.

I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.

I use intellij on Linux and macos.

It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.

So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.

SWT was pretty good in my experience.

I've been an JetBrains (IntelliJ and these days CLion) user since about 2004 and what I'd say is this was a hard fought and slow incremental advancement. Back in the 00s, IDEA's UI experience was really sub-par and its foreign nature on the platform was very very clear.

It's amazing the amount of work JetBrains has put into this.

Ahh, well, it is the only one I use so, just a slight bias there :-D

Can you provide any source/documentation on how to achieve this?

As far as I know Electron is based on Chromium. And Chromium doesn't use native controls, it has its own custom controls that sometimes look similar to native controls.

I feel like it's a spectrum. The simpler the app, the more likely it's better to try an integrate with a closer to native look. I always found the issue of "native" to be a bit funny to me as someone coming from the 3D/VFX space, since all of the applications are built to be multiplatform and don't give a hoot about "native". Consistency of the application experience across platforms trumps all. The number of people I've seen complain about this? Zero. Usually the only issues arise around file pickers (some have custom ones, others use platform ones which have differences).

Granted these applications boast a ridiculous amount of features and are incredibly complex putting them on the opposite end of the spectrum compared to simple GUIs and chat/productivity applications.

To me, it's nice that platforms provide native toolkits* to provide this level of integration. But I don't view any app as "native" unless it comes from the party making the platform, as they are really the only ones that actually have to adhere to their human interface guidelines to the fullest extent.

* On Linux this is more up-in-the-air. I personally don't consider GTK and Qt as native toolkits, but the foundational pairing for things like libadwaita and KDE Frameworks which provide the associated platform widgets and HIG. Using the toolkits directly is fine and will mostly work, but it's not the same as a "native" application.

This was my experience as well. Simple windows with a button that increments a number are nice and understandable but if you try to get more complex controls working, you run into docs.

With C code often being unreadable, I found that Vala applications often have readable examples of how to use UI components. However, tooling support for Vala is extremely limited so experimenting with existing code may be a annoying. That said, I've had good experiences with opening these projects in Gnome Builder (once it got updated to work on my computer again).

If your component of choice doesn't have a Vala example, I'd resort to reading the documentation. Reverse engineering the API from the docs is often quite doable if you first look at how a component you do understand.

I've had similar problems, but worse, when I tried mixing Rust and Qt. I've never used Qt before so that doesn't help, but I found the API even less predictable in many cases, with some docs and examples several versions out of date.

I'd seriously consider just shipping a WINE'd Windows binary (using a tool like https://winepak.github.io/) for Linux targets with the current state of Rust GUI platforms. The amount of game UI/custom UI libraries out there is impressive but they all feel terribly wrong when I try to use them, in the same way most Flutter apps are terrible to use on desktop.

Do you know which of those toolkits is used for the new Windows 11 Notepad? It's quite a bit more "laggy" to scroll in than the old Notepad that's still on the Server edition.

Not quite, WebView2, which has the benefit of not dragging Chrome with every single application.

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:

  <SomeLayout>
    if $is_android {
     //Only render the back button for Android
     <BackButton />
    }
    /* ... */
  </SomeLayout>

  <SomeElement some_property={self.get_platform_specific_value()} />

Or any mix of the above.

Neat. Thanks!