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. > 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? > Most won't. How do you choose which ones should get the feature? If you're > arguing for a white list, please compile such al ist, including all uses in > KDE code, all applications, etc. No, I'm not. I think I misread some replies as a suggestion the timer feature could maybe be removed. > 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? > 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. >> Indeed, I wondered about that, and then let it pass because the compiler >> will probably optimise it away. > > it won't, because the QBasicTimer object needs to be stored somewhere. If > you're replacing an int m_timerId with QBasicTimer, there's no overhead. But > if you don't store the timer ID, there's an overhead. > > You can't not store the QBasicTimer (pardon the double negative). On its > destruction, it will stop the timer. So if you used it in a regular function > scope, the tiemr would never fire. Erm, I was clearly distracted earlier (note to self: discussing Qt concepts doesn't mix with Dolly Parton 8-) ). I thought I'd seen that QCocoaMenu::timerEvent() did something like int timerId = e->timerId(); if (timerId == m_updateTimer) { //etc } and that the temp. variable was the cause of the overhead you mentioned. Sorry for the noise. R. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development