[noelcserepy]

Summary

Each hotkey press brought back a welcome or settings window the user had left open. cx.activate(true) unhides every window the app owns, and a cancelled capture calls cx.hide(), so the window disappeared and then came back on the next press.

 capture
+  close Welcome and SettingsView windows
   cx.activate(true)
   screencapture -> editor

 SettingsView
-  open_settings: on_window_should_close -> re-enable hotkey
+  new: on_release -> re-enable hotkey

remove_window skips on_window_should_close. Without the second change, capturing from the tray while settings records a shortcut would leave the hotkey off. Release runs on every close path.

Welcome still opens only on the first launch. Settings still opens from the tray menu.

Evidence

• Before: the installed v0.1.0, running since launch, still owned the 340x443 welcome window, hidden behind cx.hide(). The next hotkey press unhid it.
  After: private instance launched with the welcome window open (onscreen=1). Pressed the hotkey: welcome onscreen=false while screencapture ran. Pressed Esc, then the hotkey again: the welcome window was gone from the window list.
• Mid-recording close: clicked Capture in Settings → Shortcuts ("Press keys…"), closed the window with the close button, pressed the hotkey: screencapture started.

Merge Danger

Door: two-way

Blast Radius: small

A capture started while settings is open closes settings. Settings saves on every change, so nothing is lost.

[noelcserepy]

Review: findings at 1489a92

Bugs

Summary

The PR closes welcome and settings windows before starting a capture. The new settings close path bypasses cleanup that restores the capture hotkey.

Findings

1. Capture leaves the global shortcut disabled during shortcut recording (major)

File: src/main.rs:121

Scenario: Open Settings → Shortcuts, click a shortcut to record new keys, then choose Capture from the tray menu.

Consequence: Settings closes, but the global capture shortcut remains disabled after capturing or cancelling. The user must restore it through Settings or restart the app.

Evidence: A headless probe ran the actual SettingsView::set_recording method, registered the existing close callback, then executed the new window-removal loop. OS hotkey registration was replaced with an in-memory enabled flag. It printed:

recording: hotkey_enabled=false
after capture close: windows=0, hotkey_enabled=false

GPUI’s remove_window() bypasses on_window_should_close, where open_settings() restores the hotkey. The tray Capture command remains enabled during recording, making this path reachable.

Verified

• Headless GPUI probe: confirmed settings removal leaves hotkey state disabled.
• Merge-base comparison: the capture-triggered removal is new.
• git status --short: clean after deleting the temporary probe.

Not verified

• Native window activation, screen capture and OS hotkey delivery: repository instructions prohibit launching or driving the app.
• CI formatting and Clippy gates: not rerun as instructed. The repository has no tests.

Standards

Items

None.

Spec

Merge danger

Door: two-way. Blast radius: narrow. Changes only welcome and settings window closure when capture starts; reverting restores prior behavior. The body makes no merge danger claim.

Items

None.

verdict: findings

[noelcserepy]

Review: findings at 1489a92

Bugs

Summary

The PR closes welcome and settings windows before starting a capture. The new settings close path bypasses cleanup that restores the capture hotkey.

Findings

1. Capture leaves the global shortcut disabled during shortcut recording (major)

File: src/main.rs:121

Scenario: Open Settings → Shortcuts, click a shortcut to record new keys, then choose Capture from the tray menu.

Consequence: Settings closes, but the global capture shortcut remains disabled after capturing or cancelling. The user must restore it through Settings or restart the app.

Evidence: A headless probe ran the actual SettingsView::set_recording method, registered the existing close callback, then executed the new window-removal loop. OS hotkey registration was replaced with an in-memory enabled flag. It printed:

recording: hotkey_enabled=false
after capture close: windows=0, hotkey_enabled=false

GPUI’s remove_window() bypasses on_window_should_close, where open_settings() restores the hotkey. The tray Capture command remains enabled during recording, making this path reachable.

Verified

• Headless GPUI probe: confirmed settings removal leaves hotkey state disabled.
• Merge-base comparison: the capture-triggered removal is new.
• git status --short: clean after deleting the temporary probe.

Not verified

• Native window activation, screen capture and OS hotkey delivery: repository instructions prohibit launching or driving the app.
• CI formatting and Clippy gates: not rerun as instructed. The repository has no tests.

Standards

Items

None.

Spec

Merge danger

Door: two-way. Blast radius: small. The diff closes welcome and settings windows before capture starts; reverting restores prior behavior without cleanup. This agrees with the body.

Items

None.

verdict: findings

[noelcserepy]

[claude-opus-5-5] RESPONDING ON BEHALF OF NOEL

Real bug, fixed in ed2b219. The hotkey restore moved from on_window_should_close to on_release on SettingsView, so every close path runs it, including remove_window. Checked on a live instance: started recording, closed settings, and the hotkey started a capture.

[noelcserepy]

Review: pass at ed2b219

Bugs

Summary

The PR closes Welcome and Settings when capture starts and restores the capture hotkey when Settings is released. Focused headless probes found no new defects.

Prior rounds

• Resolved: Capture during shortcut recording left the global shortcut disabled. The new release callback restores the hotkey flag after capture removes Settings.

Verified

• Headless GPUI probe using actual SettingsView methods and the capture removal loop, with OS hotkey registration stubbed:

  recording: windows=3, hotkey_enabled=false
  after capture close: windows=1, hotkey_enabled=true
  after reopen and capture close: windows=1, hotkey_enabled=true
  

• Unrelated window remained open; Settings reopened successfully.
• Reviewed merge-base-to-HEAD diff at ed2b219.
• Temporary probe deleted; working tree clean.

Not verified

• Native capture, window activation, close-button behavior and OS hotkey delivery: repository instructions prohibit launching or driving the app.
• CI formatting and Clippy gates were not rerun as instructed. The repository has no tests.

Standards

Items

None.

Spec

Merge danger

Door: two-way. Blast radius: small. The diff closes welcome and settings windows before capture and restores the hotkey when settings is released. Reverting requires no cleanup. This agrees with the body.

Items

None.

verdict: pass