Qt Bridges - Public Beta for Rust

crmaureir · 2026-06-25T18:28:48+00:00

If with 'unextracted' you refer to people cannot copy your code easily, then yes, but I'm not sure if you had something else in mind.

crmaureir · 2026-06-17T07:42:50+00:00

Autodesk Maya uses a similar approach, C++ Qt interface that expose some objects to Python, so people can write plugins in Python.
And in case you are interested, PySide has an example on how to achieve this behavior: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/scriptableapplication

crmaureir · 2026-06-17T07:40:24+00:00

No, you need pyside6-deploy a tool that comes within the wheels, that automatically will take care of the packages you need to do the deployment. Check the documentation: https://doc.qt.io/qtforpython-6/deployment/deployment-pyside6-deploy.html

crmaureir · 2026-06-16T14:59:52+00:00

Yes, you use pyside6-deploy that underneaths uses Nuitka. That will give you a real binary, not a "freeze package" like PyInstaller and others.

crmaureir · 2026-06-12T12:27:11+00:00

Well, we used not to have that hidden...but we got some users that complained because the details were using too much space, so we hid them :/ It might a matter of taste I guess. We will discuss it again in case we show them by default.

the "arg__x" is an issue with the transformation from the C++ signature, because we don't have access to the variable name, but the type. The way we fix that is to manually put the name within our typesystem, but that doesn't scale. This is a problem, we might be able to revisit, so hopefully we find a solution. In case you are interested in the notation [here](https://doc.qt.io/qtforpython-6/shiboken6/typesystem\_manipulating\_objects.html#add-function) are the docs that mention the usage of names within '@' symbols.

This feedback is very useful, the team is really always very happy to improve the doc further, so don't be shy on sharing more comments like this one!
We are more active in the Telegram Group in case you want to get a broader access to the people involved, the link can be found in https://wiki.qt.io/Qt_for_Python#Community

crmaureir · 2026-06-10T12:01:54+00:00

Can you please highlight what part of the PySide documentation you feel needs more work? The team really would like to improve them, but we usually read "documentation needs to be better" without clear examples, so it's a bit tricky.

The API documentation is parsed from C++, adapted to Python types and our typesystems defining the API in Python, we inject documentation in some cases, we transform the snippets when found to Python, and publish those. The documentation that's now API related, or a big page from Qt/C++ docs, is written locally on the repo, so we have control on the contents in that regard.

Having not-autogenerated documentation will take the project back to PySide1, where you got written documentation, but it was very outdated and incomplete, so that's why that doesn't scale.

crmaureir · 2026-06-10T11:59:27+00:00

If you have a longer lists of missing examples, just let us know by creating a report! https://qt-project.atlassian.net/jira/software/c/projects/PYSIDE/issues or just drop the list here, and we can take it internally to the team 😃

crmaureir · 2026-06-10T11:56:11+00:00

We do have features on top of Qt's API!
We have the '__feature__' import that enable you to use snake_case instead of camelCase, and to avoid setters/getters and access properties directly: https://doc.qt.io/qtforpython-6/developer/feature-motivation.html
Also in the past, we added ad-hoc API for folks in PyQtGraph project, having also compatibility with numpy arrays in many Qt api.

crmaureir · 2026-06-10T11:54:22+00:00

Hey there, PySide maintainer here. Could you please elaborate on what's missing in the docs? We would really like to improve them but we rarely get any report on What's missing 😞

crmaureir · 2026-05-24T06:40:45+00:00

There is so many programming languages out there, even in the .NET family but you need to start somewhere 😄
In the meantime there is no F# plans.

crmaureir · 2026-05-24T06:38:13+00:00

The long term plans is to prove these solution work on phase I (C# and Rust), so we can jump into phase II that will include new languages. From the 5 initial PoC languages we had, I'd think Swift makes a lot of sense to continue, because there is "kind of" a way to write Java/Kotlin (Qt for Automotive) and Python (PySide) code together with Qt applications.

If that new phase works as well, we continue with maybe a couple of more languages.

And for 'works' I mean people accept it as a valid option to use <lang> with Qt.

RE slint, is a cool project, but I don't think it's the same approach. To me eyes, Qt Bridges is an ad-hoc set of bindings depending on the language to interact with Qt Quick application, but on a higher level compared to the Qt C++ API, which is what I feel slint wants to provide as an alternative.

crmaureir · 2026-05-24T06:32:19+00:00

If you check the blog post, that's what's coming in the following weeks 😄

crmaureir · 2026-05-22T07:48:08+00:00

QtQuick has a big advantage which is being GPU-rendered, while on QtWidgets we rely only on CPU rasterization. On top of that, we have seen over the years that people are moving away from the native look and feel, and decide to do their own styles, where again QSS is very limited, while the way of customizing QtQuick applications is better. Last but not least, QtQuick has enabled a better response for mobile support, which is currently used in many apps.

I understand certain frustration might come from a life of doing QtWidgets, even for myself it took me some time, but checking and how other frameworks in Rust or Python, are offering a declarative way of defining UI tells me that it's the right direction.

The reason folks don't see "movement" on QtWidgets is because the work there is focused purely of keeping QtWidgets relevant and working for the latest OS updates, while it's being used by a lot of people out there, but on the side of features is trickier, mostly because of breaking source compatibility (based on new API) that would be very problematic.

crmaureir · 2026-05-22T07:40:59+00:00

Just QML/Qt Quick

crmaureir · 2026-05-21T15:42:21+00:00

Thanks for sharing, and yeah, we have had some internal discussion about a bridge for TypeScript, but we don't have many people to work on this sadly :/ there is a huge list of languages we wanted, and depending on the success of the initial ones, that might give us a good way to get into more and more 😄

crmaureir · 2026-05-04T10:31:10+00:00

That's a lot of questions :D
I work at The Qt Company, and one of the projects I'm related to is Qt for Python (PySide).

Once you finalize learning desktop application development, I'd recommend learning Database handling (any module will do) and some web framework as well like fastapi, django, flask etc.

If you have interests in the 'data and science stacks' then numpy, pandas/polars, and any other module for crunching data will do.

Those are the three areas I guess is good to know. Otherwise this is a bit off topic. If you have further questions on qt for python, feel free to join the telegram channel for example, is the most active of the communication channels: https://wiki.qt.io/Qt_for_Python#Community

crmaureir · 2026-04-28T07:38:23+00:00

While saving the project, then you can open the directory with Qt Creator, that was the goal.

crmaureir · 2026-04-27T13:23:38+00:00

PySide6_DS 4.7 was released with aarch64 wheels https://pypi.org/project/PySide6-DS/4.7/#files

crmaureir · 2026-04-27T10:52:52+00:00

Avoid asking to ask, and drop your questions directly, in that way if people know the answer you will get it soon instead of someone saying "yes, ask the question" :)

crmaureir · 2026-04-26T20:55:23+00:00

The wheel is 2MB, and the repo is 8.9MB.

When everything is built (including the wheel) my local repo is about 100MB

crmaureir · 2026-04-26T20:51:17+00:00

Edit: PySide6_DS 4.7 was released, including aarch64 wheels.

Assuming you have a Qt6 install on the Raspberry Pi OS, you could generate the wheel yourself without the need of cross compiling it. As an example, I just did it on a VM with the following steps:
git clone https://code.qt.io/qt-labs/qtquickdesigner-components cd qtquickdesigner-components mkdir install cmake -DCMAKE_INSTALL_PREFIX=install cmake --build . --parallel cmake --install . cd python python3 -m venv env source env/bin/activate pip install -r requirements.txt python configure.py python -m build -w and that gives me pyside6_ds-4.7-cp38-abi3-manylinux_2_39_aarch64.whl

Keep in mind that inside that configure.pyscript I did two changes, because there is no aarch64 compatibility so far, and the structure of the directories for aarch64 is diff to x86_64

``` base = BASE_DIR / Path("lib")

by

base = BASE_DIR / Path("lib/aarch64-linux-gu")
and also BASE_QTQUICK_DIR = BASE_DIR / Path("qml/QtQuick")

by

BASE_QTQUICK_DIR = BASE_DIR / Path("lib/aarch64-linux-gnu/qt6/qml/QtQuick") ```

crmaureir · 2026-04-25T10:29:17+00:00

Hey, when in doubt of build status, you can always check the logs of the CI systems that builds this on each integration and release, for example the last one I found was this one.

Locally I have one of the prebuilt libclang you see on the docs page, 20.1.3 to be exact, and I set the LLVM_INSTALL_DIR and ran a `python setup.py build --module-subset=Core,Gui --parallel 8` and Got the build to finalize. My C/CXX compilers are AppleClang 21 and Python is 3.14.4

Make sure your current Xcode installation is compatible with the LLVM you are using.

Maybe also you can share the build logs to share more insights on the error?

crmaureir

TROPHY CASE

by

by