mirror of
https://github.com/kuhyx/screen-locker.git
synced 2026-11-10 19:07:16 +01:00
Krzysztof kuhy Rudnicki
a8b34befb5
The locker cannot close() to let the app take over: close() also restores VT switching, which would hand the user Ctrl+Alt+F2 and an exit from the very obligation the lock exists to enforce. Only the grab moves; the Tk window stays mapped underneath, so the screen is still covered if the app dies. The watchdog has to be stopped for the duration, and measuring it is what makes that non-negotiable. gatelock's recovery loop re-takes any grab it finds missing every 1000ms -- by design, so that pulling a cable is not an escape -- and holds_grab() is `grab_current() is not None`, which is False once another X client holds it. Verified on a private Xvfb display: a naked release is stolen back within ~1.5s, while stopping the loop first lets the app keep the screen and the locker take it back cleanly afterwards. The same harness confirms the ordering the handshake depends on: while the locker holds the global grab a second X client cannot even finish connecting (4s, no output at all), so there is no window in which the screen is uncovered. It only gets through after the release. Reaching into lock._recovery earns an SLF001 waiver rather than a public pause on LockWindow: gatelock's _recovery.py carries a monotonicity proof that no transition ever decreases the grab, and a public lend_grab() would be exactly that transition. The waiver is documented where the other four SLF001 waivers in this repo already live. start_workout blocks the Tk loop for the whole workout, which is deliberate -- pumping Tk underneath is what would let a tick steal the screen mid-set. The docstring names the cost: a monitor hotplug is not handled until the app exits and grab_input() re-covers every live output. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DfJC1Wu1SEgJ6X49k5Jqtg |
||
|---|---|---|
| .github/workflows | ||
| docs | ||
| prompts | ||
| screen_locker | ||
| scripts | ||
| stronglift_replacement | ||
| .gitignore | ||
| .mcp.json | ||
| .pre-commit-config.yaml | ||
| arm.sh | ||
| CLAUDE.md | ||
| DESIGN_AUDIT_TODO.md | ||
| early-bird-workout-check.timer | ||
| install_autostart.sh | ||
| install_systemd.sh | ||
| install.sh | ||
| pyproject.toml | ||
| README.md | ||
| refactor_claude_todo.md | ||
| remove_autostart.sh | ||
| remove_systemd.sh | ||
| requirements.txt | ||
| run.sh | ||
| todo_finish_dart_250_prompt.md | ||
| todo_fix_pylint_10_prompt.md | ||
| workout-locker.service | ||
| workout-locker.timer | ||
| workout-sync.service | ||
| workout-sync.timer | ||
screen-locker
Tkinter/systemd screen locker with workout tracking, sick-day management, and wake-alarm integration. It enforces a workout cadence by locking the screen until a RunnerUp-verified (or explicitly justified) workout is logged.
MCP server (Claude Code integration)
screen-locker exposes a read-only MCP server (screen_locker._mcp) so
Claude Code and its subagents can query workout compliance and the
lock-decision state through typed tools — without shelling out to the
screen-locker-status CLI or opening the Tk window.
- Read-only tools:
get_status(full status snapshot),get_summary(one-line i3blocks summary +ok/warn/lockstate word),explain_lock(why the screen is / isn't locked right now),get_flags(the individual boolean lock-decision predicates for today). - There are no write/action tools, by design. Nothing here logs a workout or mutates state — workouts are logged only from RunnerUp-verified TCX data, never from a caller's claim. No tool exposes the sync token or any HMAC key.
The mcp SDK is an optional dependency (pip install -e '.[mcp]'), kept out of
the CLI/systemd system-python path. One-time setup of the dedicated venv that
Claude Code spawns:
./scripts/setup_mcp.sh
Registration lives in the checked-in .mcp.json (project scope).
Restart Claude Code in this repo and approve the project MCP-server prompt for it
to load. Verify with claude mcp list.