I was really hoping we'd have bindings to Qt by now, but looking at the GUI category on crates.io I didn't find any. What do people use to make cross platform GUIs in Rust?
There are some glaring issues w/ the Rust Qt crates, namely subclassing things like QWidget. But it is high priority [0]. This is essential for using Qt as many things are not "signals" but instead overridable protected methods. I started a embedded browser PoC [1] until I hit these limitations which forced me to use C++ [2].
And many other static langs (i.e. not-python) have issues with their Qt bindings (e.g. Go [3] which can't compile via MSVC which some things like the QtWebEngine stuff need). Sadly, for advanced UI (e.g. complex tree views, docking, etc) that is cross platform and looks native, Qt is all there is, and it's reliance on C++ makes it a bit tough to use across languages. A maintained C iface for Qt is really needed.
GTK is the best option at the moment. Apparently QT is difficult due to it being heavily based in C++'s view of the world, which doesn't translate particularly well to Rust (notably Rust not supporting OOP in the same way). There is hope of a new rust-native GUI library (possibly in the vain of Flutter[1]) based on the work done for Servo[2], but that looks to be a way off.
AFAICT, QT has its own implementation of signals and slots (events and event handlers essentially) which is a pain for Rust's ownership model and it also has a code generator that deals with some of C++'s limitations, making it harder to generate usable bindings. If that weren't enough, there is no native (clean) Rust way to do C++ inheritance which is another big pain.
I like GTK, but it's place is in gnome (which I also like) and no where else, on any other system it looks horrible and out of place, particularly when it comes to things like the file dialog.
Also the devs no longer consider it a cross platform library, everyone using it as one is stuck on GTK2.
(Not OP) Most gtk applications are very difficult for me to use, for a combination of reasons. I have joint problems that mean I rely on mouse and touch for working with text more than most people. The biggest obstacles are:
1. Gtk constantly clobbers the middle-click clipboard on Linux. In non-gtk programs that's one of my most efficient ways of entering and editing text.
2. Gtk completion dropdowns steal clicks, so typing into a field with completions (that I don't want) with an onscreen keyboard takes at least twice as many button presses as it should.
I have no such problems with Qt (or anything else).
Not-Gnome was never a priority for the developers, conversely, it doesn't work very well on Not-Gnome. That alone disqualifies it for me. Besides that, the docs are simply bad and glib is such a huge mess that I actively avoid touching anything near it with a ten foot pole.
@dom0 @flukus of course, thanks. Didn't think of that as I am a satisfied GNOME user (for the continued focus on UX refinement, simplicity, stability) and was even forgetting people might consider it for non-GNOME.
PyQt and PySide was exactly what I had in mind. It'll leak memory, segfault on load 1% of the time, segfault if you call unrelated methods in the wrong order, you'll randomly get QStrings and QExceptions instead of their Python equivalents, and it'll be impossible to debug.
Is seems that Racer is still missing support for auto-complete on basic code snippets:
let x = vec![1]
x.<no completion>
Even if they special cased vec! or all the std macros, it'd be a good on-ramp improvement. But I thought RLS was supposed to step in where Racer can't handle things - is that not the case for macro support?
The linked article mentions that RLS completes via Racer, which is inline with what I understood before: Racer's a lot faster for this use-case, so RLS delegates to it.
Yes, my confusion is that in your OP, you were talking a bunch about racer, but then switched to the RLS.
Right now, it's exactly what you said. RLS is still an extremely active project, and so are the compiler internals it relies on, so it's going to gain features in the future. I'm not aware of any specific plans to exclude macros, but it's not my area of specialty.
> Is seems that Racer is still missing support for auto-complete on basic code snippets
Interesting; I view that as a bit more than a "basic" snippet for autocompletion to handle, although that's mostly a few facto interpretation because it's one of the few things that no Rust autocompletion engine I've tried (racer, RLS, or Intellij's plugin) has been able to handle. For pretty much everything else I've tried, at least one of them has been able it.
One of the things that I'd like to see for the Rust Book is some form of "Here's how to use it in a function".
For example, Taking a random piece of code from the Rust Book
let buffer: &mut [i32];
let coefficients: [i64; 12];
let qlp_shift: i16;
for i in 12..buffer.len() {
let prediction = coefficients.iter()
.zip(&buffer[i - 12..i])
.map(|(&c, &s)| c * s as i64)
.sum::<i64>() >> qlp_shift;
let delta = buffer[i];
buffer[i] = prediction as i32 + delta;
}
How would one break part of this into a function
fn get_part ??? What might go here ???
let buffer: &mut [i32];
let coefficients: [i64; 12];
let qlp_shift: i16;
for i in 12..buffer.len() {
let prediction = get_part(&coefficients,&buffer,i)
.map(|(&c, &s)| c * s as i64)
.sum::<i64>() >> qlp_shift;
let delta = buffer[i];
buffer[i] = prediction as i32 + delta;
}
[Exercise for the reader] I'm not sure If I could write the code to do this without taking a few wrong turns.
Well, this code in particular is presented as "hey there's no context." If I were to try to extract this, I would take each of those lets and make them an argument, then see what the compiler says for the return type, done.
How do you find out what the compiler says for the return type? Is that covered in the book somewhere? I feel like this might help me quite a bit in my struggles.
Iterators are the main place this is difficult, but as steveklabnik says the compiler can tell you the return type.
However, this will get better with the introduction of "impl Trait", where the return type will become `impl Iterator<Item = (i64, &[i32])>` which while admittedly long is better than what you'd have otherwise. It's definitely a known pain point.
In practice writing Rust code (full time!) I don't encounter this issue much because I rarely want to split an iterator chain across multiple functions, and iterators are the main place the types get long and hairy. Although I've heard it's really bad with Futures, but that's why "impl Trait" is coming.
It's available online: https://doc.rust-lang.org/book/second-edition/ , a publisher that didn't believe in digital sharing that also agreed to publish it would be a little... surprising.
You're welcome; this was important to me. In addition, No Starch's commitment to letting the book be generally freely available on doc.rust-lang.org was mandatory, and they are awesome enough to be supportive of that :)
61 comments
[ 3.4 ms ] story [ 127 ms ] threadBut it looks stalled. Not sure if anyone is working on such bindings today.
UPDATE: I just found this which looks active: https://github.com/rust-qt/cpp_to_rust
And many other static langs (i.e. not-python) have issues with their Qt bindings (e.g. Go [3] which can't compile via MSVC which some things like the QtWebEngine stuff need). Sadly, for advanced UI (e.g. complex tree views, docking, etc) that is cross platform and looks native, Qt is all there is, and it's reliance on C++ makes it a bit tough to use across languages. A maintained C iface for Qt is really needed.
0 - https://github.com/rust-qt/cpp_to_rust/issues/53
1 - https://github.com/cretz/rust-qt_cef_poc
2 - https://github.com/cretz/qt_cef_poc
3 - https://github.com/therecipe/qt/
[0] https://www.reddit.com/r/rust/comments/6l5c94/can_we_crowdfu... [1] https://flutter.io/ [2] https://github.com/servo/webrender
If you are okay to use qt out of the box, there are a few bindings. But you won't be able to customise it like you would with actual qt.
Also the devs no longer consider it a cross platform library, everyone using it as one is stuck on GTK2.
There's support for Windows native file dialogs since 3.20.
https://blogs.gnome.org/alexl/2015/11/05/native-file-chooser...
1. Gtk constantly clobbers the middle-click clipboard on Linux. In non-gtk programs that's one of my most efficient ways of entering and editing text.
2. Gtk completion dropdowns steal clicks, so typing into a field with completions (that I don't want) with an onscreen keyboard takes at least twice as many button presses as it should.
I have no such problems with Qt (or anything else).
[1] https://users.rust-lang.org/t/current-state-of-gui-developme...
They use it for systems software and backend services.
[0]: https://internals.rust-lang.org/t/crates-io-package-policies...
https://twitter.com/jdalton/status/869964222716821504
(continued) https://twitter.com/littlecalculist/status/87035656004781670...
and there's "pythonium trioxide", but I've gotten the impression that its more of an exploratory project: https://github.com/PyO3/PyO3
The extension-module feature might give you what you want
Right now, it's exactly what you said. RLS is still an extremely active project, and so are the compiler internals it relies on, so it's going to gain features in the future. I'm not aware of any specific plans to exclude macros, but it's not my area of specialty.
Interesting; I view that as a bit more than a "basic" snippet for autocompletion to handle, although that's mostly a few facto interpretation because it's one of the few things that no Rust autocompletion engine I've tried (racer, RLS, or Intellij's plugin) has been able to handle. For pretty much everything else I've tried, at least one of them has been able it.
For example, Taking a random piece of code from the Rust Book
How would one break part of this into a function [Exercise for the reader] I'm not sure If I could write the code to do this without taking a few wrong turns.Another way is to use some sort of IDE integration that gives you "show me the type on hover".
That is how I check such types outside IDEs in other ML derived languages.
However, this will get better with the introduction of "impl Trait", where the return type will become `impl Iterator<Item = (i64, &[i32])>` which while admittedly long is better than what you'd have otherwise. It's definitely a known pain point.
In practice writing Rust code (full time!) I don't encounter this issue much because I rarely want to split an iterator chain across multiple functions, and iterators are the main place the types get long and hairy. Although I've heard it's really bad with Futures, but that's why "impl Trait" is coming.
Thanks for choosing a publisher that supplies DRM-free eBooks ;)
http://bukk.it/clap.gif