--nextPart1526075.BUEAoT6fXZ
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

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 wri=
te
> > > the UI in C++ or QML. The generated code has no dependencies apart fr=
om
> > > Qt Core and the Rust crate libc.
> >=20
> > 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
>=20
> cpp_to_rust is an ambitious project. cpp_to_rust lets you call Qt librari=
es
> 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 deal=
ing
> with ownership. A QObject is responsible for destroying and deallocating
> its children. QString is value type with a reference-counted memory block
> inside.
>=20
> 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.
>=20
> 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.
>=20
> The interesting part of writing Qt code is custom implementations of QObj=
ect
> and QAbstractItemModel that you pass to Qt elements. QComboBox, QTableVie=
w,
> QListView all take QAbstractItemModel implementations.
>=20
> 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=20
your intent was to see your binding generator as something temporary or=20
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.
>=20
> For example, here is an implementation of a QAbstractItemModel that is us=
ed
> as model in QtChart and (Q)TableView in the demo. It does not look like a
> QAIM at all.
>=20
> https://cgit.kde.org/scratch/vandenoever/rust_qt_binding_generator.git/tr=
ee/
> demo/rust/src/implementation/time_series.rs
>=20
> Of course, it's a bit simple, because it's static data.
>=20
> 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)
>=20
> 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 t=
he
> 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=20
argument for different languages though.

> > > [...]
> > > This project is not a typical C++ KDE project, but I hope it can be p=
art
> > > of KDE anyway.
> >=20
> > 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.
>=20
> Cool. Thanks for taking a look.

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

Regards.
=2D-=20
K=E9vin Ottens, http://ervin.ipsquad.net

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


--nextPart1526075.BUEAoT6fXZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQXFmpSdcX6bxpI/XgHS7vLjezJ4gUCWa0gIwAKCRAHS7vLjezJ
4qGRAKCnVSOCQUY8ZBCQo2csAnfHpOssXACgnZk3iHC/8XVfj4Nc/NpAsQrHDrQ=
=xvFe
-----END PGP SIGNATURE-----

--nextPart1526075.BUEAoT6fXZ--