[Development] Repository request: qt/qtbridge-java

[Volker Hilsheimer]

> On 10 Dec 2025, at 17:04, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Wednesday, 10 December 2025 03:26:57 Pacific Standard Time Volker Hilsheimer 
> via Development wrote:
>> 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.
> 
> Repository names do not have to map to the marketing name of the technology. 
> For example, Qt Quick and QML live in the "qtdeclarative" repository, for 
> historical reasons.
> 
> However, in this case, it's the marketing name that is the problem: you're not 
> giving access to 95% of Qt; you're only providing access to QML and Qt Quick. 
> So I find that calling it a "Qt Bridge" is misleading, unless there are plans 
> to expand to more than QML. In which case, I ask again that someone explain 
> how this relates to PySide.
> 
> This is just advice and feedback. We have no jurisdiction over the marketing.


Qt for Python/PySide as a language binding, and the Qt Bridge for Python, can and will coexist.

Is it useful for Python developers to get access to e.g. QFile via PySide? I’m not entirely convinced ;) That’s one of the lessons we want to take seriously with Qt Bridges: let Python developers write Python code using standard Python libraries; and then use Qt for those things that are not available within the Python eco-system, or where we are convinced that Qt has a superior solution. And also then, we want to stay as close to Python as possible, and not require that people can implement a QAbstractItemModel just to show the contents of a Python list in a UI.

UI development, and Qt Quick in particular, is where we start, because that’s where we see Qt shine.


Volker