-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The idleness fullscreen option can totally disable idle watcher #255
Comments
It says "minimum 1.30", so maybe one minute is too fast? Will test later. |
No, it isn't related to one minute. I suggested 1 minute only for a quick test. Please test and tell me the result! Do you think we'll need a point release for this? If you confirm the issue and also its fix ( |
For whatever reason, if user activity is simulated inside the slot that is connected to `KIdleTime::timeoutReached`, `KIdleTime` won't time out anymore. The patch fixes the issue by using a singleshot timer. Closes #255 NOTE: Simulating user activity is needed in this case because a window may lose its fullscreen state without the user's interaction (as when a video ends).
Can confirm the issue by now. |
Good. And a point release? |
Sure, it's a bug. But we could ship also the idleness thing at this point. |
For whatever reason, if user activity is simulated inside the slot that is connected to `KIdleTime::timeoutReached`, `KIdleTime` won't time out anymore. The patch fixes the issue by using a singleshot timer. Closes #255 NOTE: Simulating user activity is needed in this case because a window may lose its fullscreen state without the user's interaction (as when a video ends).
It's some time I see our PC doesn't go in suspension always when idle. |
Only suspension? |
Strange, looks like so, I switched to "lock screen" and it worked, switched back top suspend and it didn't. |
It's strange, indeed. It shows that the problem isn't in idle watcher. I'll test with my old laptop. If I encounter the problem, I'll open another report because this one was about idle watcher. |
I tested and everything was OK. What I did:
The computer suspended after one minute, as expected. I close this again because what you see is definitely not related to the idle watcher but please open another report if you're sure that you have the latest git on the computer, where you did the test. Please also include every step, even those that may seem unimportant. |
In my 2nd test, I let the video be played for 5 minutes before stopping it and exiting Youtube's fullscreen mode but I didn't close Firefox afterward. Again, the laptop was suspended after one minute. |
In the meantime I tested on the laptop, both on AC and on battery, everything was fine. |
Good. So, your previous test happened on a desktop computer? Unfortunately, my desktop computer is too old and too slow; haven't turned it on for years and can't update anything on it. |
Back on the Desktop PC; restarted session.
You could try to remove the battery for testing? What I found so far;
As said there are many combinations, will repeat and do more later. |
No, the battery is integrated into the case.
OK, but will the message also appear with login if you uncheck it? |
In the end, someone (perhaps I) should read the code line by line and see whether the absence of a battery is treated incorrectly. |
BTW, #261 is about lack of battery. But it's a feature request, not a bug report. For the bug you've probably encountered, please open a separate issue. |
No. I tried to repeat the idleness suspend issue on the old laptop with the battery removed, no success. So giving up this atm, at least I think I know by now which config works always on my desktop PC. |
I don't know if the following problem was there from start or happened after an upgrade because I only recently started to use the idle watcher.
Steps to Reproduce
Then nothing will happen after one, two, three,.. minutes. The idle watcher will be magically disabled — or at least it is here (confirmation would be appreciated).
Solution
It seems that if
KIdleTime::instance()->simulateUserActivity();
is called directly from inside the slot ofKIdleTime::timeoutReached
(as it is called in the code), no timeout will happen anymore.This may be a bug in
KIdleTime
but the fix/workaround is easy: ifKIdleTime::instance()->simulateUserActivity();
is called byQTimer::singleShot()
, the problem will disappear.System Information
The text was updated successfully, but these errors were encountered: