[Development] Feature freeze exception for QTBUG-95587

[Elvis Stansvik]

Den tors 9 sep. 2021 kl 17:33 skrev Ulf Hermann <ulf.hermann at qt.io>:
>
> 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.

>From a somewhat outside (user) perspective, my language-wart alarm
goes off by this. I don't think introducing completely new syntax for
something as specific as URL resolution is something that should be
squeezed into the language during a feature freeze. Yes, URLs are
vital to QML I guess, but are they *that* vital? The bar should be
quite high IMO. In the apps I've worked on, URLs and URL handling is
really not central at all. That is anecdotal, but it would then be
good to see examples of QML apps where the lack of an @ operator for
URL resolution would be unbearable.

I don't see what's inherently wrong with a plain function like
Qt.resolvedUrl. It's very obvious - it says what it does on the tin.
Names are good that way.

@ on the other hand would be completely opaque to a newcomer.

When in a later mail, you reject qsUrl as an alternative to
Qt.resolvedUrl because 'it doesn't express "resolved"', I must ask:
How exactly does @ express "resolved"?

Could you perhaps introduce a plain function for this, like e.g.
Qt.resolvedUrl, or maybe put it inside the string as "csd:foo.png",
and let the question of syntactic sugar stew a bit?

Taking Python as example, one could compare this to the discussions
preceding the recent introductions of the walrus and union operators.
Those were very long processes. Granted Python has many times the
number of users, but still.

Just my two cents.

Elvis

>
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development