> 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
