----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126078/ -----------------------------------------------------------
(Updated Nov. 17, 2015, 10:12 p.m.) Review request for KDE Software on Mac OS X and KDE Frameworks. Changes ------- This revision takes comments from the mailing list into account. Pure end-of-idle detection is done in a way similar to how `WidgetBasedPoller` does it, by detecting global UI events. That part explains the newly introduced ObjC++ file. Like `WidgetBasedPoller`, the new implementation has to resort to a polling approach, and like that example class, the the polling frequency is adaptive. However, the adaptive algorithm: - uses the difference between the current idle time and the next timeout from the timeouts list as the source of the "error" value used to calculate the timer interval - uses <1 gain (difference/2) - relies on a sorted timeouts list, which ensures that the initial "next timeout" is equal to the minimal timeout In addition, using a sorted timeout list means that determination of a timeout hit becomes much simpler, basically `idle >= timeout[i]`. That removes the possibility to signal early, or to reject signalling because a timeout was detected after the acceptance window. I have left the `kidletime_example` run idling for over 3 minutes; as far as I can tell it behaves as expected, and yields a better-than-1ms accuracy (on average timeouts are signalled less than 1ms late). It only shows near the top in a running `top` listing on rare occasions, and then only at a few percents CPU. I have left in the hooks to configure a fixed, higher polling frequency, for now, until I'm convinced that they're indeed not justified given the 1ms resolution imposed by the API. Repository: kidletime Description ------- I noticed that the KIdleTime example doesn't work properly on OS X, and that the plugin for OS X still uses the deprecated Carbon-based algorithm that I already patched for KDE4. This patch is a work-in-progress (hence the qDebugs) update to use IOKit, IORegistry and CoreServices to do idle-time calculation as it should be done, and allow simulated user activity through a "less deprecated" function. Diffs (updated) ----- src/plugins/osx/CMakeLists.txt e1b50b8 src/plugins/osx/macpoller.h ef51ea5 src/plugins/osx/macpoller.cpp ad9c10f src/plugins/osx/macpoller_helper.mm PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126078/diff/ Testing ------- On OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 . The example now works: when I set a QTimer with interval==0, the expected wait for user input (`resumingFromIdle` signal) works. However, I am getting a `stopCatchingIdleEvents` signal which means the application waits forever, without ever getting to compare idle time to the list of timeouts. I haven't been able to figure out where that signal comes from, nor why this doesn't happen on Linux. Surely I'm missing something, but what? Thanks, René J.V. Bertin
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
