Hacker News Reader

Comment by csnover | Hacker News Reader

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

[1] https://github.com/rust-qt/ritual

View on HN

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/

But now I've moved on to another GUI project: 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.

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

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/

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.

Qt is already idiomatic C++17. Isn't it?

You're joking right?

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.

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.

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

Integration is for instance not having to use QString(View) is the first place, like one doesnt with many of the bindings, including Qts own Python binding.

If you can show me a codebase that you think is modern C++ and uses Qt, it would be much appreaciated. I keep running into walls and havng to go back to coding like it's 98 basically, but hey, love to be shown it's me.

> Integration is for instance not having to use QString(View) is the first place, like one doesnt with many of the bindings, including Qts own Python binding.

that's because Python has unicode strings. C++ doesn't have a single, canonical unicode string type.

QString and QStringView are fundamentally different data types than std::string and std::string_view which aren't unicode ; the std::string and std::string_view Qt equivalents are QByteArray and QByteArrayView.

Plenty of people that actually pay for Qt, use it in environments where beautiful C++17 CppCon like examples are not welcomed, or even possible.

Naturally they care most about the people that support their families.

Anyone that dislikes this is free to provide pull requests.

I think they accept pull requests.

Reply on news.ycombinator.com