> On Nov 19, 2015, at 09:44, René J.V. Bertin <[email protected]> wrote: > > On Thursday November 19 2015 09:08:16 Jeremy Huddleston Sequoia wrote: > >> Regarding doing something similar in OS X, I'm not sure if there's something >> that matches exactly what you're looking for. > > That's my impression too > >> A naive approach would be to use dispatch_after() to check the idle time at >> an appropriate time in the future (target_idle_time - current_idle_time). > > That's still polling, so not different from any approach using another kind > of timer, right?
It's slightly better than naive polling because you're scheduling the block to run at the earliest time that you might have a hit. > Is it supposed to be more precise, or more friendly to the power manager > (battery use) than, say, a QTimer? There doesn't appear to be an easy way to > cancel a scheduled dispatch, right? If you want a way to cancel it, you should use a timer source and then cancel the timer. Using a timer source is probably more appropriate than dispatch_after but is less obvious in usage, so I didn't mention it. > The question in this context is how you continue after that initial interval, > if the period you're timing hasn't ended at target_idle_time. How long should > you wait then before you check again; Do the calculation again and wait that long. Eg: Assume you want to know when the system has been idle for 10 minutes, you'll schedule the block to run in (10_minutes - current_idle_time). When the block runs, you check the current idle time. If it's over 10 minutes, great. If it's not, reschedule that block for (10_minutes - current_idle_time). If using dispatch_after, you'd just call dispatch_after with the new "check at" time. If you are using a timer source, you would use dispatch_source_set_timer() to set the next time. If you want the ability to change the timeout, cancel it, etc, you definitely would wan to use a timer source. > I think that's an ill-defined problem. > The only variable there is one can set a watch on is HIDIdleTime. I'm not > even sure how XSync implements its alarm if not with a polling timer (and > probably one for every configured timeout to monitor). > Then again, I am probably thinking too much about this, taking a step back I > don't really see why indeed I'd have to do something smarter than simply > setting a timer at some known future moment in time to see if the idle > condition still applies. > > R.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. X11-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com This email sent to [email protected]
