[Feature request]: Movement detection, user is back

[rockrevenchy]

Version

• I'm using version 1.17.2

Existing requests

• I've checked Existing requests

Advanced Preferences

• I've checked Advanced Preferences

What operating system are you using?

Linux

Operating System Version

Ubuntu 24.04 LTS with KDE plasma 6.3.2 (Wayland) (feature request disregards the platform altho)

Problem description

So basically whenever I go on a break the countdown will do as it should but I will more often than not end up taking my time doing whatever business I went on (walking, washroom, preparing coffee, food, whatever) and then when I come back my computer basically assumed I was back and started counting down to the next break.

My current solution, tho a very lousy one, was to simply reset breaks every single time I came back to my computer rather than have it call another break shortly after I sat down.

Possible solution

The idea I was thinking of was to simply have an option to leave the overlay after the break is over and have it detect any movement, once it does, it resumes as it should

(rather than say postpone this break in the mid bottom it would just say something like "move your mouse/ click/ press any key" or something alike to resume after the break would be over)

Alternative solutions

Perhaps it could quietly do the detection after a break, if no movement is detected after the break, the timer would quietly hang.

Additional information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[hovancik]

Hi, have you tried idle time detection? It should detect that you are not away from PC and pause breaks.

Ah, I see you are on Wayland, where it is currently not working : #1261

[rockrevenchy]

oh interesting, sorry I assumed this was like this regardless of platform

[simonwinther]

I’m also very interested in making this happen. Our initial idea was similar but focused more on a super simple version: instead of relying on movement detection (which can be tricky across platforms like Wayland), just have an optional setting where, after the break timer ends, the screen stays on until the user presses any key or clicks to confirm they're back. Only then would it exit the break screen and continue.

[simonwinther]

I would love to implement this if I may?

[simonwinther]

With all provided language support as well.

[hovancik]

This seems to be the same as #1001 (comment), I guess we should keep only one open.

Anyway @simonsejse can you describe how you imagine this would work? I prefer to discuss that before implementation to make sure I would merge such a functionality :) I am also in the midle of big migration to ESM #1599 so not good time to start doing code changes :)

[rockrevenchy]

here's a mockup of how i'd imagine this would look like

I would think it would do the sound it does once the countdown is finished but remain as seen on the picture (or similar)

this option could remain either hidden or somewhere in the configs but probably not on by default

(the background image is because I didnt want to show my desktop mess and I didnt want to change the opacity either lol dont worry about it)

(for reference the keyboard is unicode character 🖮 other characters could do well there too such as 🖰 or 🖳 )

[simonwinther]

That is exactly how @rockrevenchy shows it, yes. I implemented a small working version — not tested thoroughly though.

When enabled, the break screen stays after time runs out until the user presses any key or clicks as @rockrevenchy I love the unicode keyboard for an extra touch.

The following changes I made was the following:

defaultSettings.js

By default it is set to false.

requireKeyPressToContinue: true, // manual resume after microbreak

en.json

"pressAnyKeyOrClickToContinue": "Press any key or click to continue",
"settings": {
  // ...
  "requireKeyPressToContinue": "Require key press to continue",
  // ...
}

preferences.html

Enable disable checkbox in settings.

<div>
  <input type="checkbox"
         value="requireKeyPressToContinue"
         id="requireKeyPressToContinue">
  <label data-i18next="preferences.settings.requireKeyPressToContinue"
         for="requireKeyPressToContinue"></label>
</div>

main.js

Listens for 'break-renderer-waiting-for-keypress' from the renderer and cancels the scheduler’s auto-finish to pause until user interaction.

ipcMain.on('break-renderer-waiting-for-keypress', (event, breakType) => {
  const expectedRef = breakType === 'microbreak' ? 'finishMicrobreak' : 'finishBreak';

  const isActiveWindowRelevant = (breakType === 'microbreak' && microbreakWins && microbreakWins.length > 0) ||
                                (breakType === 'break' && breakWins && breakWins.length > 0);

  if (!isActiveWindowRelevant) {
    log.warn(`Stretchly: Received 'break-renderer-waiting-for-keypress' for ${breakType} but no corresponding windows are active. Ignoring stale message.`);
    return; 
  }

  if (!breakPlanner.scheduler || breakPlanner.scheduler.reference !== expectedRef) {
    log.warn(`Stretchly: Received 'break-renderer-waiting-for-keypress' for active ${breakType}, but scheduler state is unexpected. Scheduler ref: ${breakPlanner.scheduler ? breakPlanner.scheduler.reference : 'null'}. Ignoring cancel.`);
    return;
  }

  log.info(`Stretchly: ${breakType} duration visually ended in renderer, now awaiting interaction. Cancelling main process automatic finish.`);
  breakPlanner.scheduler.cancel(); 
});

microbreaks.js

After the timer ends, this checks requireKeyPressToContinue. If enabled, it hides controls and waits for a key press or mouse click before sending finish-microbreak. Otherwise, it finishes automatically as before.
After the timer ends, this checks requireKeyPressToContinue. If enabled, it hides controls, sends 'break-renderer-waiting-for-keypress' to the main process, which cancels the scheduler's auto finish. Then waits for a key press or mouse click before sending finish-microbreak. Otherwise, it finishes automatically as before.

const intervalId = window.setInterval(() => {
  ...
  if (elapsed < duration) {
    ...
  } else {
    clearInterval(intervalId);

    if (settings.get('requireKeyPressToContinue')) {
      if (progress) progress.style.display = 'none';
      if (progressTime) progressTime.style.display = 'none';
      if (postponeElement) postponeElement.style.display = 'none';
      if (closeElement) closeElement.style.display = 'none';

      if (ideaElement) {
        ideaElement.innerHTML = i18next.t('break.pressAnyKeyOrClickToContinue');
        ideaElement.style.fontSize = '1.5em';
        ideaElement.style.textAlign = 'center';
      }

      ipcRenderer.send('break-renderer-waiting-for-keypress', 'microbreak');

      const onInteraction = () => {
        document.removeEventListener('keydown', onInteraction);
        document.removeEventListener('mousedown', onInteraction);
        ipcRenderer.send('finish-microbreak', true, true);
      };

      document.addEventListener('keydown', onInteraction);
      document.addEventListener('mousedown', onInteraction);
    } else {
      ipcRenderer.send('finish-break', true, true);
    }
  }
  ...
}, 100);

If requireKeyPressToContinue is enabled, the microbreak screen will stay up after the timer ends and only go away once the user presses any key or clicks. This prevents auto-starting the next break cycle before you're actually back.

It’s not visually as polished as what @rockrevenchy showed above, but it works well enough for a functional version

Image 1

Image 2

Image 3

And if you click keyboard or mouse it ends as you see on third picture.

[simonwinther]

The important thing is that the next break counter does not start before you are back at the computer and interacting with it.

[simonwinther]

Any update on this?

[rockrevenchy]

I'll take that as a no lol

[hovancik]

This seems to be the same as #1001 (comment), I guess we should keep only one open.

Anyway @simonsejse can you describe how you imagine this would work? I prefer to discuss that before implementation to make sure I would merge such a functionality :) I am also in the midle of big migration to ESM #1599 so not good time to start doing code changes :)

I am still working on rewrite to ESM

[balajeerc]

Now that the ESM migration (#1599) is in trunk, a gentle request to consider incorporating the suggestion from @rockrevenchy

I suspect there are going to be increasingly more number of people on Wayland where movement detection doesn't work as well. See #1261

Having a 'Click here to resume' button also seems like a portable solution that ought to work nicely across environments.

[hovancik]

Hey, so thinking about this now and I am beggining to think this is a bit different: "Don't stop break unless user says so."

So basically, we should not have countdown of time till end of break, but "yourbreak is going on for X:XX:XX, click here to finish it"