For a subset of applications DearImgui is suitable.

There's a gallery of screenshots here. https://github.com/ocornut/imgui/issues/123

Unlike the others mentioned it is an immediate mode GUI, which is an interesting approach.

Rust has decent GTK bindings, and that's basically the only decent option at the moment.

But better user relm as well, Gtk-rs alone is a bit of pain if one doesn't want to use Rc<RefCell<>> everywhere (see Gtk-rs samples and clone macro).

> If you are targeting Linux with a professional GUI application your only options in 2020 are

There are other options. Maybe unpopular options, but options nonetheless: Electron, and immediate mode GUIs.

They certainly have downsides. But there are "professional" GUI applications in widespread use that are written with both.

Immediate mode makes accessibility difficult, in my experience. That's certainly something worth considering.

Applications made in Electron are not professional. I am shocked anybody uses such applications. Electron is basically a web browser displaying a web page.

Are you suggesting that vscode is "not professional"?

I thought the whole idea is to create an alternative using Rust. Otherwise you can just use existing GTK or Qt bindings.

What would you propose doing differently than what we're doing? This is a serious question.

Sorry, couldn't answer before, HN was doing its weird "you post too often" dance.

I guess I misunderstood the intent behind the project. I thought it's like a full alternative to GTK / Qt but in Rust which would be really nice to have, but I get that it would be a much bigger project than something built on top of them.

Have you looked into iced? It targets Vulkan or WebGL.

Ah, yes. There is cross-platform infrastructure we could use, which is what Iced does. We have chosen to do things a bit differently. In general, we use platform capabilities where they're available, for a much lighter weight build and less impedance mismatch with native look and feel. It's a tradeoff, and one of the downsides is that the Linux port needs a bit of extra attention.

Ultimately, I believe our approach will yield higher quality results, but there's a lot to learn from Iced as well.

I remember you wrote before that "there is no such thing as native GUI." Is that more of a high level situation, with text rendering and other lower level things still best handled by "going native"? What other things count as low level like this?

Yes. What I meant by that was more a reference that platforms increasingly support diverse ecosystems of UI toolkits, especially at the high level. Even on mac there's a choice between SwiftUI and AppKit (technically Catalyst too, but that doesn't seem to be a hit), while on Windows there is even greater diversity. So basically it's a way of saying "just use the native toolkit" doesn't actually solve as many problems as one might think.

At the lower level, for some things you really have to integrate deeply with the platform, and for others (text layout is one), there are advantages, including faster builds and smaller binaries. (Ultimately I'd like to have a highly GPU accelerated 2D graphics library that does everything, including text, but that's some ways off and doesn't block current work)

He mentions it about halfway down the article along with other systems he's examining.