PyOPIA's process command only shows real progress via a Rich TTY progress
bar (invisible when run non-interactively, e.g. via Docker without -t,
which is how pyopia-gui always invokes it) or DEBUG-level log lines -
pyopia-gui's Process tab currently just streams raw log output with an
indeterminate spinner, no real percentage/ETA.
SINTEF/pyopia#423 requests
a machine-readable progress option; a --progress-file flag implementing
it is on the pyopia-gui-support staging branch
(SINTEF/pyopia#435, commit
8c719fd) - not yet merged to main.
Once available, wire it into the Process tab's "Run processing" flow -
poll the progress file alongside the existing log streaming, and show a
real progress bar/percentage/ETA, matching the pattern already used for
Raw data explorer's thumbnail generation (ui.linear_progress + a status
label, not just a spinner).
Blocked on SINTEF/pyopia#423/#435 landing in a real release - revisit once
that's in place.
PyOPIA's
processcommand only shows real progress via a Rich TTY progressbar (invisible when run non-interactively, e.g. via Docker without
-t,which is how pyopia-gui always invokes it) or DEBUG-level log lines -
pyopia-gui's Process tab currently just streams raw log output with an
indeterminate spinner, no real percentage/ETA.
SINTEF/pyopia#423 requests
a machine-readable progress option; a
--progress-fileflag implementingit is on the
pyopia-gui-supportstaging branch(SINTEF/pyopia#435, commit
8c719fd) - not yet merged tomain.Once available, wire it into the Process tab's "Run processing" flow -
poll the progress file alongside the existing log streaming, and show a
real progress bar/percentage/ETA, matching the pattern already used for
Raw data explorer's thumbnail generation (
ui.linear_progress+ a statuslabel, not just a spinner).
Blocked on SINTEF/pyopia#423/#435 landing in a real release - revisit once
that's in place.