Is it just me or it feels way too ugly? Multiple opaque layers of abstraction plus Rust kind of feels shoehorned when it's called from C++. Something tells me it's terribly difficult to write, debug and deploy. I don't exactly see the benefit of adding Rust here.
C++ and Rust are very different. A direct binding is near impossible. This project takes a pragmatic approach: the GUI part is QML/Qt and the logic part is Rust. The separation is quite strict. The demo application showcases more of the features than the blog does. Notably, the mapping between the Qt data models and the Rust code is something that makes development effective. This will be emphasized in the upcoming FOSDEM presentation.
> I don't exactly see the benefit of adding Rust here.
From that perspective, there isn't any. Dyed-in-the-wool "QT app-devs", if there is such a category (KDE devs?) already have access to Rust libraries, in the same way they have access to most stuff in weird compiled languages: you wrap the library in a C ABI and call that. It's a well-understood process in QT land.
I think this project is more an effort to give Rust projects access to a native graphics toolkit (that happens to be QT) for adding a GUI to a previously CLI application. I could see, for example, the Parity Ethereum client (written in Rust) getting a native system-tray/notification-area widget written in QT.
The binding generator generates a binding from a JSON file. That gives C++ and Rust code. Additionally, a default Rust implementation is generated for convenience where the programmer fills in the application logic.
At no point is there a need to edit a generated C++ file. Any other build tool with C++ support could be used instead of CMake. What it should do is call rust_qt_binding_generator when the binding description changes.
Rust has benefits over C++. But you cannot just port a project from C++ to Rust, especially if you use a Qt GUI.
To combine Rust with Qt you could use a language binding that wraps Qt in a Rust API. This is a very big undertaking and will result in an API that is not Rusty at all. Qt is a great toolkit but it does not have all the safety guarantees that Rust has. So the Rust API on top of Qt would have a complicated manual.
This binding generator creates code from a JSON description that is very limited compared to Qt or Rust, but it generates code that is good Qt and good Rust.
The generated code has no dependencies apart, obviously, from Qt and Rust and the generator itself is small and has no dependencies apart from Qt.
Yes, if you combine two languages, you get the warts from both languages and that is indeed uglier than using a single language.
This is the reason why I have learned to only use first party SDK languages for production code.
Anything else that isn't supported by a platform SDK out of the box, means extra work writing FFI bindings, complexity (is the bug on the platform libraries, FFI bindings or runtime library of the new language), harder to debug (lack of support from SDK tools).
Of course, if the goal is to try to push SDK vendors to add support, then this is probably the only path to raise awareness.
i think the benefit is more for Rust users who find they need to make a GUI. There aren’t many good options right now so this will probably be welcome.
The project has no assumption of the platform that is used. It works with vanilla Qt projects regardless of IDE or build tool. Call rust_qt_binding_generator from your build tool to generate the binding files.
This project is different from most language bindings. With it, you generate a binding just for the code specific to your project. So interface the between Rust and C++ is very small. This project does not wrap Qt API in Rust code or Rust API for Qt. Instead of using a lot of energy to heat the whole house, you put on a sweater.
Having official status, means anyone coding for the said platform can be confident that everything related to the platform infrastructure (IDE, libraries, debuggers, documentation, discussion forums, build systems) will take into account the language.
Anything that is just 3rd party will have integration issues, as one needs to rely on the language community to step up to sort them out, or even left in a zombie state as interest fades away.
Most time on the project is spent on making a sensible binding at all. The ergonomics could definitely be improved. Rust has powerful macros that could make it simpler to use these bindings. My development time is finite.
