HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
woboq
qmetaobject-rs
Rust2019–2026
woboq / qmetaobject-rs

qmetaobject-rs

Integrate Qml and Rust by building the QMetaObject at compile time.

Explore on GitHubRead Hacker News discussions
6Distinct people
13Mentions
0Explicit recommenders
737GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Integrate Qml and Rust by building the QMetaObject at compile time.

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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 year13 dated mentions

Observed mentions: 2019-07-06 14:46:26 UTC to 2026-06-13 12:29:05 UTC.

01232019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

13 sources
aquariusDue·Jun 13, 2026
I'm a bit out of the loop but I checked out the GitHub repo [0] and while the authors moved onto Slint the crate is still actively maintained. That said I also looked at the latest commits and that threw me down a rabbit hole of finding out that the main maintainer has a blog where he wrote about using Sailfish OS as a daily driver [1] and imagine my surprise when he revealed that he actually co-maintains a Signal client app for SailfishOS too. I looked into the GitLab repo for that app [2] and I gleefully discovered that it's mostly written in Rust, the Cargo.toml contains a dependency to qmetaobject-rs too. All that is to say that I'm glad there's another way to get Rust on mobile aside from stuff like flutter_rust_bridge. [0] https://github.com/woboq/qmetaobject-rs [1] https://www.rubdos.be/2026/04/17/my-sailfish-os-journey-apps... [2]
Read the rest
https://gitlab.com/whisperfish/whisperfish
In The state of building user interfaces in Rust
ogoffart·May 27, 2025
I actually wrote Rust bindings for Qt a while back: https://github.com/woboq/qmetaobject-rs/. I'm curious to see how Qt's own take with Qt Bridges will work out. That said, I’ve since moved on and now work on Slint [https://github.com/slint-ui/slint] Slint was created with the same idea as what drives "Qt Bridges". We made a UI toolkit that is language-agnostic from the start. Slint uses its own UI language (inspired by QML), and gives you first-class, idiomatic APIs in Rust, C++, Pyhton, and JavaScript. And a clean separation between UI and business logic.
In Qt's New Bridging Technology – Looking Back to Move Forward
rubymamis·Jan 5, 2024
You can use Rust with QML[1]. QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you. I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[
Read the rest
4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer. [1] https://github.com/woboq/qmetaobject-rs [2] https://www.get-plume.com/ [3] https://www.appflowy.io/ [4] https://github.com/stdware/qwindowkit
In 9 years of Apple text editor solo dev
ogoffart·Mar 2, 2022
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
Read the rest
start aim to expose its API to several programming languages so bindings can be made idiomatic in almost every programming languages.
In CXX-Qt: Safe Rust bindings for Qt
ogoffart·Mar 2, 2022
Well, that's the thing. In my (biased) opinion, that crates doesn't have any of the problem mentioned. - The qmetaobject crate tries to be idiomatic rust and to be used without any C++ - As far as the user is concerned, there shouldn't be any call involving C++ - It does follow the Rust multi-threading guarantees - The License is the same as CXX-Qt - It does support plugins: https://github.com/woboq/qmetaobject-rs/tree/master/examples... - It uses code generation via macro
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
ogoffart·Apr 19, 2020
I'm using this to write Qt bindings: https://github.com/woboq/qmetaobject-rs/ > Is it just about convenience so you don't need to bother with putting your C++ code in a different file? Yes, mostly. I find that having the code in place makes a big difference. I do not like useless levels of indirection and context switches while coding. This way is much better then having to edit three files (the .cpp, the ffi module, and the caller) each time I want to do a call into C++ while making sure they are in sync.
In Writing Python inside Rust

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.