QtCS2024 QML Next

Session Summary

With "QML Next," we want to expand the use of Qt (as technology) with QML and Qt Quick to new users. There are many ways to do this in general. This talk will describe one of those but also mention other routes The current concept and prototype is a start to address all those users who do not come to Qt because they want or need to use other languages which are not C++ Compared to discussions at QtCS23, there is a shorter list of languages which are doable for one or another reason Lets have a look at what all that is and might be and, most importantly, if such a solution would one which you would use

Session Owners

Vladimir Minenko - Product Lead for Qt Foundations, The Qt Company

Slides from the "QML Next" talk

Slides:

Notes

• Ulf comment about three points
  • write application in other language
  • add UI written in QML/QtQuick
  • pass data back and forth
  • ... and those should be the complete requirements for the example apps.

• X: some requirements to have components in diff languages. Maybe something around QML_ELEMENT might be good, so this company could enable more languages.
• Ulf: we have type registration for Rust. And for Python.
• Kai: Maybe geting qtquick in another language. there was an idea to have qml as a standalone thing long time ago. Service somewhere providing data and a frontend showing the data usually.
• Ulf: we have a qml http request that could be used...
• Dennis: maybe using gRPC? but it could be overkill.
• Ulf: maybe performance doesn't matter much...we have a qml module that exposes it.
• Q: Do you have use-cases for other languages and need UIs?
• Y: there is a case with Go, Nim and QML.
• Andy: needing to learn more than one language is normal, so it shouldn't be an issue. Frontend developers shouldn't use c++ in 2024.
• Joshua: I have a talk similar to this in Akademy.
• Comments on the current Python implementation on how to simplify things, and reduce the 'Qt' parts from the code.
• Z: use case for backend-frontend decoupled. You will be competing with web frameworks.
• Ulf: we do compete with web frameworks, qml is easier compared to html/css/js and we are more performant.
• Z: I would prefer to use QtQuick...but some times businesses make decisions that are are not convinient. Some times it depends on the pool of developers because it's easier to hire people.
• Ulf: maybe functionality and app size matters as well
• P: Maybe we nyeed to expose qml to a rest api to integrate more languages. it would be nice to have standard type and have a simpler model integration. Maybe a qml application withou a c++ main
• Ulf: you can do that...and you can have it bundle.