On Fri, 21 Feb 2020 at 22:11, André Pönitz wrote:
>
> On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > > 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
On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > 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
On Fri, Feb 21, 2020 at 02:41:35PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote:
>
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability. Can you please explain what that vital
> > > information
On Fri, Feb 21, 2020 at 08:40:23AM +, Alex Blasche wrote:
> > -Original Message- From: Kai Köhne
>
> > Another alternative is to actually use C++ attributes for this:
> >
> > [[qt::emit]] somethingChanged();
>
> I think a fallback to
>
> somethingChanged()
>
> without any annot
On Friday, 21 February 2020 06:02:29 PST NIkolai Marchenko wrote:
> it's definitely neat, but it's nothing that you can't do with pure c++
> though. It's just qt's native implementation of score guard pattern. Tbh I
> didn't even know it existed because I use my own scope guarder class.
The reason
On Friday, 21 February 2020 08:53:33 PST Oswald Buddenhagen wrote:
> On Fri, Feb 21, 2020 at 08:29:54AM -0800, Thiago Macieira wrote:
> >can we deprecate setupChildProcess() in Qt 5.15 and *remove it* in 6.0?
>
> at least, we should. ;)
> but let's bikeshed the name of the callback setter, which n
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
On Fri, Feb 21, 2020 at 08:29:54AM -0800, Thiago Macieira wrote:
can we deprecate setupChildProcess() in Qt 5.15 and *remove it* in 6.0?
at least, we should. ;)
but let's bikeshed the name of the callback setter, which needs to be
added at the same time -
setChildProcess{Modifier,Initializer,
On Friday, 21 February 2020 05:25:13 PST Giuseppe D'Angelo via Development
wrote:
> * Qt 6.x
> ** Introduce opt-in ways to request lowercase keywords:
> -DQT_USE_KEYWORDS, CONFIG+=keywords, whatever. They do nothing.
> ** Default for user projects is still same as today (use lowercase).
> ** User
> On 21 Feb 2020, at 17:29, Thiago Macieira wrote:
>
> On Tuesday, 18 February 2020 15:44:24 PST Thiago Macieira wrote:
>> $ grep -r 'public QProcess'
>> kcoreaddons/src/lib/io/kprocess.h:class KCOREADDONS_EXPORT KProcess : public
>> QProcess
>> khtml/src/java/kjavaprocess.h:class KJavaProcess :
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.
--
Thiago Macieir
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"?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
On Tuesday, 18 February 2020 15:44:24 PST Thiago Macieira wrote:
> $ grep -r 'public QProcess'
> kcoreaddons/src/lib/io/kprocess.h:class KCOREADDONS_EXPORT KProcess : public
> QProcess
> khtml/src/java/kjavaprocess.h:class KJavaProcess : public QProcess //QObject
> kpty/src/kpty.cpp:class UtemptPro
> On 20 Feb 2020, at 16:28, Konstantin Tokarev wrote:
>
> Hello,
>
> Are there any options available for subject? I've tried to use official
> contacts page, but it forces use of corporate email, but my request has
> nothing to do with any commercial development.
>
> --
> Regards,
> Konstant
> On 21 Feb 2020, at 14:26, Giuseppe D'Angelo via Development
> wrote:
>
> Il 21/02/20 13:59, Shawn Rutledge ha scritto:
>> (Some people name every slot function starting with the word “slot” to make
>> clear what it is.)
>
> So, literally any function they write, since _anything_ can be a sl
On 2020-02-21 15:02, NIkolai Marchenko wrote:
it's definitely neat, but it's nothing that you can't do with pure c++
though. It's just qt's native implementation of score guard pattern.
Tbh I didn't even know it existed because I use my own scope guarder
class.
On Fri, Feb 21, 2020 at 4:33 PM
it's definitely neat, but it's nothing that you can't do with pure c++
though. It's just qt's native implementation of score guard pattern. Tbh I
didn't even know it existed because I use my own scope guarder class.
On Fri, Feb 21, 2020 at 4:33 PM Henry Skoglund wrote:
> Hi, just want to thank w
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 coul
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 exact
Il 21/02/20 13:59, Shawn Rutledge ha scritto:
(Some people name every slot function starting with the word “slot” to make
clear what it is.)
So, literally any function they write, since _anything_ can be a slot?
Or any function in a QObject subclass? (Not to mention that functions
are suppos
Il 20/02/20 14:44, Kai Köhne ha scritto:
As a counter proposal that (I hope) would get broader consensus, I suggest to
just do this for 'emit': QTBUG-82379 .
I don't think this is exactly a counter proposal for the plan or the
scheduling posted by Marc, though. We're now bikeshedding about Q
21.02.2020, 16:18, "Ville Voutilainen" :
> 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
>>
Hi, just want to thank whoever worked to implement qScopeGuard (in
5.12), it was a perfect gift from heaven today :-)
I'm writing a LOB app with heavy database munging, and want to show the
user an hourglass cursor while munging/waiting for MS SQLServer.
However my functions have lots of exits
On 2020-02-21 13:00, 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 abl
> -Original Message-
> From: Development On Behalf Of
> Shawn Rutledge
> Sent: Friday, 21 February 2020 1:59 PM
> To: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
>
>
> > On 21
On Fri, Feb 21, 2020 at 12:49:02PM +0100, Julien Cugnière wrote:
For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangerous as a signal.
indeed, the recursivity of the issue utterly destroys the "safety"
argument.
however, i still like a
Il 21/02/20 09:23, Kai Köhne ha scritto:
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
C++ attributes are required since C++11, and since C++17 the compiler is also
required to just ignore one's it doesn't know [1]. Because it is part of th
On Fri, 21 Feb 2020 at 15:00, Ville Voutilainen
wrote:
> > And I'd argue that the emitter shouldn't even know who or how many slots
> > are connected to the signal, might even be zero, it shouldn't matter.
>
> ..and? What does that have to do with whether you do or do you emit?
Mr. Email Client,
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
Il 21/02/20 12:49, Julien Cugnière ha scritto:
Isn't that true of any function call though ? Any function could end
up deleting this, or trigerring code in another thread, or anything.
For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangero
> -Original Message-
> From: Eike Ziller
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots)
> On 21 Feb 2020, at 13:30, Mitch Curtis wrote:
> How can you tell if it's a signal being emitted or just a function call
> without the emit syntax? With the emit syntax before the signal emission,
> it's immediately obvious that it's a signal. Not all signals follow the
> *Changed() naming co
On Fri, 21 Feb 2020 at 14:57, Mitch Curtis wrote:
> > It’s not beter than any code comment that you could also put there, like
> >
> > /*emit*/ something();
> >
> > or
> >
> > something(); // emit
>
> I disagree; I think those are ugly.
Having a keyword-extension to normal C++ is ugly as sin, to
On 2020-02-21 12:41, Ville Voutilainen wrote:
On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote:
> > without any annotation is not what we want. We'd miss vital information
> and reduce readability.
> Can you please explain what that vital information is?
How can you tell if it's a signal being
> -Original Message-
> From: Eike Ziller
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots)
> -Original Message-
> From: Ville Voutilainen
> Sent: Friday, 21 February 2020 1:42 PM
> To: Mitch Curtis
> Cc: Alex Blasche ; 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 13:30, Mitch Curtis wrote:
>
>> -Original Message-
>> From: Development On Behalf Of
>> Ville Voutilainen
>> Sent: Friday, 21 February 2020 12:16 PM
>> To: Alex Blasche
>> Cc: development@qt-project.org
>> Subject: Re: [Development] A modest proposal: disable low
On Fri, 21 Feb 2020 at 14:21, Ville Voutilainen
wrote:
>
> On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen wrote:
> > Hmm.. Or perhaps:
> >
> > #define qEmit(x) x
> > or
> > #define qEmit(x) do { x; } while (false)
> > to handle the syntactic edge cases.
>
> Well, if we're re-entertaining a f
On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote:
> > > without any annotation is not what we want. We'd miss vital information
> > and reduce readability.
> > Can you please explain what that vital information is?
> How can you tell if it's a signal being emitted or just a function call
> witho
On Fri, Feb 21, 2020 at 08:23:51AM +, Kai Koehne wrote:
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
that's a terrible idea, because it's visually noisy (and correspondingly
bothersome to type).
if anything, i'd go for
#define qEmit
_
> -Original Message-
> From: Development On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 12:16 PM
> To: Alex Blasche
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by
On Fri, 21 Feb 2020 at 13:52, Julien Cugnière wrote:
>
> Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development
> a écrit :
> >
> > Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> > >> without any annotation is not what we want. We'd miss vital information
> > >> and reduce readabil
On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen wrote:
> Hmm.. Or perhaps:
>
> #define qEmit(x) x
> or
> #define qEmit(x) do { x; } while (false)
> to handle the syntactic edge cases.
Well, if we're re-entertaining a function-like wrapper, we could just
as well avoid
getting back to the not-s
On Friday, 21 February 2020 12:44:56 CET Allan Sandfeld Jensen wrote:
> On Friday, 21 February 2020 12:28:29 CET Giuseppe D'Angelo via Development
>
> wrote:
> > Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> > >> without any annotation is not what we want. We'd miss vital information
> > >> a
Hi,
Just adding in another vote for introducing a “In Review/Integration” state.
As a disclaimer, I am working in the same team as Eddy.
The reason I see it beneficial is to have better visibility on the progress of
working on a certain task. Eddy already made it clear that while something is
“
Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development
a écrit :
>
> Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> >> without any annotation is not what we want. We'd miss vital information
> >> and reduce readability.
> > Can you please explain what that vital information is?
>
>
On Friday, 21 February 2020 12:28:29 CET Giuseppe D'Angelo via Development
wrote:
> Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> >> without any annotation is not what we want. We'd miss vital information
> >> and reduce readability.>
> > Can you please explain what that vital information is
Il 21/02/20 12:15, Ville Voutilainen ha scritto:
without any annotation is not what we want. We'd miss vital information and
reduce readability.
Can you please explain what that vital information is?
That control is leaving the "local" function, and *anything* can happen
at that point. Inclu
On Fri, 21 Feb 2020 at 10:47, Allan Sandfeld Jensen wrote:
>
> On Sunday, 16 February 2020 19:32:02 CET Thiago Macieira wrote:
> > On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development wrote:
> > > C++20 will contain new classes with emit() member functions
> > > (wg21.link/P0053).
On Fri, 21 Feb 2020 at 10:42, Alex Blasche wrote:
> I think a fallback to
>
> somethingChanged()
>
> without any annotation is not what we want. We'd miss vital information and
> reduce readability.
Can you please explain what that vital information is?
__
On Fri, Feb 21, 2020 at 10:25 AM Kai Köhne wrote:
> Hi,
>
> Another alternative is to actually use C++ attributes for this:
>
> [[qt::emit]] somethingChanged();
>
Nice idea, +1.
___
Development mailing list
Development@qt-project.org
https://lists.qt
Hey,
That's a great idea.
Dan
From: Vad Rulezz
To:
Sent: 2/21/2020 9:52 AM
Subject: Re: [Development] A modest proposal: disable lower-case keywords
(emit, foreach, forever, signals, slots) by default
Hello,
On 2/21/20 11:23 AM, Kai Köhne wrote:
> Another alternative is t
Hello,
On 2/21/20 11:23 AM, Kai Köhne wrote:
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
+1 Good idea.
Vad
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org
On Sunday, 16 February 2020 19:32:02 CET Thiago Macieira wrote:
> On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development wrote:
> > C++20 will contain new classes with emit() member functions
> > (wg21.link/P0053). While that will only pose problems for users that
> > include the new
> -Original Message-
> From: Kai Köhne
> Another alternative is to actually use C++ attributes for this:
>
> [[qt::emit]] somethingChanged();
I think a fallback to
somethingChanged()
without any annotation is not what we want. We'd miss vital information and
reduce readability. Ha
Hi,
Another alternative is to actually use C++ attributes for this:
[[qt::emit]] somethingChanged();
C++ attributes are required since C++11, and since C++17 the compiler is also
required to just ignore one's it doesn't know [1]. Because it is part of the
core language, It is also something
56 matches
Mail list logo
