20007238be1f5680e6526fcbc14a6a945bc3a98c
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ekklesiaandClaude Opus 5
|
0e91b4cbd3 |
fix: keep the dock's Close button reachable
The Close button followed focus, and moving the pointer down to the dock moves focus off the popup. So the button disappeared somewhere on the journey to it, and a secondary Chrome window could not be closed with a mouse at all. Found on the endpoint; my fault. The target is remembered instead. Once a secondary window has been focused the dock keeps offering to close it, and losing focus — to the dock, the main browser, a print dialog, any layer-shell surface — changes nothing. It moves on only when that window closes or another secondary takes over, and it falls back to another open secondary rather than to nothing, so cancelling a print dialog leaves the render window still closeable. It is chosen from the secondary list, which never contains the first window, so it can never name the main browser. Restoring the floating role to a window that already existed no longer moves or focuses it. Moving it would undo wherever the teacher dragged it; focusing it would raise the render window over the print dialog sitting above it, which is one way the print flow was getting disturbed. Verified by driving a real pointer through the exact path that was broken: pointer over the popup, click to focus, then travel down to the dock in steps, screenshotting throughout. The button is still there on arrival, at 992,1041. Then the print flow: main browser, render window and a separate Print dialog, pointer to the dock, button still there, and killing the dialog leaves the render window as the new target with the main browser untouched. The button's own action could not be actuated in that harness, because synthetic pointer input does not reach Wayland clients under headless sway — the Browser button does not respond to it either. The action was run directly instead, closing exactly the remembered container and leaving main Chrome alive. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
f65c814eff |
fix: put the popup close button in the dock, and clear the printer location
Three things, none of them redesigns. The close affordance for a secondary Chrome window was a separate layer-shell surface anchored to that window's corner, repositioned by a five-per-second poll. Any position change tore the surface down and built another, so on real hardware it chased the window and flickered. Removed entirely: the GTK button process, the geometry maths that placed it, the --close-button mode that spawned it, and the poll loop that drove it. The window helper no longer imports GTK at all. The behaviour underneath it was right and is kept. The first Chrome top-level is the classroom browser, tiled and borderless; later ones float centred at about three quarters of the output. Creation order is the only thing that can tell them apart — confirmed on a real session, where every Chrome top-level shares app_id, shell, PID and a null transient_for, and sway exposes no window properties for Wayland toplevels at all. Titles are still not used. It now follows sway's own window events instead of polling, so dragging a popup costs nothing. Close moved into the dock, which was already on screen and does not move, so it cannot chase anything. It appears only while a secondary window is focused and runs kill on that one container. The helper publishes which window that is; the dock watches the file rather than polling. A stock sway title bar has no close button, so restoring the border would not have solved this either. Two bugs found by looking rather than by testing state. Chrome renegotiates the size of a popup opened with explicit dimensions after the resize returns, which left windows centred for a width they no longer had; placement now settles and repeats once, at creation only, so dragging is still free. And the dock's Close button came up empty because show_all does not recurse into a no-show-all widget. The printer's Location is now blank. CUPS prints it under the queue name in every dialog, so "Ekklesia Classroom" was a second line the teacher had to read past; the identity is one word. The already-configured check includes Location, so a machine set up before this is corrected rather than left as close enough. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5
|
a1a218b29f |
fix: draw classroom icons at the display's real pixel density
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]> |
||
|
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]> |