KDE Review: Rust Qt Binding Generator
Jos van den Oever
jos at vandenoever.info
Mon Sep 4 08:43:46 BST 2017
Op maandag 4 september 2017 07:46:28 CEST schreef Kevin Ottens:
> On Sunday, 3 September 2017 18:14:49 CEST Jos van den Oever wrote:
> > [...]
> > The idea of this binding generator is that you write each part in the most
> > appropriate language. Rust bindings for Qt are hard to get right and will
> > still have caveats for a while. With this generator, you write the UI in
> > C++ or QML. The generated code has no dependencies apart from Qt Core and
> > the Rust crate libc.
> So what's the intent with this one? Is it a stop gap measure until
> cpp_to_rust is more complete?
cpp_to_rust is an ambitious project. cpp_to_rust lets you call Qt libraries
from a Rust project. This means that the qt_core, qt_gui etc crates have to
take care of thread-safety and ownership. Qt has quite a few ways of dealing
with ownership. A QObject is responsible for destroying and deallocating its
children. QString is value type with a reference-counted memory block inside.
I spent time on another binding project and sent patches to it, but it was not
active anymore. Then I realized that it is early for depending on a project
that tries to wrap Qt as a Rust crate.
If you'd like to use Rust in an existing KDE project, you'd not take that
approach either. You'd call new Rust code from your Qt code. cpp_to_rust
focusses the other way around.
The interesting part of writing Qt code is custom implementations of QObject
and QAbstractItemModel that you pass to Qt elements. QComboBox, QTableView,
QListView all take QAbstractItemModel implementations.
So the binding generator, which I'm fine to call a stop gap measure, focusses
on that part. You implement QObject and QAIM with Rust code that does not feel
like Qt, but feels like Rust code.
For example, here is an implementation of a QAbstractItemModel that is used as
model in QtChart and (Q)TableView in the demo. It does not look like a QAIM at
Of course, it's a bit simple, because it's static data.
When cpp_to_rust has a stable release and is easy to use from exisiting C++/
CMake projects, this project can be ported to use that. The code that
generates Qt implementations could then be a Rust macro.
> Are you contributing to it as well? (I started patching it locally but still
> need to clean up my work for upstream contribution)
No, I contributed to a previous binding project. cpp_to_rust is an attractive
idea because it allows you to code only in Rust. Enticing as the idea is, I
wanted something that works now. In addition, I like the idea of separating UI
> > [...]
> > This project is not a typical C++ KDE project, but I hope it can be part
> > of
> > KDE anyway.
> Of course take the above more as curiosity and wondering how that will fit
> regarding the larger Rust ecosystem. I don't see a problem with things like
> this to be part of KDE.
Cool. Thanks for taking a look.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel