5 ms·

I'm the author of the generator. There's a presentation on the project here: https://fosdem.org/2018/schedule/event/rust_qt_binding_generator/ https://fosdem.or

• rhn_mk1 8y ago
  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/ https://github.com/rhn/notquick/ [1] https://github.com/rhn/rust-qt-binding-generator https://github.com/rhn/rust-qt-binding-generator
  • oever 8y ago
    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-binding-generator 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.
    • rhn_mk1 8y ago
      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.
      • oever 8y ago
        > 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.
• dvfjsdhgfv 8y ago
  Does it use native system dialogs for opening files etc.?
  • oever 8y ago
    On Windows and macOS, by default Qt will use the native file dialog.
• harrisreynolds 8y ago
  Nice work man! I added your project to Chartly [1]. Looks like a weekend warrior project with most commits on Fri/Sat/Sun. [1] https://chart.ly/github-dashboard/KDE/rust-qt-binding-generator https://chart.ly/github-dashboard/KDE/rust-qt-binding-genera...
• monocasa 8y ago
  How difficult is it to hook up to OpenGL?
  • oever 8y ago
    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/ http://blog.qt.io/blog/category/qt-3d/
    • monocasa 8y ago
      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.
      • oever 8y ago
        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 http://doc.qt.io/qt-5/qopenglwidget.html#context https://github.com/glium/glium https://github.com/glium/glium
        • monocasa 8y ago
          Word, thanks!