
A Simple Rust GUI with QML - irfanka
https://www.vandenoever.info/blog/2017/02/17/a-simple-rust-gui-with-qml.html
======
conradev
Because it has largely not been done before, part of me wonders how well Rust
would work to build a large, complex GUI. All GUI code I've seen relies on
inheritance and dynamic dispatch to structure APIs.

I would love to see something like the Flutter Engine[1] written in Rust,
which is a layer tree that runs in an OpenGL context and includes text
rendering, shape drawing, gesture recognition, scroll layers, a layout engine,
etc. – all components necessary for modern mobile app development.

[1] [https://github.com/flutter/engine](https://github.com/flutter/engine)

~~~
pcwalton
> I would love to see something like the Flutter Engine[1] written in Rust,
> which is a layer tree that runs in an OpenGL context and includes text
> rendering, shape drawing, gesture recognition, scroll layers, a layout
> engine, etc. – all components necessary for modern mobile app development.

WebRender and Servo together contain all of these.

~~~
conradev
Right, but those components exist as bindings for HTML/CSS/JS. It would be
awesome to see a Rust UI framework built on top of them.

It's certainly no coincidence that the top contributors to the Flutter engine
are all Chromium contributors.

~~~
JasonSage
WebRender is not coupled in any way to HTML/CSS/JS as far as I know (I've used
it in an app).

Fundamentally, it allows you to represent a scene-graph and render it
efficiently. How you go about constructing and manipulating your scene graph
is up to the application which uses it.

In Servo's case it parses HTML and CSS for structure and style and allows
manipulations through JS through the DOM, but none of those are any concern
for webrender.

~~~
infogulch
I'd like to see rust bindings to the DOM. HTML and CSS are actually pretty
good for representing UIs, the bottleneck is JS. I think it'd be interesting
to build a desktop ui based on Servo.

~~~
JasonSage
I'd like to do this as well.

One of Servo's 2017 goals is to "Determine product opportunities for a
standalone Servo browser or embeddable library." I'm following this very
closely. I'd love to use a Rust equivalent of Electron in some projects.

I think Servo has much greater potential to be a viable high-end gaming
platform than Firefox[0] (sans Quantum). HTML/CSS/JS UI with WebRender and
some 3D rendering API which is not susceptible to bad GC pauses looks like the
holy grail of game programming to me.

[0]:
[https://wiki.mozilla.org/Platform/Games](https://wiki.mozilla.org/Platform/Games)

------
erichdongubler
Gist that I've been developing for quick setup guides (PRs welcome!):
[https://gist.github.com/ErichDonGubler/c802e066de7068241f0e6...](https://gist.github.com/ErichDonGubler/c802e066de7068241f0e6e492e6584ed)

We're still trying to get this to work with Windows. I've been reporting on
this issue here: [https://github.com/White-Oak/qml-
rust/issues/31](https://github.com/White-Oak/qml-rust/issues/31).

Any suggestions to get this going would be appreciated! Developing with
Rust/QML on Windows definitely seems possible at this point...that said, most
of what's left to be defined is what setup is required to actually get things
to work.

~~~
busterarm
It was a bit of a struggle, but I was able to get this going for Mac
w/Homebrew.

after `brew install qt5`, I had to `brew linkapps qt5` & `brew link --force
qt5`. Then `ln -s /usr/local/opt/qt5/mkspecs /usr/local/mkspecs && ln -s
/usr/local/opt/qt5/plugins /usr/local/plugins` which is super not ideal.

I had some error and ran `brew install doxygen --with-qt5` which may not be
necessary, but after these steps it built.

Edit: scratch that. As soon as I try the example in main.rs, it fails to build
again. 'ld: framework not found QtCore'

~~~
eridius
BTW, the qt5 formula explicitly says it's keg-only because it "has CMake
issues when linked".

~~~
busterarm
Noticed that. Found some discussions about a possible bug in cmake or qt5 that
were reported a month or two ago.

------
makmanalp
Part of me wonders how much better web programming could have been a decade
ago if QT was the standard that browsers implemented, and we just shipped
around QT frontends that ran sandboxed in the browser.

~~~
pcwalton
And instead of JS, we'd be stuck with C++. Not an improvement.

At least the frontend stack with the largest deployment—HTML, CSS, and JS—has
a garbage collector and is memory safe. With C#/VB.NET on Windows, Swift on
Mac/iOS, and Java on Android ascendant, this is now obviously the way to go.
Imagine if we had permanently made the mistake of saddling the Web with
manual, error-prone memory management.

~~~
makmanalp
Not true at all! Have you tried PyQT? It was in my experience an absolute
pleasure to use, and I think satisfies your main criteria. No reason why there
couldn't be similar bindings for any given language you prefer, though I
understand the merits of standardizing on one.

But also the point is that the Qt runtime would be part of the browser, which
is usually all C++ or Rust or whatever anyway - not the web programmer's
responsibility.

What makes me sad is that Qt for a very long time has had a very well thought
out ways of handling the complexities of UIs, including separating view from
layout from business logic, doing layouts properly, they even have a pretty
and lightweight DSL for defining UIs, which you can then style with a CSS-ish
language. And a non-terrible UI builder on top of that. It even does
responsive UIs these days! Granted, how well this would handle something as
complex as current webapps is an interesting question, but they've always kept
up with the changes, no problem.

Also they did proper threads and event loops, data storage and query APIs,
serialization, networking and sockets, highly performant 2D and 3D graphics
(GPU-accelerated stuff!), an embedded browser, and all this was (and is) all
cross-platform! It really was miraculous magic that we had this circa
2005-2007, and it's frustrating to see bits and pieces of this just recently
getting web standards. If in this day and age I see one more proposal for how
to do javascript promises or Commonjs / AMD / ES6 modules or something I'm
going to die of frustration and exhaustion. :-(

~~~
sevensor
I'm paid (in part) to develop a GUI application with PyQt. It's excellent.
Riverbank Computing deserves every penny. And QOpenGLWidget + PyQt is far and
away the easiest way to get off the ground with modern OpenGL.

------
c-smile
Just in case, Rust integration of Sciter is even easier:

    
    
       extern crate sciter;
    
       fn main() {
          let mut frame = sciter::Window::new();
          frame.load_file("minimal.htm");
          frame.run_app();
       }
    

Result:
[https://camo.githubusercontent.com/b7d9438384930801ba15d027d...](https://camo.githubusercontent.com/b7d9438384930801ba15d027d42ca23441924dae/687474703a2f2f692e696d6775722e636f6d2f6f6a634d354a4a2e706e67)

Rust/Sciter integration: [https://github.com/sciter-sdk/rust-
sciter](https://github.com/sciter-sdk/rust-sciter)

~~~
IshKebab
Yeah but I feel like HTML GUIs are the antithesis of Rust. Granted, it may be
the best option at the moment.

~~~
c-smile
Why is it an antithesis?

HTML UI at the end is just a set of few simple concepts (at least with
Sciter):

1\. UI is a composition of just two universal components: Element and Node
(text, comment, etc).

2\. UI is a single rooted tree of such blocks - DOM tree.

3\. The tree can be styled by well known CSS means.

4\. Events are delivered to particular UI elements using bubbling/sinking
event propagation schema.

5\. Any DOM Element may have so called behavior assigned to it. The behavior
is either native (C/C++/Rust/Go/etc) or script function. All <input> elements
are normal DOM elements with corresponding behaviors attached.

I do not see how this simple setup can be an antithesis to anything.

~~~
IshKebab
Because Rust is all about efficiency and doing things 'the right way'. HTML is
one massive hack at this point and one that wasn't even designed for making
desktop GUIs. It's also really slow compared to true GUIs. Remember Firefox
OS? Yeah.

------
shmerl
How does it compare to
[https://github.com/cyndis/qmlrs](https://github.com/cyndis/qmlrs) ?

~~~
lordnaikon
This project is "dead" for quite some time now. Don't know if they really
restructure the project (this was the last active conversation i witnessed in
the issues section
[https://github.com/cyndis/qmlrs/issues/28](https://github.com/cyndis/qmlrs/issues/28)
) or if its just abandoned now. currently i use this for playing around with
rust + qml [https://github.com/White-Oak/qml-rust](https://github.com/White-
Oak/qml-rust) this is the one used in the example, too

------
flukus
I'd prefer some real rust bindings instead of screwing around with qml.

------
david-cako
What is it about Rust that makes porting QT different from any other language?

~~~
mercurial
C++ is notoriously hard to bind. The only high-quality Qt bindings I know of
are Python ones (Pyside).

~~~
shmerl
How did PyQt manage to solve this problem?

~~~
sevensor
PyQt has a whole other project, called sip, in service to it. If I understand
it correctly, sip generates the bindings semi-automatically with a lot of
special cases for Qt. Compared to the other set of Python C++ library bindings
I've used (Vtk), they're magnificent.

~~~
mindv0rtex
Any tips you can give as far as starting to learn VTK, especially its Python
bindings?

~~~
sevensor
My experience is with maintaining somebody else's code, so I learned by
cutting myself on its sharp edges. My advice is to avoid if possible. Unlike
Qt, you can't subclass Vtk objects in Python. Which is a huge pain, because
the Vtk design is _heavily_ object-oriented. The autogenerated documentation
is pretty unhelpful. It looks like this:
[http://www.vtk.org/doc/nightly/html/classvtkSliderWidget.htm...](http://www.vtk.org/doc/nightly/html/classvtkSliderWidget.html).
Compare that with the magnificent Qt documentation:
[http://doc.qt.io/qt-5/qslider.html](http://doc.qt.io/qt-5/qslider.html), and
you'll see why I prefer working with Qt.

------
un008
I prefer go-qml [https://github.com/go-qml/qml](https://github.com/go-qml/qml)

or PyQt

