5 ms·

It is great to see how many people want to bring Qt support to Rust and are trying to do so, and I hope that these folks succeed, but it’s wearisome to me how e

It is great to see how many people want to bring Qt support to Rust and are trying to do so, and I hope that these folks succeed, but it’s wearisome to me how each person/group creates a new project instead of working with others who are already in this problem space. Of the half-dozen or so[0] existing attempts so far to create Qt bindings to Rust, none of them have actually succeeded, either because they tried to start from scratch again and then abandoned the attempt midway, or because they are limited to QML. Ritual[1] is the only crate I’ve seen that attempts to actually expose the whole Qt API, but it’s pretty awful to use, incomplete, and dead. Rust doesn’t need more Qt crates. It needs one Qt crate that is complete and works well. (Or, ideally, a native Rust cross-platform GUI crate that works as well as Qt, but that’s an even longer and harder task.) [0] https://lib.rs/keywords/qt https://lib.rs/keywords/qt [1] https://github.com/rust-qt/ritual https://github.com/rust-qt/ritual

mockery 5y ago
It's totally reasonable to lament duplicated effort, but it's worth pointing out that this particular attempt is from a company[0] whose business is Qt consulting - so it's easy to imagine that they might succeed (due to expertise, size, and motivation) where others have not. The post also explains why they started from scratch vs. existing approaches - I'm not qualified to evaluate the claims, but I think they deserve some credit for explicitly talking through their reasons. [0] https://www.kdab.com/ https://www.kdab.com/
ogoffart 5y ago
The thing is that Qt is a C++ toolkit written in C++ and meant to be used from C++ with its C++ API. Especially if we want to use QtWidgets, the API surface is huge. There are a bunch of bindings with different language, but even the ones that are officially supported like PySide will still be second class citizen and awkward to use. Automated binding generation will never give you idiomatic API in whatever language. And if you want an idiomatic library that wraps Qt, it's going to take a huge amount of work. Which is why I think restricting to QML makes sense because that's a much smaller API surface. That was the ambition behind my previous crate that exposes QML to rust: https://github.com/woboq/qmetaobject-rs/ https://github.com/woboq/qmetaobject-rs/ But now I've moved on to another GUI project: Slint https://github.com/slint-ui/slint https://github.com/slint-ui/slint It is implemented in Rust, but from the start aim to expose its API to several programming languages so bindings can be made idiomatic in almost every programming languages.
- longstation 5y ago
  In case anyone is interested, Slint used to be called SixtyFPS. It's created by a few ex-QT employees.
brnt 5y ago
Quite frankly, I'd love to have some idiomatic C++14/17/20 bindings for Qt. The official Qt for Python binding fits in very well with the language and style I think, but when using it in C++, I have to mix wildly different styles and me no likely.
- pjmlp 5y ago
  I think they accept pull requests.
- isomel 5y ago
  Qt is already idiomatic C++17. Isn't it?
  - brnt 5y ago
    You're joking right?
    - runnerup 5y ago
      No, they’re ignorant. And the rest of us could use a clue too — I only use Qt with python and would love context on this.
      - brnt 5y ago
        Idiomatic C++98 and idiomatic C++17 might as well be two different languages. Using Qt, you'll feel forced to unlearn much of the recent good stuff and code like it's 98-ish. The fact that Qt comes with many of it's own standard types (QString!) without automatic conversion (unlike Qt for Python) makes it verbose and integrates badly with STL types. Then there are still some macros you need to use (e.g. for Connections). In Python they did an excellent job with all of that.
        jcelerier 5y ago
        What more integration do you need ? Qt types are able to use move semantics, are compatible with standard algorithms, support function objects and thus lambdas for callbacks, standard atomics, there's QStringView to match std::string_view use cases... What else ? Hell, it's trivial to make Qt work with c++20 coroutines ; Qt itself requires C++17 compilers since Qt 6

mockery 5y ago

It's totally reasonable to lament duplicated effort, but it's worth pointing out that this particular attempt is from a company[0] whose business is Qt consulting - so it's easy to imagine that they might succeed (due to expertise, size, and motivation) where others have not. The post also explains why they started from scratch vs. existing approaches - I'm not qualified to evaluate the claims, but I think they deserve some credit for explicitly talking through their reasons. [0] https://www.kdab.com/ https://www.kdab.com/

ogoffart 5y ago

The thing is that Qt is a C++ toolkit written in C++ and meant to be used from C++ with its C++ API. Especially if we want to use QtWidgets, the API surface is huge. There are a bunch of bindings with different language, but even the ones that are officially supported like PySide will still be second class citizen and awkward to use. Automated binding generation will never give you idiomatic API in whatever language. And if you want an idiomatic library that wraps Qt, it's going to take a huge amount of work. Which is why I think restricting to QML makes sense because that's a much smaller API surface. That was the ambition behind my previous crate that exposes QML to rust: https://github.com/woboq/qmetaobject-rs/ https://github.com/woboq/qmetaobject-rs/ But now I've moved on to another GUI project: Slint https://github.com/slint-ui/slint https://github.com/slint-ui/slint It is implemented in Rust, but from the start aim to expose its API to several programming languages so bindings can be made idiomatic in almost every programming languages.

longstation 5y ago
In case anyone is interested, Slint used to be called SixtyFPS. It's created by a few ex-QT employees.

brnt 5y ago

Quite frankly, I'd love to have some idiomatic C++14/17/20 bindings for Qt. The official Qt for Python binding fits in very well with the language and style I think, but when using it in C++, I have to mix wildly different styles and me no likely.

pjmlp 5y ago
I think they accept pull requests.
isomel 5y ago
Qt is already idiomatic C++17. Isn't it?
- brnt 5y ago
  You're joking right?
  - runnerup 5y ago
    No, they’re ignorant. And the rest of us could use a clue too — I only use Qt with python and would love context on this.
    - brnt 5y ago
      Idiomatic C++98 and idiomatic C++17 might as well be two different languages. Using Qt, you'll feel forced to unlearn much of the recent good stuff and code like it's 98-ish. The fact that Qt comes with many of it's own standard types (QString!) without automatic conversion (unlike Qt for Python) makes it verbose and integrates badly with STL types. Then there are still some macros you need to use (e.g. for Connections). In Python they did an excellent job with all of that.
      - jcelerier 5y ago
        What more integration do you need ? Qt types are able to use move semantics, are compatible with standard algorithms, support function objects and thus lambdas for callbacks, standard atomics, there's QStringView to match std::string_view use cases... What else ? Hell, it's trivial to make Qt work with c++20 coroutines ; Qt itself requires C++17 compilers since Qt 6