Hi Jos, and thanks for coming up with this.

I found the project quite useful as a way to move away from C++ to Rust [0]. Of course, there were still some unsupported features, but that didn't stop me.

I did some additional work [1], where properties can be writeable references to Rust objects, and where I hope to make QML objects (list items) possible to create from Rust as the next step.

I'm sure you thought about those problems before, and I'm curious if you know any non-obvious solutions. Apart from that, what's the preferred way to submit changes?

[0] https://github.com/rhn/notquick/

[1] https://github.com/rhn/rust-qt-binding-generator

Your notquick [0], "a nice workflow for emails that works for me", is similar to a topic I've thought about a lot and which was one of the reasons to start RQBG. (I'd like to tie my mail more to my projects and tasks via content addressable storage and RDF). Coding in Rust is fantastic, but the GUI options are not there yet. Hence RQBG which is meant to stay small (<3k lines atm).

Your project uses it in the right way: just commit the generated files. It's a drag and error-prone to write so much binding code by hand.

> some additional work where properties can be writeable references to Rust objects

You can nest objects. The demo code does this. Here's an example where both Parent and Child are a QObject:

    "objects": {
        "Child": {
            "type": "Object",
            "properties": [
                "name": {
                    "type": "QString"
                }
            ]
        },
        "Parent": {
            "type": "Object",
            "properties": [
                "child": {
                    "type": "Child"
                }
            ]
        }
    }

> some additional work [...] where I hope to make QML objects (list items) possible to create from Rust

You'd like to use object types as itemProperties as well? That's not possible at the moment, but a logical extension.

Experimenting in your own branch is a good way to start. Wishes and designs for them can be discussed in the issue tracker: https://bugs.kde.org/describecomponents.cgi?product=rust-qt-...

Currently, generated model code derives from QObject (Object) or QAbstractItemModel (List and Tree). Deriving from QWidget or QQuickItem would make it possible to write GUI components in Rust as well. Those classes are large though and I've not yet had the urge/need to try that.

By writeable references, I meant replacing one QML reference by another:

    RustFoo {id: "foo"}
    RustBar {
      foo_field: foo
    }

This is possible with my branch. Your above example needs to be amended the following way:

    "child": {
        "type": "Child",
    +     "write": "true"
    }

The API changes quite a bit unfortunately, and is no longer so nice to use.

Unfortunately, my ideas to use (read-only) objects in itemProperties all end up complicating the API even worse, with abundant Box<>es and wrappers over wrappers. I can't find an elegant way to work around the mismatch between some Rust and C++ concepts (mostly lifetimes), but I expect to come up with something worth discussing within a couple of weeks.

> The API changes quite a bit unfortunately, and is no longer so nice to use.

The object property could be changed to use QSharedPointer<X> when it is writable instead of a raw pointer (const X*). The setter could be done completely in C++ initially, since the main use case, as you show, is to assign that value in QML or Qt code.

> objects in itemProperties [..] I expect to come up with something worth discussing within a couple of weeks

Looking forward to it!

For any Qt, QML or Rust experts reading this: I'd love your keen eyes on the generated code from Rust Qt Binding Generator.

Does it use native system dialogs for opening files etc.?

On Windows and macOS, by default Qt will use the native file dialog.

How difficult is it to hook up to OpenGL?

By default Qt renders with OpenGL. You can talk to OpenGL via the Qt APIs. You can provide application logic in Rust, but the actual GUI is still written en C++ or QML.

You can use Qt 3D for a UI with Rust logic. Writing a 3d scene with the declarative QML language is nice. Or you do this with your favorite text editor or Qt 3D Studio.

http://blog.qt.io/blog/category/qt-3d/

I guess I meant, how difficult is it to have a OpenGL component with relatively arbitrary OpenGL commands issued from Rust. I don't really care if the buttons are rendered in OpenGL or not, but I need an OpenGL pane inside a normal GUI. Imagine a Rust CAD application with a QT GUI.

QT-3D doesn't really fit my use case unfortunately.

RQBG does not generate bindings for that, but you could derive from QOpenGLWidget and write FFI to call into Rust for painting and resizing. Then you'd use Glium to do the painting. You can still use RQBG for the application logic.

http://doc.qt.io/qt-5/qopenglwidget.html#context

https://github.com/glium/glium

Word, thanks!