For a general idea of what we are trying to achieve with Qt Bridges, read Vladimir’s blog [1] from May, following the announcement of the plan at Qt World Summit:
https://www.qt.io/blog/about-the-new-qt-bridging-technology And here’s a recording from this year’s KDE Akademy [2] (including the technical mishaps): [2] https://www.youtube.com/watch?v=yEZnwkCLa44&list=PLsHpGlwPdtMrmR5QxoSYGbuiy2we0uMmt&index=2 We don’t have a recording of the Qt Contributors Summit this year where we also talked about Qt Bridges as part of the roadmap re-cap, and in a dedicated session [3]. [3] https://wiki.qt.io/QtCS25_-_Using_Qt_Quick_with_other_programming_languages Perhaps this helps a bit with the context. Both the blog and Qt CS are from May, at which point things were still in a very early stage. The teams have now pushed the development to a point where we have something to show for each of the languages, which is a good time to start moving the work under the open governance and contribution model of the Qt Project. Volker > On 9 Dec 2025, at 13:47, Juha Vuolle <[email protected]> wrote: > > Hi Thiago, > > I believe there may have been some softness in terminology, I'll try to > clarify. > I'll reply from a Java/Kotlin point of view because the details vary > per bridged language. > >> Are users going to write actual Java > Yes - users write normal Java/Kotlin apps, using their usual > toolchains and IDEs. > > Some of their classes, functions and properties can be exposed to QML, and the > bridge handles the communication between Java and QML through C++/JNI. > From the developer’s perspective, the C++ layer is an implementation detail > they never need to interact with. > > Terminology-wise: > - 'bridged' language is Java/Kotlin (the user's application logic) > - 'bridging' language is C++ (internal implementation of the bridge) > > Java/Kotlin Bridge provides the handful of annotations and APIs for > users to mark what&how they > want to expose/bridge from Java to QML. They annotate normal > Java/Kotlin classes. > This includes things like variables, callbacks (~signals), and > invokable functions. > >> When I read "application logic to Qt Quick application", I think of the C++ >> backend of that application > Yes, conceptually this replaces the traditional C++ backend of a Quick > application. > But bridge is not a traditional 'binding API' where we 'expose Qt to > Java'. But rather it's that we 'expose Java to QML'. > > Trivial example (subject to changes): > > MyType.java: > @Registrable > MyType { > public void doStuff() { /**/ } > } > > Main.qml: > import MyQtBridge > > MyType { id: mt } > Button { onClicked: mt.doStuff(); } > > On Mon, 8 Dec 2025 at 22:42, Thiago Macieira <[email protected]> > wrote: >> >> On Monday, 8 December 2025 09:34:49 Pacific Standard Time Cristián Maureira- >> Fredes via Development wrote: >>> Hey Thiago! >>> >>> What I meant with the description >>> was that we are trying for the module to be as close to Java, >>> without imposing C++ or Qt code patterns. >>> >>> By "bridge language style" in this case, we meant "Java coding style". >> >> So you're not bridging to Java, you're bridging to Java developers, by making >> the coding easier for them to get comfortable with. >> >> Python I would understand, since it's a completely different syntax, what >> with >> whitespaces being meaningful and the absence of the increment operators. But >> Java uses the same syntax as C and C++. So how can we get anything closer to >> Java that isn't Java itself? >> >>> Since the description is the same for the other languages, >>> an example could be to use decorators, pragmas, >>> properties, observables, when possible, to replace >>> some of the Qt functionality that due to its C++ nature >>> might look strange for 'the bridge language' users. >> >> "Bridge language" is the language with which you implement the bridge itself. >> Given that these are qt/* projects, those should be C++. Did you mean the >> language on the other side of the bridge, that is, the "bridged language"? >> >>> If with my explanation, the meaning was better understood >>> and you have a suggestion in the description, please let me know :) >> >> I don't understand at all. >> >> Are users going to write actual Java, Python, or Swift or Rust? When I read >> "application logic to Qt Quick application", I think of the C++ backend of >> that application, which would imply that's what you're replacing. I don't see >> how you can do that without going all the way: there's no hybrid of C++ and >> Python syntax. You're either C++ (where "++" is the increment operator) or >> you're Python (where "++" are just two pluses together not separated by >> whitespace). >> >> Or are we talking about the language that goes inside of .qml files, >> replacing >> JavaScript? How faithful is this meant to be for the actual language? How >> much >> of the standard libraries of those languages is this going to offer, because >> people wouldn't use the JS one? >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Principal Engineer - Intel DCG - Platform & Sys. Eng. >> -- >> 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
