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

[Giuseppe D'Angelo via Development]

Il 24/02/20 13:48, Mitch Curtis ha scritto:

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


Not to mention: code review, which doesn't highlight anything at all.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
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

[Marc Mutz via Development]

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.


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]]:


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

Re: [Development] ?==?utf-8?q? Determining what versions of imports a QML module provides

[Bernhard Rosenkraenzer via Development]

Hi,
 
On Monday, February 24, 2020 18:19 CET, Ulf Hermann  wrote: 
 
> > Is there a better way to determine what modules are provided?
> 
> You could scan the plugins.qmltypes files. There you get a detailed 
> listing that tells you what components are available under what imports 
> and versions.

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:

$ find /usr/lib64/qt5/qml -name plugins.qmltypes |xargs grep tooling |grep -vE 
'qmltypes:(//|import )'
$

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.

Am I doing something wrong?

Best regards
bero

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

Hi,

> Is there a better way to determine what modules are provided?

You could scan the plugins.qmltypes files. There you get a detailed 
listing that tells you what components are available under what imports 
and versions.

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

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

[Bernhard Rosenkraenzer via Development]

Hi,
I'm adding a Requires:/Provides: autogenerator for QML modules to rpm (so 
packages containing a qml file will automatically pull in the right library 
dependencies).

I have a more or less working prototype that extracts relevant information from 
qmldir files, but given "module" statements in qmldir don't have version 
information attached to them, there's no way to figure out that e.g. 
qtdeclarative 5.15 provides QtQuick 2.15 (and not any other version number).

Leaving version numbers aside, I also don't find a few submodules (that can be 
imported) by scanning qmldir files -- e.g. QtQuick, QtQuick.tooling, 
QtQuick.Window.

Is there a better way to determine what modules are provided?

Best regards
bero

___
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

[Konstantin Tokarev]

24.02.2020, 18:19, "Allan Sandfeld Jensen" :
>
> Yeah you would need something like qEmit(_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(_signal, Args...));

FWIW, using lambda expression is almost always a better solution that std::bind.

-- 
Regards,
Konstantin

___
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

[Kai Köhne]

Hi,

Since this is arguably as much about taste as it is about technicalities, I 
thought it might be interesting to do a quick poll in the form of a survey:

https://www.1ka.si/a/255723

Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever 
gets most clicks gets implemented in the end. Still, I'm curious ...

Kai

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Monday, February 24, 2020 2:53 PM
> To: Lars Knoll 
> 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 Mon, 24 Feb 2020 at 14:42, Lars Knoll  wrote:
> > 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.
> 
> Was the keyword ever required? Seems like it's just a taste difference from a
> 
> qEmit(my_signal());
> 
> to write
> 
> emit my_signal();
> 
> The first one can be namespaced, and thus its name lookup controlled.
> It also never clashes with a member name.
> Its worse aesthetics aside, if we'd had that since the beginning, we wouldn't 
> be
> talking about the current clashes with std::osyncstream.
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Allan Sandfeld Jensen]

On Monday, 24 February 2020 15:03:41 CET Ville Voutilainen wrote:
> On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen
> 
>  wrote:
> > On Mon, 24 Feb 2020 at 14:42, Lars Knoll  wrote:
> > > 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.> 
> > Was the keyword ever required? Seems like it's just a taste difference
> > from a
> > 
> > qEmit(my_signal());
> > 
> > to write
> > 
> > emit my_signal();
> > 
> > The first one can be namespaced, and thus its name lookup controlled.
> > It also never clashes with a member name.
> > Its worse aesthetics aside, if we'd had that since the beginning, we
> > wouldn't be talking about the current clashes
> > with std::osyncstream.
> 
> Hah, except it of course doesn't work with my_signal that returns void.

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

'Allan


___
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 15:52, Ville Voutilainen
 wrote:
>
> On Mon, 24 Feb 2020 at 14:42, Lars Knoll  wrote:
> > 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.
>
> Was the keyword ever required? Seems like it's just a taste difference from a
>
> qEmit(my_signal());
>
> to write
>
> emit my_signal();
>
> The first one can be namespaced, and thus its name lookup controlled.
> It also never clashes with a member name.
> Its worse aesthetics aside, if we'd had that since the beginning, we
> wouldn't be talking about the current clashes
> with std::osyncstream.

Hah, except it of course doesn't work with my_signal that returns void.
___
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 14:42, Lars Knoll  wrote:
> 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.

Was the keyword ever required? Seems like it's just a taste difference from a

qEmit(my_signal());

to write

emit my_signal();

The first one can be namespaced, and thus its name lookup controlled.
It also never clashes with a member name.
Its worse aesthetics aside, if we'd had that since the beginning, we
wouldn't be talking about the current clashes
with std::osyncstream.
___
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 14:35, Mitch Curtis  wrote:
> > > > > Signals have different semantics than regular functions.
> > > >
> > > > In what way?
> > >
> > > They typically call back into "upper layers", which is worth considering 
> > > on
> > the calling side, e.g. due to the danger of inconsistent state getting 
> > accessed
> > if you don't emit the signal at the end of a function, to name just one 
> > tyical
> > pitfall.
> > > I, for one, definitely want to see whether I am emitting a signal or not.
> >
> > Right; the claims that you can ignore signal emits when looking at a piece 
> > of
> > code or expect that they don't affect the current scope are exactly
> > backwards.
> >
> > A signal emitted yields to a coroutine scheduler that runs arbitrary 
> > callbacks,
> > which in case of direct connections absolutely can affect the current scope.
> >
> > Thanks, Christian - that's the first ever plausible explanation for marking 
> > a
> > signal emission.
>
> Personally I find it a bit concerning that you don't consider readability or 
> maintainability a plausible explanation for annotating code with emit.

I find it rather more concerning that you make such a claim, when in
the quoted bit I do consider readability and maintainability
such plausible explanations. Perhaps that's because I don't consider
vague claims of readability and maintainability plausible,
but I do consider readability and maintainability with an actual
reason plausible, and
typically-calling-up-into-arbitrary-code-that-can-and-does-call-back-to-us
is such a reason.

>Though I can rest easy with the knowledge that you're not the sole authority 
>for what constitutes a plausible explanation, despite how you worded it.

Well, for what constitutes a plausible explanation to me, I actually
am the sole authority.

> I can only assume that that same mindset must also encapsulate all of the 
> developers who never wrote any comments for their code because... it made 
> sense to them and that's all matters.

Did you plan to set that strawman on fire, or are you just playing with it?
___
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

[Mitch Curtis]

> -Original Message-
> From: Edward Welbourne 
> Sent: Monday, 24 February 2020 1:35 PM
> To: Mitch Curtis 
> Cc: Qt development mailing list ; Lars Knoll
> ; Thiago Macieira 
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 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.
> 
>   Eddy.

Sorry, I should have been more specific: I meant any form of emit (e.g. qEmit) 
that doesn't conflict. So far the arguments have been:

- It's ugly.

Purely subjective. Are code comments also ugly?

- It can be misused

I've never seen it happen. In the very few cases where it does, the 
consequences are so insignificant as to not even be worth considering.

- It's redundant

Only when the major/popular IDEs that a significant portion of Qt users use can 
highlight signal emissions. Until then, it's not redundant if it improves 
readability.
___
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

[Mitch Curtis]

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

> Cheers,
> Lars
> 
> 
> 
>   Cheers,
>   Lars
> 
> 
>   ___
>   Development mailing list
>   Development@qt-project.org  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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

On 24 Feb 2020, at 13:22, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

-Original Message-
From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of
Lars Knoll
Sent: Monday, 24 February 2020 12:25 PM
To: Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Cc: Qt development mailing list 
mailto:development@qt-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.

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.

Cheers,
Lars


Cheers,
Lars

___
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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 3:02 PM
> To: Christian Kandeler 
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 15:44, Christian Kandeler 
> wrote:
> >
> > On Fri, 21 Feb 2020 15:00:53 +0200
> > Ville Voutilainen  wrote:
> >
> > > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins 
> wrote:
> > > > > Why do I need to know that it's a signal being emitted? How is
> > > > > that "vital information"? I could just as well invoke any other
> > > > > callback, but I find myself not exactly yearning for being able
> > > > > to write callback somethingHappened();
> > > >
> > > >
> > > > Signals have different semantics than regular functions.
> > >
> > > In what way?
> >
> > They typically call back into "upper layers", which is worth considering on
> the calling side, e.g. due to the danger of inconsistent state getting 
> accessed
> if you don't emit the signal at the end of a function, to name just one tyical
> pitfall.
> > I, for one, definitely want to see whether I am emitting a signal or not.
> 
> Right; the claims that you can ignore signal emits when looking at a piece of
> code or expect that they don't affect the current scope are exactly
> backwards.
> 
> A signal emitted yields to a coroutine scheduler that runs arbitrary 
> callbacks,
> which in case of direct connections absolutely can affect the current scope.
> 
> Thanks, Christian - that's the first ever plausible explanation for marking a
> signal emission.

Personally I find it a bit concerning that you don't consider readability or 
maintainability a plausible explanation for annotating code with emit. Though I 
can rest easy with the knowledge that you're not the sole authority for what 
constitutes a plausible explanation, despite how you worded it.

I can only assume that that same mindset must also encapsulate all of the 
developers who never wrote any comments for their code because... it made sense 
to them and that's all matters.

> 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. We could even have qEmit() return void, to prevent a
> possible return value from being (ab)used.
> 
> 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();
> 
> The big advantage of that ugly version is that it's regular C++ without using
> macros.
> 
> At the risk of riffing on this a tad too far, we could alternatively consider 
> using
> an operator on a global dummy qEmit object, but that runs a risk of getting
> into precedence games.
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Edward Welbourne]

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.

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

[Mitch Curtis]

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

> Cheers,
> Lars
> 
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

On 24 Feb 2020, at 12:30, André Somers 
mailto:an...@familiesomers.nl>> wrote:

Hi Lars,

Sent from my phone, please excuse my brevity

On 24 Feb 2020, at 12:27, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:



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. It’s also safer, as the keyword can be forgotten or applied to 
the wrong places.

You seem to assume everyone used QtCreator as their IDE of choice. That is not 
a reasonable assumption I think.

No, but ‘emit’ as a macro that expands to nothing (and for that matter all 
other proposals such as [[qt::emit]] or qEmit()) is not a great solution 
neither. It can easily be forgotten or placed in the wrong position (and I’ve 
seen both quite a few times).

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

[André Somers]

Hi Lars,

Sent from my phone, please excuse my brevity

> On 24 Feb 2020, at 12:27, 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.

You seem to assume everyone used QtCreator as their IDE of choice. That is not 
a reasonable assumption I think. 

André

> 
> Cheers,
> Lars
> 
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Lars Knoll]

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

Cheers,
Lars

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

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Lars Knoll]

> On 21 Feb 2020, at 18:49, Thiago Macieira  wrote:
> 
> On Friday, 21 February 2020 08:39:57 PST Volker Hilsheimer wrote:
>> I’m fine with that, and as communicated by Jani, deprecations can be done
>> even with feature freeze in effect, with approval from module maintainer
>> (up until Beta1; after that only with Lars’ approval).
> 
> Do note the flip side of the coin: adding a new API to replace the overriding.

Right, it’s a bit more than just deprecating a method. But looking at your 
proposal I’m ok with the change for 5.15, if you can get it done quickly.

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

[Shawn Rutledge]

> On 24 Feb 2020, at 10:54, Ville Voutilainen  
> wrote:
> 
> On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier
>  wrote:
>> 
>> A good inspiration for that feature would be the Just My Code feature of 
>> recent visual studio :
>> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019
> 
> That is indeed what I'm gunning for. :) If our problem is that users
> mistakenly step into moc-generated
> code, let's fix that in our tooling instead of inventing new language 
> keywords.

Users might want to skip all Qt code.  Qt developers mainly want to skip all 
moc-generated code I suppose.

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

[Development] Qt 5.15 API review

[Jani Heikkinen]

Hi,

It seems Qt 5.15 API review is still quite badly ongoing, see 
https://bugreports.qt.io/browse/QTBUG-81853

* qtbase (https://codereview.qt-project.org/c/qt/qtbase/+/289203): started but 
pretty low activity there.
* qtdeclarative 
(https://codereview.qt-project.org/c/qt/qtdeclarative/+/289205): started & +1 
already 
* qtmultimedia (https://codereview.qt-project.org/c/qt/qtmultimedia/+/289206): 
started & +1 already
* qttools (https://codereview.qt-project.org/c/qt/qttools/+/289207): started 
but pretty low activity there.
* qtlocation (https://codereview.qt-project.org/c/qt/qtlocation/+/289208): 
started but pretty low activity there.
* qtconnectivity 
(https://codereview.qt-project.org/c/qt/qtconnectivity/+/289209) : started & +1 
already
* qtwayland (https://codereview.qt-project.org/c/qt/qtwayland/+/289210) : 
started & +1 already
* qt3d (https://codereview.qt-project.org/c/qt/qt3d/+/289211): Not started at 
all
* qtwebengine (https://codereview.qt-project.org/c/qt/qtwebengine/+/289212): 
started
* qtquick3D (https://codereview.qt-project.org/c/qt/qtquick3d/+/289214): started

Please try to do reviews ASAP, thanks!

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

Re: [Development] Patch workflow in qt5 supermodule (provisioning)

[Volker Hilsheimer]

Yes, no change yet. The implementation of the cherry-pick automation is 
happening here

https://codereview.qt-project.org/c/qt/qtqa/+/291376/4

and in the related changes. Good progress, thanks to Daniel and the various 
peeps helping with reviews and feedback! Considering the time it takes to get 
Qt 5.15 to merge into dev by now, I’m really looking forward to it :)


Cheers,
Volker



> On 23 Feb 2020, at 21:45, Liang Qi  wrote:
> 
> Hi,
> 
> I think we haven’t move to “cherry-pick” mode, (dev first, then cherry-pick 
> to other branches) yet.
> 
> So still like before, do it in the lowest needed branch of 5.14/5.15/dev, 
> then cherry-pick to 5.12 if needed.
> 
> —Liang
> 
>> On 20 Feb 2020, at 13:03, Konstantin Tokarev  wrote:
>> 
>> Hello,
>> 
>> In the light of recent changes, should provisioning patches be merged to dev 
>> first now and then cherry-picked, or previous workflow remains?
>> 
>> -- 
>> Regards,
>> Konstantin
>> 
>> ___
>> 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 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 11:23, Jean-Michaël Celerier
 wrote:
>
> A good inspiration for that feature would be the Just My Code feature of 
> recent visual studio :
> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019

That is indeed what I'm gunning for. :) If our problem is that users
mistakenly step into moc-generated
code, let's fix that in our tooling instead of inventing new language keywords.
___
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

[Jean-Michaël Celerier]

A good inspiration for that feature would be the Just My Code feature of
recent visual studio :
https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019

Best,
Jean-Michaël

On Mon, Feb 24, 2020 at 8:51 AM Shawn Rutledge  wrote:

>
> > On 22 Feb 2020, at 12:57, Ville Voutilainen 
> wrote:
> >
> > On Sat, 22 Feb 2020 at 13:07, André Pönitz  wrote:
> >>> Buy a debugger that can skip code that you didn't write.
> >>
> >> The point was that in a such a situation I, as user, would not even
> >> try to step in when the call is marked with 'emit'. This 'emit' in
> >> a line *is* valuable markup, that saves me time.
> >>
> >> That's unrelated to what the debugger would or could do if I did step
> in,
> >> I just don't need to follow that path.
> >>
> >> [And apart from that: There's no need to *buy* such debugger, e.g. gdb's
> >> 'skip' actually works]
> >
> > It occurs to me that, in case Creator doesn't do that already, we could
> make its
> > debugger UI to automatically tell the underlying debugger to skip
> > moc-generated code,
> > as a default.
>
> I’m probably dreaming, but wouldn’t it be cool if it were possible somehow
> to “step into” each handler function that is connected, while skipping over
> the details of how we get there…. At least for direct connections.
>
> ___
> 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] Why isn't FocusScope a property on Item?

[Giuseppe D'Angelo via Development]

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?


Any custom QQuickItem subclass can be a FocusScope, it just needs to set 
a flag on itself. Why is the flag something only toggable from C++, 
rather than being a Q_PROPERTY?



The *entire* implementation of FocusScope is exactly what one may think:


QQuickFocusScope::QQuickFocusScope(QQuickItem *parent)
: QQuickItem(parent)
{
setFlag(ItemIsFocusScope);
}



What's the problem with this? It's just that one needing a focus scope 
in QML needs to introduce a new element in the tree. That is *super* 
annoying: it messes up sizing / anchoring, requires aliasing properties 
from FocusScope's contents, and so on.


So, does anyone know the historical reasoning here, or any good reason 
for not changing FocusScope just a normal property on Item?




(Note: I'm not opening the problem about whether a component/top level 
item in a QML file isn't automatically a focus scope -- that would lead 
to "interesting" complications of the language.)


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
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

[Marc Mutz via Development]

On 2020-02-21 17:31, Thiago Macieira wrote:

On Friday, 21 February 2020 03:21:32 PST Ville Voutilainen wrote:

Yes, and the name change was discussed but rejected.


Do you know why it was such strong against? Was it, "darn it's too 
late" or

was it "we don't care"?


Both. I think the argument that Qt uses 'emit' as a macro would have 
caught with people at design time. Not so on the last day of the last 
meeting before C++20 was to go DIS. That said, it might have even caught 
had it only been `bool basic_syncstream::emit()`, because try_emit() was 
actually deemed better by some influential people, due to the bool 
return type. But the cause was lost when `void 
basic_osyncstream::emit()` entered the game, and so we couldn't keep the 
stem, we'd have to bikeshed a new verb altogether.


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