On 25.11.19 16:36, André Somers wrote:
On 25-11-19 15:53, Ulf Hermann wrote:
Yeah, that's going to make using QML in actual applications a whole lot
harder. For instance, sometimes access to some root node is needed even
from deep leaf files. Removing that capability is quite a drastic measure.
Yes, but the problems with this construct are the same as with generic
context properties: Your QML component requires some context that it
doesn't declare. Therefore your code is not reusable and brittle wrt
addition of properties in other places.
Mind that all those dynamic lookups will still live on in QML 2, and we
will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
"It will still work in QML 2" is not a great one if you want people to port
over to QML 3. And you will need to support something like this anyway.
So far, the feeling I'm getting is that you're quite rigorously axing things
from QML 2 in QML 3 in order to clean up because it is "broken" in QML 2. But
without careful consideration what should replace it, that will just lead to
the same issues again or a less usable QML for real world applications.
I'm a bit concerned.
Maybe the marketing isn't quite right.
Perhaps it shouldn't be named "QML 3" but "QML strict"
QML3 tell peolpe
"This is the new version, you should port your code, the old version is going
to be deprecated at some point"
While maybe true, I understand people's frustration. And since you will need to
maintain both QML2 and QML3 at the same time, it might be better to rename it
to something like "QML Strict" which convey the meaning:
"QML Strict is as subset of QML which is more maintainable and performs better"
--
Olivier
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
