21–30 of 55 posts
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.
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…
> 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 certainly no coincidence that the top contributors to the Flutter engine are all Chromium contributors.
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…
There's Conrod: https://github.com/PistonDevelopers/conrod
also, the fact that it is one letter away from my name was confusing at first :P
Earlier quoted context omitted.
What about PyQt5? Or does it work differently?
PyQt5 does not seem to be maintained. The last couple of times I checked it, it was pretty dead: one maintainer with no time.
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.
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. :-(
extern crate sciter;
fn main() {
let mut frame = sciter::Window::new();
frame.load_file("minimal.htm");
frame.run_app();
}
Rust/Sciter integration: https://github.com/sciter-sdk/rust-sciter
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.
You mean something like Douglas Crockford's seif https://news.ycombinator.com/item?id=11273630 project?
Gist that I've been developing for quick setup guides (PRs welcome!): https://gist.github.com/ErichDonGubler/c802e066de7068241f0e6... 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…
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'
Earlier quoted context omitted.
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.
Theres some truth around it. While QML may be nice I found the total experience of the QT stack lacking. It's still required to do large parts of the application in C++, since QML is mainly the View part. The impedance mismatch between the c++ and QML parts is huge compared to an environment that only uses a single language. I was part of some embedded system projects that used Actionscript (Adobe AIR) for some forme…
I see a clear benefit in separating the language for the UI from the application logic language. Having choice of the second is good. Otherwise you are limited a monolithic structure, and need to reinvent the way to define UI in each language.
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…