The XR announcement is probably one of the most exciting parts of this presentation. I am so glad they made QtRHI back in 2018. This should make it possible to make apps that run on apple vision pro and oculus with the native rendering Api. Then multiview as well for proper performance. The direction looks really promising for businesses making ar apps!
@@MauriceKalinowski Ah.. "fuzz" testing. Now I understand it. I am sorry for my bad English. Thank you for clarifying it to me. I already read a bit about fuzz testing, but never done it so far.
Well... I still feel QtQuick/QML is not production ready on desktop. Not even after so many years. It is still missing that slick and smooth user experience and real developer productivity. And because it has been so many years since it was introduced, I tend to think it will never be ready because there seem to be some bad past decisions buried deep in the architecture that cannot be overcome. QtQuick/QML seems as a wrong path taken long time ago in the past which Qt now cannot return from. Therefore so many companies that I know still stick to QtWidgets. But QtWidgets start showing their age (unless they are heavily styled and customized) and when these companies decide to leave QtWidgets someday in the future I am pretty sure they will not go for QtQuick/QML but they will leave Qt ecosystem forever. It seems to me that Qt abandoned desktop. Which makes me sad, because I like Qt very much...
Thanks for the feedback! Do you have some specific examples of smooth user experience that you would like to see in QML/QtQuick/QQC2? What are the bad decisions in the architecture which can not be corrected today from your perspective? As you saw on this video, Qt wants to make those things better, not to mention the fact that some improvements for Qt Quick for desktops are already on the way. Please let us / me know! Thanks!
@@VladimirMinenko There are several problems in user experience I have had with QtQuick/QML. See for example video attached with bug QTBUG-120051, which I have just posted to Qt bug tracker. Do you think this is what professional-grade software should look like? And there are more problems with UI response speed. Try dragging for example any quick item around in a window - the items is visibly lagging behind the mouse cursor (especially on my Windows machine; macOS is slightly better in this). The overall experience of QtQuick/QML applications is like I am wading knee-deep in a layer of heavy mud. Curiously enough QtWidgets application often feel much snapier and smoother that QtQuick/QML ones despite not being GPU accelerated. Also the default look and feel of the default styles is very mobile-phone-like and not suitable for desktop. Of course I can adjust many things, but I am talking about the overall default impression. It is obvious that desktop was not a priority when QtQuick/QML was designed. Regarding the architecture - there are many things that I do not like but it is hard to give any solid arguments because I am definitely not a QtQuick/QML expert. But I hate how much boilerplate code I must write in order to bridge C++/QML barrier there and back. Everything must be declared as property, each dynamic data must be contained in some kind of QAbstractItemModel, all communication is just via queued signals and slots, I cannot call methods directly, I cannot even access the UI controls directly from C++. I would love to write everything in C++ but I cannot. In my opinion C++ should be first-class citizen language in QtQuick instead of QML. In my opinion QML should be only an optional tool for simpler building UIs with QtQuick, like QtDesigner is an optional tool for building UI with QtWidgets. I also find customizing and deriving from existing QtQuick controls very hard if not impossible. Writing completely new controls from the scratch feels also very hard. Everything is just so complicated. And this seems to that it is caused only by the fact that QML is the cornerstone of QtQuick applications instead of being an optional part. This decision was probably based on the idea that the codebase will be ideally split between designers (who will maintain QML frontend) and actual programmers (who will maintain C++ code), but this philosophy is IMHO wrong - it only introduces the artificial C++/QML barrier but does not bring any tangible benefits. But as I say I am not an expert in QtQuick/QML. Maybe I am missing something very obvious to overcome all this and make it simple and easy. I definitely appreciate the hard work that Qt team is doing and how they try to improve Qt more and more. But I personally feel that QtQuick/QML is not the right direction of the UI toolkit of the future on desktop. It seems to me that it is trying hard to overcome some bad past architectural decisions but still fails because these are rooted too deep in the code... I would wish Qt7 would make some big revamp of the overall architecture and offer some other way of making UI... But honestly I do not think this will happen. Qt seems to be stuck and will survive only in the embedded world and everywhere else it is going to slowly die... Which is sad. The community seems diminishing, there are very few new projects and the competition grows very fast.
The XR announcement is probably one of the most exciting parts of this presentation. I am so glad they made QtRHI back in 2018. This should make it possible to make apps that run on apple vision pro and oculus with the native rendering Api. Then multiview as well for proper performance. The direction looks really promising for businesses making ar apps!
Question about 20:20: What is "fast testing"? Is that a tool name? Can you give a link to that tool, please?
Volker is referring to fuzz testing here. Qt uses fuzzing extensively to verify or check for illegal input of data to many of our classes.
@@MauriceKalinowski Ah.. "fuzz" testing. Now I understand it. I am sorry for my bad English. Thank you for clarifying it to me. I already read a bit about fuzz testing, but never done it so far.
Well... I still feel QtQuick/QML is not production ready on desktop. Not even after so many years. It is still missing that slick and smooth user experience and real developer productivity. And because it has been so many years since it was introduced, I tend to think it will never be ready because there seem to be some bad past decisions buried deep in the architecture that cannot be overcome. QtQuick/QML seems as a wrong path taken long time ago in the past which Qt now cannot return from. Therefore so many companies that I know still stick to QtWidgets. But QtWidgets start showing their age (unless they are heavily styled and customized) and when these companies decide to leave QtWidgets someday in the future I am pretty sure they will not go for QtQuick/QML but they will leave Qt ecosystem forever. It seems to me that Qt abandoned desktop. Which makes me sad, because I like Qt very much...
Thanks for the feedback! Do you have some specific examples of smooth user experience that you would like to see in QML/QtQuick/QQC2? What are the bad decisions in the architecture which can not be corrected today from your perspective? As you saw on this video, Qt wants to make those things better, not to mention the fact that some improvements for Qt Quick for desktops are already on the way. Please let us / me know! Thanks!
@@VladimirMinenko There are several problems in user experience I have had with QtQuick/QML. See for example video attached with bug QTBUG-120051, which I have just posted to Qt bug tracker. Do you think this is what professional-grade software should look like? And there are more problems with UI response speed. Try dragging for example any quick item around in a window - the items is visibly lagging behind the mouse cursor (especially on my Windows machine; macOS is slightly better in this). The overall experience of QtQuick/QML applications is like I am wading knee-deep in a layer of heavy mud. Curiously enough QtWidgets application often feel much snapier and smoother that QtQuick/QML ones despite not being GPU accelerated. Also the default look and feel of the default styles is very mobile-phone-like and not suitable for desktop. Of course I can adjust many things, but I am talking about the overall default impression. It is obvious that desktop was not a priority when QtQuick/QML was designed.
Regarding the architecture - there are many things that I do not like but it is hard to give any solid arguments because I am definitely not a QtQuick/QML expert. But I hate how much boilerplate code I must write in order to bridge C++/QML barrier there and back. Everything must be declared as property, each dynamic data must be contained in some kind of QAbstractItemModel, all communication is just via queued signals and slots, I cannot call methods directly, I cannot even access the UI controls directly from C++. I would love to write everything in C++ but I cannot. In my opinion C++ should be first-class citizen language in QtQuick instead of QML. In my opinion QML should be only an optional tool for simpler building UIs with QtQuick, like QtDesigner is an optional tool for building UI with QtWidgets. I also find customizing and deriving from existing QtQuick controls very hard if not impossible. Writing completely new controls from the scratch feels also very hard. Everything is just so complicated. And this seems to that it is caused only by the fact that QML is the cornerstone of QtQuick applications instead of being an optional part. This decision was probably based on the idea that the codebase will be ideally split between designers (who will maintain QML frontend) and actual programmers (who will maintain C++ code), but this philosophy is IMHO wrong - it only introduces the artificial C++/QML barrier but does not bring any tangible benefits. But as I say I am not an expert in QtQuick/QML. Maybe I am missing something very obvious to overcome all this and make it simple and easy.
I definitely appreciate the hard work that Qt team is doing and how they try to improve Qt more and more. But I personally feel that QtQuick/QML is not the right direction of the UI toolkit of the future on desktop. It seems to me that it is trying hard to overcome some bad past architectural decisions but still fails because these are rooted too deep in the code... I would wish Qt7 would make some big revamp of the overall architecture and offer some other way of making UI... But honestly I do not think this will happen. Qt seems to be stuck and will survive only in the embedded world and everywhere else it is going to slowly die... Which is sad. The community seems diminishing, there are very few new projects and the competition grows very fast.
@@vladimirkraus1438 Thank you for speaking up! Quite some things to read and digest!
Qt Widgets are the best and much better than QML on desktop, please don't ever abandon them