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
