[Development] Repository request: qt/qtbridge-java

[André Somers]

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 <thiago.macieira at intel.com> 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
>