ekklesiaandClaude Opus 5
a1a218b29f
Icons went soft under UI_SCALE while the clock text beside them stayed sharp, which is visible on a 24" monitor even if it hides on a TV. new_from_file_at_scale rasterises an SVG at its *logical* size. The artwork is vector, but by the time sway scaled the session it was already a fixed raster, and the compositor enlarged that. Text never had the problem because GTK draws it at the real density. GTK 3 has no fractional scaling, so sway advertises the ceiling integer scale and scales the finished buffer down. Measured under sway: scale factor 1 at output scale 1.0, and 2 at 1.25, 1.5 and 2.0. So each icon is now rasterised at size x scale_factor physical pixels and handed to GTK as a cairo surface carrying that device scale. The icon lands at the real density; its logical size, and the whole dock layout, is unchanged. Icons redraw on notify::scale-factor as well as at realize, since the scale factor is not known until a widget is on a display and changes if UI_SCALE is changed under a running session. Browser, DVD, LIVE and all six DVD control icons go through it, in a shared module so the dock and the DVD session cannot diverge. The throbber is drawn rather than loaded and had the same flaw, so it draws on a device-scaled surface too rather than being the one soft thing left in a sharp dock. The artwork is untouched. Verified by rendering the dock under sway at 1.0, 1.25, 1.5 and 2.0 against the previous build: apparent icon size is identical at every scale (28, 35, 42, 56 px), 1.0 is unchanged pixel-for-pixel, and peak edge contrast on the Chrome icon goes from 60 to 99 at 1.25, 49 to 83 at 1.5, and 37 to 82 at 2.0 out of 255. The DVD control bar was checked the same way. Also records that Wonder Ink session-only cookies are confirmed working on the endpoint, which settles the question 0.1.34 shipped as unverified and tells us the session is in cookies rather than localStorage. Co-Authored-By: Claude Opus 5 <[email protected]>
100 lines
4.6 KiB
Markdown
100 lines
4.6 KiB
Markdown
# The classroom browser
|
|
|
|
A classroom computer is a shared appliance, not somebody's laptop. There
|
|
is **one local Chrome profile**, owned by the room. Teachers sign into
|
|
*websites*; nobody signs into *Chrome*.
|
|
|
|
## Policies
|
|
|
|
All of these are in
|
|
`/etc/opt/chrome/policies/managed/ekklesia-classroom.json`, and every
|
|
name was checked against the strings of the installed Chrome 152 binary
|
|
with deliberately invalid names as a control.
|
|
|
|
| Policy | Value | Why |
|
|
| --- | --- | --- |
|
|
| `BrowserSignin` | `0` | Chrome never asks who is using it |
|
|
| `SyncDisabled` | `true` | Explicit, though `BrowserSignin: 0` implies it |
|
|
| `SigninInterceptionEnabled` | `false` | No "this account is managed" bubble |
|
|
| `BrowserAddPersonEnabled` | `false` | No new Chrome profiles |
|
|
| `BrowserGuestModeEnabled` | `false` | Removes the Guest entry point from the profile menu |
|
|
| `ProfilePickerOnStartupAvailability` | `1` | No profile picker at startup |
|
|
| `PasswordManagerEnabled` | `false` | No offers to save passwords |
|
|
| `PasswordLeakDetectionEnabled` | `false` | No leak warnings |
|
|
| `BackgroundModeEnabled` | `false` | Closing the last window really ends the session |
|
|
| `CookiesSessionOnlyForUrls` | `["[*.]wonderink.org"]` | Wonder Ink should not outlive a teacher |
|
|
| `DefaultBrowserSettingEnabled` | `false` | No default-browser prompt |
|
|
| `PromotionalTabsEnabled` | `false` | No welcome tabs |
|
|
| `MetricsReportingEnabled` | `false` | — |
|
|
| `ShowHomeButton` | `true` | One obvious way back |
|
|
| `HomepageLocation` | Wonder Ink | — |
|
|
| `HomepageIsNewTabPage` | `false` | — |
|
|
|
|
`BrowserGuestModeEnabled: false` is the answer to "other profile
|
|
switching entry points". Guest mode is the one that survives
|
|
`BrowserAddPersonEnabled: false`, and disabling it is the supported
|
|
mechanism — no UI hacks. Guest mode is **not** used as the browsing
|
|
model: the room needs one persistent profile so the church YouTube login
|
|
survives.
|
|
|
|
None of this touches website logins. Wonder Ink, Google and YouTube
|
|
sign-ins are ordinary site sessions and are unaffected by
|
|
`BrowserSignin: 0`, which governs signing in to the *browser*.
|
|
|
|
## What the policies do not remove
|
|
|
|
The avatar button stays in the toolbar. Verified by screenshotting
|
|
Chrome with these policies applied and comparing against Chrome without
|
|
them: the button is in the same place either way.
|
|
|
|
What changes is what is behind it. Sign-in, adding a profile and Guest
|
|
mode are all disabled by policy, so the menu has nothing left that
|
|
creates or switches a profile. Chrome 152 has no policy that removes the
|
|
button itself — `ProfileSwitcherEnabled` and similar names do not exist,
|
|
checked against the binary — and hiding it would mean the UI hacks this
|
|
is meant to avoid.
|
|
|
|
Worth a look at the endpoint: open that menu once and confirm it offers
|
|
nothing actionable.
|
|
|
|
## Wonder Ink between teachers — CONFIRMED WORKING
|
|
|
|
Teacher A signs in, uses the room, Chrome closes, teacher B opens Chrome
|
|
and Wonder Ink is signed out, while YouTube stays signed into the church
|
|
account.
|
|
|
|
`CookiesSessionOnlyForUrls` with `[*.]wonderink.org` does it. That
|
|
pattern covers `app.wonderink.org` and every other subdomain.
|
|
|
|
**Confirmed on the physical endpoint**, which is the only place it could
|
|
be: it needs a real Wonder Ink login. It could not be established here,
|
|
and three attempts to prove the mechanism against a local test site were
|
|
inconclusive because the positive control never worked — so this was
|
|
shipped as unverified and the endpoint settled it.
|
|
|
|
Two consequences worth keeping in mind.
|
|
|
|
Wonder Ink's session is therefore **in cookies**, not in `localStorage`.
|
|
That matters because there is no per-site Chrome policy that clears
|
|
localStorage on exit: `ClearBrowsingDataOnExitList` and
|
|
`BrowsingDataLifetime` both exist in Chrome 152 but are global, and
|
|
blanket clearing would take YouTube with it. Had it gone the other way,
|
|
this would have needed a classroom-owned cleanup instead.
|
|
|
|
### If Wonder Ink login is "Sign in with Google"
|
|
|
|
`app.wonderink.org` loads Google Identity Services
|
|
(`accounts.google.com/gsi/client`), so Google sign-in is at least
|
|
offered.
|
|
|
|
If teachers sign into Wonder Ink *through Google*, clearing
|
|
`wonderink.org` will sign them out of Wonder Ink — but the Google
|
|
session at `accounts.google.com` is deliberately kept, because that is
|
|
what keeps YouTube Premium signed in. The next teacher could then be one
|
|
click from re-entering the previous teacher's Wonder Ink account.
|
|
|
|
These two requirements genuinely conflict, and which one applies depends
|
|
on how teachers actually sign in. Worth knowing before Sunday. If
|
|
teachers use Wonder Ink email-and-password accounts, there is no
|
|
conflict at all.
|