37 Commits

Include renames

Author	SHA1	Message	Date
tfaour	474b92a282	Add server-side support for a second panel (13.3in Spectra 6 / EE02) and scaffold its firmware target ... Server: Frame.panel_type (new column + migration) is auto-derived from the device's reported board (X-Frame-Board), never user-set -- the panel is a property of the hardware, not a picker in the UI. image_pipeline's packing/render pipeline is parameterized by panel geometry instead of hardcoded 800x480 globals, with the real confirmed 13.3in geometry (1600x1200) registered alongside the original 7.3in panel. Existing 7.3in frames are unaffected (column default + board mapping both resolve to the original panel). Board identifiers are also renamed (devkit/xiao -> devkit_esp32c6/ xiao_esp32c6, plus new "ee02") since the EE02 board also carries a XIAO module -- "xiao" alone stopped disambiguating hardware. The server keeps accepting the legacy bare names indefinitely for already-flashed devices. Firmware: scaffolds a third build target (ee02, ESP32-S3 -- a real chip-target change, not just a same-chip Kconfig variant like xiao) and a new epd13in3e driver component skeleton. The actual panel init/LUT/ refresh register sequence isn't ported from vendor demo code yet (none was available), so that component deliberately fails to compile (#error) rather than risk sending unverified register values to real hardware -- devkit/xiao are unaffected and build identically to before. CI's ee02 build step is continue-on-error for the same reason.	2026-08-04 20:08:22 +00:00
tfaour	1d39e439ff	Drop the last legacy widget-system and shared-token auth scaffolding ... Server: migration 41 drops the pre-widget-system Frame columns (mode/album_id/current_asset_id/queue/calendar_*/whiteboard_*, etc) docs/widgets.md flagged as the deliberately-deferred Phase 6 cleanup, with a raw-SQL backfill safety net for any frame that still somehow lacks a Widget. Also drops legacy_token_enabled and the shared MANAGEMENT_TOKEN fallback it gated in require_device/require_browser -- the per-frame manage_token/device_token flow (and the /m/ page) fully supersede it now; MANAGEMENT_TOKEN's only remaining role is the optional pre-setup claim gate. Confirmed with the maintainer that the deployed frame is already off the shared token before removing the server-side fallback. Firmware: the captive portal's "Access Token" field and its NVS/ build_url plumbing only ever mattered for pointing new firmware at an old pre-multi-frame server -- gone along with the server-side fallback it fed. Version bump to publish the change.	2026-08-04 18:33:29 +00:00
tfaour	2868087467	Add a per-widget text-size picker for calendar/tasks legibility ... Calendar and tasks pack the most body text at the smallest default sizes, so those two gear-icon dialogs get a "Text size" card (Normal/ Large/X-Large) alongside the existing Border card -- a new Widget-level font_scale column with its own POST .../font-scale endpoint, same Widget-property-not-config-field shape as border_style. Threaded through every classic (calendar_render.py) and modern (html_render.py/ calendar_html_render.py) size calc via one shared panel_style. scaled_size() so row heights/max_rows already derived from font size re-fit around the bigger text automatically.	2026-08-02 03:23:27 +00:00
tfaour	5f4f8f2ea7	Add a curated theme system for "modern" style widgets, inspired by Tesserae ... Frame.theme (7 presets in app/theme_tokens.py) drives font family, corner radius, drop shadow, and an accent hue for every modern-style widget's header/accent region. Rich accent colors (not just the 6 flat panel inks) are approximated via denser Bayer stippling confined to just that region (html_render.ordered_dither_regions), so icon/text content elsewhere stays exactly as crisp as it is today -- verified directly against real Chromium renders, both in unit tests and via run-server. "classic" is a byte-identical no-visual-change default: weather's header keeps its original fixed blue gradient, tasks/calendar keep their flat THEME_* ink. Themes are purely stylistic -- battery's charge-level color, calendar/ tasks' per-owner event chips, and text's own per-widget font choice are never touched.	2026-07-31 10:34:28 +00:00
tfaour	e331f5e5a1	Roll out "modern" HTML/CSS render style to every widget except photos ... Extends weather's experimental Chromium+Jinja2 render style to battery, text, tasks, static image, whiteboard, and calendar (all four view modes -- agenda/today_tomorrow/week/month), and gives the photos widget its own genuinely independent palette + dithering strength. Photos: Frame.photo_palette_rgb/photo_dither_strength (mirroring the existing palette_rgb/dither_strength), with a second "Photos configuration" card in Advanced Configuration. widgets/photos.py's render() quantizes itself against these before returning -- no render_panel changes needed, since photos is the only widget that genuinely needs a different reference palette and can carry that itself, the same way modern-style widgets already self-dither via ordered_dither. Battery/text/tasks/static image/whiteboard: same render_style pattern weather established (render_style column, html_render.py build function, Jinja2 template, dialog toggle). Static image/whiteboard get their first-ever visual chrome (a rounded-corner shadowed card, shared framed_image.html.jinja) since classic draws them with zero frame at all. Fixed the same "preview endpoint bypasses render_style" bug weather originally shipped with, for tasks/static/whiteboard/ calendar's preview endpoints. Calendar: own module (app/calendar_html_render.py, mirroring calendar_render.py's separation from the simpler widgets) covering all four view modes, not just agenda -- reuses calendar_render's own private helpers so event colors/times/weather/month-grid math match classic exactly. Found and fixed two real cross-day layout bugs along the way: a per-day header height that varied based on whether that specific day had a weather entry (misaligning where every other day's event rows started across the week/month grid), and regular-weight small text being fragile under Bayer ordered dithering (out-of-month day numbers degraded into unrecognizable speckle) -- fixed by using bold everywhere and de-emphasizing via size instead of weight/gray, since gray text has the same dithering fragility this project's PIL renderers already avoid for exactly this reason. Migrations 32-38 (Frame's two new columns, then one render_style column per widget config table). 452 tests passing, including new dispatch/ migration coverage per widget type and a dedicated photos test proving photo_palette_rgb produces genuinely independent quantization from the frame's main palette_rgb.	2026-07-31 03:52:19 +00:00
tfaour	8ea1c53ec3	Add experimental HTML/CSS "modern" render style for weather widget ... The weather widget's icons/layout are hand-drawn PIL primitives -- clean under quantization but flat, no gradients/shadows. Adds an opt-in render_style="modern" (current/daily modes only) that instead renders a Jinja2 template through a persistent headless-Chromium browser (app/html_render.py), following the approach of Tesserae, an open-source e-ink dashboard targeting this same panel family. Key design points: - The Chromium dependency (Playwright) is lazily imported only when a weather widget actually uses "modern" style, and the background browser itself only launches on first use -- every other widget type, and this one's own classic/hourly/multi_city paths, never pay for it. - No Frame-level dithering setting needed: html_render dithers its own rendered widget to exact palette colors (Bayer/ordered, not Floyd-Steinberg) before compositing, so the shared whole-canvas Floyd-Steinberg pass sees zero quantization error there and leaves it untouched -- same trick draw_text/hand-drawn icons already use. Floyd- Steinberg keeps working unchanged for photos and every other widget. - A "Load calibrated Spectra 6 preset" button in Advanced configuration offers a community-measured palette (data ported from paperlesspaper/epdoptimize, Apache 2.0) as an alternative starting point to the existing idealized DEFAULT_PALETTE_RGB -- fills the existing palette table, doesn't save by itself. Known open risk, not resolved here: a headless Chromium binary is far larger than the ~100MB single-layer limit that already forced this project's pip/npm installs into split layers, and (unlike those) is a single ~180MB file that can't be split across layers by ordinary Dockerfile restructuring. Flagged prominently in server/Dockerfile and docs/widgets.md -- treat this render style as experimental/local-only until that's resolved.	2026-07-30 22:18:43 +00:00
tfaour	aa4a382c1b	Add "now displaying" / "up next" preview pair to the frame header ... The server now records exactly what was last sent to the device on every device-facing render (/frame/image, /frame/advance, /frame/back, and the global hold actions), persisted as Frame.last_displayed_image/ _at and served back via GET /api/frames/{id}/now-displaying. The header thumbnail is split into that frozen "now displaying" snapshot and the existing live "up next" re-render, with an arrow between them -- so editing a layout shows the change immediately on the right while the left stays exactly what's actually on the panel until the device's next real wake.	2026-07-28 00:41:11 +00:00
tfaour	fcf3aec4c0	Move button actions to per-widget config, add hold-for-global-action ... Next/back button assignment moves from a frame-level "Button assignments" card into each widget's own gear-icon dialog, prefilled with a sane default at creation (photos/calendar -> advance/back, whiteboard/weather -> check_now, others -> none). At most one binding per (widget, button) now -- cross-widget execution order never mattered since each widget's action only touches its own state. New firmware capability: holding NEXT or BACK past a configurable duration (min 3s, server-side default) triggers a frame-wide action instead of the per-widget short-press one -- cycling saved layouts, refreshing all widgets, or freezing/unfreezing every photo widget (see app/global_actions.py). Firmware next/back checks gain the same hold-duration polling the combo button already had; the threshold comes from the previous wake's /frame/config fetch (persisted in NVS), since this wake's button decision happens before that request. Not done here: firmware/version.txt is intentionally left unbumped -- this hasn't been built or hardware-tested (no ESP-IDF toolchain in this environment), so no firmware release build should be triggered yet.	2026-07-27 22:09:33 +00:00
tfaour	9911151d8d	Add per-photo-widget lock (freezes current photo until unlocked) ... A "Lock this photo" button in the photos widget's dialog toggles PhotoWidgetConfig.locked, which suppresses both the timer-elapsed auto-advance and the advance/back button actions until unlocked. The Layout tab canvas shows a lock badge on any locked photo widget's box.	2026-07-27 21:07:54 +00:00
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	eb7127718b	Add battery widget (device's own last-reported level, no live upstream) ... Shows Frame.battery_percent/battery_as_of, already set by every device wake-on-battery report, plus routers/common.py's existing battery_estimate_s time-remaining estimate -- nothing new to fetch or cache. Compact (icon + percent) or detailed (+ estimate, last report age) display mode. No button actions.	2026-07-27 19:02:21 +00:00
tfaour	52ebafab78	Add standalone weather widget (current/hourly/daily/multi-city, pluggable providers) ... New widget type with four display modes -- current conditions, an hourly forecast strip, a multi-day forecast, and several cities' current day side by side -- backed by a pluggable provider registry (app/weather/, mirroring the app/widgets/ dispatch pattern): Open-Meteo (worldwide) and NWS (US-only) both wired up now, Environment Canada documented as the next one to add given its more involved station/grid-lookup API. The calendar widget's existing embedded weather strip is untouched and still Open-Meteo-only; this lifts the same underlying icon-drawing primitives (now shared via app/weather_render.py, calendar_render.py still imports draw_weather_row unchanged) into a widget that can be placed and sized on its own. Icons are redrawn in the panel's actual ink colors (yellow sun/bolt, blue rain/snow) instead of flat black, and build_multi_city's icon/font sizing now scales with how many cities need to fit rather than the box's height alone -- both fixed after catching them via live browser verification, along with a mode-switch cache-shape crash and a mobile-width dialog overflow. New WeatherWidgetConfig table (migration 24), grid footprint, widget module, common.py fetch/cache helper, router endpoints (location set/ clear, city add/remove, preview), dialog template + JS, and full test coverage (providers, widget render, HTTP endpoints, migration replay). docs/widgets.md and CLAUDE.md's TODO updated accordingly.	2026-07-27 16:16:43 +00:00
Thomas Faour	c1c657c0a9	Saved layouts feature	2026-07-25 18:18:48 +00:00
Thomas Faour	edbd90745b	Add font family choice to the text widget, move toolbar below the editor ... Six more vendored families alongside the existing Noto Sans (Inter, Source Sans 3, Noto Serif, Crimson Text, Arvo, IBM Plex Mono -- sans/ serif/slab/mono variety), all OFL-licensed with their own per-family license file in app/fonts/ since each has a different copyright holder. Static Regular/Bold/Italic/BoldItalic builds only -- variable-font-only families (Inter and Source Sans's current Google Fonts releases, plus Playfair Display/Lora/Merriweather) were skipped in favor of static builds from their own upstream repos, keeping every family's loading code uniform with what was already there. Considered but deliberately left out: Georgia -- a proprietary Microsoft core font, not freely redistributable, unlike everything else vendored here. Also moves the bold/italic/underline/color toolbar below the contenteditable box per request, and reorders the dialog's Settings card to a more natural family-then-size order. Fixes a latent migration bug this surfaced: migration 20 (static image widget) used Base.metadata.create_all, which creates every table declared in Base.metadata that's missing, not just its own new one -- harmless when nothing else pending, but once TextWidgetConfig existed it would silently pre-create text_widget_configs (in whatever shape models.py currently declares) before migration 21 got a turn, so migration 21's own CREATE TABLE (or a later ALTER TABLE adding font_family) would collide with a table create_all had already leaked into existence. Both migrations 20 and 21 now use raw, frozen CREATE TABLE SQL instead, matching migration 17's existing precedent for exactly this reason.	2026-07-25 16:05:22 +00:00
Thomas Faour	3735c5bfa7	Add a text widget (rich text: bold/italic/underline, per-run color/highlight) ... A new self-contained widget type showing user-authored rich text -- no live upstream to poll, like the static image widget, just word-wrapped styled text instead of an uploaded image. The dialog's contenteditable HTML is never stored or replayed as HTML: app/text_content.py parses it server-side (on save) into a plain paragraphs-of-styled-runs structure -- the actual sanitization boundary, since raw HTML never round-trips back into any browser DOM (the dialog rebuilds its editor from that same JSON via createElement/textContent). app/widgets/text.py renders it with a custom word-wrap/shrink-to-fit layout, using real vendored font weights (app/fonts/NotoSans-{Regular,Bold,Italic,BoldItalic}.ttf, OFL-licensed like the emoji fonts already there) rather than every other widget's single ImageFont.load_default() -- the one widget type where that distinction matters.	2026-07-25 14:21:52 +00:00
Thomas Faour	35e80c6d1c	Add a static image widget (PNG/JPEG/GIF/BMP/WEBP/TIFF/PDF upload) ... A new widget type showing a single user-uploaded image with no live upstream to poll -- decoded once at upload time (PDF's first page via pypdfium2, BSD-3-Clause/Apache-2.0, no copyleft exposure) into plain RGB PNG bytes, then composed per a crop/stretch/letterbox display mode like the photos widget.	2026-07-25 08:39:09 +00:00
Thomas Faour	4a2b1f3795	Let a tasks widget have a custom on-panel name ... Adds TaskWidgetConfig.name (migration 19, plain column add) shown at the top of the widget on the actual panel instead of the hardcoded "Tasks" header -- e.g. "Chores" or "Mom's list". The only widget type with its own on-panel title at all, since it's the only one where "which list is this" isn't already obvious from a calendar/photo/ whiteboard's own content. Threaded through calendar_render's _draw_tasks/_build_tasks/ render_tasks/render_tasks_preview_png as a `title` param (default "Tasks", truncated to fit -- a long custom name shouldn't be able to overflow the widget's box), the config-save endpoint (tasks_name, truncated server-side to a sane header length rather than rejected), and a new "Settings" section in the tasks dialog. Verified live in the browser: the name actually renders at the top of the real composited panel (not just the dialog preview, which stays gated on having a configured source), and persists correctly on both desktop and mobile. Full suite (196 tests) passes.	2026-07-25 04:05:36 +00:00
Thomas Faour	14c47aa2a0	Let a tasks widget merge multiple task lists, checkbox+color like calendar ... Tasks widgets could only ever point at one CalDAV task list (a radio- button picker, owner-only). Now they merge any number of included task lists across every linked user, same checkbox-inclusion + optional pinned-color shape a calendar widget already has for its calendars -- FrameTaskList mirrors FrameCalendar exactly, down to the same owner- adds/anyone-mutes permission split (api_widget_task_list_select/ api_widget_task_list_color). Reused calendar_render._event_colors/ _draw_color_bar as-is for the per-task color bar -- a task dict's owner_display_name/color_index is exactly that function's single- source fallback shape. Also added an opt-in "show tasks completed in the last 24 hours" toggle (TaskWidgetConfig.show_completed): caldav_client.fetch_tasks now accepts a completed_since cutoff and returns completed VTODOs (with their completion time) instead of silently dropping them, and _draw_tasks gives a completed task a filled checkbox + muted text instead of the normal empty-box/due-date row. Migration 18 splits the single-source TaskWidgetConfig columns (added by 17, splitting tasks out of the calendar widget in the first place) into frame_task_lists, carrying forward each widget's existing single source as its first included list -- same shape migration 9 used carrying forward frame_calendars' old single opt-in. Verified live in the browser (desktop + mobile): the new "Included task lists" + "Recently completed" dialog sections, the show_completed toggle actually persisting through a real HTTP round-trip, and no regression in the calendar widget's own "Included calendars" dialog. Full suite (192 tests, including new merge_tasks/config_save/migration coverage) passes.	2026-07-25 03:39:26 +00:00
Thomas Faour	b5c52004c8	Split the tasks feature out of the calendar widget into its own widget type ... Task lists used to be a week-view-only sub-feature bolted onto calendar widgets (CalendarWidgetConfig.tasks_*), so a task list could only exist tied to a calendar's view and only inside its footprint. Tasks are now a standalone widget type (TaskWidgetConfig, app/widgets/tasks.py) that can be placed and sized independently, same as photos/calendar/ whiteboard -- no separate "enabled" flag either, since being on the grid at all is the on/off switch, matching every other widget type. Migration 17 creates task_widget_configs, extracts any existing calendar widget's configured task source into a new sibling tasks widget (auto-placed in open grid space, source dropped+logged if truly none is left), then drops calendar_widget_configs' now-dead tasks_* columns in the same migration -- this project's usual same-migration- drop convention. Also handles the rarer case of a database jumping straight from before the widget system existed to after this split in one boot, via the legacy Frame.calendar_tasks_* columns. Verified live in the browser at desktop and mobile widths: adding a Tasks widget, its own dialog (task-list source picker + preview), and confirming the calendar widget's dialog no longer mentions tasks at all. Full test suite (180 tests, including new coverage for the widget render/actions, the migration's data-extraction path, and the permission-boundary shape for tasks-source) passes.	2026-07-25 02:11:45 +00: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
tfaour	8bc0749b42	Widget system Phase 0: data model + migration ... First step of replacing Frame.mode (one renderer owns the whole panel) with an Android-home-screen-style widget system -- a frame will hold N independently placed/sized widgets (photos/calendar/whiteboard), each with its own config/state, plus fully user-assignable NEXT/BACK button actions. Full plan at .claude/plans/prancy-snacking-iverson.md. This phase is additive only and changes no existing behavior -- nothing reads these new tables yet: - models.py: Widget (placement) + PhotoWidgetConfig/CalendarWidgetConfig/ WhiteboardWidgetConfig (per-type 1:1 extension tables, matching this codebase's existing convention of dedicated tables for naturally-scoped state rather than one wide table) + FrameButtonAction (ordered (widget, action) bindings per physical button). - grid.py: pure snap-to-grid placement math, defined relative to the panel's long/short axis so it stays valid across logical_render_size(orientation)'s genuine width/height swap for portrait, not just a rotation applied at the end. - db.py: widget_locked(), the widget-scoped equivalent of frame_locked() -- deliberately still locks at frame granularity (not a new per-widget lock) to avoid a new class of multi-lock deadlock bugs. - migration.py: _migration_16 creates the new tables; a separate _ensure_widgets_backfilled() (ORM-based, not raw SQL -- much less error-prone for this much per-mode branching) gives every existing frame a widget reproducing its exact current mode/settings, so upgrading changes nothing about what a frame displays or what its buttons do. calendar_photo_inlay frames specifically get two widgets (calendar + photo, split like the old inlay did) rather than silently losing the photo half. 10 new tests covering fresh-install backfill, re-run idempotency, the photo-inlay two-widget case, whiteboard's check_now button mapping, and migration_16's actual CREATE TABLE path against a simulated pre-existing database (not just the fresh-install create_all() shortcut). Full suite (69 tests) passes.	2026-07-24 08:27:47 -04:00
tfaour	b4ca795003	Add a whiteboard file picker and force-refresh ... File picker: an optional WebDAV browse root in Settings (User.webdav_base_url) plus a plain-PROPFIND directory listing (webdav_client.list_directory) power a "Browse..." panel on a frame's Whiteboard tab, so a file can be clicked into rather than typing its exact WebDAV URL. Manual URL entry still works unchanged either way. Force-refresh: get_or_refresh_whiteboard takes a force flag that skips the fetch throttle entirely; the Whiteboard tab's refresh button now passes it, so clicking it always re-fetches and re-renders instead of possibly just re-showing the same cached image from within the last ~20 minutes.	2026-07-23 18:20:39 -04:00
tfaour	644fdefa66	Add whiteboard frame mode (Nextcloud Whiteboard / Excalidraw over WebDAV) ... New third mode alongside photos/calendar: fetches a .whiteboard file over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and renders it via a small Node.js sidecar using Excalidraw's own real export code (@excalidraw/utils + @resvg/resvg-js, no headless browser), since a .whiteboard file turns out to be Excalidraw scene JSON, not an image. The sidecar runs as a second process inside this same container (Dockerfile installs Node, start.sh backgrounds it before exec'ing uvicorn) rather than a separate docker-compose service -- lightweight, stateless, reachable only at 127.0.0.1 from the Python process, nothing worth independently scaling. The rendered PNG is treated exactly like a photo from there on -- composed/quantized through the existing image_pipeline (letterboxed, never cropped) rather than a second parallel rendering pipeline. WebDAV credentials support the common "it's actually the same Nextcloud account as my CalDAV" case (an explicit opt-in checkbox, not silently inferred) while still working with any WebDAV server generically. Frame-level source (URL + owning account) follows the same owner- controls-their-own-data permission split as calendar sources and the week view's task list: only the account owner can point a frame at it, anyone linked can clear it. Honest limitation: this environment has no Node.js/npm, so render-service/ is written carefully against each library's documented API (verified via the npm registry, including transitive dependency licenses after the CalDAV/AGPL surprise earlier this session) but has never actually been executed. First real docker build is the first true test -- see render-service/README.md.	2026-07-23 17:02:08 -04:00
tfaour	db9a6f1875	Week view: relative start-day offset for non-7-day counts; hide week-only settings elsewhere ... calendar_week_start's fixed-weekday anchor ("start on the most recent Monday") stops making sense once the view isn't a literal calendar week, so a non-7-day week view now starts calendar_week_start_offset days from today instead (0 = starts today, negative/positive = past/ future) -- calendar_week_start still governs at the default 7 days, unchanged. Also hides the Calendar tab's week-only fields (days to show, layout, start offset) unless View is actually set to Week, and further hides the new start-offset field specifically when Days to show is 7 (where it has no effect). "Week starts on" stays visible for Month too, since it actually still applies there.	2026-07-23 08:17:25 -04:00
tfaour	ce8525bee8	Week view flexibility: configurable day count, layout, and a CalDAV task list ... - Day count (2-10, was fixed at 7) -- 5 days trims the weekend clutter without losing the grid format. - Layout choice: days side by side (original behavior) or stacked vertically as full agenda-style sections (reuses _draw_agenda_day, same approach _build_today_tomorrow already used for a fixed 2 days). - Optional task list (CalDAV VTODO collections only -- a plain ICS subscription doesn't meaningfully have one) that takes the space of one day slot instead of adding an extra one. Same owner-controls- their-own-data permission split as calendar sources: only the calendar's owner can point a frame's task list at it, but anyone linked to the frame can clear it. Browse-offset paging now moves by N days (was hardcoded to weeks), identical to the old behavior when days=7. Changing the day count resets the browse offset, same reasoning as changing views already did.	2026-07-23 07:58:13 -04:00
tfaour	27cd6b3703	Manual per-calendar color choice for calendar mode ... Each linked person can pin one of the panel's four non-black/white colors (Yellow/Red/Blue/Green) to their own calendar instead of relying on calendar_render.py's old auto-cycle-by-owner-name order -- owner-only, like adding a calendar in the first place. Colors resolve against whichever palette a frame actually renders with (including a custom Advanced configuration override), so a pinned "Blue" stays this frame's actual blue. Event color bars/dots are also bigger and rounded now across agenda/week/month views, easier to tell apart at a glance.	2026-07-22 22:30:55 -04:00
tfaour	ffce798754	Add weather to calendar mode; fix CalDAV events never showing ... Weather: multiple cities per frame, geocoded via Open-Meteo (no API key), shown above the event list on agenda/today & tomorrow/week views -- never month, no room for it there. Hand-drawn sun/cloud/rain/snow/ thunderstorm icons (no new font/icon asset, same primitives-only approach the rest of calendar_render.py already uses). City geocoding handles "City, State" qualifiers Open-Meteo's own search doesn't (disambiguates same-named cities, e.g. the three "Portland"s). CalDAV fix: events were never showing despite calendars discovering fine, because fetch_calendar_events relied on the calendar-query REPORT's server-side time-range filter, which real servers implement inconsistently (confirmed against a real server, not just guessed -- reproduced locally with Radicale). Switched to fetching every event unfiltered and doing all date-window filtering/expansion client-side, same approach already used for plain ICS feeds.	2026-07-22 22:22:11 -04:00
tfaour	acdb929a99	Move mode picker below device status bar; fix invisible calendar lines; add CalDAV calendar support ... Calendar rule/grid lines were light gray, which dithers away to near-invisible on the 6-color e-ink palette -- now black. CalDAV accounts (Nextcloud, Fastmail, iCloud, ...) can now be linked alongside the existing single ICS subscription, since one account can expose several calendars. A frame's Calendar tab now lists calendars per person rather than one opt-in per person: your own row shows every calendar you have available with a full add/remove toggle, while other linked users' rows show only calendars they've included, toggleable off (mute) but not on -- only a calendar's owner can add it to a shared frame. FrameCalendar replaces the old single-boolean UserFrame.calendar_included; existing opt-ins are migrated forward.	2026-07-22 22:01:05 -04:00
tfaour	aa194be09a	Calendar mode polish batch + Today & Tomorrow view ... Responds to post-launch feedback on calendar mode: configurable week-start day for week/month views, crisper non-antialiased text (threshold-masked instead of drawn straight, so Floyd-Steinberg dithering doesn't speckle glyph edges), a color-coded/proportionally filled battery icon on the manage overlay, word-wrapped placeholder text so "Calendar isn't set up yet" no longer clips in portrait, photo inlay support extended from agenda-only to every view, and a fix so manage-overlay face labels reposition correctly when a photo inlay is active (they previously assumed the photo filled the whole canvas). Also adds a fourth calendar view, "Today & Tomorrow" -- a two-day agenda that reuses the same per-day row-layout helper the single-day agenda view already has.	2026-07-22 21:20:44 -04:00
tfaour	1fa1c68478	Add calendar frame mode data model (migration 7) ... New columns, all ADD COLUMN with inert defaults -- no existing frame's behavior changes until mode is explicitly switched to "calendar": - users.calendar_ics_url: one personal iCal/CalDAV subscription per user, same shape as the existing per-user immich_url/immich_api_key. - user_frames.calendar_included: explicit per-(user,frame) opt-in, default off. Being linked to a frame does not by itself contribute your calendar to it -- each person's calendar is their own data to share, not something a frame's controller decides on their behalf. - frames.calendar_view/calendar_photo_inlay/calendar_browse_offset: per-frame display settings and NEXT/BACK navigation state. - frames.calendar_checked_at/calendar_cached_events/calendar_fetch_summary: the throttled merge-fetch cache, same shape as the existing firmware_update_checked_at/firmware_gitea_latest_version pattern.	2026-07-22 19:05:02 -04:00
tfaour	55b53d5bb2	Fix migration runner crashing on a genuinely fresh database ... _migration_1() is Base.metadata.create_all() -- it already builds today's full schema straight from models.py. Every migration after it is an incremental ALTER/UPDATE meant to bring an *existing* install forward from an older version; replaying them against a brand-new database collided with columns create_all had already added ("duplicate column name"), crashing on first boot. Found while testing the device-status-bar change against a scratch DB. Every real deployment has been migrating forward incrementally since before this bug existed, so it never showed up in practice -- but any brand-new install would have hit it. Fresh databases now jump straight to the latest schema_version after create_all; existing databases keep applying whichever migrations are still pending, same as before.	2026-07-22 10:48:36 -04:00
tfaour	e48ac50ea1	Color/contrast/dithering sliders + before/after render preview ... Advanced configuration gains three sliders (PIL ImageEnhance factors for color/contrast, 0-2, 1=unchanged; a 0-1 dithering strength) applied to every photo this frame renders. Confirmed the parameter conventions against a similar project (jwchen119/EPF: ImageEnhance.Color/Contrast, 1.0 baseline) before implementing; dithering strength isn't natively exposed by PIL's quantize(), so it's implemented by blending the source toward its own flat/undithered quantization before running Floyd- Steinberg on the blend -- at 0 there's no quantization error left to diffuse (exactly the flat result), at 1 it's the original unmodified behavior, with a smooth continuum between rather than dithering being an on/off toggle. image_pipeline.py split into composition (_compose), enhancement (_enhance), quantization (_quantize), and transpose+pack stages so render_frame (device bytes) and the new render_preview_png (a normal viewable PNG, upright logical orientation) share the same pipeline instead of duplicating it. Named-face overlay label math (face_labels.py) was already routed through the shared _placement_transform, so it needed no changes for the new params. Also added the requested before/after comparison: the Configuration tab's new Preview card shows the current photo's untouched Immich preview next to that same photo run through the frame's actual saved rendering pipeline (two new GET endpoints, /preview/original and /preview/rendered) -- immediate visual feedback for tuning the palette and these new sliders. "Refresh preview" re-fetches after saving. Schema migration v6 adds color_boost/contrast_boost/dither_strength, defaulting to 1.0/1.0/1.0 -- reproduces the exact previous rendering until a frame's Configuration tab changes one. Verified against the live-shaped test database: the migration, sliders persisting and clamping out-of-range input, both preview endpoints (real JPEG passthrough / real PNG at correct logical size+orientation), confirmed dither_strength=0 actually changes the rendered bytes vs. default, and the standing legacy-device curl suite.	2026-07-22 08:46:22 -04:00
tfaour	49bc9f9ec9	Display mode: crop to fill, crop to faces, stretch to fill, shrink to fit ... Replaces the smart_crop_faces boolean with a 4-way display_mode select on each frame's Configuration tab (image_pipeline.DISPLAY_MODES): - Crop to fill / Crop to faces: the previous False/True behavior, unchanged (center-crop trimming excess, optionally shifted to keep faces on screen). - Stretch to fill (new): fills the panel exactly, aspect ratio not preserved -- a plain resize, no crop. - Shrink to fit (new): the whole photo visible, letterboxed with white where it doesn't fill the panel. Named-face overlay label positioning (face_labels.py, the manage menu's "who's in this photo") now goes through a shared _placement_transform() in image_pipeline.py instead of duplicating crop-box math, so label placement stays correct (and in-bounds) under all four modes, not just the two crop ones -- letterbox/stretch never crop a face out, so labels just use straight scale+offset math there. Schema migration v5 adds display_mode, backfills it from the old boolean (True/False -> crop_faces/crop_fill), and drops the boolean. Verified against the live-shaped test database: the migration (existing frames correctly preserved as crop_faces), the config page's new 4-option select, actual renders under letterbox (confirmed real white letterbox padding in the packed panel-code bytes) and stretch_fill, invalid-input fallback, and the standing legacy-device curl suite.	2026-07-22 01:32:52 -04:00
tfaour	5b11f2accb	Per-frame palette calibration + sidebar battery indicator ... Advanced configuration (Configuration tab, collapsed <details> section): a color picker per ink color (black/white/yellow/red/blue/green), overriding image_pipeline.DEFAULT_PALETTE_RGB for that frame's actual panel -- different units can vary enough from the documented approximations to be worth calibrating once you can compare a rendered photo against the real hardware. Stored as Frame.palette_rgb (NULL = default, schema migration v4), threaded through render_frame/ render_placeholder/_quantize_and_pack (which now builds the PIL palette image per call instead of once at import) so both photos and the unclaimed/unconfigured placeholder screen respect it. "Reset to defaults" clears back to NULL. Config-save validates exactly 6 #rrggbb values, rejecting anything else with a 400. Also: each frame's sidebar entry now shows its last-reported battery percent (🔋NN%) next to the name, using the frame_dot's existing recently-seen indicator conventions -- silent when never reported (mains-only frames, or before the first report), matching how battery is hidden everywhere else it's not applicable. Verified against the same live-shaped database as the SMTP work: the v3->v4 migration, save/reload/reset round trip through the real HTTP route, an actual rendered image using a custom palette (confirmed via its packed panel-code bytes), input validation, and the sidebar badge against real battery data -- plus the standing legacy-device curl suite.	2026-07-22 01:19:06 -04:00
tfaour	c1c803b497	SMTP: implicit TLS (port 465) support + fix quarantined mail ... Two real fixes to app/mail.py, both found by testing against an actual mail server rather than just a fake stub: - Replaces the STARTTLS-only smtp_use_tls boolean with a three-way smtp_encryption ("none"/"starttls"/"ssl"). Implicit TLS (port 465, what Purelymail and most providers offer alongside 587/STARTTLS) is a different handshake entirely -- TLS from the first byte, not a plaintext connection that gets upgraded -- so it needs its own smtplib.SMTP_SSL code path, not just a skipped starttls() call. Schema migration v3 adds the column, backfills it from the old boolean, and drops the boolean (safe on a live, populated DB). - Outgoing mail was missing Date and Message-ID headers -- email.mime doesn't set either automatically, and a missing Message-ID in particular is enough for a strict content filter (confirmed via a real Postfix+Amavis mail server's logs: SPF/DKIM/DMARC all passed cleanly, but Amavis quarantined the message as "BAD-HEADER-0" purely for the missing id) to silently swallow an otherwise-legitimate email, even though smtplib reports success -- the send genuinely succeeds to the relay, it just never survives the recipient's own filtering. Both headers are now set, with the Message-ID's domain matching the From address. Verified: SMTP_SSL path against a hand-rolled implicit-TLS fake server (self-signed cert, client-side verification relaxed only in the test harness -- production code keeps ssl.create_default_context()'s real verification), the v2->v3 migration against live data, the full admin SMTP-save + test-email round trip over HTTP, and the standing legacy- device curl suite.	2026-07-22 01:07:50 -04:00
tfaour	8e10ca540e	Add SMTP email: password reset + per-frame battery-threshold alerts ... Admin-configured SMTP (server/port/username/password/from address/ STARTTLS, a singleton server_settings row set from /admin -- not env vars, since it's operator infrastructure a household admin sets up once through the UI) powers two features, both requiring the relevant user to have an email set in their own Settings: - "Forgot password?" on /login emails a one-hour single-use reset link (password_reset_tokens table). The endpoint always returns the same generic "check your email" response regardless of whether the address matched an account, so it can't be used to enumerate registered users. - A frame's Configuration tab can set a battery-alert threshold (Frame.battery_alert_threshold_pct, -1 = disabled); POST /frame/battery emails the owner the first time a report drops to or below it, then stays quiet for the rest of that discharge cycle (battery_alert_sent, reset alongside battery_history whenever the existing recharge-jump detection fires) -- not once per wake. New app/mail.py wraps stdlib smtplib (no new dependency); send_email() never raises, so a broken mail server can't 500 a battery report or a password-reset request. Schema migration v2 adds users.email and the two frame columns via ALTER TABLE (safe against the live, already- populated database) plus the two new tables via the existing create_all-based migration runner. Verified against a real (already-migrated, real user/frame data) database: the v1->v2 migration, admin SMTP config + test-email button, full forgot/reset-password roundtrip (including single-use token invalidation and the no-enumeration response), and the battery alert firing exactly once per crossing against a hand-rolled fake SMTP server -- all via curl end-to-end, plus the standing legacy-device curl suite to confirm the device protocol is untouched.	2026-07-22 00:51:54 -04:00
tfaour	9fbbb8ed2b	Redesign phase A: SQLite storage, per-frame data model, device identity ... Replaces the single global config.json (whole-file pydantic model under one RLock) with SQLite via SQLAlchemy 2.0: users/sessions/frames/links/ pending-claims/battery_log tables (models.py), a per-frame lock registry (db.frame_locked) succeeding config.locked(), and hand-rolled schema versioning (migration.py). A pre-database deployment's config.json is imported verbatim as frame #1 on first boot and left untouched as the rollback path; the old single firmware.bin slot becomes per-frame firmware/<id>.bin. Routes split out of the 900-line main.py into routers/device.py (the frozen /frame/* protocol) and routers/api.py (web UI, still on the old single-frame paths for now). Device auth moves to require_device, which already speaks the full multi-frame protocol: per-frame device tokens pushed via /frame/config and acknowledged on first use, self- registration of unknown device ids as unclaimed frames, pending-claim attachment, and the legacy-token migration window that keeps the currently-deployed firmware (no id, shared MANAGEMENT_TOKEN) resolving to frame #1 -- including the one-time binding of its device id when it first reports one after a future OTA. Externally identical for existing deployments: same paths, same token semantics, same response shapes -- verified with a migration fixture, the legacy-device curl suite, a 20-way concurrent-advance smoke test, and a mutate-restart-assert persistence check against a fake Immich. photo_queue.py ports nearly verbatim onto the Frame ORM row (MutableList JSON columns make its in-place list mutations dirty-track); quiet-hours math extracted unchanged into quiet_hours.py.	2026-07-21 23:21:38 -04:00