Compute render output path when evaluating job settings, which is done
within the Flamenco add-on, instead of in the job compiler script. This
allows the UI to show the render path, rather than it only being known
after the job has been submitted.
This might not be the best way to do things, but it is very flexible and
allows TDs to determine the behaviour in their own job compiler script.
It doesn't allow a preview of "this is what the final render path will be"
in the Blender GUI though.
4196460c29a607e1d3d2d052bf2bf546d5c05616 changed the name of the job
setting used to communicate the input blend file path, but the tests
weren't updated for this.
The add-on code was copy-pasted from other addons and used the GPL v2
license, whereas by accident the LICENSE text file had the GNU "Affero" GPL
license v3 (instead of regular GPL v3).
This is now all streamlined, and all code is licensed as "GPL v3 or later".
Furthermore, the code comments just show a SPDX License Identifier
instead of an entire license block.
Both Go's standard `path` and `path/filepath` packages are too limiting to
work well for Flamenco. The former assumes Linux/POSIX paths, the latter
only works with platform-native paths. Neither can work with Windows paths
on Linux, or Linux paths on Windows.
Some parts of Flamenco had a Command consist of "name + settings", and
other parts used "type + parameters" (with the same semantics). This is
now unified to "name + parameters".
Add `subtype` and `editable` fields:
- `subtype`: to distinguish between regular strings, file paths, dir paths,
etc.
- `editable`: To indicate a setting should be editale after submitting the
job. Editing will trigger re-compilation of the job.
Each job compiler script now must define a `compileJob(job)` function,
which will be called by Flamenco when necessary.
This makes it possible to run the script without a job, and get other
exported symbols from it, such as metadata about which settings its job
type needs/exposes.
