Re: [Development] Feature freeze exception for QTBUG-95587

[Alberto Mardegan]

On 13/09/21 21:58, Elvis Stansvik wrote:
> 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.

FWIW I've been using it for ages, and yes, if it initially it sounded a
bit verbose, now I'm perfectly accustomed to it.

> @ 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"?

qsUrl could be a nice addition, but even than, I don't feel such a
strong need for it either.

I think that the point raised by Oswald, about the waste of using "@"
for such a narrow functionality, also deserves more attention.

Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

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. 


A separate type would not help here. You would have to change your code 
in order to use it. If you do so, you can as well write 
Qt.resolvedUrl(). Furthermore, the "string" type can already be used to 
store unresolved URLs today.



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.


We may have not made the discussion public enough, but I can assure you 
the decision was not rushed. There were many bug reports on the 
inconsistent automatic URL resolution in Qt5, and we've been trying to 
improve it for years. In the end it turned out that the only consistent 
solution is not to automatically resolve URLs. When Qt6 came around we 
saw the chance to do exactly that.


Usually, you set a property in the same scope as you create an element. 
So, all those


Image { source: "foo/bar.png" }

are unaffected. It doesn't matter if the Image element resolves the URL 
in its scope, or if the QML engine resolves the URL in ... the same 
scope. Technically, most user code does not need to change.


The case that hasn't seen enough consideration is the mechanism employed 
by QtQuick.Controls in some places, where the URL is exposed via an 
alias property. There, the scopes are in fact different and you have to 
resolve the URL explicitly. These places do need to change.


From my point of view, those cases still don't outweigh the abundant 
problems we had in Qt5.


Yet, the fact that you need to convert in some places, but not in others 
is not ideal. Such subtleties make it hard to reason about the code in 
question. The need for resolving is not apparent from the immediate 
context but requires examining the internals of the element that 
receives the URL. Furthermore, the places you need to change should be 
automatically detectable by tooling so that we can, for example, make 
qmllint show you the places where you have to resolve.


The core of the problem is our implicit conversion from string to url. 
At the point where we convert, we don't know whether we should resolve 
the url in the current context or not. We cannot know because we don't 
know what the URL will be used for and whether it is already absolute. 
The user might just store the URL to be passed somewhere else or used 
for further conversions. In this case we should not resolve it. Or the 
user might want to load some resources from the URL. In this case we 
should resolve it. However, if it is already absolute, it doesn't really 
matter.


In order to make code that uses URLs more accessible to reasoning and 
tooling, we _need_ the user to specify. Right now, there are three ways 
to specify:


- The well-known Qt.resolvedUrl(url) explicitly resolves the URL in the 
current context.
- The new Qt.resolvedUrl(url, context) explicitly resolves the URL in 
the given context.

- The new Qt.url(url) explicitly doesn't resolve.

Given all this, we should eventually deprecate the implicit conversion 
and transition to the explicit ones. Then we can make qmllint flag every 
implicit string-to-url conversion and suggest the above three 
alternatives. I know we need to wait a minor release or two before 
adding a deprecation warning, but from a language perspective, this is 
the way to go. It will make your QML code more legible and you will 
immediately see where each URL is resolved.


Now, we can observe that the common case of explicitly resolving in the 
current context is rather verbose. Therefore, I imagine a shorthand 
would be useful. That's where the idea of the '@' operator comes from.



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*/}`.


Mind that the URL is not resolved on _creation_ in Qt5, but rather when 
assigning to a property. We've 

Re: [Development] Feature freeze exception for QTBUG-95587

[Edward Welbourne]

On 2021 Sep 13, at 20:58, Elvis Stansvik 
mailto:elvst...@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.

IIUC, the present work has to do with the fact that things you might not
be thinking of as URLs really are - at least under the QML bonnet - such
as references to assets you ship with your QML application; the images,
textures and so on, that you might think of as "file-names" are
apparently handled as URLs.  After all, relative path resolution and URL
resolution are essentially similar.

Shawn Rutledge (14 September 2021 09:12) replied:
> 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?

If someone has to edit all the same lines, does it really make that big
a difference that the edit is a one-character insert or wrapping a
string literal or url-or-string-valued expression in a function call ?
Particularly given a half-way decent refactoring tool ...

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

I must confess I find those persuasive points.
And Qt makes plenty of other sacrifices of brevity for clarity.

> Yep.  But Qt.anything() is also weird IMO: there’s no reason why the
> object containing this function should be called Qt.

Let me give you a reason - Qt is the implementor of the JS engine.
Specifically, the ECMA 262 spec's section on its *very* limited support
for URI-related functions [0] says (inter alia):

  The ECMAScript language itself does not provide any support for using
  URIs except for functions that encode and decode URIs as described in
  19.2.6.2, 19.2.6.3, 19.2.6.4 and 19.2.6.5

  NOTE Many implementations of ECMAScript provide additional
  functions and methods that manipulate web pages; these functions
  are beyond the scope of this standard.

As Qt's V4 engine is QML's implementation of ECMAScript, the resolver
function is an extension to the standard and should therefore be
accessed by an overtly implementation-specific namespace.

[0] https://tc39.es/ecma262/#sec-uri-handling-functions

> So maybe we need a function with a short name, not in a namespace?

A function without the Qt prefix is implicitly a member of the ES global
object and, as such, a "departure from" ES 262.  Code written apparently
in JavaScript but exercising extensions provided by a particular
implementation *should* make those extensions overt, if only so that
someone trying to reuse that code in real JavaScript knows what they're
going to have to adapt to the differences between implementations.

That said, I do think there might be value to talking to the ES 262
committee about adding resolveURI() to the suite of URI-related
functions that they provide, since it is surely one of the things that
all the "implementations of ECMAScript" do provide, one way or another.
All the same, until ES 262 includes it, please let's *not* add it to the
global object of V4, if only to avoid being stuck with a compatibility
problem when ES 262 does grow such a function.

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

Having syntax incompatible with ECMA 262 is a matter to approach with
great care.  It will seem weird to those coming from JavaScript to write
UIs using QML, which I understand to be A Major Goal of QML.

> Or a function on the string: Image { source: “my
> icon.png”.resolvedUrl() }.

Again, extending the String type's prototype is a "departure from" ES
262 and I would counsel against it.  Anything that's an extension to the
base language *should* be packaged in a way that makes clear that it
*is* an extension specific to QML.

> But I’m just brainstorming without the implementation perspective in
> mind.

and I'm admittedly being rather conservative ;^>

I worked on a web browser for a 

Re: [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 > 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
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Shawn Rutledge]

On 2021 Sep 13, at 20:58, Elvis Stansvik 
mailto:elvst...@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?

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Elvis Stansvik]

Den tors 9 sep. 2021 kl 17:33 skrev Ulf Hermann :
>
> 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@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

To me, the fact that this raises discussion on if this syntax should 
have other applications perhaps already justifies a "no" to your actual 
question: should this be allowed in a bugfix release.


I would think not just a small library tool but an actual language 
change warrants a bit more consideration and should not be introduced in 
a what is supposed to be a bugfix release. This is more than just a 
bugfix, it's a significant feature. Adding those without giving them 
proper consideration seems to be an excellent way to grow ugly warts on 
the language that will be very hard to plaster over later on.


I've already dropped the "Pick-to: 6.2". There was no overwhelming 
interest in having this feature as soon as possible. So, we've lived 
with the problem in 6.0 and 6.1. We can live with it in 6.2. The 
discussion on whether we should claim the "@" symbol for this feature is 
still important, no matter when we introduce it.


cheers,
Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Tor Arne Vestbø]

I agree, this feels like it should have some wider discussion.

Cheers,
tor arne 

> On 13 Sep 2021, at 13:27, André Somers  wrote:
> 
> 
> On 09-09-2021 17:32, Ulf Hermann wrote:
>> 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.
>> 
> To me, the fact that this raises discussion on if this syntax should have 
> other applications perhaps already justifies a "no" to your actual question: 
> should this be allowed in a bugfix release.
> 
> I would think not just a small library tool but an actual language change 
> warrants a bit more consideration and should not be introduced in a what is 
> supposed to be a bugfix release. This is more than just a bugfix, it's a 
> significant feature. Adding those without giving them proper consideration 
> seems to be an excellent way to grow ugly warts on the language that will be 
> very hard to plaster over later on.
> 
> Cheers,
> 
> André
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[André Somers]

On 09-09-2021 17:32, Ulf Hermann wrote:

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.


To me, the fact that this raises discussion on if this syntax should 
have other applications perhaps already justifies a "no" to your actual 
question: should this be allowed in a bugfix release.


I would think not just a small library tool but an actual language 
change warrants a bit more consideration and should not be introduced in 
a what is supposed to be a bugfix release. This is more than just a 
bugfix, it's a significant feature. Adding those without giving them 
proper consideration seems to be an excellent way to grow ugly warts on 
the language that will be very hard to plaster over later on.


Cheers,

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Edward Welbourne]

On 2021 Sep 9, at 17:32, Ulf Hermann  wrote:
>> As Qt.resolvedUrl() is quite a mouthful, there should be a shorthand
>> for it: the '@' operator.

Shawn Rutledge (13 September 2021 08:24) wrote:
> I’m never quite sure to what extent QML is “our” language, or to what
> extent the rule is “just do what Javascript does”, and then we have to
> defer to ECMA standards, and common web-development practices (which I
> don’t know very much about).  But is there any precedent for this “@“
> operator, for what it’s worth?

For reference, the ECMA 262 spec uses @@ internally as a prefix on the
names of some "well-known symbols" [0] and, in its specification of
URI-handling functions, it mentions @ as a reserved character in URIs
(within the string, though, not in the ECMAScript syntax).
So it has no special meaning in ES syntax.

[0] https://tc39.es/ecma262/#sec-well-known-symbols
[1] https://tc39.es/ecma262/#sec-uri-syntax-and-semantics

The only other uses of @ in the spec are to tag the twitter links of the
authors in the preamble.

In python, on the other hand, @ is used to introduce decorators:

  @decor
  def fun(x): return x

is roughly synonymous with

  def fun(x): return x
  fun = decor(fun)

In particular, this is the basis of @property declarations.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

However, if we nail down the meaning of @"string" to "create and
resolve a URL", then we cannot use a plain '@' for much else.


it would be kinda logical for @ applied to a structure to mean resolving
all urls inside it, which would be a clear clash with
https://bugreports.qt.io/browse/QBS-58 (i was once told that this would
be interesting for declaring state machines in quick as well).


The way it's implemented now, it only reacts to types that can easily be 
converted to url. That is strings, QVariant of QUrl, and the JavaScript 
URL object. Furthermore, I've added provisions that allow specific 
semantics for '@' to be specified via a prefix in the future. Plain '@' 
is now a shorthand for 'url@'. So, QBS could define a 'str@' or similar 
to do its array thing, or even give '@' a special meaning for arrays of 
strings (_that_ sounds a bit wasteful, though).


See https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987


the @ is about the only punctuation char that has no syntactical meaning
in js (or at least didn't when i checked last time), so it does seem
perfect for language extensions, and therefore a waste to use for just
a single thing.


With the prefixes we retain the capability for generic extension of the 
language. I would still like to make '@' a shorthand for 'url@' so that 
people actually use it.



specifically for urls, one could do something more extreme to limit the
impact on the "syntax space", e.g., use @, i.e., replace the
quotation chars as well. of course, this may be even more confusing for
tooling that doesn't natively speak the new qml version.


It should not only work for literals, but also for other expressions. 
Therefore, special quotes won't do.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Oswald Buddenhagen]

On Mon, Sep 13, 2021 at 09:56:23AM +0200, Ulf Hermann wrote:

However, if we nail down the meaning of @"string" to "create and
resolve a URL", then we cannot use a plain '@' for much else.


it would be kinda logical for @ applied to a structure to mean resolving
all urls inside it, which would be a clear clash with
https://bugreports.qt.io/browse/QBS-58 (i was once told that this would
be interesting for declaring state machines in quick as well).

the @ is about the only punctuation char that has no syntactical meaning
in js (or at least didn't when i checked last time), so it does seem
perfect for language extensions, and therefore a waste to use for just
a single thing.

specifically for urls, one could do something more extreme to limit the
impact on the "syntax space", e.g., use @, i.e., replace the
quotation chars as well. of course, this may be even more confusing for
tooling that doesn't natively speak the new qml version.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

My first impression is that this looks like nice syntax.  However maybe we 
should discuss a bit how it fits into the language design, since it seems like 
we’re trying to have a cohesive language design nowadays.  I’m never quite sure 
to what extent QML is “our” language, or to what extent the rule is “just do 
what Javascript does”, and then we have to defer to ECMA standards, and common 
web-development practices (which I don’t know very much about).  But is there 
any precedent for this “@“ operator, for what it’s worth?


We've extended the JavaScript syntax in quite a few ways already. We 
have type annotations borrowed from TypeScript, and an "as" keyword with 
our own semantics. Adding additional constructs that don't clash with 
JavaScript is fine.



QML has this peculiarity of doing string conversion when binding to properties 
of specific types, like color: “#123” and point: “5,6” and vector3Prop: 
“5,6,7”.  Personally I prefer languages in which the syntax for type conversion 
is definable and extensible rather than being just a side effect of trying to 
shoehorn a string into some other type; but that’s what we have.  And another 
peculiarity is putting all those constructor functions into the Qt namespace, 
like Qt.rgba(), Qt.point(), Qt.vector3d() etc.  (This is probably even less 
intuitive for JS developers?)  If we were trying to design a language from 
scratch, without the baggage left from Qt 4, we’d probably be able to do better 
with the syntax for both of those, right?  But can we evolve toward something 
better now?


Creation of value value types from JavaScript is indeed still an open 
problem. I don't think we will need an extra operator to fix it, though. 
You should just be able to pass the parameters to a value type 
constructor as a JavaScript array or object. For example:


property point p: [5, 6]
property point p: {x: 5, y: 6}

In order to make this perform, we need some kind of typed JavaScript 
"parameter object" that lives on the stack as far as possible while 
adhering to reference semantics. We want such a thing anyway, for 
compilation to C++. The specifics are not decided, yet. If you have any 
particular ideas, let me know.



So now it seems like you are introducing a prefix operator on that 
string-shoehorning, which could potentially become a multi-purpose feature. It 
causes a bit of bias that this operator is pronounced “at”, so maybe the 
thought is it fits better with the sorts of conversions that imply some sense 
of “place”, either a geometric location or in a virtual space like the space of 
URLs and URIs?


Yes, introducing an entirely new operator for the specific purpose of 
URL conversion and resolution seems rather excessive at first. However, 
URLs are a vital thing in QML, and the automatic string-shoehorning is 
indeed not ideal. In order to make the conversion explicit, you have to 
write Qt.resolvedUrl() today. No one wants to do that in all the places 
where they use URLs. We still should make the conversion explicit, in 
order to avoid all the ambiguity surrounding strings and URLs, as seen 
in the various bugs. Instead of an operator, we could introduce a new 
function in the global object, e.g. qsUrl(). However, this potentially 
clashes with other names and is not that much nicer than 
Qt.resolvedUrl(). Also, it doesn't express "resolved" (and I want a 
non-resolving URL constructor, too). The '@' operator is nice in that it 
can be easily thought of as resolving the "place" it points to and it 
doesn't require parentheses.


However, if we nail down the meaning of @"string" to "create and resolve 
a URL", then we cannot use a plain '@' for much else. We might, however, 
add, for example, a @point[32, 34] that would create a point and resolve 
it in some way. The plain '@' would then become a shorthand for @url. 
URL is certainly the most important value type that isn't also a 
JavaScript type. Therefore, the extra short syntax seems adequate to me.


(This brings up the point that I should check for @somevariable to be 
invalid ... there you do need to add parentheses or a space)



We already have some string conversions in place, but if we define “@“ as 
giving that conversion some sort of “alternate” interpretation, in how many 
more contexts does that idea make sense?  Do we need an “alternate” way of 
converting colors, points, rectangles or something like that?  Or could the “@“ 
operator be even more general than that, sometimes being applied to other types 
than strings?  Maybe to convert Euler angles to a quaternion?  Radians to 
degrees?


In the above sense, the '@' operator should only be used for things that 
perform some resolution. I could, for example, envision geometry mapped 
to/from the surrounding element. An object type like QQuickItem might 
define '@' operations for specific value types which would then be valid 
in its scope.



If we use the “@“ operator for this-and-that over time, it would still be best 
if 

Re: [Development] Feature freeze exception for QTBUG-95587

[Shawn Rutledge]

> On 2021 Sep 9, at 17:32, Ulf Hermann  wrote:
> 
> 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.

My first impression is that this looks like nice syntax.  However maybe we 
should discuss a bit how it fits into the language design, since it seems like 
we’re trying to have a cohesive language design nowadays.  I’m never quite sure 
to what extent QML is “our” language, or to what extent the rule is “just do 
what Javascript does”, and then we have to defer to ECMA standards, and common 
web-development practices (which I don’t know very much about).  But is there 
any precedent for this “@“ operator, for what it’s worth?

QML has this peculiarity of doing string conversion when binding to properties 
of specific types, like color: “#123” and point: “5,6” and vector3Prop: 
“5,6,7”.  Personally I prefer languages in which the syntax for type conversion 
is definable and extensible rather than being just a side effect of trying to 
shoehorn a string into some other type; but that’s what we have.  And another 
peculiarity is putting all those constructor functions into the Qt namespace, 
like Qt.rgba(), Qt.point(), Qt.vector3d() etc.  (This is probably even less 
intuitive for JS developers?)  If we were trying to design a language from 
scratch, without the baggage left from Qt 4, we’d probably be able to do better 
with the syntax for both of those, right?  But can we evolve toward something 
better now?

So now it seems like you are introducing a prefix operator on that 
string-shoehorning, which could potentially become a multi-purpose feature. It 
causes a bit of bias that this operator is pronounced “at”, so maybe the 
thought is it fits better with the sorts of conversions that imply some sense 
of “place”, either a geometric location or in a virtual space like the space of 
URLs and URIs?

We already have some string conversions in place, but if we define “@“ as 
giving that conversion some sort of “alternate” interpretation, in how many 
more contexts does that idea make sense?  Do we need an “alternate” way of 
converting colors, points, rectangles or something like that?  Or could the “@“ 
operator be even more general than that, sometimes being applied to other types 
than strings?  Maybe to convert Euler angles to a quaternion?  Radians to 
degrees?

If we use the “@“ operator for this-and-that over time, it would still be best 
if it retains some sort of language-wide cohesive meaning.  On the other hand, 
it seems a waste to introduce a nice single-character operator and only ever 
use it for _one_ purpose; of course that’s fine for a range of minor versions 
if it only does one thing, as long as we know how we can potentially go further 
with it.

Oh I just got another idea… if we had introduced units into QML (which we IMO 
should have), as in being able to specify Rectangle { width: 5mm }, we could 
think of URL resolution as another type of unit conversion; so then I suppose 
it should be some sort of postfix operator rather than prefix, like maybe Image 
{ source: “my icon.png”csd } (if we define “csd” as meaning “component source 
directory”).  Using short words rather than punctuation would leave it more 
open to having several more such conversion operators rather than only one 
“alternate”.  OTOH I think @“my icon.png” looks nicer for this one usecase, 
considered alone.  In C++ we have a counter example with string-conversion 
tokens that are prefixes, as in u”string”.  And the even weirder ones with 
extra stuff on both ends, as in u"qtbase”_qs.

It’s just a question of which approach leads to more cohesion of the QML 
language as a whole, and which way is most intuitive for users (those who have 
mainly prior JS experience, and those who have Qt C++ experience).

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Feature freeze exception for QTBUG-95587

[Ulf Hermann]

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