[Development] QTCS2019 Notes from QtQml session

Shawn Rutledge Shawn.Rutledge at qt.io
Wed Nov 27 13:08:24 CET 2019

On 26 Nov 2019, at 12:35, Olivier Goffart <olivier at woboq.com<mailto:olivier at woboq.com>> wrote:

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”

I agree, was just going to write a comment about that.  If we will continue to support QML 2 for cases when the runtime engine is useful, for the foreseeable future, then QML 3 isn’t really the successor, is it?  If QML 3 was the successor, the ability to run QML without compiling it first would be sorely missed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191127/08b05dcb/attachment-0001.html>

More information about the Development mailing list