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.
> All GUI code I've seen relies on inheritance and dynamic dispatch to structure APIs.
Rust has dynamic dispatch, by using trait objects (https://doc.rust-lang.org/book/trait-objects.html). It also has something similar to interface inheritance ("trait Foo: Bar" means that everything that implements the trait Foo must also implement the trait Bar), and one can always do "C-style inheritance" (have the parent be the first field of the child) for structs.
Given that, I'd say building a large, complex GUI framework in Rust is possible. I also wonder how a GUI framework written for Rust (instead of Rust bindings to a framework for another language) would look like.
> 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.
It's not nearly as complex as that, but I can comment on a GUI program I've been developing for the last few months using the GTK bindings for rust [1]. I'm comparing rust today with C++/Qt as it was about 8 years ago, so bear that in mind in what follows. Before this project, the last big GUI I worked on was about 100k lines of C++, with a very intricate GUI involving both standard 2d components and quite a bit of animated OpenGL stuff. The program I'm working on now in rust is much smaller (about 20 different windows and dialogs, with various normal features along the lines of entry completion and search, and is about 5000 lines of code), but I think it's big enough that I have a feel for what it would be like to develop a big app in this environment.
After the initial bumps and scratches getting used to rust, I've found the experience to be better overall than I remember it being back in the day with C++ and Qt. I actually ended up implementing my own tiny version of signals and slots as I remembered them from Qt to handle interactions between the user and the stuff on the back end (mostly sqlite at this point). That in combination with a certain relaxed attitude about using Rc<RefCell<_>> for GUI stuff has put me in a place where I'm pretty confident that any normal GUI operation is pretty straightforward with rust.
The amount of boilerplate code seems pretty similar between the two. I think that a GUI framework specifically designed for rust might actually be a big win over other options here, but so far there isn't one that I know of that meets my needs. As it is, using the GTK components from rust is easier than using them from C (in my opinion), and comparable with my memory of using Qt in C++.
I've also found that the type system and the error handling are great compared to what I used before. They help not only in catching problems, but also in ensuring that the design is complete before I get too far into it. The code I'm writing now is much more reliable in terms of handling errors and covering corner cases than what I did back then in c++/qt. There is a price for this upfront in terms of aligning your mental model with what rust wants, especially if you're coming from the same background I was. Once that is done I don't think it's any more difficult to get stuff done here than it was there, and the results seem to be quite a bit more robust.
It wasn't all good times though - the initial unlearning/relearning curve was pretty rough for me. I've been programming professionally in various languages for about 15 years, and rust has taken longer for me to get comfortable with than any other language. That's including a wide variety of languages from various paradigms including constraint/logic programming (prolog and ciao), functional (lisp, ocaml, haskell, etc.), imperative (python,ruby,c/c++,javascript) and other more obscure ones. Something about the familiar features of algebraic data types, pattern matching, and type inference combined with the strict memory model caused a lot of mental interference that took me a long time to sort out.
The build system is actually one of the biggest reasons I stuck with rust through the pain of getting started. I really love cargo, to the point now that I can't stand the thought of going back to makefiles, cmake, or any other C++ build system I've tried. Cargo seems to just work, which means I spend less time fighting with obscure linker and compiler flags and more time getting things done. I'd put up with a lot from the language just to keep the build system, to be honest.
Overall developing a GUI app in rust has been a decent experience. If you're already comfortable with the language, I'd recommend spending the time to learn the GTK bindings. Once you internalize their basic operating scheme, the time required to get GUI stuff done with rust is comparable to other languages and toolkits, but you get the peculiar combination of benefits that come from using rust itself.
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.
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'
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.
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.
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 ) or if its just abandoned now. currently i use this for playing around with rust + qml https://github.com/White-Oak/qml-rust this is the one used in the example, too
conradev|9 years ago
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
cesarb|9 years ago
Rust has dynamic dispatch, by using trait objects (https://doc.rust-lang.org/book/trait-objects.html). It also has something similar to interface inheritance ("trait Foo: Bar" means that everything that implements the trait Foo must also implement the trait Bar), and one can always do "C-style inheritance" (have the parent be the first field of the child) for structs.
Given that, I'd say building a large, complex GUI framework in Rust is possible. I also wonder how a GUI framework written for Rust (instead of Rust bindings to a framework for another language) would look like.
pcwalton|9 years ago
WebRender and Servo together contain all of these.
wtetzner|9 years ago
discreteevent|9 years ago
aethertap|9 years ago
After the initial bumps and scratches getting used to rust, I've found the experience to be better overall than I remember it being back in the day with C++ and Qt. I actually ended up implementing my own tiny version of signals and slots as I remembered them from Qt to handle interactions between the user and the stuff on the back end (mostly sqlite at this point). That in combination with a certain relaxed attitude about using Rc<RefCell<_>> for GUI stuff has put me in a place where I'm pretty confident that any normal GUI operation is pretty straightforward with rust.
The amount of boilerplate code seems pretty similar between the two. I think that a GUI framework specifically designed for rust might actually be a big win over other options here, but so far there isn't one that I know of that meets my needs. As it is, using the GTK components from rust is easier than using them from C (in my opinion), and comparable with my memory of using Qt in C++.
I've also found that the type system and the error handling are great compared to what I used before. They help not only in catching problems, but also in ensuring that the design is complete before I get too far into it. The code I'm writing now is much more reliable in terms of handling errors and covering corner cases than what I did back then in c++/qt. There is a price for this upfront in terms of aligning your mental model with what rust wants, especially if you're coming from the same background I was. Once that is done I don't think it's any more difficult to get stuff done here than it was there, and the results seem to be quite a bit more robust.
It wasn't all good times though - the initial unlearning/relearning curve was pretty rough for me. I've been programming professionally in various languages for about 15 years, and rust has taken longer for me to get comfortable with than any other language. That's including a wide variety of languages from various paradigms including constraint/logic programming (prolog and ciao), functional (lisp, ocaml, haskell, etc.), imperative (python,ruby,c/c++,javascript) and other more obscure ones. Something about the familiar features of algebraic data types, pattern matching, and type inference combined with the strict memory model caused a lot of mental interference that took me a long time to sort out.
The build system is actually one of the biggest reasons I stuck with rust through the pain of getting started. I really love cargo, to the point now that I can't stand the thought of going back to makefiles, cmake, or any other C++ build system I've tried. Cargo seems to just work, which means I spend less time fighting with obscure linker and compiler flags and more time getting things done. I'd put up with a lot from the language just to keep the build system, to be honest.
Overall developing a GUI app in rust has been a decent experience. If you're already comfortable with the language, I'd recommend spending the time to learn the GTK bindings. Once you internalize their basic operating scheme, the time required to get GUI stuff done with rust is comparable to other languages and toolkits, but you get the peculiar combination of benefits that come from using rust itself.
1. http://gtk-rs.org
erichdongubler|9 years ago
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.
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|9 years ago
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'
makmanalp|9 years ago
pcwalton|9 years ago
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.
d215|9 years ago
david-cako|9 years ago
HTML + CSS + JS are just barely not shitty, but have such widespread adoption and libraries. Web apps are just so easy to package and maintain.
c-smile|9 years ago
Rust/Sciter integration: https://github.com/sciter-sdk/rust-sciter
IshKebab|9 years ago
shmerl|9 years ago
lordnaikon|9 years ago
flukus|9 years ago
david-cako|9 years ago
mercurial|9 years ago
un008|9 years ago
or PyQt