[Development] Feature freeze exception for QTBUG-95587

[Shawn Rutledge]

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 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.

Yep.  But Qt.anything() is also weird IMO: there’s no reason why the object containing this function should be called Qt.  So maybe we need a function with a short name, not in a namespace? Or in some object that actually makes sense?  Or the suffix solution, because if we add units later, that will start to look like the same sort of thing even if it’s actually a bit different.  Or a function on the string: Image { source: “my icon.png”.resolvedUrl() }. But I’m just brainstorming without the implementation perspective in mind.

or maybe put it inside the string as "csd:foo.png",
and let the question of syntactic sugar stew a bit?

That’s an interesting idea, but then csd: starts to look like a new URL protocol alongside http: and file: and qrc:, right?  Don't we need another one for the directory in which the leaf component instantiation was done, rather than the directory in which the component exists?

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