[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-11-19 16:17:51
Message-ID: 1876480.31soUWqclA () patux
[Download RAW message or body]

On Thursday November 19 2015 15:21:10 Dario Freddi wrote:

> * KIdleTime strives to be as lightweight as possible. This is something
> which came from the old approach used in KDE3/4 powermanagement which was
...
> resource (aka: the power manager) to take care of this, but it was deemed
> crazy to bring in such complexity for those applications which might care

That kind of application simply doesn't make sense on operating systems that already \
have their own, built-in power management...

OTOH, I wouldn't be amazed if it is non-trivial to guarantee good and reliable timing \
accuracy on an OS like Linux: that would fit in with the experience I have with its \
use in time-critical applications (where it always required realtime extensions to \
the kernel). But I continue the think that a simple framework like this can very well \
attempt to provide the best accuracy/cost compromise that the host allows, esp. if \
that doesn't mean adding crazy complexity. As it happens, OS X returns the "idle \
time" in *nano* seconds; do not think for a second (pun intended) that it would do \
that if the underlying measurement didn't have that kind of accuracy. I think that \
makes it safe to say that my current implementation indeed provides just short of a \
1ms accuracy, with a CoarseTimer and an adaptive polling interval that spends most of \
the timeout duration waiting for the timer to fire.

It's quite possible that's enough, and that there will never be any reason (demand) \
to export the interval control I drafted. But consider this: KF5 frameworks are young \
(despite the almost crazy progression of the release number, which for me is a \
telltale sign of immaturity). They are also hardly (nor have they been) used beyond \
Linux, and in practice not at all on OS X. Who knows what uses any framework might be \
considered for that wasn't really part of its original mission statement? If that's \
always going to elicit a rejecting attitude, I'll be better off going back to making \
the minimum modifications required to make things work for MacPorts, and only request \
inclusion if it turns out maintaining those changes requires too much continuous \
effort.

As to use over a remote, non-X11 connection: applications should not attempt to \
determine idle time in that case. They shouldn't receive return values that suggest 0 \
idle time, they should receive an error that tells them they're out of bounds. If Qt \
provided a way to raise an error to the user (and force the app to exit) without \
provoking a crash (abort), I'd use that, but I'm not aware of any such facility. As \
it is, the OS X implementation will probably signal the actual idle time of whomever \
is logged in locally ...

R.
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]