A 32" panel a few feet from the children and a 65" set across a hall want the same design at different sizes. UI_SCALE in device.conf now sets that, and nobody has to edit CSS or source to tune a room. The stylesheet and the notification config become templates carrying measurement tokens. classroom-dock resolves the stylesheet in memory at startup; classroom-notifications resolves the notification config into the session's runtime directory and execs mako on it, so the process is still just mako and everything that looks for it by name still finds it. Neither template is rewritten on disk, so an update cannot lose a room's setting and a room cannot drift from the packaged design. Dock height and the reserved strip, corner radii, padding, button size, spacing, every icon, the clock and its inset, and the notification geometry all follow the scale. Colours, translucency and the hairline borders do not: those are the design, not the size. At UI_SCALE=1.0 the rendered stylesheet is byte-identical to the one the shell used before any of this existed, which is the property worth keeping. Values outside 0.8 to 1.5 are clamped and anything that is not a number falls back to 1.0, so a typo in device.conf cannot produce an unusable classroom. Device configuration moves into a shared module, since the dock and the notification daemon now have to agree about what a setting means. Co-Authored-By: Claude Opus 5 <[email protected]>
4.9 KiB
Classroom test checklist
Run against the exact artifact published to canary, on the real endpoint,
before promoting to stable with ./update_stable.sh.
Boot
- Cold boot reaches the classroom shell with no terminal or window junk
- Reboot does the same
- Wallpaper appears
- Dock appears, centred
- Clock appears, bottom right
UI scale
UI_SCALE=1.0looks exactly as it did before scaling existedUI_SCALE=1.25, thensudo systemctl restart getty@tty1: dock, icons, clock and notifications all grow togetherUI_SCALE=0.8shrinks them together- The reserved bottom strip grows and shrinks with the dock, and a maximised Chrome window still stops above it
- A nonsense value (
UI_SCALE=banana) still gives a working shell - An extreme value (
UI_SCALE=9) is clamped, not obeyed
Reserved bottom shell (regression)
The bottom strip is one full-width layer-shell surface with a 76px exclusive zone. Dock and clock live inside it. Do not split them back into separate layer-shell windows.
- A maximised Chrome window stops above the bottom strip
- The clock does not float over Chrome
- Dock stays centred, clock stays bottom right
- Wallpaper shows through the unused parts of the strip
- Every dock button still responds to clicks
- A fullscreen application covers the whole display, dock included
Browser
- First Browser click launches Chrome
- Chrome opens on Wonder Ink (https://app.wonderink.org/)
- Clicking Browser while Chrome is focused minimises it
- Clicking Browser again restores it maximised, not floating or draggable
- Clicking Browser while Chrome is running but unfocused focuses it
Super+Mminimises the focused windowSuper+Shift+Mrestores the most recently minimised window- Normal navigation to any other site works
- The Home button returns to Wonder Ink
- Fullscreen YouTube video uses the whole display
- Leaving fullscreen restores the correct geometry above the dock
- No first-run, default-browser or sign-in nag appears
chrome://policylists the Ekklesia policies as applied, with no "unknown policy" entries- Chrome does not start by itself at boot
- After a reboot, cookies and site logins are still there
- After an OTA update, cookies and site logins are still there
Known limitation: Chrome's own minimise button in its title bar does
nothing. Sway ignores the Wayland minimise request and gives no event to
hook. Minimising is the dock's Browser button or Super+M.
Notifications
classroom-notify-testrenders with the classroom styling: dark translucent, rounded, white text, top rightclassroom-notify-test --critical "Parent Call" "Room 3 needs a parent."renders in the critical style and does not time out- Notifications appear over a fullscreen video
Over SSH from an administrator account, run it with sudo:
sudo classroom-notify-test --dry-run # show the session it resolved
sudo classroom-notify-test # send into the classroom desktop
The classroom desktop belongs to the classroom user, and mako sits on that user's D-Bus session. A plain notify-send from an SSH session lands in the administrator's own session, where nothing owns org.freedesktop.Notifications, so D-Bus tries to start a second mako with no display and the call times out with NoReply. The script finds the running sway process for the classroom user and delivers into its session instead. It never starts mako.
sudo classroom-notify-testfrom an SSH session displays on the classroom screensudo classroom-notify-test --dry-runreports the resolved XDG_RUNTIME_DIR, bus address and Wayland display- Running it as an unprivileged admin account explains it needs sudo
tests/test-classroom-notify-test.shpasses (also run by the build)
DVD
With DVD_ENABLED=false:
- No DVD button in the dock
With DVD_ENABLED=true:
- Drive unplugged: button present, icon held back, friendly notification on click
- Drive present, no disc: friendly notification on click, nothing crashes
- Inserting a disc produces one DVD Ready notification
- The DVD icon comes up to full strength while a disc is in
- Nothing plays until the button is pressed
- Clicking plays the disc
- Menus work
- Audio works
- Chapter navigation works
- Fullscreen works
Super+Mminimises the player, the DVD button restores it- Closing the player works
- Ejecting is detected, the icon goes back
- Reinserting is detected again
- Commercial CSS disc, after
classroom-dvd-css-setup
OTA
./update_canary.shpublishes package first, manifest last- The endpoint on the canary channel picks the update up
- SHA-256 verification passes
- Install succeeds and the endpoint reboots
- Everything above still works after the update