[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Review: Rust Qt Binding Generator
From:       Jos van den Oever <jos () vandenoever ! info>
Date:       2017-09-04 7:43:46
Message-ID: 11486402.bXnMM4kuHJ () joga
[Download RAW message or body]


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, 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.

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

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

Cheers,
Jos

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]