jensandClaude Sonnet 4.6
7ff4051288
Notes Mainsail (Vue 3 + TypeScript + Vuetify, uPlot for live charts) as the reference point for a future rewrite of app.js's hand-rolled DOM wiring and the still-missing Automatic/Plot tab charts. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0189FkmyJkY77HqsNomr1DwV
88 lines
5.0 KiB
Markdown
88 lines
5.0 KiB
Markdown
# web/ (browser client) vs. client/brewpi_gui.py parity backlog
|
|
|
|
`web/app.js` ported the Manual tab's direct controls and the Progress tab
|
|
wholesale from `client/brewpi_gui.py` (see README.md's "Browser client").
|
|
Everything below is what that v1 pass deliberately left out - either
|
|
flagged as deferred in the plan, or only noticed once the port was done
|
|
and checked against the Qt source side by side.
|
|
|
|
- [x] **No way to actually run a brew.** ~~There's no Start/Pause/Stop/
|
|
Confirm anywhere in `web/index.html`~~ Start/Pause/Stop/Confirm are all
|
|
wired up (`btn-sud-start`/`btn-sud-pause`/`btn-sud-stop` in `app.js`,
|
|
gated by `updateSudActions()` mirroring `update_sud_actions()`'s
|
|
enabled/disabled logic - Pause only enabled while actually running,
|
|
same as the desktop client's `actionPause`; Confirm via the
|
|
`#sud-message-dialog` below).
|
|
|
|
- [x] **`WAIT_USER` never surfaces to the user.** `showUserMessage()`
|
|
pops `#sud-message-dialog` (a plain `<dialog>`, no library) the instant
|
|
`WAIT_USER` is newly entered (`onSudChanged()`'s `State` branch tracks
|
|
`prevState` for this), and sends `{"Sud": {"Confirm": true}}` on the
|
|
dialog's `close` event - covers both the OK button and Escape, mirrors
|
|
`show_user_message()` (`client/brewpi_gui.py:877-882`).
|
|
|
|
- [x] **No schedule management.** New/Load/Save are now wired up in
|
|
`app.js`: Load is `<input type="file">` + `FileReader` +
|
|
`{"Sud": {"Load": ...}}`; Save sends `{"Sud": {"Save": true}}` and
|
|
downloads (`Blob`+`<a download>`) whichever `Json` push answers it
|
|
(tracked via `sudSavePending`, mirroring `brewpi_gui.py`'s
|
|
`sud_save_path`); New sends the same hardcoded empty-doc `Load` Qt does.
|
|
|
|
- [ ] **No temperature-controller state/cooldown indicator.** Qt shows
|
|
the raw FSM state (`label_state.setText(msg['State'])` - e.g.
|
|
`"States.HOLD"`) and a separate blinking "Cool down" label specifically
|
|
for `States.COOL` (`set_tc_cooling()`, `client/brewpi_gui.py:820-829`,
|
|
driven by `on_tempctrl_changed()`'s `'State'` branch). `app.js`'s
|
|
`onTempCtrlChanged()` never reads `msg.State` at all right now - worth
|
|
a small label in the Controller panel, reusing the same 500ms
|
|
blink-timer pattern the Progress tab's LEDs already have.
|
|
|
|
- [ ] **No transient status notifications.** Qt's status bar shows
|
|
short-lived messages on certain events - e.g. `"Sud schedule updated:
|
|
{name}"` for 5s on every `Name` push (`client/brewpi_gui.py:1043-1045`).
|
|
`web/`'s status line only ever shows the persistent Sud/env summaries;
|
|
there's nowhere for one-shot events to surface at all.
|
|
|
|
- [ ] **Nothing persists across reloads.** `client/user_config.py` keeps
|
|
the last ambient temperature and Sud file-dialog directory in
|
|
`~/.config/brewpi/gui.json` across restarts. `web/`'s ambient-temp
|
|
field always starts blank until the first `System.AmbientTemp` push;
|
|
`localStorage` would be the natural equivalent (and the host field
|
|
could remember the last-used server too, which the desktop GUI doesn't
|
|
even need since it's one app per machine).
|
|
|
|
- [ ] **No reconnect handling.** A dropped WebSocket (`ws.onclose`) just
|
|
flips the UI to "Disconnected" and stops - the user has to click
|
|
Connect again by hand. `WsClient` (`ws/client/ws_client.py`, used by
|
|
the desktop GUI) - check whether it already retries and mirror that, or
|
|
add a simple backoff retry loop in `connect()`.
|
|
|
|
- [ ] **Automatic tab (forecast-vs-actual plot) and Plot tab (live strip
|
|
charts) don't exist.** Flagged in the original plan and in README.md's
|
|
"Browser client" section as deferred pending a charting decision, not
|
|
an oversight - listed here too so this file alone is a complete picture
|
|
of the gap. `SudForecastPlot`/`RealtimePlot`
|
|
(`client/brewpi_gui.py:121-258`) are the reference for what each needs
|
|
to show. See the **uPlot** mention below - that's the leading candidate
|
|
for both.
|
|
|
|
- [ ] **UI migration to Vue.js, charts via uPlot.** `app.js` is vanilla
|
|
JS with hand-rolled `document.getElementById`/`textContent` wiring for
|
|
every piece of state (see its own intro comment) - workable for v1's
|
|
scope, but every new feature (Pause, the Confirm `<dialog>`, ...) is
|
|
more manual DOM plumbing, and there's no charting at all yet (previous
|
|
item). Mainsail (the Klipper web UI - a comparable "control a piece of
|
|
hardware over a persistent WebSocket" app) is the reference point for
|
|
both: **Vue 3 + TypeScript + Vuetify** for reactive state-to-DOM
|
|
binding instead of this file's manual updates, and **uPlot** for live
|
|
charts specifically - it's canvas-based and fast enough for
|
|
high-frequency ticks (this server pushes `Elapsed`/`Ist` on every tick),
|
|
unlike heavier libraries like Chart.js. A bigger lift than anything
|
|
else in this file - revisit once the rest of this backlog (or at least
|
|
the charting item) makes it worth the rewrite, not before.
|
|
|
|
- [ ] **No authentication.** Also already called out in README.md - matches
|
|
the WebSocket server's own complete lack of it, not a new gap, but
|
|
worth a line here too since "browser, reachable from anywhere on the
|
|
network" is a wider exposure than the desktop app ever was.
|