Add a "Last Rendered" view to the webapp.
The Manager now stores (in the database) which job was the last
recipient of a rendered image, and serves that to the appropriate
OpenAPI endpoint.
A new SocketIO subscription + accompanying room makes it possible for
the web interface to receive all rendered images (if they survive the
queue, which discards images when it gets too full).
It doesn't update automatically yet (still needs SocketIO notifications),
and there is no check yet for whether there is actually any last-rendered
image at all, but at least there is a component that shows the image.
When data is updated, resize columns in the job/task/worker tables. For
example, status change requests of Workers require more space, for example
going from `awake` to `awake → offline`.
Having only the status dot was hard to read. It requires you to learn &
remember the different colours, or to mouse-over and wait to see the
tooltip. For accessibility, we shouldn't be using just the colour to
convey information in the interface.
The 720px was almost filling up the entire height, making it hard to add
anything new at the top. Soon it should be auto-resizing anyway, making
this less relevant.
UI/UX needs improvements, but there now are some buttons to manage Workers.
They request forced status changes, so nothing lazy yet. Still have to
consider how to include that in the UI. Could probably follow the
Flamenco 2 Manager design.
Making the UUID optional (rF221ed17fa27193086ec5c9201d48f7cd826e75a4) made
the generated JavaScript code ignore the 3rd parameter. Apparently the
constructor parameters are only for the mandatory properties, and the
rest has to be set on a per-property basis.
SocketIO clients no longer automatically subscribe to the jobs updates.
This is now done explicitly via the `allJobs` subscription type, and
unsubscribing is also possible.
The tasks table resize function is called via `this.$nextTick()`, which
means that the component can actually already be unmounted by the time
the actual function call is performed. This is now detected & handled.
Show workers with their status, and allow clicking on a worker to activate
it and show its details (which currently is limited to just its ID). Does
include Vue Router handling of the active worker ID and CSS classes for
worker statuses.
This basically copies the `JobsTable` component to `workers/WorkersTable`.
The intention is that all the jobs-specific components will move into a
`jobs` subdirectory at some point.
The `JobDetails` component now emits a `reshuffled` event whenever its
contents have changed, so that other components can respond to any changes
in available space. This event now triggers a resize of the tasks table
on the next DOM tick (so that the new sizes of the HTML elements are
available).
The `TasksTable` component also recomputes the table size when the task
status filters change (because that might have triggered a show/hide of
the filter bar). It also computes the available height slightly differently
so that it's all done relative to the tabulator element.
There is just one TODO left, which is a hard-coded offset of 12 that
should be obtained dynamically from somewhere -- no idea where it comes
from or why it's necessary.
Calculate the Tasks List height by subtracting its offsetTop from
the Jobs Details column height.
Known issues:
There is a glitch in which the height can be sometimes longer or shorter
than expected, due to asynchronous loading of other components in Job Details
(such as Job Settings or table filters).
The code to fetch the task log tail is moved from `JobsView.vue` to
`TaskLog.vue`, as that knows exactly when it's shown & hidden.
The subscriptions to the task log updates will have to be managed in the
same way; that's for another commit.
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.
