
Rust Qt Binding Generator - vbsteven
https://github.com/KDE/rust-qt-binding-generator
======
oever
I'm the author of the generator. There's a presentation on the project here:
[https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...](https://fosdem.org/2018/schedule/event/rust_qt_binding_generator/)

Happy to answer questions.

~~~
rhn_mk1
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
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-...](https://bugs.kde.org/describecomponents.cgi?product=rust-qt-binding-
generator)

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

------
VexorLoophole
I am no developer but like to toy around, build small tools and automate
stuff. So i often can't wrap my head around programming stuff promoted on HN
(also i simply can't wrap my head around rust since i never really learned
programming from the ground up...).

But stuff like this, some Binding Generator really amazes me and i am also
able to understand the code. Had the same feeling when i was working on some
REST API Binding in Elixir, and was looking at other Repos and found a
generated Slack Package. Out-of-the-box solutions like this are great (myself
would start to write every function by hand and probably stop half through and
try something else...). Thank you for making something like this open source
so beginners like myself can take a look :)

~~~
vardump
> (also i simply can't wrap my head around rust since i never really learned
> programming from the ground up...).

If you want to learn, alternate between studying and doing.

Read up on the basics, then go to doing mode, study something a bit more
advanced, rinse and repeat.

Start the doing part by modifying existing code; perhaps some command line
utility, they tend to be simple. Then add some features in it. You could also
cut out all the functionality and implement something different in the
skeleton.

It's a good idea to use version control even for your experiments, so you can
go back when you inevitably break something so that it no longer compiles or
works correctly. Sometimes breakage is obvious only much later. One thing is
for sure -- you will break things, and version control will watch your back.

I'd recommend git (or hg), because they can be used locally without a server.
Or a github account. (But really even zipping the directory is better than no
history at all. But seriously, use proper version control tools.)

This method will work for Rust or anything else that can be similarly
iterated.

~~~
VexorLoophole
Thank you for your tips.

Of course i am already using git. Working as a solo sysadmin i often automate
stuff and need some scripts which i all version control. Since i like to work
as a sysadmin i have of course also my own git server etc. :)

At the moment i try to focus on elixir, since i like the clean syntax and the
REPL to try things (which is also a problem when i try to write something in
rust. Since my programming workflow is pretty much based on try and error
while i have the feeling a rust (or c) developer often knows beforehand what
he puts into the function and what will come out). At work i often need to
communicate with some kind of API (for example automatic sorting of pages in
confluence) and all this GenServer Stuff helps me in Elixir.

But i think Rust would be a good choice if i need to write something more
metal. Some small command line utility on one of the servers. Will try your
"change an existing code"-approach!

------
j1elo
This, together with the Rust autogenerated bindings for GStreamer
([https://github.com/sdroege/gstreamer-
rs](https://github.com/sdroege/gstreamer-rs)) make up for my two favourite
work-related C / C++ technologies. Kudos for this, it's great to see how the
Rust ecosystem is growing more and more every day!

------
StevePerkins
I've seen a ton of bindings like this over the years, mostly implemented with
SWIG ([http://www.swig.org/](http://www.swig.org/))... for binding desktop GUI
libraries like Qt, wxWidgets, etc to languages more accessible than C++.

It's all awesome, and this example here is certainly better than most
(fantastic work!). The problem has traditionally been that most of these
things are hobby projects from a single developer, and they go moribund when
the developer gets bored and moves onto something else. Hell, if you Google
around a bit, you might still find a "wxJava" binding on Sourceforge that I
started and abandoned ~15 years ago.

To actually be fit for production use, one of these things needs to be either:
(a) sponsored by some entity that keeps leadership continuity going, or (b)
driven by an unusually large and unusually non-toxic volunteer group that is
able to effectively mimic "a", or (c) created by someone who sees it as their
crowning achievement and effectively dedicates their life to it. If this
project really does have committed backing from the full KDE organization
itself, then that's very encouraging!

I'd be interested to know if it's really an organization level commitment, or
if they're just providing hosting for an experiment spearheaded by a single
contributor (the Go team at Google has an "experimental" GUI library like
this, but it's just one guy's noodling and no one really sees it as gaining
traction outside of that). I'd also be curious what the cross-platform story
is at this point (i.e. does it build and run on Windows?).

The only other examples I've seen so far that even come close to fitting the
bill are in the Python community. And even that is a bit of a mess. There's
confusion between two competing Qt bindings... and the wxWidgets binding has
been going through a re-write for years, such that it's confusing whether to
stay on the old version or adapt the new one (kinda like Python itself!).

But I still keep my eyes open, and look into this space every year or so. It
would just be so awesome if there were a viable cross-platform desktop GUI
solution, for a modern statically typed language somewhere between the
extremes of C++ and JavaScript. I accept that desktop development is less
important than it was 15 years ago... but I reject this notion that, "
_Desktop development is dead, just use Electron_ ". There are still millions
of use cases for true desktop applications. The only thing that's "dead" is
the notion of being able to get away with just writing a native Windows
version, and ignoring Macs (or vice-versa). And all of the cross-platform
solutions have major problems, or are tied to languages or toolchains that
people don't want to use, so that lack kinda sucks the oxygen out of the room
for the open-source and hobbyist crowd on web forums.

~~~
dvfjsdhgfv
I completely agree with your thoughts. However, Rust is getting a lot of
traction these days. Sooner or later more people will start to wonder "How do
I write a portable app in it?" The Qt solution is a neat one, and might soon
become the de facto standard - something similar happened with Python and Tk
in the past.

~~~
danieldk
I have dabbled a bit in Rust GUI programming for a small project and gtk-rs
also works quite well. Is is also actively maintained and has regular
releases.

[http://gtk-rs.org/](http://gtk-rs.org/)

Some people from the GNOME and Rust communities are working on macro magic
that allows you to create GObject classes from Rust [1].

The downside is that the applications do not look native on macOS or Windows.
But so doesn't Electron ;).

[1] [https://gitlab.gnome.org/federico/gnome-
class/](https://gitlab.gnome.org/federico/gnome-class/)

------
dman
What are the safety guarantees of the resulting program?

~~~
kazinator
The safety guarantees are precisely those of a program which calls reams of
legacy C++ cruft.

~~~
dman
Would appreciate pointers to pure rust GUI libraries from any rust experts in
this thread.

~~~
dagmx
The current state of UI in rust is very early.

Most of the mature UI libs are bindings to another language.

However there are some native UI libs

[https://github.com/PistonDevelopers/conrod/blob/master/READM...](https://github.com/PistonDevelopers/conrod/blob/master/README.md)

