KDE Review: Rust Qt Binding Generator

[Kevin Ottens]

Hello,

On Monday, 4 September 2017 09:43:46 CEST Jos van den Oever wrote:
> 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?
> > https://github.com/rust-qt/cpp_to_rust
> 
> 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,

Note that I didn't mean that to diminish your work, I was really wondering if 
your intent was to see your binding generator as something temporary or 
something with longer term plans.

Looks like it's longer term which sounds good.

> 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 all.
> 
> https://cgit.kde.org/scratch/vandenoever/rust_qt_binding_generator.git/tree/
> demo/rust/src/implementation/time_series.rs
> 
> 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.

Thanks a lot for the extra insights. Makes sense.

> > 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 and logic.

Sure, it always make sense to separate them, I don't perceive this as an 
argument for different languages though.

> > > [...]
> > > 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.

Interesting stuff anyway, looking forward to it having stable releases. :-)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20170904/51fc45b5/attachment.sig>