> On 10 Dec 2025, at 17:04, Thiago Macieira <[email protected]> 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 -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
