GTK is the best option at the moment. Apparently QT is difficult due to it being heavily based in C++'s view of the world, which doesn't translate particularly well to Rust (notably Rust not supporting OOP in the same way). There is hope of a new rust-native GUI library (possibly in the vain of Flutter[1]) based on the work done for Servo[2], but that looks to be a way off.

[0] https://www.reddit.com/r/rust/comments/6l5c94/can_we_crowdfu... [1] https://flutter.io/ [2] https://github.com/servo/webrender

I think translation problems aren't caused by OOP itself, but by messed up name mangling, and total lack of any sane standard for it in C++.

Name mangling is almost completely a non-issue. We solved it years ago for the Servo SpiderMonkey bindings, to name one instance.

What is the most difficult part for Qt then? Translating some of its concepts in Rust?

AFAICT, QT has its own implementation of signals and slots (events and event handlers essentially) which is a pain for Rust's ownership model and it also has a code generator that deals with some of C++'s limitations, making it harder to generate usable bindings. If that weren't enough, there is no native (clean) Rust way to do C++ inheritance which is another big pain.

Rust doesn't have a concept of inheritance and overriding which is a pretty key part of the qt design.

If you are okay to use qt out of the box, there are a few bindings. But you won't be able to customise it like you would with actual qt.

Name mangling is by far the easiest part. It's already solved via bindgen and clang.

That only works for clang based static/dyn libs though right? If I remember correctly msvc has a different set of mangling.

Clang also supports MSVC mangling. I've never tried it with bindgen, but it can be done.

Huh, nifty. Learn something new every day, thanks!

Clang supports MSVC manglings and bindgen correctly exposes them.

When it comes to UI toolkits, there's just one rule -- "anything but GTK".

Care to elaborate?

I like GTK, but it's place is in gnome (which I also like) and no where else, on any other system it looks horrible and out of place, particularly when it comes to things like the file dialog.

Also the devs no longer consider it a cross platform library, everyone using it as one is stuck on GTK2.

GTK is a bazaar style project, if it has issues on some platform then that's because no developers have stepped up to fix issues on that platform.

There's support for Windows native file dialogs since 3.20.

https://blogs.gnome.org/alexl/2015/11/05/native-file-chooser...

(Not OP) Most gtk applications are very difficult for me to use, for a combination of reasons. I have joint problems that mean I rely on mouse and touch for working with text more than most people. The biggest obstacles are:

1. Gtk constantly clobbers the middle-click clipboard on Linux. In non-gtk programs that's one of my most efficient ways of entering and editing text.

2. Gtk completion dropdowns steal clicks, so typing into a field with completions (that I don't want) with an onscreen keyboard takes at least twice as many button presses as it should.

I have no such problems with Qt (or anything else).

Not-Gnome was never a priority for the developers, conversely, it doesn't work very well on Not-Gnome. That alone disqualifies it for me. Besides that, the docs are simply bad and glib is such a huge mess that I actively avoid touching anything near it with a ten foot pole.

@dom0 @flukus of course, thanks. Didn't think of that as I am a satisfied GNOME user (for the continued focus on UX refinement, simplicity, stability) and was even forgetting people might consider it for non-GNOME.

This thread [1] has some good recent discussion of the current state.

[1] https://users.rust-lang.org/t/current-state-of-gui-developme...

The last time I checked there was this: https://github.com/White-Oak/qml-rust

But it looks stalled. Not sure if anyone is working on such bindings today.

UPDATE: I just found this which looks active: https://github.com/rust-qt/cpp_to_rust

There are some glaring issues w/ the Rust Qt crates, namely subclassing things like QWidget. But it is high priority [0]. This is essential for using Qt as many things are not "signals" but instead overridable protected methods. I started a embedded browser PoC [1] until I hit these limitations which forced me to use C++ [2].

And many other static langs (i.e. not-python) have issues with their Qt bindings (e.g. Go [3] which can't compile via MSVC which some things like the QtWebEngine stuff need). Sadly, for advanced UI (e.g. complex tree views, docking, etc) that is cross platform and looks native, Qt is all there is, and it's reliance on C++ makes it a bit tough to use across languages. A maintained C iface for Qt is really needed.

0 - https://github.com/rust-qt/cpp_to_rust/issues/53

1 - https://github.com/cretz/rust-qt_cef_poc

2 - https://github.com/cretz/qt_cef_poc

3 - https://github.com/therecipe/qt/

bindgen has native C++ support (as of recently), so hopefully that will help.

That's great!

You might try the imgui/nuklear crates, dealing with generated bindings for something massive like Qt will never be pleasant.

Both PyQt and PySide work quite well for something that "will never be pleasant".

PyQt and PySide was exactly what I had in mind. It'll leak memory, segfault on load 1% of the time, segfault if you call unrelated methods in the wrong order, you'll randomly get QStrings and QExceptions instead of their Python equivalents, and it'll be impossible to debug.

Nothing much (some OpenGL bindings and such).

They use it for systems software and backend services.