[Development] Qbs development

[Иван Комиссаров]

Hello everybody

I would like to raise an issue about Oswald Buddenhagen abusing his maintainer 
rights. He is constantly blocking the merge of the patchset which implements a 
new feature in Qbs [0]. I started working on this almost a year ago and the 
issue was approved for the first time in October 2020 (!). Since then, Oswald 
popped up more and more random topics, demanding answers to all possible 
questions about the overall architecture and blocking the merge. While I highly 
appreciate his input, I don’t think it’s productive to postpone a relatively 
small feature for almost a year based on the assumption that it may not fit in 
the overall architecture. I prefer to move forward in small step, collect 
use-cases from actual users’ needs and see how this feature shows itself.
Also, Oswald mainly reviews the documentation and makes assumptions about the 
code based onion the documentation… I find this approach flawed, since 
documentation does not (and should not) show the user all the complexity of the 
actual implementation. Another annoying part is that Oswald neither does not 
know the Qbs code nor has desire to read and understand parts he’s commenting 
on.
I’ve been tolerating such behaviour for almost a year, but now I am confident 
that we can and should proceed with the current implementation and that Oswald 
is stalling the Qbs development. We’re not moving forward, I cannot fix bugs 
that depend on this feature I cannot implement new features based on this one - 
see the list of issue blocked by the related JIRA task - [1].

Oswald has been doing this in the past [2] - instead of allowing to contribute 
a small fix for a simple bug, Oswald turned the patchset into a lengthy 
discussion about architecture… I haven’t seen any contributions from Christian 
Gagneraud ever since (might be unrelated, though) and the bug is not fixed as 
of today.
I kindly asked Oswald to remove his -2 and allow me to proceed, but he chose to 
ignore my request. I’d like to ask Gerrit Administrators to remove his -2 so I 
can proceed with the development.

Also, some actions might be taken to prevent from happening in the future - if 
technically possible, I’d like to request the revoke of his approver rights on 
the Qbs project as per this part of the Qt Governance Model:
«In extreme circumstances Approver privileges can be revoked by a vote of no 
confidence, proposed by an existing Approver or Maintainer and arranged by the 
Chief Maintainer. Privilege revocation requires a two-thirds majority vote of 
those Approvers and Maintainers who express an opinion.» [3]

Ivan.

[0] https://codereview.qt-project.org/c/qbs/qbs/+/315910 

[1] https://bugreports.qt.io/projects/QBS/issues/QBS-1604
[2] https://codereview.qt-project.org/c/qbs/qbs/+/301461 

[3] https://wiki.qt.io/The_Qt_Governance_Model___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] moc output from non-local tool build

[Thiago Macieira]

On Monday, 13 September 2021 11:21:37 PDT Thiago Macieira wrote:
> Your way is easier on the packagers, though, since the cross-compilations
> are usually not critical content, but the host/native Qt is. But I don't
> think it's the typical scenario for cross-compiling. People usually
> download the sources in order to cross-compile Qt with their device's
> toolchain and they'd like to use the system's Qt to help bootstrap. The
> system's Qt is usually older.

Ah, but for embedded device targets, one usually wants the best possible, so 
depending on your distro's older and crappier moc is not a good idea.

Sounds to me like we should do both, with a 2-year sliding window of 
compatibility. My current changes require no extra effort (they're done 
anyway, will push soon).

Adding the version arguments to the tools requires a bit more effort.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
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] moc output from non-local tool build

[Thiago Macieira]

On Monday, 13 September 2021 09:13:02 PDT Marius Kittler wrote:
> From my GNU/Linux user/distributor perspective it would be great if the host
> moc could be slightly newer than the target Qt libs. So if the distribution
> upgrades the regular Qt package the cross packages (targeting mingw-w64 and
> Android) would still be usable until they're updated as well. I don't
> expect that there would be a big delay. So it would be sufficient if moc
> would be able to generate files which can still be used with the previous
> release of Qt, so moc from Qt 6.2.0 would be able to generate files for Qt
> 6.1.3 libraries.

I was thinking the opposite: that the moc tool could be slightly older. Qt 
already needs to deal with compiled moc content that hasn't been recompiled, 
so the libraries already have backwards-compatibility in one direction. If 
there was a need to have extra compatibility, I thought extending QtCore 
compatibility with moc content that hasn't been regenerated would be the 
logical next step.

Doing your way is possible, but probably requires that moc output #ifdef 
content. Whereas my change would replace:

QT_PLUGIN_METADATA_SECTION
static constexpr unsigned char qt_pluginMetaData_QEglFSIntegrationPlugin[] = {
'Q', 'T', 'M', 'E', 'T', 'A', 'D', 'A', 'T', 'A', ' ', '!',
// metadata version, Qt version, architectural requirements
0, QT_VERSION_MAJOR, QT_VERSION_MINOR, qPluginArchRequirements(),
[...some content..]
};
QT_MOC_EXPORT_PLUGIN(QEglFSIntegrationPlugin, QEglFSIntegrationPlugin)

with
static constexpr unsigned char qt_pluginMetaDataV2_QEglFSIntegrationPlugin[] = 
{
[... same content ...]
};
QT_MOC_EXPORT_PLUGIN_V2(QEglFSIntegrationPlugin, QEglFSIntegrationPlugin, 
qt_pluginMetaDataV2_QEglFSIntegrationPlugin)

Your way is easier on the packagers, though, since the cross-compilations are 
usually not critical content, but the host/native Qt is. But I don't think 
it's the typical scenario for cross-compiling. People usually download the 
sources in order to cross-compile Qt with their device's toolchain and they'd 
like to use the system's Qt to help bootstrap. The system's Qt is usually 
older.

> To me it would make sense adding a CLI flag to moc to specify the target
> version and the CMake build scripts would pass it automatically (instead of
> rejecting the newer moc completely like it is currently implemented).

That works too. It's doable for moc to remember how to emit old code, so a 
version switch would help it. By default, it would simply emit "latest".

> Of course all of this effort would be quite fruitless if other tools like
> uic would not support the same as well. Likely those tools are quite
> unproblematic. Maybe only the build system needs to be changed to accept
> newer host versions.

True, but those tools change much less frequently and integrate much less 
tightly than moc.

If we decide to go this route, we should add the version flag right now, even 
if we don't use it. That way, if a new version wants to use it, an older build 
will have passed it.

> Alternatively it would also be interesting to provide a "tools only" build
> to be able to provide host tools of the required version. However, I
> actually like not having to build tools over and over again for every
> target so a "compatible" moc sounds much better to me.

That's technically just a qtbase build. moc is the only tool that needs to 
bootstrap in a host build, all the rest link to QtCore.

Which reminds me we can probably shrink the bootstrap lib to bare bones and 
save on compilation time.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

Re: [Development] moc output from non-local tool build

[Marius Kittler]

Am Freitag, 10. September 2021, 16:58:55 CEST schrieb Thiago Macieira:
> Qt 6 supports using the moc from a different build of Qt, to help with the
> bootstrapping issue and also so you don't always run a debug-mode moc in
> your debug builds of Qt.
> 
> Is that moc required to be from the same Qt version as the Qt you're trying
> to build? Or is there a leeway in accepting slightly different builds?
> 
> We haven't yet made changes to the moc output that would make it
> incompatible, but I am thinking of doing that now for plugins and I'd like
> to know if I have to keep compatibility with a slightly older moc. It's not
> a problem, I just want to know if this is required.

From my GNU/Linux user/distributor perspective it would be great if the host 
moc could be slightly newer than the target Qt libs. So if the distribution 
upgrades the regular Qt package the cross packages (targeting mingw-w64 and 
Android) would still be usable until they're updated as well. I don't expect 
that there would be a big delay. So it would be sufficient if moc would be 
able to generate files which can still be used with the previous release of 
Qt, so moc from Qt 6.2.0 would be able to generate files for Qt 6.1.3 
libraries.

To me it would make sense adding a CLI flag to moc to specify the target 
version and the CMake build scripts would pass it automatically (instead of 
rejecting the newer moc completely like it is currently implemented).

Of course all of this effort would be quite fruitless if other tools like uic 
would not support the same as well. Likely those tools are quite 
unproblematic. Maybe only the build system needs to be changed to accept newer 
host versions.

Alternatively it would also be interesting to provide a "tools only" build to 
be able to provide host tools of the required version. However, I actually 
like not having to build tools over and over again for every target so a 
"compatible" moc sounds much better to me.


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

Re: [Development] moc output from non-local tool build

[Thiago Macieira]

On Monday, 13 September 2021 00:38:55 PDT Joerg Bornemann wrote:
> For a cross-build, currently, the host Qt needs to have the same version
> as the target Qt. When trying to build, let's say, Qt for Android 6.2.0
> with a host Qt 6.1.2, you're getting an error:
> 
>Could not find a configuration file for package "Qt6CoreTools" that is
>compatible with requested version "6.2.0".
> 
> This is because our find_package calls for the host Qt contain the exact
> version number of the Qt that is being built.

Fair enough, but then the question is whether that's intended or a simple 
accident of how it was implementation.

BTW, is the functionality now working for non-crossing builds? I've been 
trying to use the CMake Ninja multi-config setup, but it's very painful due to 
lots of implementations issues. I'll have to go back to regular single-config 
and I don't want to use the local moc.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
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] 6.2.0 and QTBUG-92733/QTBUG-96359

[Christoph Cullmann (cullmann.io) via Development]

On 2021-09-13 11:19, Volker Hilsheimer wrote:

Hi Christoph,

I just cherry-picked the fix down into 6.2.0, the release team should
be able to stage the fix for the RC.


Great, thanks!

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org
___
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] 6.2.0 and QTBUG-92733/QTBUG-96359

[Volker Hilsheimer]

Hi Christoph,

I just cherry-picked the fix down into 6.2.0, the release team should be able 
to stage the fix for the RC.

Thanks!

Volker


> On 13 Sep 2021, at 11:03, Christoph Cullmann (cullmann.io) via Development 
>  wrote:
> 
> Hi,
> 
> perhaps this is the wrong place to raise this, but could one reconsider
> to have the trivial fix for the more or less duplicated bugs
> 
> https://bugreports.qt.io/browse/QTBUG-96285
> https://bugreports.qt.io/browse/QTBUG-96359
> 
> in Qt 6.2.0?
> 
> Without that fix, more or less all applications that use QProcess will 
> randomly
> fail on Windows. I would consider this rather blocking, but the aimed 6.2.1
> seems to not indicate this. And the fix is minimal.
> 
> Greetings
> Christoph
> 
> -- 
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
> ___
> 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

[Development] 6.2.0 and QTBUG-92733/QTBUG-96359

[Christoph Cullmann (cullmann.io) via Development]

Hi,

perhaps this is the wrong place to raise this, but could one reconsider
to have the trivial fix for the more or less duplicated bugs

https://bugreports.qt.io/browse/QTBUG-96285
https://bugreports.qt.io/browse/QTBUG-96359

in Qt 6.2.0?

Without that fix, more or less all applications that use QProcess will 
randomly
fail on Windows. I would consider this rather blocking, but the aimed 
6.2.1

seems to not indicate this. And the fix is minimal.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org
___
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] moc output from non-local tool build

[Joerg Bornemann]

On 9/10/21 4:58 PM, Thiago Macieira wrote:


Qt 6 supports using the moc from a different build of Qt, to help with the
bootstrapping issue and also so you don't always run a debug-mode moc in your
debug builds of Qt.

Is that moc required to be from the same Qt version as the Qt you're trying to
build? Or is there a leeway in accepting slightly different builds?


For a cross-build, currently, the host Qt needs to have the same version 
as the target Qt. When trying to build, let's say, Qt for Android 6.2.0 
with a host Qt 6.1.2, you're getting an error:


  Could not find a configuration file for package "Qt6CoreTools" that is
  compatible with requested version "6.2.0".

This is because our find_package calls for the host Qt contain the exact 
version number of the Qt that is being built.



Cheers,

Joerg
___
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 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