Hi,
On 14-09-2021 09:12, Shawn Rutledge wrote:
On 2021 Sep 13, at 20:58, Elvis Stansvik <[email protected]
<mailto:[email protected]>> wrote:
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.
We’re talking about potentially a lot of Image items though, Loaders,
anything else that has a source url and gets used in a component which
is instantiated in multiple contexts. If it looks like a path, it’s
actually a URL. If it’s relative and Qt gets the base wrong, you need
to worry about it. When 6.2 LTS comes out, we’re guessing a lot of
apps will be ported, and this will come up a lot. It might cause some
noise in Jira with the same bug report being written repeatedly: image
doesn’t load, no idea why, it worked in Qt 5, blah blah. Even if they
understand, they will be unhappy having to write this boilerplate
Qt.resolvedUrl() all over, and still complain that Qt 5 worked better.
But if we make a syntactic improvement: before you had to write
Qt.resolvedUrl() and now you write something simpler, maybe that will
ease the pain a bit?
I am wondering if the change was a good idea at all then. To me, it
feels like the change at the root of all this was not well thought out.
If it is expected that this change is going to hit so many users and
they need some facility to make it easier on them than littering their
code with Qt.resolvedUrl, it would perhaps have made more sense to go
the other way around and introduce an unresolved URL type, which can
then be resolved to a QUrl where needed without touching the default. It
feels like the support introduced for the more edge case use of
unresolved URLs as the default mode has ended up causing problems for
all those use cases where resolved URLs are needed. I don't _know_ what
discussion there has been around that at the introduction of this
change, but it _feels_ like it might be the result of a rushed in change.
And now, another fundamental change is suggested again to patch up the
problem caused by the first change.
I would suggest seriously considering reverting changes that cause the
issue, and solving the need for being able to handle an unresolved URL
in a different, backwards compatible way.
Perhaps something along these lines would be possible:
A URL in QML can be resolved or unresolved. If a URL is constructed for
a string (like we have been doing for ages in QML), it is directly
resolved automatically. If you need an unresolved URL, you use another
syntax to construct the URL setting some flag on it to indicate it needs
to be resolved at some later point using another context. Syntax could
be either some constructor function (like Qt.resolvedUrl()) or perhaps
as a fully fledged type `Url{url: "someUnresolvedUrl"; unresolved: true
/*=default*/}`.
Cheers,
André
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
