Clicking on a job/task in their respective lists will now always activate
it, regardless of where on the row was clicked.
Managing the filters by clicking on the status was a nice idea, but was
confusing in practice.
It returns 2048 bytes at most. It'll likely be less than that, as it will
ignore the first bytes until the very first newline (to avoid returning
cut-off lines). If the log file itself is 2048 bytes or smaller, return the
entire file.
Add a small wrapper around github.com/google/uuid. That way it's clearer
which functionality is used by Flamenco, doesn't link most of the code to
any specific UUID library, and allows a bit of customisation.
The only customisation now is that Flamenco is a bit stricter in the
formats it accepts; only the `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` is
accepted. This makes things a little bit stricter, with the advantage
that we don't need to do any normalisation of received UUID strings.
Implement task log broadcasting via SocketIO. The logs aren't shown in the
web interface yet, but do arrive there in a Pinia store. That store is
capped at 1000 lines to keep memory requirements low-ish.
Tabulator can't handle data changes before it's been initialised. If
there is a race condition and a job/task update comes in before that, just
ignore the update.
It might be better to use Vue's `nextTick()` function to defer the update
until Tabulator is ready to receive it, but doing so in a reliable way
might be tricky.
Fix a bug where the filter would only show available statuses and thus
make it impossible to disable a filter that's no longer available.
For example, when showing only `active` tasks, and no task is active any
more, it would remove the "filter circle" for `active` status, and thus
make it impossible to disable the filter. Now the filter will always
show all enabled statuses, even when there is no more job/task
with that status.
Fix the FFmpeg unit test on Windows, by:
- Having actual input files (otherwise the input-glob-creation-function
errors out), and
- ensuring the cleanup function is always run, and
- testing for the right CLI arguments.
Instead of having a per-setting boolean to control whether it's visible
or hidden, there are now four values:
- `visible`: always show.
- `submission`: only show in the UI of a job submitter (like a Blender
add-on).
- `web`: only show in the web interface for management, but not when
submitting the job.
- `hidden`: never show; only available to the job compiler script as
internal setting.
Without this, the tasks table would be shown (off-screen, so you'd have
to scroll to see it) when there is an active job ID, but no data loaded
due to the backend being unavailable.
Rename `pkg/api/flamenco-manager.yaml` to `flamenco-openapi.yaml`, to
distinguish the OpenAPI definition file from the Flamenco Manager
configuration file of the same name (but in a different directory).
No functional changes.
Rename `JobUpdate` to `SocketIOJobUpdate` to make it consistent with
`SocketIOTaskUpdate`.
Note that `TaskUpdate` exists as another schema, used by Workers to
update tasks they're performing.
