QtCS2024 QML Next: Difference between revisions
Jump to navigation
Jump to search
WindJunkie (talk | contribs) (Initial version) |
WindJunkie (talk | contribs) (added slides) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
==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. | 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 | |||
[[File:QtCS 2024 - QML Next.pdf|thumb|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. | |||
[[Category:QtCS2024]] | |||
Latest revision as of 13:09, 11 October 2024
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:
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.