Commit Graph
5 Commits
Author SHA1 Message Date
ekklesiaandClaude Opus 5 87b55761c6 feat: give the classroom a desktop instead of a shell
The whole appliance UI is now configuration for a desktop Debian already
ships: a Plasma 6.3 session with a colour scheme, a look and feel package
that builds the bar, window rules, and KDE's own Kiosk restrictions.

Two things were measured rather than assumed, and both changed a decision.

Plasma restarts a crashed panel three times a minute and then gives up,
which is the failure a classroom has already had. Four lines of systemd
drop-in make it unconditional; the panel then survived eight SIGKILLs a
second apart, back each time in 2.4s.

Plasma draws a minimised task and a background task identically, so the
five states the room needs cannot all be shown. Rather than write a task
manager, the classroom removes minimise: clicking a launcher always means
show me this.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-10 08:35:12 -05:00
ekklesia 7f66228b9e Release 0.1.37 deployment prep 2026-09-06 17:30:30 -05:00
ekklesiaandClaude Opus 5 0b2f99a853 feat: make Chrome a room appliance rather than somebody's browser
A classroom computer is shared. There is one local Chrome profile owned
by the room, teachers sign into websites, and nobody signs into Chrome.

BrowserSignin=0 stops Chrome asking who is using it, with SyncDisabled
set explicitly alongside it so the intent is in the file rather than
implied. BrowserAddPersonEnabled=false stops new profiles and
ProfilePickerOnStartupAvailability=1 stops the picker.

BrowserGuestModeEnabled=false is the answer to the other profile
switching entry point. Guest is the one that survives disabling add
person, and turning it off is the supported mechanism rather than hiding
UI. Guest is not the browsing model: the room needs one persistent
profile so the church YouTube login survives.

CookiesSessionOnlyForUrls scoped to [*.]wonderink.org, which covers
app.wonderink.org and every other subdomain, so a teacher's Wonder Ink
session does not outlive them. BackgroundModeEnabled was already false,
which is what lets a session actually end.

Every policy name was checked against the strings of the installed
Chrome 152 binary, with deliberately invalid names as a control so the
check is known to discriminate.

Two things are recorded honestly in docs/browser.md rather than claimed.
The avatar button stays in the toolbar — screenshotted with and without
these policies, it is in the same place either way; what changes is that
nothing behind it can create or switch a profile, and no Chrome 152
policy removes the button. And whether session-only cookies actually
sign Wonder Ink out is unverified: it needs a real Wonder Ink login,
which this machine does not have, and three attempts to prove the
mechanism against a local site were inconclusive because the positive
control never worked. The endpoint procedure to settle it, including how
to tell a cookie session from a localStorage one, is written down.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-05 08:27:16 -05:00
ekklesiaandClaude Opus 5 255072ac94 feat: settle Chrome's window, crash bubble and password prompts
Three things a volunteer should never have to see.

Sway was drawing its own title bar above Chrome's tab strip, which
already carries the window controls. Verified on a real session: Chrome
is an xdg_shell client with app_id "google-chrome" and sway was giving
it border "normal". A scoped rule removes the compositor decoration
only — Chrome keeps its tabs and address bar, stays a normal window, and
still maximises and minimises. A class rule covers an XWayland fallback.
Nothing else changes: the only other window in this classroom is VLC,
which is already borderless, so no broader rule is warranted.

"Restore pages? Chrome didn't shut down correctly" is suppressed with
--hide-crash-restore-bubble. Note the name. The switch this was going to
use, --disable-session-crashed-bubble, is not present in Chrome 152 at
all — checked against the strings of the installed binary — so it would
have silently done nothing.

That hides the prompt; the profile was still being marked as crashed,
which is the untidy half. Chrome's browser process shuts down cleanly on
SIGTERM, so a shutdown unit now gives it one and waits up to eight
seconds before the session is torn out from under it. Best effort by
construction: a shutdown that will not finish is far worse than a crash
flag.

Password prompts go off with the PasswordManagerEnabled policy, on the
path the classroom already manages. Existing profile and session data
are untouched, and website logins are unaffected: Wonder Ink and YouTube
stay signed in.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-05 00:21:02 -05:00
ekklesiaandClaude Opus 5 6b133bdc3e feat: settle Chrome and notifications into the classroom look
Chrome stays a full browser. The managed policy only removes the things
a volunteer should never be asked about — the first-run tour, the
default-browser prompt, sync and sign-in promos, the profile picker —
and pins the Home button to Wonder Ink so there is always one obvious
way back. Startup URL is a recommended policy rather than a managed one,
so a teacher can still change it. Nothing restricts where they browse,
and the profile is untouched, so YouTube and other logins survive
reboots and updates.

Notifications were still stock mako, which looked nothing like the rest
of the shell. Give them the dock's palette: the same dark slate, the
same hairline white border, rounded, white text, top right. Kept a
little more opaque than the dock so text stays readable over video, and
on the overlay layer so a parent-call alert can still reach someone
watching a fullscreen DVD.

mako was only ever reaching the session through D-Bus activation. Start
it from the sway config so it is running before anything needs it.

classroom-notify-test sends a sample so the styling can be checked
without waiting for a real event.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-04 17:07:05 -05:00