Omapresent 0.1.3

Omapresent 0.1.3

A single-fix patch release: the audience window's video Play button works with
a real mouse.

The fix

• Clicking a deferred video loader in the separate audience window now
  highlights on hover and starts the video, with a real pointer, on a real
  desktop. A key pressed straight after that click still moves the
  presentation instead of disappearing into the page.
• The built-in welcome deck gains a "What's different?" slide, and its QR-codes
  slide is now tagged --- {r}, so the deck demonstrates a second recall key
  alongside the existing q.

What 0.1.2 got wrong

0.1.2 said "embedded players respond to the mouse again". That was half true,
and the wrong half was the one you could see.

0.1.2 removed a full-window pointer overlay in the audience window that was
swallowing hover and click. That overlay was real, and removing it was
necessary — but it was not the only thing in the way. The same file also set
activeFocusOnPress: false on its web view, to stop a click on a video from
taking the keyboard away from the key handler. Qt WebEngine's delegate does
more than refuse focus for that setting: while the view neither holds active
focus nor may take it on press, it drops the whole pointer stream before
Chromium ever sees it — hover included. Measured on Qt 6.11.2, mouseover,
mousedown and click each arrived zero times with the property set and once
each without it.

So after 0.1.2 the Play button in the audience window was still dead to the
mouse, while the editor preview, which never set the property, kept working.
0.1.3 lets the press through and hands the keyboard back on the following turn,
once the page has had the event, so both halves hold at once.

The fault was never in stacking, CSS, pointer-events or layout —
elementFromPoint found the button either way.

Verification

A regression test drives the production AudienceWindow.qml and the real
qrc renderer, waits for the production loader, reads the loader's own
getBoundingClientRect(), and synthesizes a native press at that centre
through Qt's normal delivery path. It asserts the page's own listeners saw
mouseover, mousedown and click, that the loader matched :hover, that
the production click handler started activation, and that Right pressed
straight afterwards advances the deck. It fails on the original defect at the
hover assertion, and on the naive fix — dropping the property with no
hand-back — at the keyboard assertion.

The fix was also confirmed by hand, with a real mouse, in the separate audience
window on Hyprland/Wayland. That is the check the automated suite cannot make
on its own.

Unchanged

Wheel scrolling from the audience window, every presentation key from either
window, the presenter's controls, the audience window's independent Wayland
top-level identity, offline behaviour and the editor preview are all untouched.

Upgrading: no deck, settings or skill changes are required.

Created by Claude Opus 5 on 2026-08-30 21:10 PT on ombee