qmlrs 0.2 rewrite using libqmlbind's C API

[bgdncz]

This is the backend for the Ruby QML bindings and is meant to be used for other language bindings as well. Maybe this would make this library more versatile!

[rainbyte]

Each qml binding has its own backend, maybe it would be better to have just a single one.

[tpickett66]

@cyndis and/or @florianjacob, is this something you'd consider a pull request on? I spiked on it over the weekend and it seems like it should be a straightforward process to transition.

[florianjacob]

In general, I think it's a good idea to share such efforts if possible. libqmlrs seems to be very feature-complete, except its lack of documentation to guide you through the header files and its custom-defined types.

So far, I only skimmed over the C++ wrapper internals enough to understand what the provided methods are for and what their Qt equivalent is, so I can't comment on whether the qmlrs wrapper is technically better than libqmlrs.

Did you already push your work somewhere?

[tpickett66]

My spike was in a blank crate, I just pushed it to https://github.com/tpickett66/rust-qml

[florianjacob]

Hm… Maybe we should really do a blank-crate rewrite using libqmlbind, and publish it as 0.2.0 when it supports let's say context properties with slots and signals.

[tpickett66]

That could be the right approach to take. Assuming you'd want to maintain API compatibility maybe current efforts would best be spent by adding to the test suite.

[florianjacob]

Regarding API compatibility: As I see it, we have two API parts: The slot declaration macro, and the enginge creation / .exec() part. The macro might already has to change to support signals as well as slots, and the engine creation is following what you would do in Qt/C++ so I don't think there is a sensible alternative, but as only a single piece of code in every project, it could be easily changed in one place. So don't refrain yourself too much here too much with maintaining APIs here!

Still, adding the tests and discussing the change when the API breaks is a good idea, of course.

Go ahead if you want to continue to work on this. I guess I can comment if you want to discuss something or review PRs for your repo to get it in shape for a release, but I won't have time to contribute code for the next 3 weeks.

I'd tag a first release for people to test when the libqmlbind-based lib is on par feature-wise with current qmlrs, and accept & release it as official qmlrs 0.2.0 when support for signals is implemented.

I think it could lead to a good macro to first ignore the macro but provide a way to register signals / slots by hand without macros, and then think of a macro as optional but very useful shorthand, much like it is done in serde.

[eightbitraptor]

As a reasonably inexperienced Rust developer who's interested in contributing to this, is there anyway I can get involved at this point?

[florianjacob]

@eightbitraptor Thanks for your interest! I guess there'll be suitable tasks which don't need much knowledge about the Dark Magic of Rust as soon as the very basics (i.e. how to glue Rust and libqmlbind together and expose that as safe rust) is done, e.g. stuff like adding each data type a QVariant can be or every method libqmlbind provides that aren't vital to show at least a window.

[florianjacob]

@tpickett66 had some unexpected hours of time last sunday. Based on your version, I got as far as being able to display a window and exposing methods on a struct. I'll publish it around the beginning of next week when I had time to document it a little what I actually did there and how libqmlbind does things. It's a pity libqmlbind is not documented at all, but I think I now understand most concepts there.

Spoiler: libqmlbind doesn't support the quick-and-dirty-way of “just expose this instance as a rootContext property to QML“ qmlrs was based on before, but only the clean „register this as a qml module, import & instantiate objects in QML“ way. Which is probably not a bad thing, but will break the old qmlrs API now definitely. Shouldn't be hard to fix, for users, though, and the benefits of working properties & signals will outweigh that.

[White-Oak]

Ahem, I'm completely incompetent here, so sorry in advance, but I've seen that starting from 5.7 Qt will require C++11 to build it. Does it render proposed libqmlbind (C API) obsolete or not?

[georgschoelly]

@White-Oak: Unless I'm very mistaken, libqmlbind is there to support bindings that cannot interface with C++ and need a C API. Switching to a more modern version of C++ does not change that.

[White-Oak]

@georgeschoelly Nice to hear!

[florianjacob]

@White-Oak : @georgschoelly is correct, libqmlbind just uses C function calls as universal exchange format between libraries that almost every other language can talk to, i.e. ruby for ruby-qml for which it was written for, or, in our case, Rust via std::ffi. libqmlbind itself is actually written in C++, so there's nothing to worry about. 😄

As a side note, I'd be happy if libqmlbind also already required C++11 as a dependency, so one would be able to use some new nice stuff like nullptr in its code, but I don't know whether that's already the case.

[White-Oak]

@florianjacob It's nice, thanks for the detailed answer! Sorry to bother, I knew nothing about these libraries 😖

[florianjacob]

Because the question “is this parameter / return value of libqmlbind mut or const? Does it transfer ownership or not?“ was so pervasive and always lead to digging in libqmlbind's code / Qt's documentation and me starting to add comments for libqmlbind's functions in my code, I decided to pause working on this and document libqmlbind properly first. I'll continue here as soon as my PR is ready to be merged.

How did we ever got away with not specifying these things at all in C/C++? 😆

[florianjacob]

status update: documentation is now finished & merged, and I also did a few code fixes I found along the way. @rainbyte is working on Examples based on other binding projects, which will be ported as examples for the rewritten qmlrs.

In the documentation process, some opportunities for archirectural improvements were discovered. Taking those is the next milestone on the way to the rewrite.

[vandenoever]

If I can help out with doing testing, please let me know. I'd love to have signals in the code.

[nbigaouette]

Any news on the port? I'm quite interested in this, but I can't find any information on its status. Is it started at all? In another repo / unpushed branch? Is it waiting on something from libqmlbind? MR seanchas116/libqmlbind#9 was merged (great work @florianjacob!) so at least the documentation should be fairly complete...

[nbigaouette]

Since I'm eager to do some rust, I attempted to wrap libqmlbind. The result is https://github.com/nbigaouette/qmlrsng

The way I see it there is two crates, one exposing the unsage C api, one being a safe abstraction over the first one.

libqmlbind was wrapped using bindgen.

The unsafe one kind of works; I am able to show a hello world QML window. There's a lot of work to do, but it's a good proof of concept.

Any comments or help welcome!

[pythoneer]

@nbigaouette this looks nice. I tried this myself. It would at least be good to know if the project is still alive.

[Raven24]

Is this rewrite something to consider being worth waiting for? I'd be about to start a personal mini-project and I'd like to use QML and Rust, if at all possible. If the API might be evolving, I could also postpone my efforts...
I'm just curious if there is a timeframe where there might be some progress on this or whether the efforts on the rewrite are on hold for now, anyway.

[White-Oak]

@Raven24 In the meantime, I wrote https://github.com/White-Oak/qml-rust bindings for qml. They support providing values to qml, defining QObjects from Rust, QListModels, registering additional QML types.

However, main source of "how-tos" is available only from examples, proper tutorials or guides still need to be written.

[florianjacob]

Sorry to keep you all hanging, was way too demotivated by the introduction of DOtherSide in #22 and the prospect of working through another C binding library to find out which one is the better fit and then possibly starting all over again, to continue to work on this.

But now there's QML: A New Hope, qmetaobject-rs looks way better than what I hoped to achieve with my rewrite. If that concept works out and there's a first release, I'll think about deprecating qmlrs in favour of that, in an effort to concentrate the endavours on the best approach.