On Wednesday, 30 August 2017 17:17:32 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > It makes QTimer possible. > > That sounds quite important to me :-) > > I guess so :) I still don't get what purpose calling QObject::timerEvent() > has if the method itself does nothing. Gives me something to ponder.
Again, that's what makes QTimer possible. void QTimer::timerEvent(QTimerEvent *e) { if (e->timerId() == id) { if (single) stop(); emit timeout(QPrivateSignal()); } } > > function, because it would break the existing code. And we can't make it a > > single shot because it would be even worse: it would silently would > > equally > > break existing code that expects the timer to repeat itself. This code is > > You're making me doubt. If some class inheriting QObject provides its own > QFoo:timerEvent() as I understand it should, QObject::timerEvent() isn't > called, right? Is there code that makes that call explicitly? This is the same as any event override in Qt, which is basically the same as any virtual function override in C++. The overriding function gets to decide whether it needs to call the base implementation for something. QObject::timerEvent does nothing, but other QObject::xxxEvent functions might, ditto for QWidget::xxxEvent(). > > And how would we even achieve this? The only way I can think of is to make > > those functions private (a Qt 6 change) and add the whitelisted classes as > > friends. > > What's to stop you (in some future Qt major version) from moving the timer > features to a dedicated QObjectTimer class, forcing code that relies on the > feature to inherit that class in addition to QObject? Source compatibility. Which is why it's unlikely we'll do it. That said, it's not a horrible idea to move this out of QObject. We don't have an equivalent watchSocket() function that registers socket notifiers -- we make people use QSocketNotifier instead. > > Ok, so you found by git bisect (or similar) action. I was hoping you had > > some interesting way of debugging that the problem is timers constantly > > firing. I > Sadly, no. A boring way: > > QCocoaMenu::timerEvent(...) > { > qInfo() << $somethingSnarky; > > > I did try monitoring the process with Instruments but that failed to attach. But how did you find out it was a timer? And that it was a timer in QCocoaMenu? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development