qtdeclarative

C++2021–2025

qt / qtdeclarative

qtdeclarative

Qt Declarative (Quick 2)

Mobile & Desktop

Explore on GitHub Read Hacker News discussions

7Distinct people

8Mentions

0Explicit recommenders

299GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Qt Declarative (Quick 2)

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:03:16 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 year8 dated mentions

Observed mentions: 2021-09-22 21:27:03 UTC to 2025-12-29 15:11:12 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	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	2
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2

What Hacker News says

8 sources

rubymamis·Dec 29, 2025

QML isn't slower than Qt QWidgets, in the end of the day Qt Quick components are simply C++ objects, you can look at the source code[1]. [1] https://github.com/qt/qtdeclarative

In Developing a Beautiful and Performant Block Editor in Qt C++ and QML

rubymamis·Nov 25, 2025

Qt Quick components are just C++ classes[1]. [1] https://github.com/qt/qtdeclarative

In Build desktop applications using Go and Web Technologies

dagmx·Jun 17, 2024

UI libraries are a poor reason to pick Rust over Swift, given that Rust has a very poor UI story. Doesn’t your comment apply very equally to Rust? There’s basically Slint and Tauri, and several bindings in various states of disarray. Not exactly very compelling. The Rust ecosystem has very many strengths, but UI is not one of them. Regardless, you’re incorrect about there being no way to make GUI applications Here’s a Gnome binding https://swift.org/blog/adwaita-swift/ The C++ interop allows easy binding to Qt https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he... Win32 https://github.com/compnerd/swift-win32 The fact that Swift has easier C++ interop than Rust makes the cross platform UI story much easier and more compelling than what I’ve found in Rust. Bindings are much simpler to manage and can be handled by a single module m

Read the rest

ap file with a single line in it most of the time. Adding to that, many well established UI libraries depend on classes to implement them. Rusts lack of classes, while wonderful otherwise, makes binding to heavy class based libraries very onerous. Don’t get me wrong, I really enjoy rust. It’s just, it’s very ill suited for UI work today itself. I almost always write my UI side in C++ if I have to and bind over when needed instead.

In Packaging Swift Apps for Alpine Linux

jclay·Jun 12, 2024

There’s a very minimal example using C++ interop in Qt’s test suite: https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he... I’ve kicked around with the C++ interop a few times. Projects like Qt that use raw pointers extensively seem hard to expose. Ended up having to wrap Qt classes to model as a value type which was straight forward but it’s not nearly as seamless as the Objective-C++ experience

In Swift Static Linux SDK

eliaspro·Sep 13, 2022

We're currently dealing with crashes across all Qt applications using QML on NixOS [1], since Qt utilizes the binary's mtime to invalidate the cache of embedded QML resources. Since all builds have an mtime of 0 as timestamps are the biggest source of reproducibility issues [2], QML loads outdated cache objects which will then load invalid bytecode at runtime and therefore causing a crash. Our initial plan was to utilize a hash of the binary [3] which should be IMHO the most straightforward, unlikely to break and future-proof way to solve the problem. The currently suggested implementation's performance could most likely be improved by generating the hash once on startup instead of every time when a QML resource is loaded, but I believe since it's already cached in memory, hashing is not that expensive, binary sizes are usually relatively

Read the rest

small and resource loading (of embedded ones) doesn't happen that often, it should be already reasonably fast (real performance test haven't been done yet). The big challenge will be upstreaming it, once we've proven it to properly work. The current approach has been apparently rejected [4] and was declared to be a downstream issue, which I personally don't agree with, since sooner or later reproducible builds will become the norm and therefore will affect everyone. Current ideas to work around it require individual solutions per distribution/ISV, as this would mean they'd have to come up with domain specific criteria for cache invalidation (as the store path/derivation hash on NixOS) and to maintain a downstream patch for this solution and furthermore wouldn't work for local build processes (e.g. from within an IDE). Lesson of the day: never use mtimes, they'll bite you in the ass sooner or later! [1] https://github.com/NixOS/nixpkgs/issues/177720 [2] https://reproducible-builds.org/docs/timestamps/ [3] https://github.com/qt/qtdeclarative/commit/5106afcd76e377a6b... [4] https://github.com/NixOS/nixpkgs/issues/177720#issuecomment-...

In Mtime comparison considered harmful (2018)

nyanpasu64·Feb 17, 2022

I found a qmlcompiler folder at https://github.com/qt/qtdeclarative/tree/dev/src/qmlcompiler, but I don't know if it's the compiler itself or bindings. I can't find qmlsc in GitHub qt or qtproject though.

In A new wave of Linux applications

jcelerier·Sep 23, 2021

> I've already said elsewhere that having read their licensing terms and limits on what parts and how it can be used I would not touch QT with the wooden pole. the OSS licensing terms are the LGPL or GPL. - https://github.com/qt/qtbase/blob/dev/LICENSE.GPL3 - https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3 - https://github.com/qt/qtdeclarative/blob/dev/LICENSE.GPL3 - https://github.com/qt/qtdeclarative/blob/dev/LICENSE.LGPLv3 they can add whatever separate licensing scheme they want in addition to that but if a repo has LICENSE.LGPLv3 in it, you can use it under LGPL like every other OSS project (and those two repos cover by far most of Qt, you can pretty much build an entire OS userspace out of them).

In Delphi 11 Alexandria

eatonphil·Sep 22, 2021

Ok sweet I see now. They used JavaScriptCore until 2011 or so, switched to V8 until 2013, and have been using their own implementation, q4, since then. The source code seems to be here: https://github.com/qt/qtdeclarative/tree/dev/src/qml/jsrunti.... Thanks! Will add and be live shortly.

In Enumerating and analyzing 40 non-V8 JavaScript implementations