Stopwatch delete confirmation, and pause

Hey! I love the work, but I’ll get right down to it.
I would love a ‘delete confirmation’ message before deleting stopwatch history.
I personally use the stopwatch a lot when I’m working on a project where I have to frequently stop and continue. Right now I try to backup my stopwatch history, however adding a ‘delete confirmation’ message would give a lot more confidence in using this feature so one click does not mean lost tracked time.
For obvious reasons a pause button on the stopwatch would be great as well!
I thought these features were simple enough to warrant an ask. Hopefully I’m right.

The stopwatch is currently pretty rough and does not get as much love as it might need (we have a lot planned for it as in its current state it’s not very useful, but we has prioritized other things instead).

I have not added a confirmation popup, but instead moved it into the “Edit” modal like this.

This should fix the issue of pressing the delete button by mistake.

Once merged this will be available in the next release.

The way we intended the user to start/pause/resume is to instead just stop and then press the “Start new” button. It’s annoying to have to add all those events up yourself, but in the future the idea is that we will summarize all events with the same label so it’s easy to track a label per day, week, month and year yet still provide the ability to dig down and see exactly what time you worked on something.

I agree, moving the delete button in the edit menu solves the issue. Thanks for the quick response! Looking forward to future developments.

1 Like

To add a possible implementation here that wouldn’t necessarily conflict with your idea and Erik’s.

Have a simple “Pause/Resume” button for current running event.

When you click Pause, several things happen:

  1. Current event finishes
  2. New event starts with title “Break”, and tag/data property: “break:True”

When you click Resume, several things happen:

  1. Current event finishes (i.e the break finishes)
  2. New event starts with all properties of the last event (i.e the event before the break)

If the “break” tag/property exists, show “Resume” button for running event, otherwise you show the “Pause button”.

And if any event data properties are modified, you simply check if the event before/after it is a break, and if they are, then you recursively update the next/prev event with same properties(b/c most people usually will do 1-2 breaks, will be very few updates)


This would still enable you to track events with the same label, with the added benefit of breaks which can now also be tracked

I think we want to avoid having a break event because it does not contain any information other than making the kind of state machine that we have today in stopwatch more complicated. I’m not sure what kind of value a break event would give after it’s resumed. Reminds me of how we had an “hibernating” status in the afk watcher before which was reliable and worked well, but it was simply unused so it got removed.

It is possible however to change the UI to make it appear as if the stopwatch has timers which can be paused/resumed rather than reflecting the underlying data structure of one event for each start/stop which is probably a good idea. I will keep that in mind.