rust-qt

ritual

Rust2017–2022

rust-qt / ritual

ritual

Use C++ libraries from Rust

Mobile & Desktop Libraries & SDKs

Explore on GitHub Read Hacker News discussions

6Distinct people

7Mentions

0Explicit recommenders

1.3KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Use C++ libraries from Rust

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2017-03-07 20:20:09 UTC to 2022-03-02 17:17:53 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	1	2
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	0	1

What Hacker News says

7 sources

csnover·Mar 2, 2022

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 lon

Read the rest

ger and harder task.) [0] https://lib.rs/keywords/qt [1] https://github.com/rust-qt/ritual

In CXX-Qt: Safe Rust bindings for Qt

csnover·Oct 8, 2020

Rust doesn’t support object inheritance (only traits). It also doesn’t have function overloads or default arguments. Qt relies heavily on all of these C++ features; inheritance is fundamental to how Qt works (for example, it is impossible to respond to mouse/keyboard events without subclassing to override virtual methods), and function overloads with default arguments are used everywhere. As a result, it’s a struggle to shoehorn this object model into Rust. rust-qt[0] doesn’t support inheritance at all, so you can only connect to things in Qt which accept callbacks using slots. It requires `'static` lifetime on those callbacks, so as far as I can tell you are also forced to use `Rc`s whenever you are doing something with a rust-qt object even if you should be able to use a plain reference. The code is auto-generated, so all APIs are `unsa

Read the rest

fe`, and no function overloads means names are gross because the function signatures must be expressed in the function name (e.g. the `QMessageBox` constructor[1] becomes `QMessageBox::from_icon2_q_string_q_flags_standard_button_q_widget`). This could be improved by using `Option`s for arguments with defaults, but right now this is what it looks like. qmetaobject-rs[2] has some support for inheritance but as far as I can tell it’s limited to a couple of base types only. It’s also designed around using QML, so it doesn’t actually expose most of the Qt API. As such I don’t have too much experience with it. I’m unaware of any other usable Rust Qt bindings right now. I currently make things work by using rust-cpp[3] to create C++ subclasses and smuggle events, but this sucks because it also means the objects on the Rust side need to have the Qt API re-exposed manually since AFAIK there isn’t a way to have Rust handle that without using a code generator. (There might be some hackier ways to make this work, or maybe someone with more Rust experience than me knows of something smarter that could happen, but in any case the ergonomics right now are not good for the average developer.) [0] https://github.com/rust-qt/ritual [1] https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1 [2] https://github.com/woboq/qmetaobject-rs [3] https://github.com/mystor/rust-cpp

In Rust 1.47

aazaa·Jan 22, 2020Submission

Ritual: Use C++ Libraries from Rust

1 points · Open discussion

jclay·Apr 23, 2019

The issue with bindings is that you either commit to maintaining them yourself, or you rely on someone else. In this case, the Rust Qt bindings I found [0] were generated for Qt 5.8, which was released nearly 3 years ago. The tests on Github report "failing". Then, you have the cognitive overhead of translating the documentation, and other sample code. In my experience with bindings, this ends up requiring knowledge of the language you're binding to. It seems easier to just write it in the native language instead and deal with those quirks rather than bindings quirks. Do the Rust bindings show the Qt docs in the autocomplete? If there's not input validation on the binding side, then you'll end up in C++ again figuring out how to sort things out. Regarding CUDA, I think we're all hoping for a cross GPU alternative. There's OpenCL, Sycl, RO

Read the rest

Cm, Kokkos but their API is also written in (you guessed it) C++. Need to render to OpenGL? You'll be writing in C. Unless one of the companies decides to replace driver interfaces with Rust, any application using them will be dependent on N bindings working. You're ultimately not escaping C/C++ for any systems development. You either deal with the complexity of interfacing between language A and C/C++ or just deal with the quirks of C/C++ themselves. Pick your poison. 0. https://github.com/rust-qt/ritual

In Modern C++ Won't Save Us

kodablah·Jul 5, 2017

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. 0 - https://github.com/rust-qt/cpp_to_rust/issues/53 1 - https://github.com/cretz/rust-qt_cef_poc 2 - http

Read the rest

s://github.com/cretz/qt_cef_poc 3 - https://github.com/therecipe/qt/

In Rust's 2017 roadmap, six months in

shmerl·Jul 5, 2017

The last time I checked there was this: https://github.com/White-Oak/qml-rust But 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

In Rust's 2017 roadmap, six months in

thegeomaster·Mar 7, 2017Submission

Cpp_to_rust: automatically create Rust crates that provide API to C++ libraries

3 points · Open discussion