search

tom-james-watson / breaktimer-app

Manage periodic breaks. Avoid eye-strain and RSI.
https://breaktimer.app
GNU General Public License v3.0
1.05k stars 79 forks source link

Request: option of background overlay for breaks but not for notification #305

Open wolftune opened 2 days ago

wolftune commented 2 days ago

The best workflow (as the older program WorkRave uses) is for the notification of upcoming breaks to not actually block work. Thus, I can wrap up a task before the break. It's great that breaktimer supports this, but only with the overlay background off.

It's nice to have the overlay during the break.

So, I suggest two settings for the overlay, one for the notification/warning time, one for the break. I would personally set it to only have the overlay during the full break.

Thanks

tom-james-watson commented 2 days ago

Yes this is something that I've been thinking about too. The current countdown too the break is too intrusive and I think makes it more likely that you skip the break. I want to work on a change that makes the countdown way more subtle and, as you say, gives you a chance to wrap up what you're doing before the break starts.

wolftune commented 1 day ago

It can't be too subtle or it's too easy to ignore.

WorkRave does this in a quirky way: it starts with just-obtrusive-enough, and if you move the cursor around the area where the warning is, the warning itself moves to top or bottom of screen in order to get out of the way. If activity is sensed, the warning gets more noisy to get extra attention. As an option, if the activity continues through the end of the warning time, it can count as postponement. In other words, the break actually starts when the warning is active and activity stops.

WorkRave offers options for allowing only a limited number of postponements.

WorkRave is the only thing I've tried that works like that, but https://github.com/AllanChain/sane-break is a new one that seems similar.

All these options have trade-offs, no program has all the features perfect.

In this case, prior to extra optimizing of some perfect idea, just my original suggestion here of two checkboxes for the overlay separate for warning vs break, that would be a step. That would allow input just enough for the user to save or close or take some "okay, just do this and then break" time while still getting the full overlay during the break.

tom-james-watson commented 22 hours ago

Yeah, that more or mess aligns with what I'm thinking.

I would make the countdown window way more subtle, so that you can keep working whilst it's there, but ovvious obvious enough that you can't ignore it. I'd explore a few different ideas for whether it will always start a break after some amount of time or maybe it should always require manual interaction to actually start begin the break. But yes, the key is giving the user more time to prepare for the break to prevent mindless skipping or snoozing.

wolftune commented 22 hours ago

yeah, come to think of it, the ideal would probably have user settings for whether breaks are forced, postponed (warning goes away for a bit, snoozed essentially), and whether there's a button to go ahead with break vs the go-ahead being non-activity…