[Development] Feature freeze exception for QTBUG-95587

[André Somers]

Hi,

On 14-09-2021 09:12, Shawn Rutledge wrote:
>
>> On 2021 Sep 13, at 20:58, Elvis Stansvik <elvstone at gmail.com 
>> <mailto:elvstone at gmail.com>> 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é


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210914/1d1c5fee/attachment.html>