`make publish-release-packages` uploads the release packages for the
current version of Flamenco. Note that it does NOT build those, so run
`make release-packages` beforehand.
If there are no jobs in the database yet, show a "get the addon" call to
action. This includes the current API URL, which can be copied by clicking
on it.
There is no feedback yet that the copy took place, though.
The blocklist is now shown in the job details, in its own tab. The list
is only fetched when the tab is visible, and doesn't get dynamically
updated yet.
Remove a whole lot of `console.log()` calls. They were useful during
development, but not really suitable for production environments. Because
they also include (potentially large) objects, they can even slow down
the webapp itself.
The website (which is available in the sources as well) contains all the
information from the README already. Having only one source of information
is good for maintainability.
For some reason, calling `AssocQueryStringW` on Windows Home returns error
code 122, "The data area passed to a system call is too small", even when
the data area is large enough. Furthermore, the API actually describes that
in such cases `S_FALSE` is supposed to be returned, with `*pcchOut` set to
the required size. Because of this apparent violation of the documentation,
and because it just works, Flamenco now ignores this particular error and
just returns the obtained string.
Convert the database interface from the stdlib `database/sql` package to
the GORM object relational mapper.
GORM is also used by the Manager, and thus with this change both Worker
and Manager have a uniform way of accessing their databases.
The Manager now broadcasts a worker update to SocketIO clients when a
worker gets a new task assigned. This ensures the "current task" shown in
the worker details view is up to date.
The etag prevents job submissions with old settings, when the job
compiler script has been edited. The etag is the SHA1 hash of the
`JOB_TYPE` dictionary (as defined by the JavaScript file). The hash is
computed in a way that's independent of the exact formatting in the
JavaScript file. Also the actual JS code itself is irrelevant, just the
`JOB_TYPE` dictionary is used.
Whenever the URL to Flamenco Manager is updated, check it and report.
This required moving the 'ping manager' code into a separate function, as
calling an operator from an RNA update callback is not a good idea.
The concept of "job types" is more important. The fact that they are
defined by scripts is secondary. I've also added more documentation about
the settings & task types.
Blender cannot be told to only allow absolute path for an RNA property
(of type `string`, subtype `dir_path`), so as a workaround the final
`render_output_path` is now using `bpy.path.abspath()` to make the path
absolute.
This has as advantage that the render output path can be defined by artists
as a blendfile-relative path, and that it'll be resolved when submitting
the blend file.
For each job setting, if it's visible and has an `eval` property, it is now
evaluated immediately when switching job types. This means that properties
like the frame range get filled in automatically.
If there is already a value, this process is skipped, in order to not
overwrite the user's choice.
This resolves a common issue where the render job was rejected because
the frame range was kept empty.
Refactor the `FLAMENCO_OT_submit_job.poll()` function to actually use the
`job_types.active_job_type()` function instead of reimplementing similar
logic.
No functional changes.
