You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: