Skip to content
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

"Breaks" progress uninterrupted when the user is active (using input devices) #1570

Open
Chealer opened this issue Feb 22, 2025 · 2 comments

Comments

@Chealer
Copy link

Chealer commented Feb 22, 2025

Stretchly 1.17.2 (under Windows 11) does not really block its host during breaks. Screens still display a bit (by default) more than Stretchly, and keyboards and other input devices are usable. This behavior matches Workrave, and I find it adequate (I even argued it should be less obtrusive in ticket #1561).

Unfortunately, this can allow users to ignore break prompts (at least partially) without even postponing or skipping breaks. Even with the default (large) window size, in a fair share of contexts, the user can continue what he's doing while Stretchly counts the time as a break. This is particularly feasible in a full-height application which has an input field at the bottom, like instant messaging applications such as Google Chat, Facebook Messenger, WhatsApp, Discord, Pidgin, KiwiIRC, Konversation, Element, Cisco Jabber, Rocket.Chat or Microsoft Teams.

This is particularly likely to happen when the break starts as the user is already typing (it is very tempting to finish the sentence/message). Workrave avoids this by stealing focus, which already encourages the user to comply immediately, since focus restores automatically after the break. But the main way Workrave prevents this is by monitoring input devices; any usage of a keyboard or other input device during a break interrupts the break for the next 5(?) seconds.

@senpl
Copy link
Contributor

senpl commented Feb 26, 2025

It should not blocked by default, it should be option. If I just want to pause background talk or similar thing I still should be able to do that. Ideally would be to pause currently playing audio (of course if user wish to do this).

@Chealer
Copy link
Author

Chealer commented Feb 26, 2025

@senpl : I suggest you read this report in English (without automated translation) or try Workrave to understand the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants