jens/brewpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

feat: replace modal user-confirm dialog with persistent flashing button

Browse Source 
Both clients used a modal OK dialog for a Sud step's WAIT_USER
confirmation (e.g. "Bitte Malz einfuellen und bestaetigen"). Replaced
with a persistent "Confirm" control in the top toolbar/header instead:
flashes yellow with the step's message while pending, and modally
disables the rest of the GUI (main content plus Start/Pause/Stop/
New/Save/Load, and Connect) until it's clicked - forcing the pending
step to be dealt with first. Disabled and blank otherwise.

client/brewpi_gui.py: set_user_confirm_pending() drives a QTimer blink
(same pattern as the existing "Cool down" indicator) and disables
centralwidget + the relevant toolbar QActions individually, so the new
button (a toolbar sibling) stays enabled; Start/Pause/Stop are restored
via update_sud_actions() rather than a blanket re-enable.

web/app.js: setUserConfirmPending() toggles a 'confirm-pending' class
(CSS @keyframes flash, matching the file's existing animation-by-class
convention) and a 'modally-disabled' class on #layout; also wired into
ws.onclose so a dropped connection doesn't leave the page stuck modally
disabled on a confirm that'll never resolve.

Also fixes a message-ordering race in both clients (found testing the
web version on an iPad, connecting fresh while a step was already
WAIT_USER): a step's UserMessage is set once when the step starts, well
before State later flips to WAIT_USER, so an already-connected client
sees them at genuinely different times - but a client connecting fresh
gets both bundled into one replayed snapshot, where State's key can
sort before UserMessage's. Processing State first checked the pending
guard before that same message had set the text, silently failing it
and leaving the button looking merely disabled. Both onSudChanged()/
on_sud_changed() now force UserMessage (and, in the web client, Json)
to process before State/Step regardless of the bundled dict's key
order, same pattern already used for the pre-existing Json-before-Step
case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M2ierBoxW3v7nUbDw3M2pE
This commit is contained in:
jens
2026-07-06 11:57:23 +02:00
co-authored by Claude Sonnet 5
parent 6d1429daca
commit 3b34f52bb0
4 changed files with 168 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files
web/app.js
+49 -12
View File
@@ -582,12 +582,34 @@ function updateClosedLoopStatus() {
statusEl.className = `panel-status ${closedLoop ? 'status-connected' : 'status-disconnected'}`;
}
// Mirrors client/brewpi_gui.py's show_user_message(): the Sud is already
// blocked in WAIT_USER server-side - dismissing this dialog (OK or Escape,
// both fire the dialog's 'close' event) is what unblocks it.
function showUserMessage(message) {
document.getElementById('sud-message-text').textContent = message;
document.getElementById('sud-message-dialog').showModal();
// Mirrors client/brewpi_gui.py's set_user_confirm_pending(): a persistent
// header control rather than a modal dialog. While pending, the Confirm
// button flashes yellow with the step's message and #layout (everything
// except the header) is modally disabled via the 'modally-disabled' class
// (opacity + pointer-events:none - see style.css) so the pending step has
// to be dealt with before anything else. The Sud is already blocked in
// WAIT_USER server-side; clicking Confirm is what unblocks it.
let userConfirmPending = false;
const CONFIRM_DISABLE_IDS = ['btn-connect', 'btn-sud-start', 'btn-sud-pause', 'btn-sud-stop',
'btn-sud-new', 'btn-sud-load', 'btn-sud-save'];
function setUserConfirmPending(pending, message = '') {
if (pending === userConfirmPending) return;
userConfirmPending = pending;
const btn = document.getElementById('btn-user-confirm');
document.getElementById('user-confirm-text').textContent = pending ? message : '';
btn.disabled = !pending;
btn.classList.toggle('confirm-pending', pending);
document.getElementById('layout').classList.toggle('modally-disabled', pending);
for (const id of CONFIRM_DISABLE_IDS) {
document.getElementById(id).disabled = pending;
}
if (!pending) {
// Start/Pause/Stop depend on sudState/sudEmpty/connected, not just
// "was disabled for confirm" - let the usual logic pick the right
// one back up rather than assuming all should simply re-enable.
updateSudActions();
}
}
function downloadJson(doc) {
@@ -755,7 +777,19 @@ function onSudChanged(msg) {
// Processing Step first would set sudStepIndex before the schedule
// exists, then Json would reset it to null (isNewSchedule=true on
// first/reloaded connect) with no subsequent Step to restore it.
const keys = ['Json', ...Object.keys(msg).filter(k => k !== 'Json')];
//
// UserMessage must likewise be processed before State: a step's
// user_message is set once, when the step starts (components/sud.py's
// _advance()), well before state later flips to WAIT_USER
// (_finish_step()) - so UserMessage's key was inserted into
// global_state earlier in the server's lifetime and would otherwise
// precede State here too. A client connecting fresh mid-confirm gets
// both bundled into this same replay message; processing State first
// would check sudUserMessage before this very message has set it,
// silently failing setUserConfirmPending()'s guard and leaving the
// Confirm button looking merely disabled instead of pending - the
// same race the old modal dialog had, just never noticed until now.
const keys = ['Json', 'UserMessage', ...Object.keys(msg).filter(k => k !== 'Json' && k !== 'UserMessage')];
for (const key of keys) {
if (!(key in msg)) continue;
if (key === 'Json') {
@@ -791,10 +825,9 @@ function onSudChanged(msg) {
sudState = newState;
updateControlsEnabled();
if (newState === WAIT_USER_STATE && prevState !== WAIT_USER_STATE && sudUserMessage) {
showUserMessage(sudUserMessage);
setUserConfirmPending(true, sudUserMessage);
} else if (prevState === WAIT_USER_STATE && newState !== WAIT_USER_STATE) {
const dlg = document.getElementById('sud-message-dialog');
if (dlg.open) dlg.close();
setUserConfirmPending(false);
}
updateStepPlates();
updateSudActions();
@@ -945,6 +978,11 @@ function connect() {
for (const id of ['temp-soll', 'heatrate-soll', 'heater-power', 'stirrer-speed', 'closed-loop']) {
document.getElementById(id).disabled = false;
}
// Nothing reported over a dead connection can be trusted anymore -
// don't leave the page modally stuck on a pending confirm that'll
// never resolve now (mirrors client/brewpi_gui.py's disconnect
// handling).
setUserConfirmPending(false);
setConnected(false);
};
ws.onmessage = (event) => {
@@ -1053,8 +1091,7 @@ document.getElementById('btn-sud-pause').addEventListener('click', () => {
document.getElementById('btn-sud-stop').addEventListener('click', () => {
sendMsg('Sud', {Stop: true});
});
document.getElementById('sud-message-dialog').addEventListener('cancel', e => e.preventDefault());
document.getElementById('sud-message-ok').addEventListener('click', () => {
document.getElementById('btn-user-confirm').addEventListener('click', () => {
sendMsg('Sud', {Confirm: true});
});