Hi, This sounds like a really interesting project! I am curious to see how some of the complexities are resolved (e.g. object lifetimes etc), but I am certain that once they are, this will be a really nice addition. It will be really interesting to see how much tooling and formal verification could be supported, if using an appropriate bridge!
One comment, inline: On Wed, Dec 10, 2025 at 11:46 PM Vladimir Minenko via Development < [email protected]> wrote: > > On 10. Dec 2025, at 14:08, André Somers via Development < > [email protected]> wrote: > > So... QtBridges that don't expose qt, but only allow you to make something > talking to QML. > > > to Qt Quick via QML from my perspective and IMHO. > I am not sure I understand properly what is meant by this. Are there specifically QtQuick-related dependencies/functionalities involved, or does the bridge simply allow the developer to expose certain types (with properties, signals, invokable methods, enums, etc, which are defined in a language other than Qt/C++) in a QML module? If the former, what are those dependencies? If the latter, when you say "to QtQuick via QML" is that simply an expression of your expectation that the vast majority of users will be writing applications using both QtQuick and QML, and make use of the bridged functionality within such applications? Or am I misunderstanding entirely? In general, I think it would be vastly preferable if language-bridged QML modules could be used in QML applications which do not have a UI, or which do not render their UI with QtQuick. And, if that is the case, I personally would really prefer if (especially in technical communication, such as here in the dev list) we were consistent with terms. Qt is not QML. And QML is not QtQuick. These terms are specific meanings which communicate specific things to developers (... or at least, I think they should). Maybe I'm just being overly pedantic about semantics - it is an occasional failing of mine ;-) Best regards, Chris. > Does that mean your message is now that Qt is just QML, and the rest of it > doesn't really matter? > > > Not at all! Our message should be understood as: Qt is not only C++, QML > and Python (via bindngs like PySide). It is not only that, it is more. > > Long term, we would like to even find ways how bring languages and C++ > being even at the same time. So that Qt will be seen more and more as a > language-indepedent framework. > > Some day, we also want to find ways how to involve folks from > https://wiki.qt.io/Language_Bindings so that over time, it becomes a > wider effort and exploration > > Just checking if I understood the message correctly, of course. > > > I’m glad you do. And I miss more voices from outside of The Group :-) > > — > Vladimir > > > > 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 > > > -- > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development >
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
