Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

> On 24 Feb 2020, at 23:29, Marc Mutz  wrote:
> 
> Hi Lars, others,
> 
> On 2020-02-24 12:25, Lars Knoll wrote:
>>> On 21 Feb 2020, at 17:39, Thiago Macieira  wrote:
>>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
 Having a keyword-extension to normal C++ is ugly as sin, to some of
 us. It causes
 fair amounts of "wtf is that?".
>>> That was my reaction when I first saw it, in 1999.
>>> Over 20 years later, I don't bat an eye.
>> After 20 years, my eyes simply ignore any ‘emit’ in the source code.
>> In any case, I do understand why Qt added emit as a keyword 25 years
>> ago. But today, we do have IDEs which should be able to figure out on
>> the fly whether a function call is a signal emission (as they already
>> do for virtual vs non virtual methods). So why don’t we move the over
>> to be a tooling problem? Simply highlight signal emissions differently
>> in the IDE and you don’t need a keyword for it anymore. It’s also
>> safer, as the keyword can be forgotten or applied to the wrong places.
> 
> Please don't make this only about emit. We had clashes with signals in 
> boost.signals, we have suffered clashes with Window's min/max and several X11 
> #defines, we know we should not inflict (non-all-uppercase) macros on the 
> world.

I’m not trying to make this only about emit. But it’s the concrete problem 
we’re facing now, and emit is IMO the one keyword where we simply don’t need a 
replacement because it has no real semantic meaning in C++.
> 
> Qt relies on macros a lot, and while I have not followed the latest Modules 
> development, I'm sure macros pose a problem for a modularized Qt, too.
> 
> So while emit is the latest in the line of macro clashes, it's not the first 
> and it likely won't be the last. So, please, just removing 'emit' because 
> it's easy doesn't solve the problem for `signals` and `slots`.
> 
> Can access specifiers have attributes?
> public [[qt::slots]]:
> 

Why do we need it, if functions can already have attributes?

public:
[[qt::slot]] void mySlot();

protected:
[[qt::signal] void mySignal();

Cheers,
Lars

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

> On 25 Feb 2020, at 20:17, Matthew Woehlke  wrote:
> 
> On 21/02/2020 09.02, Ville Voutilainen wrote:
>> Getting back to macro vs. function.. I think using a function wrapper
>> is fine, considering that signals can't
>> meaningfully return, so the prvalue/xvalue issue doesn't arise.
> 
> AFAIK, signals *can't* return, period. The signal body is written by
> moc, not the developer, and I'm not aware of any way to generate a
> signal method body that involves returning something.

We’re on a tangent here, but signals and slots can have return values, and 
these are passed correctly through the generated signal emission code. It’s not 
recommended as it violates some of the principles signals/slots have been 
designed for, but there are some valid use cases.

The way it works is that in case more than one slot is connected to such a 
signal, the return value of the last slot connected is returned, if nothing is 
connected a default constructed value is returned.

> 
>> Yeah, I'm sure we'll have no trouble finding people who think
>> 
>> qEmit(mah_bucket_callback());
>> 
>> is unacceptably ugly compared to
>> 
>> qEmit mah_bucket_callback();
> 
> Personally, I would vote for:
> 
>  template 
>  QObject::emit(Signal, Args&&...)
> 
> ...which not only avoids an extra set of parentheses, but could actually
> *verify* that what you're trying to emit is really a signal. (It has to
> be a member function, because it needs `this`.)

Sure we could do that, but it (as some of the other proposals) leads to a 
rather ugly syntax without solving any real problem. Signals/slots are a 
success because they are easy to use and just a simple function call on the 
emitting side.

Cheers,
Lars

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Ville Voutilainen]

On Tue, 25 Feb 2020 at 10:19, Ville Voutilainen
 wrote:
> Or perhaps qEmit(this)->my_signal(Args...);
>
> and hide the befriending of qEmit (so that private/protected don't

This doesn't even need friending.

#include 

template 
struct qEmit
{
T* that;
qEmit(T* it) : that(it) {}
T* operator->() {return that;}
};

struct X
{
void sig1() {std::cout << "sig1\n";}
void sig2() {std::cout << "sig2\n";}
void foo() {
qEmit(this)->sig1();
qEmit(this)->sig2();
}
};

int main()
{
X x;
x.foo();
}
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Ville Voutilainen]

On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke  wrote:
> Right, and when I realized that, it got me wondering, how many people
> will need to call that specific function that are *also* using Qt *and*
> will be unwilling to use Q_NO_KEYWORDS to work around the issue?

You're getting back to the reason why renaming osyncstream::emit() was
unconvincing, here. ;)

But the reason why we are talking about this is to search for a
solution where such clashes
don't happen in the future. Yes, we know how to deal with
boost::signals, yes, we know how
to deal with X11 Status clashing with QSettings::Status, but maybe we
shouldn't have to deal
with these clashes that are our own doing because it's us defining the
problematic macros.
(In the X11 case, it's X11, not us.) We could be better-behaving
citizens of the ecosystem,
instead of saying "well we've been bad citizens for a long time,
please just accommodate us,
here's hacks that allow you to circumvent the problems we cause".
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Matthew Woehlke]

On 25/02/2020 14.58, Ville Voutilainen wrote:
> On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>> - Until now, `emit` has rarely been used in code that needs to mix with Qt.
>>
>> - C++20 will have modules.
>>
>> - Modules are theoretically immune to the above issue.
> 
> Module definitions are immune to macros affecting what they export,
> but client code is not
> immune to mixtures of module imports and header includes when the
> latter defines a macro.
> If you import a Std.IOStream module and then include QObject, you
> can't call std::osyncstream::emit().

Right, and when I realized that, it got me wondering, how many people
will need to call that specific function that are *also* using Qt *and*
will be unwilling to use Q_NO_KEYWORDS to work around the issue?

It's not as dire as not being able to use that module *at all*, directly
*or indirectly*¹, in code that also uses Qt. More likely, it will be
boost::signals again, which doesn't seem to have been a catastrophe.

(¹ ...if your other third-party dependencies modularize, or don't use
that method in headers.)

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Ville Voutilainen]

On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke  wrote:
>
> On 24/02/2020 07.34, Edward Welbourne wrote:
> > Mitch Curtis (24 February 2020 13:22)
> >> I don't think anyone has explained what that harm is yet.
> >
> > #define emit
> >
> > causes problems when you import a header that declares
> >
> >   void emit(Type arg);
> >
> > and the compiler sees
> >
> >   void (Type arg);
> >
> > and throws a wobbly.
>
> - Until now, `emit` has rarely been used in code that needs to mix with Qt.
>
> - C++20 will have modules.
>
> - Modules are theoretically immune to the above issue.

Module definitions are immune to macros affecting what they export,
but client code is not
immune to mixtures of module imports and header includes when the
latter defines a macro.
If you import a Std.IOStream module and then include QObject, you
can't call std::osyncstream::emit().

> Where, exactly, is the problem? It seems to me we are making a big deal
> out of something that will *still* only be a problem when mixing Qt
> (with no QT_NO_KEYWORDS) and *certain uses* of .

Correct.

> This doesn't seem appreciably different from the existing situation with
> boost::signals. Ergo, I am confused why we are all acting like the sky
> is falling?

Indeed.

> Maybe we should, at least, take a step back and wait to see if this
> *actually affects many people* before worrying about it?

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Matthew Woehlke]

On 24/02/2020 07.34, Edward Welbourne wrote:
> Mitch Curtis (24 February 2020 13:22)
>> I don't think anyone has explained what that harm is yet.
> 
> #define emit
> 
> causes problems when you import a header that declares
> 
>   void emit(Type arg);
> 
> and the compiler sees
> 
>   void (Type arg);
> 
> and throws a wobbly.

- Until now, `emit` has rarely been used in code that needs to mix with Qt.

- C++20 will have modules.

- Modules are theoretically immune to the above issue.

Where, exactly, is the problem? It seems to me we are making a big deal
out of something that will *still* only be a problem when mixing Qt
(with no QT_NO_KEYWORDS) and *certain uses* of .

This doesn't seem appreciably different from the existing situation with
boost::signals. Ergo, I am confused why we are all acting like the sky
is falling?

Maybe we should, at least, take a step back and wait to see if this
*actually affects many people* before worrying about it?

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Matthew Woehlke]

On 21/02/2020 09.02, Ville Voutilainen wrote:
> Getting back to macro vs. function.. I think using a function wrapper
> is fine, considering that signals can't
> meaningfully return, so the prvalue/xvalue issue doesn't arise.

AFAIK, signals *can't* return, period. The signal body is written by
moc, not the developer, and I'm not aware of any way to generate a
signal method body that involves returning something.

> Yeah, I'm sure we'll have no trouble finding people who think
> 
> qEmit(mah_bucket_callback());
> 
> is unacceptably ugly compared to
> 
> qEmit mah_bucket_callback();

Personally, I would vote for:

  template 
  QObject::emit(Signal, Args&&...)

...which not only avoids an extra set of parentheses, but could actually
*verify* that what you're trying to emit is really a signal. (It has to
be a member function, because it needs `this`.)

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Eike Ziller]

> On 24. Feb 2020, at 13:48, Mitch Curtis  wrote:
> 
>> -Original Message-
>> From: Lars Knoll 
>> Sent: Monday, 24 February 2020 1:40 PM
>> To: Mitch Curtis 
>> Cc: Thiago Macieira ; Qt development mailing
>> list 
>> Subject: Re: [Development] A modest proposal: disable lower-case
>> keywords (emit, foreach, forever, signals, slots) by default
>> 
>>  On 24 Feb 2020, at 13:22, Mitch Curtis >  > wrote:
>> 
>> 
>>  -Original Message-
>>  From: Development >  > On Behalf Of
>>  Lars Knoll
>>  Sent: Monday, 24 February 2020 12:25 PM
>>  To: Thiago Macieira >  >
>>  Cc: Qt development mailing list > project.org  >
>>  Subject: Re: [Development] A modest proposal: disable
>> lower-case
>>  keywords (emit, foreach, forever, signals, slots) by default
>> 
>> 
>> 
>>  On 21 Feb 2020, at 17:39, Thiago Macieira
>> mailto:thiago.macie...@intel.com> >
>> 
>> 
>>  wrote:
>> 
>> 
>> 
>>  On Friday, 21 February 2020 04:59:02 PST Ville
>> Voutilainen wrote:
>> 
>> 
>>  Having a keyword-extension to normal C++ is
>> ugly as sin, to some of
>>  us. It causes fair amounts of "wtf is that?".
>> 
>> 
>> 
>>  That was my reaction when I first saw it, in 1999.
>> 
>>  Over 20 years later, I don't bat an eye.
>> 
>> 
>> 
>>  After 20 years, my eyes simply ignore any ‘emit’ in the source
>> code.
>> 
>>  In any case, I do understand why Qt added emit as a keyword
>> 25 years ago.
>>  But today, we do have IDEs which should be able to figure
>> out on the fly
>>  whether a function call is a signal emission (as they already do
>> for virtual vs
>>  non virtual methods). So why don’t we move the over to be
>> a tooling
>>  problem? Simply highlight signal emissions differently in the
>> IDE and you
>>  don’t need a keyword for it anymore.
>> 
>> 
>> 
>>  That's one way of handling it, but I don't see the harm in keeping it
>> for those who want to use it. I don't think anyone has explained what that
>> harm is yet.
>> 
>> 
>> 
>> It’s redundant. I would prefer to remove things that are redundant and
>> where the information could be provided by other means.
> 
> In that case, I share the same concerns as Andre in that it requires IDEs to 
> have knowledge about Qt. I only use Creator, so it won't bother me, but it 
> will affect others who are e.g. transitioning or are so used to another IDE 
> that they'd never switch. Semi-related to this: Jira still doesn't know about 
> QML as a highlighter syntax, 11 years later. :)
> 
>> 
>> 
>>  It’s also safer, as the keyword can be forgotten or applied to
>> the wrong places.
>> 
>> 
>> 
>>  I don't think I've ever seen this happen, and am curious as to why it's
>> dangerous. It might be misleading, but it couldn't cause harm, just a moment
>> of mild confusion. In terms of harm, I see it as on par with (or probably 
>> even
>> less dangerous than) an out-dated code comment. I think that marking signal
>> emissions aids the reader (and there is certainly *a lot* of Qt code that 
>> could
>> e.g. use more code comments to aid people who have to maintain it).
>> 
>> 
>> 
>> Of course it won’t change the logic. I could sprinkle my source code with 
>> tons
>> of “emit” all over the place and it wouldn’t change it’s meaning ;-)
>> 
>> emit if emit (emit myVar == emit true)
>> mySignal() emit emit emit;
>> 
>> But we could convey the information that this is a signal you’re calling
>> *reliably* through other means. This implies that the keyword is not
>> required.
> 
> This sounds a lot like what Eike said, where the assumption is that because 
> people can misuse it, they will. I don't know why anyone would use it in the 
> wrong context except by accident. I agree that IDE highlighting is better 
> because it's infallible, but like I said, I've never seen the keyword misused.

I wasn’t thinking of malicious misuse. But an “emit” in front of something does 
not make it “obvious” that it _has_ side effects of a signal. Just that someone 
(maybe) commented that it has that (or maybe that emit is some leftover of some 
refactoring).

It is just a comment in the code. It is not more than a regular code comment. I 
still don’t see why we need a fake keyword for it.

finshed(); // emit

has the same semantics, and actually makes it _clear_ to anyone that it is just 
a comment without meaning in C++.
And should be as toolable as “emit finished();”
Actually we have a suggestion for Qt Creator to automatically show an automatic 
comment/annotation “ } // namespace Foo” if the brace closes a namespace. 

[Development] QtWayland future

[Pier Luigi Fiorini]

Hi,

The QtWayland module contains the Wayland platform abstraction and a nice
library to make compositors using Qt and QtQuick.

QtWayland Compositor is being used by LG, Jolla, embedded projects and Liri.

The client part is an integral part of those projects and of course it's
fundamental for using Qt applications on Linux/Wayland.

Unfortunately Johan Helsing is leaving The Qt Company.

He has done an amazing work and I want to thank him.

Johan was basically acting as the maintainer, for quite some time I haven't
heard from Giulio.

I'm afraid that without him the project will quickly become stale, as it
was for quite some time in the post-Nokia era.

There are several things to address for Qt 6.

What are the plans for this module?

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

Re: [Development] Why isn't FocusScope a property on Item?

[Andrew den Exter]

On Mon, 24 Feb 2020 at 7:06 pm, Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

>
>
> So, does anyone know the historical reasoning here, or any good reason
> for not changing FocusScope just a normal property on Item?
>
> I don’t know the reason but if you just change it to a property you are
going to find yourself debugging a lot of crashes and weird state from
parent, children, and focus properties being evaluated before the focus
scope property.  If you were to defer all item focus evaluation to
componentComplete() it might be workable though.

If I really wanted to make it happen I think I’d try and work an attribute
type of concept into the language. A property you can only assign a static
value to and is guaranteed to be initialised before any bindings are
evaluated.

As or reasons for it to be its own type I’ve found the occasional need to
walk the focus hierarchy myself and if the internal focus scope and sub
focus item pointers  were public that would have been a little less
difficult. And logically the sub focus item property only belongs on
FocusItems.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Priority field in Jira

[Joerg Bornemann]

On 2/25/20 10:31, Edward Welbourne wrote:

> How about: because we can always over-ride them if we really disagree;
> and their prioritising of the bug is an opening for discussion of why
> it's so important to them - which, after all, we might have missed.
> 
> I'd rather have a dialog than a privilege,

This is about expertise, not privilege. For reporters, the priority is 
usually muuch higher than for us or even other users of Qt, because 
the priority is assessed from the viewpoint of their project.

Let's say I've written this audio player app and found some quirk in 
QtMultimedia that makes skipping impossible every once in a while. Users 
give one star ratings and complain loudly.
What priority is this bug for me? Well, P0 of course.
For us? Not so much...


Cheers,

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

Re: [Development] Priority field in Jira

[Mitch Curtis]

Will try to make comments inline... had to change email client.

On 25/2/20, 10:31 am, "Edward Welbourne"  wrote:

Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug triaging where a team of two people prioritise
>> all unprioritised bugs. So new reports rarely go more than a few days
>> without having a priority set. We've been doing this for a few years
>> (?) now and it works quite well.

> Someone just reminded me that some devs within the company don't have
> approver rights yet, which is a good point.

(Full disclosure: I was that someone.)

> So I'll revise my question:

> Why do we allow users who are unfamiliar with our conventions about
> priority values to set the priority of a bug report?

How about: because we can always over-ride them if we really disagree;
and their prioritising of the bug is an opening for discussion of why
it's so important to them - which, after all, we might have missed.

I'd rather have a dialog than a privilege,

We do have a means for dialog: the comments, which reporters kinda have to use 
to communicate their thoughts about the priority of the report, regardless of 
whether or not they can change the priority. So at that point it's more of a 
gesture of good will, which I understand, but just seems like extra work for 
everyone when the priority is inevitably restored to the previous value.

I would say a far greater privilege is being able to close a report, and that 
too will result in dialog via the comments section if the reporter is unhappy 
with the resolution.

Eddy.
   

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

Re: [Development] Why isn't FocusScope a property on Item?

[Tor Arne Vestbø]

> On 24 Feb 2020, at 10:03, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Hi,
> 
> Something that I've always wondered about (and hopefully whose reasons have 
> been lost in the Nokia times) is why FocusScope exists a dedicated item, 
> rather than simply being an ordinary property on Item?

A guess would be to promote the “grouping” of items into a focus scope, but you 
could do that with an standalone Item if needed with property you suggest. 
Another reason might have been to distinguish it from the focus property.

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

Re: [Development] Priority field in Jira

[Edward Welbourne]

Mitch Curtis (25 February 2020 10:23) elaborated on what he'd said earlier:
>> For some context and for those who don't know: within the company, we
>> now have weekly bug triaging where a team of two people prioritise
>> all unprioritised bugs. So new reports rarely go more than a few days
>> without having a priority set. We've been doing this for a few years
>> (?) now and it works quite well.

> Someone just reminded me that some devs within the company don't have
> approver rights yet, which is a good point.

(Full disclosure: I was that someone.)

> So I'll revise my question:

> Why do we allow users who are unfamiliar with our conventions about
> priority values to set the priority of a bug report?

How about: because we can always over-ride them if we really disagree;
and their prioritising of the bug is an opening for discussion of why
it's so important to them - which, after all, we might have missed.

I'd rather have a dialog than a privilege,

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

Re: [Development] Priority field in Jira

[Mitch Curtis]

> For some context and for those who don't know: within the company, we
> now have weekly bug triaging where a team of two people prioritise all
> unprioritised bugs. So new reports rarely go more than a few days without
> having a priority set. We've been doing this for a few years (?) now and it
> works quite well.

Someone just reminded me that some devs within the company don't have approver 
rights yet, which is a good point. So I'll revise my question:

Why do we allow users who are unfamiliar with our conventions about priority 
values to set the priority of a bug report?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Priority field in Jira

[Mitch Curtis]

Hi.

I'm curious about what the reasons were for allowing (non-approver) reporters 
of bugs to set the priority field in Jira.

In my experience this often results in priorities being assigned that don't 
follow our conventions [1] on what constitutes a certain priority, but instead 
a priority that reflects how important the bug is to the reporter.

That's not to say that everyone who works on Qt has the same idea about 
priority, as there is always some small variation. However, when a reporter 
changes priority, it's almost always above what most Qt developers would set. 
This doesn't happen too often from the areas of Qt that I get Jira 
notifications for, but I also don't see the point in allowing it in the first 
place (and welcome any small decreases in the amount of Jira notifications), so 
I'm hoping someone can explain.

The only information I've found so far is from this [2] email from 2013:

- Who can prioritize bugs?
   - whoever ask
   - we will create a special group in jira
   - approvers should be in the group by default
  Rationale: We do not have man power and we need help. We do not expect 
anyone to destroy our precious bugs reports or play "ping pong" with a 
priority.

For some context and for those who don't know: within the company, we now have 
weekly bug triaging where a team of two people prioritise all unprioritised 
bugs. So new reports rarely go more than a few days without having a priority 
set. We've been doing this for a few years (?) now and it works quite well.

Cheers.

[1] 
https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
[2] https://lists.qt-project.org/pipermail/development/2013-July/011874.html
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Ville Voutilainen]

On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development
 wrote:
> Qt relies on macros a lot, and while I have not followed the latest
> Modules development, I'm sure macros pose a problem for a modularized
> Qt, too.

Header units can still export macros. Macros don't go into header
units or named modules from
the client, but that doesn't save the situation - if you import
osyncstream and #define emit (via whatever
means), you still can't call osynctream::emit. So for modules, the
clashes are not as likely, but
they aren't completely unavoidable as long as emit is a macro.

> Can access specifiers have attributes?
> public [[qt::slots]]:
> 

That is pretty much exactly how the 'metaclass' (really just
reflection+injection, with the reflection+injection
metaprograms called from the class definition body, because that's
where Q_OBJECT resides)
approach envisions doing slots; there was an idea floated
around that you could write

public:
...
current [[qt::slots]]:
...
current:

so that 'current' is just 'public', or actually whatever was the
access at that point. Then 'slots/Q_SLOTS'
can expand into 'current [[qt::slots]]:' and the meta-transformation
can generate the code moc would generate
today.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Determining what versions of imports a QML module provides

[Ulf Hermann]

> That was my first thought (before looking at the qmldir files) as well, but 
> it doesn't seem to help with the same modules that are problematic with the 
> qmldir scanner.
> e.g. QtQuick.tooling:

QtQuick.tooling does not exist. It's only there to have an import 
statement in the *.qmltypes files.

> I also don't see the version number for the QtQuick import - e.g.
> $ find /usr/lib64/qt5/qml/QtQuick* -name plugins.qmltypes |xargs grep '2\.15'
> only shows some submodules.

Each type has a list of exports that tells you the version at which each 
of its metaobject revisions was introduced. For example:

 Component {
 name: "QQuickAnimatedSprite"
 defaultProperty: "data"
 prototype: "QQuickItem"
 exports: [
 "QtQuick/AnimatedSprite 2.0",
 "QtQuick/AnimatedSprite 2.1",
 "QtQuick/AnimatedSprite 2.11",
 "QtQuick/AnimatedSprite 2.12",
 "QtQuick/AnimatedSprite 2.15",
 "QtQuick/AnimatedSprite 2.4",
 "QtQuick/AnimatedSprite 2.7"
 ]
 exportMetaObjectRevisions: [0, 1, 11, 12, 15, 4, 7]
[...]
 }

There is no global version for any specific import. For example, we may 
not change anything between version 7.20 and 7.21 of some module FooBar. 
Once we release the corresponding Qt version, you can still do "import 
FooBar 7.21". It will have the same effect as "import FooBar 7.20". The 
maximum version mentioned in the FooBar's plugins.qmltypes file will 
then be 7.20.

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

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Ville Voutilainen]

On Mon, 24 Feb 2020 at 17:17, Allan Sandfeld Jensen  wrote:

> Yeah you would need something like qEmit(_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(_signal, Args...));

Or perhaps qEmit(this)->my_signal(Args...);

and hide the befriending of qEmit (so that private/protected don't
thwart this) inside
Q_OBJECT.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development