Hello everyone,
It has been a few days since we reached the first milestone of the Qt
Bridges projects (not a full-blown release!), so I wanted to share more
information about it, since the repository requests email took many
people by surprise on what was this about.
If you already know about the project and are interested, I’d like to
encourage you to visit the information that we shared in the Qt Forum,
so you can try it out!
https://forum.qt.io/topic/164138/about-the-early-code-access-in-qt-bridges
The next steps are a Beta Milestone (planned for late March), and the
Technical Preview for the end of May, but most likely we will keep you
posted with the latest updates.
Below, there is more information that can be useful if you are curious
about this new project we are developing within The Qt Company.
# What is Qt Bridges?
This project has been a research project by The Qt Company, that was
publicly announced during Qt World Summit 2025. The objective is to
bring more languages to the Qt ecosystem, by providing not a set of
bindings to the Qt API but re-thinking the interaction between Qt Quick
and other languages.
The whole idea is built on top of creating Qt Quick applications with a
QML file defining the user interface details, and the logic implemented
in other languages. The model is simple:
* QML is used to define the UI
* Host language implements the application logic (So far Java/Kotlin,
C#, Python, Swift and Rust)
* Qt Bridges provide a small, idiomatic, language-native API to describe
what data should be exposed to QML and signals interactions in a way
that looks native to both sides.
We have learned by other binding projects like Qt for Python that
maintaining bindings to other languages is a very complicated task, and
creates a few cases when one needs to do interpretation of C++ idioms,
types, and ideas that might not be straightforward to represent in other
languages (the usual example I give is ‘What is a void* in Python?’).
Another motivation is to hide that from users, by providing a new API
that can do all that handling internally as much as we can.
# Who is the target audience of the project?
Considering the goal is to bring this to new developers outside our
Qt/C++ community, the target audience of Qt Bridges are developers who
have no Qt knowledge at all but are looking for a UI framework solution.
It’s expected that seasoned Qt developers will fall into the trap of
trying to achieve the same they have been doing for a long time with
Qt/C++ in Qt Bridges, but the most likely outcome is that it will not be
possible. However, we invite you to share your ideas with us so the
use-cases can be considered once we are evaluating new API.
# Why is this project aimed at being inside the Qt Project?
We believe this project will be a good way to introduce new developers
to the Qt Project, and in some cases, they will get more familiarized
with what we have and maybe explore the Qt/C++ offering we have, or at
least being aware of so we could enable Qt Bridges to include further
functionality.
Another important aspect is the introduction of new languages to the Qt
Ecosystem, by establishing a way of continuing to expand them, following
similar integration patterns.
# Is this aimed to be a new module for Qt?
No, this is not aimed at being an official submodule for the current
qt5.git repository, but its own project. The releases are not planned to
follow the Qt release schedule, nor interfere with the Qt releases.
# What’s the license for this project?
Even though Qt Bridges is not a Qt sub module, we wanted to still follow
a similar license scheme, so we are planning to release Qt Bridges under
LGPLv3 and Qt commercial licenses.
One of our objectives is that this can become part of the KDE Free Qt
Agreement as well, to secure the Open-Source aspect of the project.
# Why does each language bridge need a separate repository?
So far, the project has been developed internally, on a mono repo, which
has shown not to be the right solution, because in some languages, the
root of the repository needs to contain certain files and configuration.
For example, Swift requires a ‘Package.swift’ file; Python needs a
‘pyproject.toml’ file. For C#, work was already underway, based on a
separate qt-labs repository, and with a broader scope than the current
approach of Qt Bridges, such as allowing C++ code to call into existing
.NET libraries.
We aren’t ruling out adding more languages in the future, so having a
separate one is the best solution we found after some internal discussions.
We are using a meta repository qt/qtbridges to bring all the language
submodules together for people that wants to develop accessing different
languages bridges, and for the common project’s documentation (currently
a snapshot can be found here:
https://doc-snapshots.qt.io/qtbridges-dev/index.html ).
# How is this being released?
Since the goal is to approach different languages communities, our goal
is to prepare packages/plugins and release them on their specific
platforms (crates.io for Rust, Maven Central for Java, NuGet for C#, etc.).
Additionally, since we are aware the Qt users might still want to give
this a try, we are settling the details for people to also download the
project with mainstream Qt Installation process (from the
Installer/Maintenance tool).
--
We really believe this is the right direction for extending our
ecosystem and transforming Qt into an amazing language agnostic framework.
Cheers
--
Dr. Cristian Maureira-Fredes
Principal R&D Manager
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
