3 Commits

Include renames

Author	SHA1	Message	Date
tfaour	b15747a604	Add per-widget border option (style, thickness, palette color) ... A Widget-level property (border_style/border_thickness/border_color_index), not a per-type config field, since every widget type can have one -- drawn once centrally in device.py's _render_widgets before compositing, using an exact panel palette color so it never dithers. Styles: solid, dashed, dotted, and a fancy double-line picture-frame-mat look. Configurable from a shared "Border" card in every widget's gear-icon dialog.	2026-07-27 19:51:04 +00:00
tfaour	8b9f636cce	Mark whiteboard as (alpha); add the Phase 5 button-assignment UI ... Whiteboard rendering isn't fully reliable yet -- tag it (alpha) everywhere it's user-facing (widget label, add-widget button, dialog title, Settings' WebDAV section) via one shared WIDGET_LABELS map (moved to common.js so both the Layout canvas and the new Configuration tab section can use it). Button assignments: a new "Button assignments" card on the Configuration tab lets you assign an ordered list of (widget, action) bindings to each physical NEXT/BACK button -- add/remove/reorder, all autosaved. Backed by new GET/PUT /api/frames/{id}/buttons endpoints; PUT replaces a button's whole list in one atomic, fully-validated call rather than separate add/remove/reorder endpoints. Device-side consumption already existed (routers/device.py's _run_button_actions); this is the UI for what was previously only reachable via the default migration mapping.	2026-07-24 17:13:51 -04:00
tfaour	a33a3a71e4	Widget system Phase 4b: per-widget gear-icon config dialogs ... Replaces the Photos/Calendar/Whiteboard tabs with a single Layout page (now the frame's landing route) where each widget gets a gear icon opening a dialog scoped to that specific widget's own settings. This was the missing piece for genuinely independent same-type widgets -- "the Calendar tab" never made sense once a frame could hold more than one calendar widget with different settings. Data layer: FrameCalendar re-keyed from frame_id to widget_id, so each calendar widget has its own independent included-calendars set. The rekey runs as an unconditional post-startup step (like the existing widget backfill), not a numbered migration -- it depends on calendar widgets already existing, which themselves come from that same backfill step, not from schema migration. Registering it as a numbered migration would have run it first during a real upgrade, silently dropping every row; caught by a new test that exercises the raw-SQL upgrade path instead of the fresh-install create_all() shortcut every other migration test takes. API layer: every endpoint that used to assume "the frame's widget of this type" (photo queue/thumbnail/preview, calendar select/color/ tasks/weather, whiteboard source/browse/preview) moved into api_widgets.py under /api/frames/{id}/widgets/{widget_id}/..., with a new require_widget_view/control dependency pair mirroring the existing frame-level ones. Device status (battery/last-seen/firmware) got its own frame-level /status endpoint, split out of the old photo-specific /queue it used to piggyback on -- fixes the status bar going silently blank on any frame without a photo widget. UI layer: each widget type's existing settings markup/JS was ported into a dialog partial + an explicit init/close function pair (the content is now fetched and injected on demand, not loaded at page load time). window.FRAME_API is repointed to the open dialog's widget-scoped API base for its duration and restored on close; a separate window.FRAME_BASE_API stays stable for the always-present header/ status-bar scripts. Caught during manual browser testing: the consolidated config-save endpoint initially expected a JSON body while the copied-over dialog JS posts form-urlencoded data (the old convention) -- fixed to match, with new HTTP-level test coverage that would have caught it immediately.	2026-07-24 14:31:24 -04:00