[Development] Avoid overloading of 'error'

[Alan Alpert]

On Tue, Jun 16, 2015 at 4:50 AM, Sze Howe Koh <szehowe.koh at gmail.com> wrote:
>
> On 16 June 2015 at 19:28, Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
> > Well,
> >
> > you can also think of “on” + <event>, 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.
>
> The QML spec says "on" + <signal>, not <state>:
> http://doc.qt.io/qt-5/qtqml-syntax-signals.html#receiving-signals-with-signal-handlers
>
> You can call connect() on the thing after "on":
> http://doc.qt.io/qt-5/qtqml-syntax-signals.html#connecting-signals-to-methods-and-signals
>
> The thing after "on" is also exposed to C++ as a signal; it can be
> passed to QObject::connect() in the SIGNAL() macro.
>
> So, we need to use signal names (which are past tense verbs).

Yes, these are the same things as the signal names. We don't want to
implement some magical difference for QML which doesn't yet exist.

So if we're migrating (slowly) to errorOccurred() as the standard
signal name (which I still think is more trouble than it's worth) then
classes exposed to QML will migrate (slowly) to onErrorOccurred, and
that's fine. It would be an additional layer of confusion and
implementation to make QML diverge in order to still have onError in
Qt 6.

--
Alan Alpert