If a node's description contains invalid operations in its `onNodeCreated`
method, exceptions are thrown without being caught and cause Meshroom
to crash.
These calls are now safely tried and any encountered exception is handled.
If the edges of a node to submit include an `InputNode` (which cannot
be computed), then that node should be excluded from the list of edges
to process as if that node had already been computed.
This allows to submit any type of graph involving `InputNode` to the farm.
For dynamic output attributes, the UID does not depend on the attribute
value.
In particular, when loading a project file, the UIDs are updated first,
and the node status and the dynamic output values are not yet loaded, so
we should not read the attribute value.
internalAttributes are managed on the Meshroom side, not at the node
level. So there is no reason to call the upgrade of internalAttributes
on the node description.
Add new type of ChoiceParam that changes dynamically according to other
values.
When value of an attribute is changed onAttributeChanged is called,
allowing to have unique reaction within node files.
Also add of callDesc function to be able to have other functions such as
onNodeCreated at creation of node.
For instance, on the Meshing node "outputMesh" param expression is:
value="{cache}/{nodeType}/{uid0}/mesh.{outputMeshFileTypeValue}",
So the extension here should not contains quotes.
We have the problem of spaces in file paths, choices (like colorspace),
etc.
An empty list is not send to the command line.
An empty string is send to the command line as "".
Add new unit test to ensure it follows the expected rules.
Chunks of that node that are already in the `SUCCESS` state will not be
updated, and those that are `SUBMITTED` but not `RUNNING` will be reset
to `NONE`.
If a node has a user-set label (defined through the internal attributes
of the node), its default name (the one that is displayed if no label
has been set) will be displayed next to it.
This allows to find quickly the correspondence between the node's label
and its type / how it is referred to in the current graph's file.
The `UidConflict` is not detected per se within the node factory as a
node's UID cannot be computed accurately from there, since its expressions
(which may impact the UID computation) have not been resolved yet.
Instead, the `UidConflict` is detected externally, and the information
is transferred to the node factory, which will create a corresponding
compatibility node with the regular process.
The created `UidConflict` compatibility node will be handled by the
Compatibility Manager like any other compatibility node.
