Krzysztof kuhy Rudnicki
e8f0ecaae1
Sixth batch of the 250-line sweep. All six gate sources named for this batch are now under cap, plus _gate_layout_probe.py, which this batch's import rewiring pulled into the changeset (over-cap count 38 -> 31). _gatelock_ui.py 477 -> 174 (palette/leaf-helper hub) _gate_layout_probe.py 346 -> 196 _gatelock_groups.py 308 -> 137 _gatelock_calendar_ui 295 -> 77 _gatelock_calendar.py 286 -> 210 _gatelock.py 263 -> 238 _gatelock_mealflow.py 259 -> 207 New siblings: _gatelock_fields (input widgets), _gatelock_layout (assembly), _gatelock_widgetgroups (per-widget mirroring), _gatelock_calendar_types (bundles/palette), _gatelock_calendar_widgets (History builders), _gatelock_dashboard and _gatelock_budgetedit (mixins), _gatelock_lockfile (the stdlib-only flock), _gate_focus_probe and _gate_measurement. The load-bearing part is the test seam, not the line counts. `_gate_fixtures._GATE_TK_MODULES` patches `tk` on a hand-listed tuple, and that list fails OPEN: a widget builder split into a new sibling that nobody adds to it builds *real* Tk widgets against fake parents. Neither existing detector sees that -- check_patch_targets.py only validates paths that still resolve, and the ~8s runtime only catches network calls. It bit twice during this split (real StringVars from make_calendar_vars returned MagicMocks instead of the asserted text), so test_gate_tk_modules.py now asserts the invariant directly: every module binding `tk` is in the patch set or named in _NO_WIDGETS with a reason. It caught a pre-existing gap too -- _gatelock_support was never in the set. Same fail-open shape drove two other choices: `escape_tab_trap` is a call-time indirection so the keyboard test's patch of `_escape_text_tab_trap` still bites, and the flock pair moved with its conftest patch target updated in the same edit (that one fails closed). build_layout is imported from _gatelock_layout directly rather than re-exported lazily, which avoids both a cycle and an import-outside-toplevel suppression. Verified: 703 Python tests / 100% branch coverage, the 5 layout-fits tests under xvfb, 555 Flutter tests (unchanged), flutter analyze clean, check_patch_targets 0, `sync` 0 (403 entries), pre-commit clean, and `gate --demo` renders both tabs with live dashboard data. ~/.local/share/diet_guard byte-identical across the batch (gate timer paused, restored after). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RA9ynjqXPnexRQnR5oAuCC |
||
|---|---|---|
| .. | ||
| .agents/skills | ||
| android | ||
| assets/icon | ||
| bin | ||
| desktop | ||
| lib | ||
| test | ||
| web | ||
| .gitignore | ||
| .metadata | ||
| analysis_options.yaml | ||
| install_arch.sh | ||
| pubspec.lock | ||
| pubspec.yaml | ||
| README.md | ||
| run.sh | ||
| skills-lock.json | ||
diet_guard_app
Companion app for diet_guard: log meals on the phone, and on the Linux
desktop, sharing one food log through GitHub-backed sync.
Two targets, and only two
| Target | What it is |
|---|---|
| Android | a normal Flutter app (flutter build apk) |
| Linux desktop | the Flutter web build, served by a local wrapper and shown in a Chrome --app window |
There is no linux/ directory. Flutter's GTK embedder manages ~20fps at
3840x2160 -- measured on a stock flutter create counter app, so it is the
toolkit rather than this code -- where the same Dart rendered by Chrome
sustains ~144fps (~/todo/docs/desktop-performance-findings.md). Running
flutter create --platforms linux here would silently restore the slow path.
Commands
flutter test # the app's suite
flutter analyze
bash run.sh # build the web bundle and launch the desktop app
bash install_arch.sh # build + install the pacman package and .desktop entry
flutter build apk --release # the phone build
adb install -r build/app/outputs/flutter-apk/app-release.apk
Never adb uninstall or pm clear this package: both wipe the on-device log.
The desktop wrapper
bin/diet_guard_desktop.dart is the other half of the desktop app, because a
browser cannot touch the filesystem. It:
- serves the built web assets from
build/web(or/opt/diet-guard-app/webonce packaged); - keeps an on-disk copy of every document and photo under
~/.local/share/diet-guard-desktop/, which is what makes a wiped Chrome profile recoverable -- for photos it is the only copy, since they never sync; - holds the GitHub token (
~/.config/diet_guard_app/sync_token, falling back to the PC gate's~/.config/diet_guard/sync_token) and proxiesapi.github.complus the device flow, whose endpoints send no CORS headers and so cannot be called from a page at all.
The port (8732) and the Chrome --user-data-dir must stay fixed.
IndexedDB is keyed by origin and lives inside that profile, so changing either
looks to the app like a device with no history.
Platform seams
dart:io does not fail a web compile; it becomes a stub that throws at
runtime, so the symptom of a missed seam is a blank white window rather than a
build error. Every platform edge is a conditional export -- document_store*,
blob_store*, background_tasks*, notification_backend*, token_vault*,
github_client_factory*, attached_image*. Branch on kIsWeb before any
Platform.is…, which itself throws on web.
What the desktop genuinely loses, by design rather than omission:
- Background reminders. A browser runs nothing once its window is closed,
so the due-slot check runs in-page every 5 minutes while the window is open.
On the PC the real backstop is
diet-guard-gate.timer, which locks the screen. - Camera capture. The browser picker is a file input.
- Photo sharing between devices -- unchanged:
imagePathwas always stripped before push.
Sync identity
Three devices push under diet-guard-sync/devices/: pc (the Python gate),
phone, and desktop. Each must keep its own id -- two devices sharing one
would overwrite each other's pushed log on every tick.