Qt and QML are fundamentally C++ things, but there is an official Python binding (PySide2) as well as PyQt5. There clearly should be Rust bindings. However bindings such as qml, qmlrs, etc. haven't been touched in years, and bindings such as qt_core seem to be for Qt 5.8 and now we have 5.11.2.
Are people just not writing GUI code using Qt or QML in Rust (*) or is there a new standard way of working with QML and Qt with Rust?
(*) gtk-rs is very good, but GTK isn't that good for portability across OSes.
I'm the author of rust_qt (including the mentioned qt_core crate). One of the biggest issues right now is the API stability. Unfortunately, when migrating to a newer Qt version, the binding generator may produce API that is incompatible with the old version. Overcoming this issue and seamlessly supporting different Qt versions is my next goal. This requires significant changes to the generation process. Things are going pretty slow right now because I don't have much free time, but I plan to continue working on it.
Making contributions easier is one of my goals. For instance, I'm working on moving the whole process into a contained environment (such as Vagrant) because setting up all the dependencies is a pain and libclang likes to produce very different results depending on the tool versions and platforms. Having an easily reproducible environment would help a lot.
Unfortunately, at this stage it's hard to provide an opportunity to contribute. The project goes through a major refactoring. Some of the assumptions the architecture is based on have proven wrong, and I have to take everything apart and fit all the pieces back together. Once this is done, contributing should become much easier.
Could you be interested in an ABI checker validating whether Rust-side struct sizes and member offsets match what the C/C++ compiler thinks them to be? I had some ideas and a start of a project when I thought of validating my binding generator for GObject-introspection.
When working on C++ library bindings, it's actually the other way around: the C/C++ compiler is the authorative source of the valid sizes and offsets, and the Rust code must match them exactly. In rust_qt, I make no assumptions about sizes and offsets, as there is really no way to get that information up front, especially in a cross-platform way. It's sometimes possible in C, but the C++ standard just leaves too many things unspecified.
So in my implementation the crate's build script invokes the C++ compiler of the current toolchain to find out sizes and alignments of the needed types. Member access goes through C++ wrapper functions, so the offset math is delegated entirely to the C++ compiler.
