So... QtBridges that don't expose qt, but only allow you to make
something talking to QML.
Does that mean your message is now that Qt is just QML, and the rest of
it doesn't really matter?
Just checking if I understood the message correctly, of course.
Cheers,
André
On 10-12-2025 12:26, Volker Hilsheimer via Development wrote:
On 10 Dec 2025, at 01:13, Thiago Macieira <[email protected]> wrote:
Got it. So in the Python world, it would allow writing a non-PySide
application logic that interacted with QML. Whether it reuses something from
PySide (like Shiboken) is an implementation detail. Is that it?
Trivial example (subject to changes):
MyType.java:
@Registrable
MyType {
public void doStuff() { /**/ }
}
Main.qml:
import MyQtBridge
MyType { id: mt }
Button { onClicked: mt.doStuff(); }
Since there's no Qt C++ here, is the name accurate? Should this talk about QML
instead? Or maybe insert "Quick" in the name?
On a product/marketing/communications level, I think we would do ourselves a
disservice by getting lost in technicalities. The story we want to tell is that
we are making Qt available to Python/C#/Java/Swift/Rust developers. We won’t
reach those developers if we throw module and technology names at them that
they won’t understand if they know nothing about Qt.
That’s for the product, and for the terminology we have been using in public
communication. In principle, and if it helps avoid confusion with other repositories,
we could use more specific terminology in the repositories and artefacts. But
assuming that “Qt Bridges” will become established vocabulary, both within the
contributor community and for the users we are targeting, a repository naming
convention “qt/qtbridges-<language>” as requested makes sense to me.
Volker
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
