Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Timer republishes the whole UI every 0.2 s during a countdown

Open
#334 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
55/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
macos, swift

Research direction

Start with the countdown tick in StageKit/AppCoordinator.swift around lines 768-779, where timerRunning and timerProgress are assigned on every tick, then follow the forwarding through StageKitController (about line 134) into updateRecordingUI in main.swift. Read the existing TimerTransportTests and run them to see the current emission counts. Done when a frozen clock produces no emissions, a second boundary produces at most two with progress 299/300, Pause and Resume still publish, and the new tests fail on main.

Written by the indexing model from the issue text.

Description

bug

Outcome: a running countdown publishes when the displayed second changes, not about 11 times a second.

Evidence (main edc15df)
  • The countdown ticks every 0.2 s (StageKit/AppCoordinator.swift:768-771).
  • Each tick assigns the published timerRunning and timerProgress unconditionally (:778-779).
  • That forwards through StageKitController (:134) into updateRecordingUI (main.swift:400-402), which rebuilds the status image (:684-695) and lays out and orders the toolbar (CapturePanel.swift:437, 447, 699).
  • Only BreakTimerView reads the progress.
Change
  • Assign timerRunning only when it changes.
  • Base progress on ceil(remaining) and assign it only when it changes.
Acceptance

TimerTransportTests:

  • Frozen clock: no emissions.
  • Second boundary: at most 2 emissions, and progress is 299/300.
  • Pause and Resume still publish.
  • Finish is correct.
  • The test fails on main.
Value before scope
  1. Outcome: less main-thread work while presenting. Evidence: the call chain above.
  2. Simpler route: guard the assignments.
  3. Owner: AppCoordinator.
  4. Complexity: removes work.
  5. Verified by: XCTest.

Grammar: Quality.

Refs #174, Refs #150


Build-ready record from the overnight lead session of 15 Oct 2026, verified against main edc15df by an independent skeptic per item. Implementation follows on a claude/* branch; this issue closes only after native acceptance.

Dominant language
Swift
Stars
0
Forks
1
Avg merge
8h 5m
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ship-Work/workbench

All issues in Ship-Work/workbench

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.