> > Yes, I meant that progress bar. > > I've had that 1s idle timer idea as well, unfortunately after writing this, > > but thank you for confirming that this would indeed work. > > I will give that a try and if I can get RSIBreak to a working state on > > wayland submit a PR for it. > > Excellent, thank you very much. > Please do please reach out if there are any questions with regards to the > wayland side. > > David
So, I implemented it this way (least invasive to RSIBreak): If the user was idle for a second (using a KIdleTime timeout), I start my own idle time counter (counter++ every second). Then I catch the next resume event (next user input) and reset my counter to 0. Now here's some things I found: 1) It works just fine in X. 2) It works with XWayland, but only detects user activity if the user makes an input to an XWayland window. This means RSIBreak will think the user is idle if using a native wayland application. On a KDE Plasma Wayland session, RSIBreak is started as an XWayland application by default. 3) It works okay if RSIBreak is started as a native Wayland application (QT_QPA_PLATFORM=wayland). All input is detected, on native and XWayland windows. But: It takes about 5-10 seconds of me not doing any inputs for the idle timeout to be called, instead of the 1 second timeout I requested. (the resume event is emitted immediately though, it is just the idle timout that is slow) So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland works. Thank you, Dominik
signature.asc
Description: OpenPGP digital signature
