Hello,
due to the magnitude of the above mentioned bug, I'm considerng to
introduce a new feature in Qt 6.2.1. The new "@" operator in QML
relieves you from typing "Qt.resolvedUrl" over and over. See
https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987
Now the question is whether we want to relax the feature freeze for this
particular issue or not.
Some background:
In Qt5, the QML engine resolves a relative URL as soon as it is assigned
to any property of type "url" or QUrl. This means that you cannot store
relative URLs in such properties, and reading such a property back in
QML gives you a different value than the one you have written. The base
URL used for resolving is the URL of the QML document where the
assignment happens. This is often not the place where the URL is meant
to be resolved. There were a number of bug reports about these
shortcomings in Qt5, especially when combined with URL interception
and/or redirection. See for example QTBUG-81244 QTBUG-88965 QTBUG-66690
QTBUG-76879
In Qt6, URLs are simply not resolved anymore when assigning them to a
property. This conveniently gets rid of all the cruft and inconsistency
resulting from the Qt5 behavior. Instead the individual elements using
URLs (Image, ShaderEffect, ...) are free to resolve them to their
liking. There is suitable functionality exported from QtQml to do that.
Now, there is one problem, QTBUG-95587: The original context where a URL
was first assigned to a property is not easily available to the final
consumer of the URL. At the same time, the element consuming the URL
might be deeply nested in the implementation details of some module and
might have a rather internal base URL. In this case, the URL as resolved
by the consumer is not very useful.
A user can fix this by explicitly calling Qt.resolvedUrl() in order to
resolve the URL in a specific context and make it absolute. As we need
URLs rather often in QML, we will see much more Qt.resolvedUrl() in Qt6
than we have seen in Qt5. As Qt.resolvedUrl() is quite a mouthful, there
should be a shorthand for it: the '@' operator.
So, is this bad enough for an exception, or should we rather live with
Qt.resolvedUrl() in 6.2. I'm tentatively in favor of the exception
because 6.2 is a rather important release and this is a rather ugly wart
in the QML language.
best regards,
Ulf
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
