OP#10281: Add the browser progressbar for long operations

[randy-seng]

What this does

Correction (scope). This PR delivers the progress model and the widget, not the wiring. No production caller builds a progressbar on this branch: LoadTrackFiles and Datastore take a ProgressbarBuilder and never call it, and the only self._progressbar(...) call site reachable from the web UI (PandasTrackProvider._convert_tracks) is skipped because the default dataset is Polars. Loading tracks in the browser still shows nothing until #840 (OP#10282) adds ProgressbarBuilder.start() and calls it from LoadTrackFiles. Struck-through text below overclaims and is kept for the record.

Long operations in the web UI showed nothing. OtAnalyticsNiceGuiApplicationStarter still wired TqdmBuilder, so progress for loading tracks or running analysis went what progress reporting exists goes to the console the browser user never sees. This branch adds NiceguiProgressbar, a persistent dialog showing item counts, a determinate bar, the last completed item, and a cancel button, and points progressbar_builder at NiceguiProgressbarBuilder. The CLI keeps tqdm.

Why

Progress belongs to the application layer, the widget to the UI, so the state is split: ProgressState in OTAnalytics/application/progress.py owns description, fraction, message, and finished, driven by the existing Counter abstraction; NiceguiProgressbar only renders it. Driving the bar by Counter rather than by iteration position matters because completions from concurrent work do not arrive in sequence order — hence complete(item) alongside the iterator path in __call__.

Cancellation is deliberately a plain flag, not asyncio.Task.cancel(). The work being cancelled is a synchronous loop over a sequence — parsing tracks, calculating events — which never yields control while it runs. There is no moment at which something from outside could interrupt it, so the only way to stop it is for the loop itself to check a flag between items. Making that work asynchronous purely to gain an interruption point would mean reshaping the operations themselves, which is far more than showing a progressbar is worth. The asyncio.Event inside is for the other side: it lets the UI await cancellation instead of polling for it.

Notes for the reviewer

Start with NiceguiProgressbar.open() in plugin_ui/nicegui_gui/nicegui/progressbar.py:74. Two early returns carry real behaviour rather than defensiveness:

• context.client.is_auto_index_client — during --config preload at startup there is no browser client, and building a dialog then raises. Progress is still tracked; only the rendering is skipped.
• self._state.finished — an empty operation would otherwise open a dialog nothing can ever close, because only a progress update reaches _refresh and closes it.

_refresh closing the dialog on finished is the only close path besides cancel; if a caller reports fewer completions than total, the dialog stays open. That is the persistent prop's cost and the reason the cancel button exists.

NiceguiProgressbarBuilder.progressbar exposing the most recent bar is a seam for the concurrent-loading work, not used yet.

Risk and rollout

Nothing outside the NiceGUI starter changes; plugin_progress.tqdm_progressbar.TqdmBuilder is untouched and still used by the CLI (guarded by a new test). Worst case in the browser is a dialog that stays open after work finishes — visible immediately, and revertible by restoring the single line in nicegui_application.py:241. Since nothing builds a progressbar yet, browser behaviour is unchanged by this PR; the dialog-stays-open risk becomes real with #840 and is revertible by restoring the single line in nicegui_application.py:241.

Cancellation has no consumer in this branch beyond the cancel button setting it; pressing cancel closes the dialog but does not yet stop the running operation.

Testing

uv run pytest on the four new/changed test modules: 27 passed. Covers counts and current item, cancel setting the signal, auto-close at completion, the builder's iterator path, empty sequences, replacing a previous bar, and both no-browser cases.

Still to verify by hand: an actual track load in the browser — a track load shows nothing on this branch, so that check belongs on #840. Worth verifying here: that --config preload startup is unaffected.

Follow-ups

#840 (OP#10282) wires the progressbar into LoadTrackFiles and moves parsing off the event loop.

Wire Cancellation into the operations themselves so cancel aborts the work, not just the dialog.

OP#10281