Temporary workspace restore: Wonder Ink brings back the teacher's recent
tabs for two hours after they last used it — never the sign-in, which
WonderInk keeps as a Basic-auth password and which is not stored. The
admin-only link bubble is documented, not overridden.
Published to canary: ekklesia-classroom_0.2.6.4_amd64.deb, sha256
80388e7ac3d9a1a266ebc3454f64808b6a0e2cd75b06fa934caf9f2a25026253, gated
on that file as an upgrade from 0.2.6.3 and from 0.2.2. 0.2.6.3 and
0.2.6.2 are on the server as they were; latest.deb and the manifest read
back over HTTPS as 0.2.6.4. Stable still answers 0.2.2; nothing here
wrote to it. No desktop is affected.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Black and white is shown in the preview as it prints, and CUPS is given
the file shown; right-click on a picture in a lesson offers Print image,
which prints that picture with the picture layout, and Print page.
Published to canary: ekklesia-classroom_0.2.6.3_amd64.deb, sha256
2b8f26409b5374f08e8d461d8c711307d5180c3b120654df0150a587b7d64710, gated
on that file as an upgrade from 0.2.6.2 and from 0.2.2. 0.2.6.2 is still
on the server as it was. Stable still answers 0.2.2; nothing here wrote
to it. No desktop is affected.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Pictures print as the picture — no black bars — at the size and place a
teacher chooses; a presentation that runs out of memory says so and can
be tried again, and the import service survives it; and a notification's
Configure button no longer opens KDE's settings under the teacher account.
Published to canary: ekklesia-classroom_0.2.6.2_amd64.deb, sha256
a7ca958ac8352bb194a2685e4339fe8cafceb5fee871e4c023402c7320945618, gated
on that file as an upgrade from 0.2.6.1 and from 0.2.2. 0.2.6.1 is
still on the server as it was. Stable still answers 0.2.2; nothing here
wrote to it. The laptop is offline and will take this when it is next
on; no desktop is affected.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Wonder Ink prints — lessons and worksheets, through a preview — without
the 0.2.2 crash; lessons are the size the browser shows them and zoom;
the tab strip looks like the classroom; and four-part versions work end
to end, with a published version never used again.
Published to canary: ekklesia-classroom_0.2.6.1_amd64.deb, sha256
7bd3aabfbbd6f727be87fea366ecaefb40bd5ada37124c96703e8b9ccf510bc3.
Gated on that exact file as an upgrade from 0.2.6 (the laptop) and from
0.2.2 (the desktops). Stable still answers 0.2.2 and nothing here wrote
to it; the three desktops are unchanged until paper comes out of Elmer
and the owner approves — see docs/testing.md.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Presentations, the teacher's manual, and the Wi-Fi hand-over fix.
Canary only. The three classroom desktops are on CHANNEL=stable, which
still answers 0.2.2 and which nothing here has written to.
The prayer-room laptop is the one machine this is for, and its Wi-Fi is
already NetworkManager's — `classroom-wifi --adopt` reports "nothing to
adopt" on it and changes nothing, which is asserted by a test rather
than remembered.
Note for whoever installs it: this release adds LibreOffice and the font
set, so the upgrade fetches 216MB across 186 packages from Debian's
mirrors. It needs the network up at the time and it is not a five
minutes before the study job.
Co-Authored-By: Claude Opus 5 <[email protected]>
The release validator caught it: in a container there is no
/etc/network/interfaces at all, and a missing file was being treated as
a read failure, so --check printed nothing and said nothing was wrong
rather than saying there was nothing to do.
A machine with no ifupdown configuration is the ordinary case for a
fresh install, and the answer is simply that this command has no work.
Co-Authored-By: Claude Opus 5 <[email protected]>
The housekeeping release: independent feature settings, the Bible study
laptop's display mode, the Wi-Fi credential rules, the panel order and the
permanent download addresses.
0.2.3 is already published and installed on the canary, so it is left
exactly as it is. Stable stays at 0.2.2 and the stable manifest is not
touched by this.
Co-Authored-By: Claude Opus 5 <[email protected]>
The audio reliability fix, built as its own version. 0.2.2 is already
published and installed on the rooms, so it is left exactly as it is.
Stable stays at 0.2.2 and the stable manifest is not touched by this.
Co-Authored-By: Claude Opus 5 <[email protected]>
0.2.1 is already published to canary and a rebuild of it would be
different bytes under a version somebody has already installed, so the
worksheet fix goes out as its own version.
Stable stays at 0.2.0 and the stable manifest is not touched by this.
Co-Authored-By: Claude Opus 5 <[email protected]>
The version the two 0.2.1 features are built as. Stable stays at 0.2.0
and the stable manifest is not touched by this.
Co-Authored-By: Claude Opus 5 <[email protected]>
0.1.50 was taken to the church and the things a container cannot answer
were answered on the hardware: boot, autologin, the panel after a reboot,
panel and browser scaling, Wonder Ink, Parent Call opening in the corner
and reaching the sanctuary with a typed name, readable and silent
notifications, HDMI audio and the volume keys.
The promotion is a fast-forward. The experiment was cut from the
published stable source and never diverged from it, so master reaches
this work without a merge and there is one history.
One thing changed for the release. The channel rules turn around:
classroom-v2 and hyprland are the obsolete channels now and a room on
either comes home to stable, while canary — where the next development
release goes — and any channel somebody named by hand stay where they
were put. A fresh installation has always defaulted to stable.
Nothing else moved. This is the 0.1.50 that was verified, with a version
number and a channel rule.
Co-Authored-By: Claude Opus 5 <[email protected]>
The render helper sat on top of the Print dialog, so the dialog could
not be reached and nothing could be printed.
Two causes. The daemon could not see window titles at all — the tree
walk never collected them — and both windows arrive close enough
together to be configured in the same pass, in whatever order the tree
lists them. Configuring a window focuses it, so whichever was done last
ended up in front, and that was not reliably the dialog.
The dialog is now recognised by its exact title and configured last, and
if a Chrome popup takes focus while it exists, focus is handed straight
back. Focus is only ever reclaimed from another popup: clicking the main
browser or the dock is the teacher's business and is left alone.
A title match, narrowly, and only for this one known dialog. Creation
order still decides which Chrome window is the browser; nothing else is
classified by what it happens to be called.
Nothing auto-closes the helper. After Print is cancelled it stays, and
the sticky dock X still closes it.
Proven by looking rather than by state. The render window is given a
saturated background in the fixture so a screenshot answers "which
window is in front" unambiguously: Print opens in front, the helper is
then deliberately raised over it and Print comes back in front,
cancelling Print leaves the helper visible with the dock X still
offering it, and that X closes exactly the helper and leaves the main
browser untouched.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
Published as 0.1.42 rather than the intended 0.1.41: update_canary.sh
increments from VERSION, which local builds had already advanced to
0.1.41. The content is the tested tree either way, and going back to a
lower number would leave a canary that nothing already on 0.1.42 would
accept.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
