On Tue, Jun 16, 2015 at 4:50 AM, Sze Howe Koh <[email protected]> wrote: > > On 16 June 2015 at 19:28, Kurt Pattyn <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
