On 2015-10-29 14:56, Sergio Martins wrote:
> On Wednesday, June 10, 2015 01:55:01 PM Matthew Woehlke wrote:
>> relating to the overloaded signals/slots problem in general:
>>
>> template
>> auto qOverload(R (T::*m)(Args...)) -> decltype(m)
>> { return m; }
>>
>> connect(&process, qOverload(
On Wednesday, June 10, 2015 01:55:01 PM Matthew Woehlke wrote:
> On 2015-06-10 10:20, Koehne Kai wrote:
> > Hi,
> >
> > I'm currently converting a codebase from old-style connects to new-style
> > ones. Thanks to Qt Creator's refactoring support this is actually quite
> > easy ... it gets ugly tho
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [...]
> So I recommend we begin the shift now in 5.6 and deprecate the old
> methods, to be removed in 6.0.
>
> As for the implementation, please connect one signal to the other, so we
> don't need to dupli
On 16/06/2015 6:49 pm, Koehne Kai wrote:
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=theqtcompany.com@qt-
>> [...]
>> If you ask my opinion, 'errorOccurred' sounds like a sensible name.
>
> I concur that errorOccurred() is the most sensible choice.
+1
--
Lorn 'ljp
On Tue, Jun 16, 2015 at 4:50 AM, Sze Howe Koh wrote:
>
> On 16 June 2015 at 19:28, Kurt Pattyn wrote:
> > Well,
> >
> > you can also think of “on” + , like in: onWindowClosed,
> > onMouseClicked, onBytesReceived, …
> > In the same analogy, you could have onErrorOccurred.
> >
> > Seems very intui
On 16 June 2015 at 19:28, Kurt Pattyn wrote:
> Well,
>
> you can also think of “on” + , like in: onWindowClosed,
> onMouseClicked, onBytesReceived, …
> In the same analogy, you could have onErrorOccurred.
>
> Seems very intuitive to me.
>
> It depends if you want to react to a state or to the eve
Well,
you can also think of “on” + , like in: onWindowClosed, onMouseClicked,
onBytesReceived, …
In the same analogy, you could have onErrorOccurred.
Seems very intuitive to me.
It depends if you want to react to a state or to the event causing that state.
Cheers,
Kurt
> On 11 Jun 2015, at 2
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [...]
> If you ask my opinion, 'errorOccurred' sounds like a sensible name.
I concur that errorOccurred() is the most sensible choice. It also matches the
wording in the existing documentation ('error occ
t: Re: [Development] Avoid overloading of 'error'
Should we re-target the discussion to the problem at hand?
The problem is that error is overloaded and that is annoying when connecting
to it. Renaming it would be one way to solve the problem. (e.g: adding a
second signal that is emit
Should we re-target the discussion to the problem at hand?
The problem is that error is overloaded and that is annoying when connecting
to it. Renaming it would be one way to solve the problem. (e.g: adding a
second signal that is emitted at the same time and possibly deprecate the old
one)
Non
ubject: Re: [Development] Avoid overloading of 'error'
On Sunday 14 June 2015 15:35:37 Lorn Potter wrote:
> On 14/06/2015 1:01 pm, Alan Alpert wrote:
> > On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter
wrote:
> >> On 11/06/2015 12:36 am, Samuel Gaist wrote:
> >>
On Sunday 14 June 2015 15:35:37 Lorn Potter wrote:
> On 14/06/2015 1:01 pm, Alan Alpert wrote:
> > On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter
wrote:
> >> On 11/06/2015 12:36 am, Samuel Gaist wrote:
> >>> failed doesn't always mean there was an error with a direct relation.
> >>
> >> I was goi
On 14/06/2015 1:01 pm, Alan Alpert wrote:
> On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter wrote:
>> On 11/06/2015 12:36 am, Samuel Gaist wrote:
>>
>>
>>>
>>> failed doesn't always mean there was an error with a direct relation.
>>
>> I was going to say this, but you beat me to it.
>> Also, "errore
On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter wrote:
> On 11/06/2015 12:36 am, Samuel Gaist wrote:
>
>
>>
>> failed doesn't always mean there was an error with a direct relation.
>
> I was going to say this, but you beat me to it.
> Also, "errored" is just wrong, "error" is also past tense.
I con
On 11/06/2015 12:36 am, Samuel Gaist wrote:
>
> failed doesn't always mean there was an error with a direct relation.
I was going to say this, but you beat me to it.
Also, "errored" is just wrong, "error" is also past tense.
--
Lorn 'ljp' Potter
Software Engineer, llornkcor technologies / Jo
elopment@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'
On Thursday 11 June 2015 07:29:51 Smith Martin wrote:
> onError is immediately understood by all sentient beings in the universe.
So, apparently either Germans are not sentient or from outside this
universe. Mi
Hi,
Perhaps my German is rusty, but I find "on error" translates well to German
with bei/beim: "Beim Auftreten eines Fehlers...".
Simon
Original Message
From: Konrad Rosenbaum
Sent: Saturday, June 13, 2015 12:54
To: development@qt-project.org
Subject: Re: [Development]
On Thursday 11 June 2015 07:29:51 Smith Martin wrote:
> onError is immediately understood by all sentient beings in the universe.
So, apparently either Germans are not sentient or from outside this
universe. Might explain a lot about me...
At the very least I disagree with your use of "immediate
On Thu, Jun 11, 2015 at 7:11 AM, Hausmann Simon
wrote:
> Hi,
>
> I agree about the inconsistency in tense, that is a good argument against
> error(),
> although it is similarly unfortunate that the inconsistency in tense is more
> widespread than
> assumed.
>
> I'm not sure onErred or onErrored
ent@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'
On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
wrote:
> Hi,
>
> I think renaming the getter to lastError is nice! I however do like error as
> signal name and it looks good in qml as onError:...
Thiago Macieira schreef op 10-6-2015 om 18:42:
> On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
>> Hi,
>>
>> I think renaming the getter to lastError is nice! I however do like error as
>> signal name and it looks good in qml as onError:...
> "onError" screams of Basic to me...
> ON
-project.org
Subject: Re: [Development] Avoid overloading of 'error'
On 06/10/2015 06:42 PM, Thiago Macieira wrote:
> On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
>> Hi,
>>
>> I think renaming the getter to lastError is nice! I however do like error as
>> si
On 06/10/2015 06:42 PM, Thiago Macieira wrote:
> On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
>> Hi,
>>
>> I think renaming the getter to lastError is nice! I however do like error as
>> signal name and it looks good in qml as onError:...
>
> "onError" screams of Basic to me...
>
On 11 June 2015 at 00:59, Alan Alpert <4163654...@gmail.com> wrote:
> On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
> wrote:
>> Hi,
>>
>> I think renaming the getter to lastError is nice! I however do like error as
>> signal name and it looks good in qml as onError:...
>
> I disagree that it lo
On 2015-06-10 10:20, Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite easy
> ... it gets ugly though when either the signal or slot method name is
> overloaded, and you
On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
wrote:
> Hi,
>
> I think renaming the getter to lastError is nice! I however do like error as
> signal name and it looks good in qml as onError:...
I disagree that it looks good in QML as onError, almost all other
signal handlers are past tense so
On Wednesday 10 June 2015 15:14:07 Hausmann Simon wrote:
> Hi,
>
> I think renaming the getter to lastError is nice! I however do like error as
> signal name and it looks good in qml as onError:...
"onError" screams of Basic to me...
ON ERROR GO SUB foo
or worse
ON ERROR RESUME
I
Hi,
I think renaming the getter to lastError is nice! I however do like error as
signal name and it looks good in qml as onError:...
Simon
Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 16:35
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading
On 10 juin 2015, at 16:20, Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite easy
> ... it gets ugly though when either the signal or slot method name is
> overloaded,
On Wednesday 10 June 2015 14:20:51 Koehne Kai wrote:
> Hi,
>
> I'm currently converting a codebase from old-style connects to new-style
> ones. Thanks to Qt Creator's refactoring support this is actually quite
> easy ... it gets ugly though when either the signal or slot method name is
> overloade
Hi,
I'm currently converting a codebase from old-style connects to new-style ones.
Thanks to Qt Creator's refactoring support this is actually quite easy ... it
gets ugly though when either the signal or slot method name is overloaded, and
you have to write nice code like
connect(&proc
31 matches
Mail list logo
