Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Aleix Pol Gonzalez]

> On Nov. 18, 2015, 8:22 a.m., Martin Gräßlin wrote:
> > src/plugins/osx/macpoller.cpp, lines 222-227
> > <https://git.reviewboard.kde.org/r/126078/diff/6/?file=417217#file417217line222>
> >
> >     seriously? You care about idle timeouts below 5 msec? This is a framework to tell the application whether the user doesn't use input devices. I don't know how fast you type, but I'm relatively certain that it takes more than 5 msec to move my finger from one key to another. What exactly is that you want to detect here? An event after each key press, maybe even between a key press and a key release? Because that's probably already more about 5 msec.
> 
> René J.V. Bertin wrote:
>     The timer is used only for the detection of idle timeouts (so *absence* of user input), and the precision with which it fires determines the accuracy with which those events can be timed. This is currently inaccessible anyway, but I don't believe in doing things half-bakedly. One might question whether it makes sense to allow the framework to work at high precision (I more or less agree that remains to be seen). But I don't think it makes sense to do that and then leave the QTimer in a mode where the requested precision cannot be met.
> 
> Martin Gräßlin wrote:
>     To get this quite clear: you care about a precision of below 5 msec, this is a third of the time it takes at least till the next frame is rendered. If you are lucky you get the result of a key press or mouse move represented on screen after 16 msec, more likely it's more. And you care about a wrong timer precision below 5 msec. Sorry that's ridiculous. Please don't include such non-sense code. You make that code more difficult to all other developers to maintain. This code has cost if it's included.

It's not a matter of doing things "right" or "wrong". It's a matter of priorities.

KIdleTime is a framework for figuring out whether the system is idle. I don't consider 5ms not using a system as it's being idling.


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126078/#review88509
-----------------------------------------------------------


On Nov. 17, 2015, 10:13 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126078/
> -----------------------------------------------------------
> 
> (Updated Nov. 17, 2015, 10:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Dario Freddi.
> 
> 
> 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
> -----
> 
>   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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151118/a772fddc/attachment-0001.html>