2 Commits

Author	SHA1	Message	Date
Krzysztof Rudnicki	1702685afd	Make the meal gate usable without a pointer on a 1366x768 screen ... The Log Meal tab did not fit this laptop, and had not for some time. Measured under a real 1366x768 X server: it required 866px inside a 739px content pane with every field EMPTY, and 938px with a day of meals logged. Because the content frame was place()-centred it was sheared at BOTH edges at once -- the "Diet Gate" title and the slot header (which meal you are being asked to log) off the top, the calorie headline and the whole dashboard off the bottom -- with no scrollbar anywhere in the package and nothing to indicate content was missing. This is a hard lock: overrideredirect, a global grab, VT switching disabled. Unreachable content is unrecoverable. Two independent causes, both needed fixing: - Every font size was handed to Tk as *points*. Tk encodes the unit in the SIGN of the size, and _gatelock_typography carried a comment asserting the opposite ("Tk has no separate px/pt distinction"). At ~100 DPI that made every string ~30% oversized. Negative sizes now; the docstring records why. - There was no scroll container. build_layout now uses gatelock's ScrollableSurface, which top-anchors, scrolls by keyboard, and scrolls to follow focus. Font sizes alone were not enough: they take the layout to 702px, still over the 571px pane at 1024x600. Both fixes are load-bearing. The grams/items selector was mouse-only. tk.OptionMenu's Menubutton defaults to takefocus=0, so ::tk::FocusOK rejects it and it never entered the tab ring -- verified by walking the real ring, which ran Entry -> Text -> Listbox -> Button -> TNotebook and skipped it entirely. Switching units rescales the whole entry, so a pointerless user could not correct "250 grams" to "3 items" inside a lock they cannot leave without logging a meal. It is now two Radiobuttons, which are in the ring by default and take both Space and Return -- and which post nothing, unlike a menu, whose grab-stealing is why screen-locker bans OptionMenu on lock surfaces outright. Also: the focus ring was invisible (Tk's default is 1px BLACK on #211D1B) and _build_desc actively inverted it by setting highlightbackground, the UNfocused ring, so the box outlined while idle and went black the moment it took focus. Enter now activates buttons (X11 Tk binds only <space>). Text widgets no longer trap Tab. notebook.enable_traversal() is called, so Ctrl+Tab and Ctrl+PageDown work. wraplength drops 900 -> 640, the line-length cap, which also stops a label forcing a 900px-wide layout onto a 1024px screen. The Flutter app had two controls with no keyboard route at all. Its desktop target is the web build in a Chrome --app window, so a touch gesture is not a fallback there, it is the only interaction: - Deleting a history entry was bound solely to onLongPress. Long-press has no keyboard equivalent whatsoever. It now has a focusable IconButton; the long-press stays as a redundant pointer shortcut. - Calendar day cells were a bare GestureDetector, so navigating to date-filtered history was pointer-only and invisible to a screen reader. Now Semantics(button: true) over an InkWell. Plus: the filter sheet built a TextEditingController inside build() with the caret forced to end-of-text, so every keystroke discarded it and silently undid mid-string Home/End/arrow editing. And nothing capped width, so on the 1366px desktop window prose ran ~180 characters per line (twice the readable limit) and a four-digit kcal field spanned ~1334px. AppWidth adds those caps. Tests: the render check is a failing test, not a script -- ruff runs with --unsafe-fixes, whose T201 fix DELETES print statements, which would silently turn a diagnostic into a no-op. test_gate_layout_fits.py was verified red on the pre-fix code ("content 866 in viewport 768 -> NO SCROLL VIEWPORT -> UNREACHABLE CONTENT") and green after. The Flutter suite gains its first keyboard-reachability assertions; it previously had ~109 tester.tap calls and zero checks that anything was focusable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:21:27 +02:00
Krzysztof kuhy Rudnicki	84bd550331	Migrate diet_guard to gatelock v0.2.0 per-output locking ... The gate is laid out once per live output instead of once on the primary, and claims the screen through an Arbiter at RANK_DIET_GUARD so the wake alarm and the workout locker can both outrank it. Three kinds of state needed three different answers. The display fields already fanned out for free -- GateVars holds root-mastered StringVars bound to labels. The typed-in fields did not: amount, per, meal name and the four macro cells were bare tk.Entry widgets, so N copies would have been N independent forms. They are variable-backed now, which is what makes logging work from whichever screen the user is actually looking at. The description box and the suggestion list cannot be shared at all -- tk.Text and tk.Listbox have no variable -- so those genuinely diverge and reads answer from the copy the user touched. The History tab is per-surface too: its grid, budget field and edit button are driven across every monitor, with the budget likewise variable-backed so the value cannot differ between screens mid-edit. Laying the gate out on the primary monitor only was considered and rejected: not having to hunt for the screen the form landed on is the entire point of per-output locking. Tests: the suite hung rather than failed on first run -- diet_guard patches its own `tk`, but LockWindow builds Toplevels through gatelock's, and real tkinter over a MagicMock root recurses without bound. `_hermetic_gatelock` closes that and redirects the runtime dir so no test can stand a production locker down. Every other test runs single-output, where fan-out is unobservable, so test_gatelock_fanout runs on two; each assertion was checked by cropping the fan-out loops to the first surface and confirming it goes red. _gatelock_ui and _gatelock_calendar were each split in two to stay under the 500-line limit, and GateVars' typed-in fields moved into a nested GateEntryVars rather than raising pylint's attribute cap. 470 tests, 100% branch coverage, pre-commit clean, no lint suppressions.	2026-07-25 16:56:13 +02:00