Files
Classroom_Desktop/docs/testing.md
T
ekklesiaandClaude Opus 5 428eb27a74 feat: scale the shell to the room's television
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]>
2026-09-04 21:33:09 -05:00

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.0 looks exactly as it did before scaling existed
  • UI_SCALE=1.25, then sudo systemctl restart getty@tty1: dock, icons, clock and notifications all grow together
  • UI_SCALE=0.8 shrinks 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+M minimises the focused window
  • Super+Shift+M restores 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://policy lists 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-test renders with the classroom styling: dark translucent, rounded, white text, top right
  • classroom-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-test from an SSH session displays on the classroom screen
  • sudo classroom-notify-test --dry-run reports 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.sh passes (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+M minimises 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.sh publishes 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