* API
Instead of having a single `load` function that exposes in its API
some elements only applicable to initializing a graph from a templates,
split it into 2 distinct functions: `load` and `initFromTemplate`.
Apply those changes to users of the API (UI, CLI), and simplify Graph
wrapper classes to better align with those concepts.
* Deserialization
Reduce the cognitive complexity of the deserizalization process
by splitting it into more atomic functions, while maintaining the
current behavior.
The 'isSaving' flag is a way to identify if the project is currently being saved and serves as a way to correctly distinguish whether the current filepath change is due to a save or a new scene or a load operation
Provide a way to control how to handle node compatibility issues
when loading a Graph with the `strictCompatibility` parameter.
Introduce a new error type, GraphCompatibilityError, to be raised
when loading a Graph with compatibility issues with strictCompatibility enabled.
The file version is updated and support for files with an older version
is added: upon detecting that the file version is old, the old UID
keys will be detected and reformatted with new ones so the file can
be properly loaded.
The UID system based on a UID index is removed and replaced by a single
UID per node.
Attributes will be included in the UID computation if the `invalidate`
is set to `True` in their description. This replaces the `uid=[]` /
`uid=[0]` element of the description.
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.
The `selectedViewpoint` property will store the attribute corresponding to
the actively selected viewpoint, if it exists. Otherwise, it will be set
to None.
The behaviour regarding `ListAttributes` was different depending on
whether an edge or a node was removed:
- if an edge was removed, the `ListAttribute` that was the destination
of that edge had its corresponding element completely removed;
- if a node was removed, the `ListAttribute` that was the destination
of one of the node's edges had its corresponding element reset, but not
removed.
With this behaviour, a user had different UIDs depending on whether
a single edge or the whole node had been removed where the UID should
always be identical.
Up until this commit, compatibility nodes (which necessarily had a version
or description issue) were ignored during the evaluation of UID conflicts,
as they had no UID.
This however created a bug, where already existing compatibility nodes
with inputs from nodes that triggered UID conflicts were losing their
input connections: when the node with the UID conflict was replaced with
a new compatibility node (with a UID conflict issue), the link was broken
and could not be resolved anymore as it lost any mention of the input
node's name. This was also valid for nodes without any compatibility issue
which had UID conflicted-nodes as their inputs.
Processing all the nodes in addition to those with a UID conflict issue
prevents this from happening: edges are correctly preserved.
This also fixes an issue that occurred when opening a project file that
contained nodes whose type was not recognized. Instead of raising an
"unknown node type" compatibility issue, "attribute is already connected"
errors were raised for the unrecognized nodes.
When loading the graph, once all the nodes have been created and the
links resolved, the computed nodes' UID can be compared with those
stored in the graph.
If a mismatch is detected, the node that presents the UID conflict is
removed from the graph and replaced with a CompatibilityNode, set with
`UidConflict`.
Nodes that come from templates are ignored as no UID is stored in
templates. Similarly, nodes that are already Compatibility nodes are left
out as they do not have a UID.
This commit adds an option to the "load" method, "publishOutputs", that
determines whether "Publish" nodes in a template project file should be
ignored during the graph's creation.
If "publishOutputs=True", then the "Publish" nodes from the template will
be added to the graph. "Publish" nodes in a project file that is not
a template will not be affected by this and will always be added to the
graph, as any other node.
This allows to have templates that are compatible with meshroom_batch,
which requires a "Publish" node when the --output option is specified,
while not having unneeded nodes in the UI or unneeded operations:
when --output is specified in meshroom_batch, "publishOutputs=True",
otherwise it will be set to False so that the "Publish" nodes are not
executed needlessly.
Non-default internal attributes need to be written in the templates,
but the "internalInputs" entry in the dictionary should not be written
at all if all the internal attributes are set to their default values.
Add two internal attributes, "Comment" and "Invalid comment", in
a specific "Notes" tab, which will contain any further internal
attribute. Internal attributes exist for all nodes.
- "pyCompatibility.basestring" are replaced by standard Python3 "str"
- "Sequence" and "Iterable" from "collections" are now directly imported
with "collections.abc"
When loading a new graph while the opened one was locally computing nodes,
computations were automatically stopped to be able to load the new graph.
However, the computing chunks' status were not being updated before
the graphs were switched up. This meant that opening that previously
computing graph again would lead to a display in which nodes appeared to
be computing although there was no ongoing computations.
For every node, the only information that is kept when saving a
template are the non-default input attributes' values as well as the
node's position.
The unit test checking the templates' nodes is updated to stop taking
outputs into account.
