Add option to use Wayland `get_idle_notification`

[xdnlprs]

On Wayland, Sane Break currently uses get_input_idle_notification when ext_idle_notifier_v1 v2 is available.

For break-reminder behavior, I think there should be an option to use get_idle_notification instead. When watching a video, reading, or otherwise passively using the computer, I still want Sane Break to treat that as computer use and remind me to take breaks. Since get_input_idle_notification ignores idle inhibitors, media playback can be treated as user-idle even though I am still using the screen.

Could Sane Break make this configurable?

[AllanChain]

While this is relatively straightforward for Wayland, Sane Break aims to be cross-platform, so it's not easy to implement. X11, Windows, and macOS do not all have the equivalents.

Maybe we can refine the problem to watching videos specifically and see if detecting playing video is achievable for all platforms.

[xdnlprs]

hi @AllanChain, isn't this an argument for using get_idle_notification by default though? Sane break already does that in all wayland compositors that don't support ext_idle_notifier_v1 v2, for example I think KDE Plasma wayland doesn't and so sane break uses get_idle_notification in it which doesn't pause on videos. Using get_idle_notification only would make the behavior the same on all linux comporitors, and in general, isn't it the better default anyway? I'm not sure how it works on macOS or windows, are you sure there sane break consider time you watch videos without input as a pause?

[AllanChain]

See #27 and links there.

[xdnlprs]

I see thanks, but still I don't fully understand the rationale behind this. I suppose the change is for those who are only worried about RSI? I think that there are people (including myself) who use Sane Break mainly to be reminded of regularly standing up (there are lot of studies that show prolonged sitting is very bad, this is just one I happened to read recently)

I was using KDE and it would work exactly like this, Sane Break would remind me of pauses even while watching videos. I recently moved to Niri wm and I was bummed discovering that Sane Break would go on pause while watching videos there.

[AllanChain]

The problem is that idle inhibitors are not meant to be treated as user interaction. In your case, it's a coincidence that video playbacks use idle inhibitors, and you want to keep the break reminder running while watching video. There are cases, like a coding agent or other software, to use the same idle inhibitors to prevent the system from sleeping to have important work done, and the users typically want the break reminder to treat this scenario as idle.

Moreover, there seems not to be a cross-platform way to reliably detect if there is a video playing in the foreground. (You know some people are using video platforms to play music in the background.) Therefore, it's not easy to implement.

But since Sane Break is open source and you are using Linux, it should be easy for you to do the modification yourself and compile locally to get around this to fit your own needs.

[xdnlprs]

I see, thanks.Maybe there's an argument to be made that those are niche cases and for most users idle inhibitor active is a good indicator that the person is at the computer? The people who are using video players to listen to music you can argue that "they are doing it wrong", and at least in Linux there are ways to inhibit suspend that do not require inhibiting idle. Using idle to achieve it you can also argue is wrong because it's a waste of power and screen life to keep the screen on if you are not looking at it.

[xdnlprs]

For example qBittorrent has a feature that prevents suspend while files are being downloaded. And it does that by preventing suspend at the OS level, it seems on Linux, Windows and macOS, not with an idle inhibitor. This is correct and doing otherwise would not only be a waste but also dangerous because if you are not around you don't want to prevent screen locking. At least at a theoretical level it is fair to argue that idle inhibitor active implies that the user is at the computer.

[AllanChain]

I have checked that there are two kinds of inhibitors on Linux, Windows, and macOS. The first one keeps the display on, and the second prevents the system from sleeping. The first kind is a good indication that the user is actively using the computer.

And therefore I have to change my point. Even though the user is actively using the computer, it does not always mean that they want to take breaks. Watching video is an ambiguous case where some users would like to take breaks while some do not. In the case of video conferences and presentations, almost all users would like to avoid the breaks. Thus, the safe default is actually disabling all breaks when there is an idle inhibitor.

And of course we can allow the users to change this. But the question is, how should we document this option? We should definitely avoid technical terms like "idle inhibitor".

[xdnlprs]

Maybe something along the line "Count passive screen time toward breaks"?

I think it's worth noting that for conferences and presentations you may often not rely on idle inhibitors being ignored, because you are not necessarily idle during them: You may be sharing your screen and doing stuff, tweaking volume, doing something on the side etc. Cases that will make you rely on Meeting Mode anyway. It's also not ideal from the "standing up" reminder point of view: Ideally as soon as the meeting ends you want to be reminded of a pause, maybe an extended one, instead what you get is the reminder being postponed for another full period of work.

Besides this, considering it's a health related app, could I argue that it's the safer default to risk annoying the user with an unwanted break and it's the unsafer one making them miss breaks that would have been needed? From my personal interest adding the option is all I need, I'm just arguing for what is best in general.

[AllanChain]

I should clarify that there are three possible actions when there is an idle inhibitor:

1. Ignore it completely and only honor real user inputs
2. Treat it as user input
3. Pause the reminder

I was referring to the third option as default, which, unfortunately, may be the worst in your opinion. The reason is that, for more than half of the people (I guess), they won't like to be disrupted while watching video, doing presentations, having video conferences, or gaming (interactive movies or strategy games). For the ones who want to "have more control over" their time, I think they can find this option.

[xdnlprs]

I see, but notice that as far as I'm aware in Wayland there is no way to tell if an idle inhibitor is active, you can have an idle notification that respect or not inhibitors, but no notification about active inhibitors. So there are only two options at least in Linux really.

It might be worth considering the user experience for people who are aware of the option when the default is the opposite of what they want. The user who does not like interruption while watching videos install Sane Break perhaps on a new computer. At some point while watching a video the Sane Break reminder starts, this immediately reminds them of the option and toggle it, they are happy.
Analogously the user who does want breaks during videos install Sane Break, they start missing breaks but don't notice. At some point, and it might be a while, they become suspicious, they are reminded of the option and toggle it. They might be unhappy if they missed many breaks.

The same may actually be said about somebody who is not aware of the option. The one who doesn't want breaks will notice very quickly that the app does not work how they want and look for a solution. Who doesn't might need a much longer time for that. This is not just speculation, it took me weeks to realize the behavior had changed after moving from KDE to Niri.

[AllanChain]

It's possible to get inhibitor info from DBus on Linux, but to get the info on Windows, we need Administrator privilege, which is not ideal. I will investigate further about the appropriate approaches.

[AllanChain]

I have created a draft PR at #159, which is purely vibed, and I only did basic code checks. I'm going to review and test it more before merging it. You are welcome to test or review if you are interested.