This is a very simple approach, where clicking on a job's status dot
toggles filtering by that status. There is no visual indication that this
filtering is active.
The Tabulator support for filtering from the headers is a bit buggy, see
https://github.com/olifolkerd/tabulator/issues/3745 -- I'm getting this
error even without `multiselect: true`.
It looks rather ugly, and this should be addressed, but without the
`height` option of Tabulator it won't be using the Virtual DOM and result
in very slow browser performance.
The selection mechanism of Tabulator was getting in the way of having nice
navigation, as it would deselect (i.e. nav to "/") before selecting the
next job (i.e. nav to "/jobs/{job-id}").
The active job is now determined by the URL and thus handled by Vue Router.
Clicking on a job simply navigates to its URL, which causes the reactive
system to load & display it.
It is still intended to get job selection for "mass actions", but that's
only possible after normal navigation is working well.
Most of the code moved from `App.vue` to `views/JobsView.vue`.
Notification bar has its own component, and there are placeholder
"views" for Workers and Settings pages.
There is still some clunky handling of updates via SocketIO, as those
are a mix of job-specific and global (like SocketIO reconnection
events). The advantage of the current approach is that SocketIO
connections are closed when you leave the Jobs page, and reopened when
you enter the Workers page. My gut feeling says this is nice because it
ensures that all SocketIO connection-specific things are cleaned up when
you navigate.
Manager now sends out task updates via SocketIO, and the web interface
handles those.
Note that there is a `BroadcastTaskUpdate()` function, but not a
`BroadcastNewTask`. The 'new job' broadcast is sent after the job's
tasks have been created, and thus there is no need for a separate
broadcast per task.
SocketIO clients can now send a message with `/subscription` event type
in order to subscribe to or unsubscribe from job-related updates.
These job-related updates themselves aren't sent yet, so this is a change
that's impossible to really test. The socketIO code for joining/leaving
rooms is called, though.
The project was created with things (components, router, views) we don't
use at the moment. To keep a clearer separation between "our code" and
"example code", I just removed the latter.
A wrapper for the generated `ApiClient` class tracks the number of running
queries. This makes it much simpler to show the "API calls pending" UI
element, regardless of which part of the webapp performs the queries.
Add a bar for "job actions", i.e. buttons that do something with the
selected job(s).
Just has one button, and it doesn't do much either, but at least the
framework for these things is here.
Use `@/path/to/file` instead of `./path/to/file`, as the former will be
valid even when used in a subdirectory (i.e. in cases where the latter
would have to change to `../path/to/file`). This makes imports uniform
and easier to copy-paste into other files.
No functional changes.
The web interface will now only show those settings that have `visible:
true`.
Probably it's a good idea to extend the job type, so that the visibility
can be controlled separately for job submission (i.e. the Blender
add-on) and job viewing (i.e. the web frontend).
